Jason described uRPF in Loose Check mode. This check to see if the source exist in the FIB. It cuts out some of the garbage while providing you a tool to do a remote-triggered (via BGP ) drop tool. Think of uRPF as a tool to do source based black hole filtering. uRPF Strict Mode is the original tool to help scale BCP38 filtering. This checks the FIB and the adjacency - insuring the source address of the packet coming into the interface has a patch to get back (hence checking the validity of the packet). This is a ISP-Customer edge tool. It _does_ work with multihomed customers for the most common multihoming configs. Just set that BGP weight on the customer's peering session. It is getting a little old, but check out the following: http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf http://www.cisco.com/public/cons/isp/security/
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Mark Turpin Sent: Thursday, May 02, 2002 10:05 AM To: LeBlanc, Jason Cc: nanog@merit.edu Subject: Re: Effective ways to deal with DDoS attacks?
On Thu, May 02, 2002 at 09:41:33AM -0700, LeBlanc, Jason wrote something like this: <snip>
There are some limitations as to where uRPF works, SONET only
on GSRs for
example (thanks Cisco). I believe it will work on 65xx (SUP1A and SUP2 I think) regardless of interface type. Impact should be minimal, as it simply does a lookup in the CEF table, if the route isn't there it discards. Keep in mind this is NOT a filter, so the impact is much less, it is simply a CEF lookup, much more efficient than a filter. This will get rid of a HUGE percentage of spoofed packets that hit your network, and would also work pretty well if you are the source of an attack. There is some debate as to whether you must not have ANY RFC1918 space for this to work. We're trying to find this out (not a priority), if I get info I'll post.
hmm... either you're being extremely vague, or you misunderstand how RPF works. http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/12 1cgcr/secur_c/scprt5/scdrpf.htm
Its not checking cef to see if a route is there.... its making sure that a packet received on an interface came in on an interface that is the best return path to reach that packet. thereby explaining why multihomed customers will get borked in the event of using rpf. enjoy, -mark -- Support your local medical examiner--die strangely.