RE: different flavours of uRPF [RE: register.com down sev0?]

["Barry Greene (bgreene)" <bgreene () cisco com>]

> > > It was possible to implement BCP38 before the router 
> vendors came up 
> > > with uRPF.
> >
> > Further, uRPF is frequently a very inefficient means of 
> implementing 
> > BCP 38.  Consider that you're going to either compare the source 
> > address against a table of 200,000 routes or against a handful of 
> > prefixes that you've statically configured in an ACL.
>
> Isn't that only a problem if you want to run a loose mode uRPF?  
> Given that loose mode uRPF isn't very useful in most places 
> where you'd like to do ingress filtering, this doesn't seem 
> like a big issue..

Loose mode is a RTBH Reaction tool - not BCP 38. Don't use a screw
driver to hammer a nail. 

> BTW, I still keep wondering why Cisco hasn't implemented 
> something like Juniper's feasible-path strict uRPF.  Works 
> quite well with multihomed and asymmetric routing as well -- 
> no need to fiddle with communities, BGP weights etc. to 
> ensure symmetry.

Wow - I'm going to need to dust off the tutorial materials on how uRPF
and using the FIB as a policy enforcement tool works. 

Does uRPF need to scan through the entire FIB? Saying this is saying
routers look through the entire FIB table to find the next hop? What
ever happened to TRIE techniques? uRPF's look up is at the same speed as
the forwarding look up. In fact, in many implementations, the
"forwarding lookup" gets the source and destination address values from
the FIB.

Now, are there other ways of doing BCP38 - yes lots:

- ACLs
- Radius loaded ACLs
- uRPF Strict-Feasible-VRF modes
- IP Source Verify
- DHCP Lease Query
- NAT on the home CPE

Why hasn't Cisco done uRPF Feasible path? Cause until recently, our CEF
structures would not allow for feasible/alternate paths. If the FIB is
your policy table, then _what_ you are limited to the capabilities of
that FIB when using it to police the packet. Cisco has that now, so
"feasible path" is just a matter of time to work through the coding
queues.

What I'm shaking my head over with this whole dialog is the 1990's
thinking. BCP38 is out of date. Anyone who works, mitigates, analysis,
and studies attack vectors on network systems know that checking the IP
source address is one of many "Anti-Spoof" checks you need to do on the
packet. With Ethernet and Cable, you need to do a MAC check. With all
mediums you need to check the Prec/DSCP value (porn at Prec 6 does
wonders for the routing protocols when there is congestion in the path).
Then there is TTL values, Fragments, and other values which need to be
policed on the edge. This is why uRPF - while helpful - is not the
primary BCP38 tool people should be considering on the edge.