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(_dot_)com
Amaranth Networks Inc. http://www.amaranthnetworks.com