different flavours of uRPF [RE: register.com down sev0?]
Barry Greene (bgreene)
bgreene at cisco.com
Fri Oct 27 20:57:11 UTC 2006
> > > It was possible to implement BCP38 before the router
> vendors came up
> > > with uRPF.
> > Further, uRPF is frequently a very inefficient means of
> > 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
Now, are there other ways of doing BCP38 - yes lots:
- 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
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.
More information about the NANOG