Re: Effective ways to deal with DDoS attacks?

[Stephen Griffin <stephen.griffin () rcn com>]

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.

If they don't do BGP in the above scenario, work out some other method
to communicate legitimate traffic sources. I know this is fairly common
pratice for UUNet insofar as routing filters with per-customer filters,
due to UUNet's opposition to the IRR.

I wish UU actually did IRR-based filters, to cut out the UU-specific
annoyance I presently deal with, since the remainder of the folks I deal
with handle the IRR.

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.