On 12-sep-2006, at 11:25, Pekka Savola wrote:
Ingress filtering is definitely to be recommended, and uRPF filtering certainly does have its uses, but, at least in the current state of the Internet, they are insufficient as a protection for the routing infrastructure.
If this refers to ensuring that your own routing infrastructure is secure, I argue this can already be achieved by appropriate edge filtering at your own borders.
All of this assumes that it's a good idea to authenticate correspondents in interactions such as routing protocols solely based on the IP address they present. The fact that this "authentication" is trivially subverted by source address spoofing which is something that's easy to do in today's internet, suggests to me that this is a fundamentally broken approach.
Even if we assume that all ISPs do source address validation on packets that they receive from their customers, there are many ways to work around this. You'd basically have to require SEND for ALL subnets connected to the internet, but since this is something that's handled locally there is no way an ISP or a real authority would be able to know for sure this is done correctly. And obviously it's possible to subvert ISP infrastructure. There are so many ISPs that this alone is enough of a risk to invalidate the assumption that source addresses can be trusted.
On the other hand, if this refers to generic routing infrastructure security, it isn't obvious how a source address validation proposal would significantly improve the current situation.
Routing protocols and the like are generally run within administrative boundaries where it's possible to filter out unwanted packets coming from elsewhere so source address spoofing shouldn't be an issue today.
The exception is BGP, which is used to talk to external networks. Although there are some weak areas in implementations here that allow an attacker to run up CPU usage on most routers, techniques such as the BGP TCP MD5 password and GTSM should be sufficient to thwart spoofing attacks.
b) uRPF does not work well in places where asymmetric routing happens. This constitutes a large part of the Internet
This is a common misconception. Maybe you haven't seen RFC 3704 (BCP 84) which describes how to do it. For more detail, also look at draft-savola-bcp84-urpf-experiences-01.txt.
Current uRPF allows you to reject traffic that doesn't come from a single known "good" source, which isn't useful if legitimate traffic can come from more than one source (= interface), which is the most common situation in larger networks for non-customer sources. An alternative is "loose" uRPF which only rejects packets witch sources that don't appear in the routing table, which doesn't apply to attacks where the address of a working host is spoofed. I understand that there is work underway to allow uRPF with multiple sources but we'll have to see how well that works in practice. (One issue would be that it requires additional FIBs that could grow quite large.)
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
