Effective ways to deal with DDoS attacks?

Stephen Griffin stephen.griffin at rcn.com
Mon May 6 03:18:16 UTC 2002


In the referenced message, Christopher L. Morrow said:
> 
> On Sun, 5 May 2002, Stephen Griffin wrote:
> 
> > In the referenced message, Christopher L. Morrow said:
> > > I was hoping someone else might mention this, BUT what about the case of
> > > customers providing transit for outbound but not inbound traffic for their
> > > customers? We have many, many cases of customers that are 'default
> > > routing' for their customers that get inbound traffic down alternate
> > > customers or peers or wherever... uRPF seems like a not so good solution
> > > for these instances :( especially since some of these are our worst
> > > abusers :(
> > >
> > > -Chris
> >
> > Tell them they will need to register their routes in the IRR, even if they
> > don't necessarily advertise all or any of them. Build your exceptions
> > based upon the irr, as for all bgp-speaking customers.
> 
> I'm not really sure how one customer IRR filtered (one example customer)
> is going to matter here, this is the equivalent of a customer connected
> via 2 t1's one to AT&T and one to UUNET, not announcing EVER his ATT
> routes to UU nor his UU routes to ATT. How would you know what traffic to
> expect from this customer at any point in time? He could just push all
> traffic over his ATT link outbound and only pull in UU on UU and ATT on
> ATT. Route filters aren't really a solution to this problem.

not route-filtering. You use the irr-data to populate the exceptions
to strict-mode rpf. The irr is more of a flight-plan of possibility.
If the customer registers both sets of routes, and you use that
data to build the acl, then it doesn't matter what the customer announces
to you. Anything which fails the actual rpf check, will then be
passed through the acl to selectively override the rpf check.

> >
> > ---rant removed---
> >
> > If there was some particular situation where neither IRR-based
> > exceptions, or customer-specific exceptions just couldn't work, then
> > do what you _can_ do. loose RPF checks based upon matching _any_ prefix, and
> > interface filter inbound and outbound on known bogons. this, at least,
> > constrains the area of ipv4 which can be used for spoofing, which
> > is better than where you started.
> >
> 
> Access-lists on interfaces?? This does not scale, puts my network at risk
> and will certainly break some 'legitimate' traffic. Additionally, as I've
> said before, spoofed attacks don't really bother me, they are more easily
> stopped and tracked.

The object is to keep the interface acls short, and use the rpf
logic to get rid of as much as you can. Rather than using interface
acls themselves to emulate a strict rpf check. If you filter only
known bogons (RFC1918, as an obvious example) I don't see what will be
broken, except that which was broken to begin with.

Along with things like compiled access-lists, the impact can be kept
quite small. You can even add in performance circuit-breakers to speed
things up. For example, allowing established TCP sessions, will (without
even compiling the acls) allow a first-match circuit breaker on a large
percentage of traffic.

While spoofed traffic may not be a concern for as701, I know I, at least,
would prefer not to get spoofed traffic via that network. I'm sure
other paying customers probably feel similarly.

I don't see how access-lists on edge interfaces don't scale, if they
are all the same short anti-bogon acl. Junipers should be able to handle
this ok, Cisco Engine3 (Edge) should be able to handle fine for GSR.
I thought AS701 was moving towards vendor-J on the edge, as it was, but
maybe I'm misremembering.

Even if it isn't possible for as701 to rpf check/filter in every
possible scenario, whatever _is_ possible would be appreciated
(by me at least).

"Progress, not perfection" as the saying goes...




More information about the NANOG mailing list