|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Effective ways to deal with DDoS attacks?
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: [email protected] [mailto:[email protected]]On Behalf Of > Mark Turpin > Sent: Thursday, May 02, 2002 10:05 AM > To: LeBlanc, Jason > Cc: [email protected] > 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.
|