Effective ways to deal with DDoS attacks?

Mon May 6 05:39:05 UTC 2002

On Sun, 5 May 2002, Stephen Griffin wrote:

> 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.
>

Perhaps I'm confused (which is likely in this case) but if the traffic is
being transitted by 2 or 3 as's before it gets to me through 'default'
routing how am I to know it was coming?

> > >
> > > ---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.
>

Any access-list of any length severly impacts edge performance, if it
works at all, and puts the network at risk. This is not dogma, this is
proven time and again on a large operational network. They are never
placed for 'permanent' reasons. It is expected that customers will
properly handle their traffic... yes they don't always do it, but it is
expected.

> 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.
>

Compiled access lists? Wow, you are a braver man than I. My experience
with them has been 'sub optimal' to say the least. Where known traffic
flows and known patterns, with reasonable route table sizes,  are
available compiled acls work fine. The internet is none of these :(

> 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.

How large is your edge? Do you have routers with +900 interfaces?
Management of acls on interfaces, even if the gear were to support it,
isn't feasible, nor is just dropping in an E3 card a solution, acls don't
work reliably on E3 cards :( E2 cards are just as fun :( the really fun
part comes with the 'limited' route table incurred with PSA acls on E2
cards!

Anyway, the point here is acls on interfaces are not a solution at the
backbone level. At the individual provider level its sure a nice thing,
and likely it should be done, but not on the backbone.

As to randomly filtering 1918 address space, at your edge that's fine, I'm
not sure breaking things for those places that use 1918 internally and
thus originate 'legitimate' 1918 address sources for 'error conditions' is
a great plan. (please see last 16 flame-fests on martian filtering)

-Chris