RE: [spoofing-tf] Source Address Validation Architecture (SAVA), BOF proposal @ IETF

["Barry Greene \(bgreene\)" bgreene@localhost]

> In the MIT Spoofer Project, the authors found that 
> approximately one-quarter of the observed addresses, 
> netblocks and autonomous systems
> (AS) permit full or partial spoofing.  And they suggested 
> that a large portion of the Internet is vulnerable to 
> spoofing. Concerted attacks employing spoofing remain a 
> serious concern.

Serious concern to whom? I'm not seeing demonstration that it is a
concern to people who operate backbones. All we needed was a couple of
backbones in 2001/2002 to deploy uRPF Strict and ACL based BCP 38 to
shift the miscreants to primarily use valid IP addresses. 

So this seems like a academic exercise vs an operation exercise.
 

> The current method of avoiding packets with spoofed source 
> addresses entering and being propagated on the Internet 
> relies on two methods:

This list is does not match reality. 

First, uRPF Strict Mode _is_ a operationally low overhead way of
deploying BCP38. It is not "an equivalent method" to BCP38. It is a tool
to deploy BCP38.

Second, The #1 BCP 38 tool today is Radius ACLs. More ports are
protected with Radius ACLs than any other BCP38 technique.

Third, you are ignoring the other BCP 38 tool - DHCP Lease Query, IP
Source Verify, etc. Please look at documents like
http://www.cablemodem.com/downloads/specs/CM-SP-SECv3.0-I01-060804.pdf
DOCSIS 3.0 Specifications which cover Source Address Validation at L2
and L3.

 
> a)       Ingress Filtering as per BCP0038 [RFC2827].  This method 
> requires    ISPs and organizations at the edge to apply 
> filters limiting 
> the    source addresses allowed on incoming packets to those    
> specifically allowed in the stub networks.  If BCP0038 were   
>  followed 
> at all ingress points to the Internet, then there would    be 
> no spoofed 
> packets on the Internet.
> 
> b)       Unicast Reverse Path Forwarding (uRPF) filtering.  This is a 
> feature available on routers that can be used to block 
> incoming packets if, in the case a packet were constructed 
> with the incoming packet's source address as its destination 
> address, the constructed packet would NOT be routed back 
> along the ingress link for the incoming packet.
> 
> 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.

I do not understand this "protection for the routing infrastructure." If
this this the goal (protecting routing infrastructure), then the first
thing you need to do is to re-color (remarking the precedence and DSCP
values). The biggest threat to the infrastructure is NOT spoofed IP
source addresses. It is traffic heading to the router marked as control
plane and management plane traffic.


> a)       Ingress filtering works, but it only works if all, 
> or at least 
> the vast majority of ingress points apply ingress filtering.  
> As can be seen in the Internet today, even when 25% of the 
> Internet is unsecured, those elements that want access to 
> "spoofable" connections simply move their connection to 
> unsecured attachment points.

Again, not true. Look at the studies for the sources of DOS attacks.
Spoofed source addresses are not currently (nor have they been) the core
contributor. 

 
> b)       uRPF does not work well in places where asymmetric routing 
> happens.  This constitutes a large part of the Internet


Not true. uRPF Strict Mode together with RFC1998++ covers 80% - 95% of
your lease line customer base. The deployments in major carriers have
validated these figures for uRPF Strict + RFC1998++ over and over again.

 
> There are many proposed  mechanisms related to the validation 
> of source IP addresses, but few of them are widely deployed 
> by the current Internet. While it is possibly too late to 
> introduce adequate source address checking in the current 
> IPv4-based Internet, the development of the next generation 
> Internet using IPv6 gives us the opportunity to implement an 
> architecture for effective source address checking.


The same factors that impeded BCP38 deployment on IPv4 are going to be
the same with IPv6. It is not about technology, it is about time and
money inside the SP to deploy the capability. If there isn't new revenue
to pay for the OPEX time, then the 'security widget' will not get turned
on.