Re: Effective ways to deal with DDoS attacks?

["Christopher L. Morrow" <chris () UU NET>]

On Sun, 5 May 2002, Stephen Griffin wrote:

> In the referenced message, Christopher L. Morrow said:
> > On Sat, 4 May 2002, Stephen Griffin wrote:
> > > In the referenced message, Iljitsch van Beijnum said:
> > > > On Fri, 3 May 2002, Stephen Griffin wrote:
> > > > For multihomed customers, these sets of prefixes should be identical, just
> > > > like with single homed customers. The only time when those sets of
> > > > prefixes is NOT the same is for a backup connection. But if a connection
> > > > is a pure backup for incoming traffic, it's reasonable to assume it's a
> > > > pure backup for outgoing traffic as well, so as long as the backup is
> > > > dormant, you don't see any traffic so no uRPF problems.
> > >
> > > Not always the case, customer behaviour can not be accurately modeled.
> >
> > 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.

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