>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.
Yes, I often use encryption, but not to a central site. Generally I
apply it at the application layer (SSH/SSL) so the peer is whoever I happen
to be talking to. However, this is irrelevant to the issue of upstream
IP address filtering.
>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.
This makes no sense at all. I've shown both that there are legitimate
reasons to send packets that the ISP might consider "alien", and also
how easy it is to circumvent ingress filtering if you are so motivated.
By the way, ingress filtering breaks things other than Mobile IP.
Consider the DirecPC service, which gives you a one-way (forward)
satellite channel at 400 kb/s. Your return link is via local dialup
service provider. If the local ISP (or its upstream provider) does
source filtering, you can't send your perfectly legitimate packets
into the network over that ISP without tunneling them all through
DirecPC's own network connection, which may be on the other side of
the continent.
>The case for "legitimate use" of source spoofing has not been
>sufficiently made. Operational reality is such that it's not
>sustainable.
The operational reality is that you'll never be able to implement
ingress filtering widely enough to provide much of a benefit. Even if
you do, it'll be circumventable (consider the many Linux and Unix
boxes out there that support IP-in-IP tunneling). And the energy you
spend doing so will be energy that could have been better spent
implementing other mechanisms to defend the Internet against MS-DOS
(multiple source denial of service) attacks.
Phil
