Re: Effective ways to deal with DDoS attacks?

From: Richard A Steenbergen (no email)
Date: Thu May 02 2002 - 13:22:48 EDT

On Thu, May 02, 2002 at 12:04:35PM -0500, Mark Turpin wrote:
> 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.
> 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.

RPF works by matching the source address of the packet against the CEF
table, in addition to the normal match against the destination address.
There are multiple modes of operation, ranging from "is there a route
for the source address to the specific interface it come in on" to "is
there a route to the source address for ANY interface on the box" The
former is used to stop your single homed customers from spoofing wildly
into the internet. The latter is usually used as a stopgap measure to
limit the number of spoofed packets coming into your network via transits.
The number you'd expect to filter is 50%, assuming the attacker in
question is using an evenly distributing random() function.

Richard A Steenbergen <>
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)

Hosted Email Solutions

Invaluement Anti-Spam DNSBLs

Powered By FreeBSD   Powered By FreeBSD