Phil Karn wrote:
>
> >tomorrow demands. And, agreed, bogus source IPs _does_ at present time
> >look like nothing but the devils work. But in, say, 10 years a new flashy
> >techology could be requiring that you have the ability to stamp packets with
> >other IPs than your own. Unfortunately, back in year 2000, somebody put in
>
> There already are some perfectly legitimate reasons to send packets
> with "alien" IP source addresses. Mobile IP is the best example, but
> various virtual private networking schemes also do this. For example,
> I have a VPN set up over my cable modem so I can have a block of
> static IP addresses for my home network. I had to do some work to
> evade the $#@!! source IP address ingress filtering in my cable
> network. I do it by tunneling the upstream packets through a machine
> at work.
Yes, and you chose the CORRECT solution. Think about it... VPN in most
cases also means encryption, and at that probably back to a central
site.
Gabriel wrote RFC 2344 for reverse tunnels, and it does essentially what
you did.
>
> Being forced to tunnel not only increases the size of each packet, but
> also entails suboptimum routing and reliance on yet more network
> elements. I use the new Linux policy routing mechanisms to tunnel
> only those packets that have to be tunneled, which helps. But it would
> sure be nice if I didn't have to tunnel my outbound packets at all.
Sorry. You're at the point where technology meets policy. Fact is, your
host identifier in the IP stack is the source IP address. Enforcing the
validity of that identifier has become necessary.
>
> Source address ingress filtering is one of those ideas that seems like
> a good one when you first think about it, but it just doesn't pan out.
> It interferes with some perfectly legitimate activities, it doesn't
> really stop the bad guys, and it deflects attention away from the real
> solutions.
The case for "legitimate use" of source spoofing has not been
sufficiently made. Operational reality is such that it's not
sustainable.
--
-----------------------------------------------------------------
Daniel Senie [EMAIL PROTECTED]
Amaranth Networks Inc. http://www.amaranthnetworks.com
