![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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 $# at !! 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 dts at senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.