![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
>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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.