Effective ways to deal with DDoS attacks?

In the referenced message, Christopher L. Morrow said:

> In the referenced message, Iljitsch van Beijnum said:
> > 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 :frowning: especially since some of these are our worst
abusers :frowning:

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

In the referenced message, Christopher L. Morrow said:
> > In the referenced message, Iljitsch van Beijnum said:
> > > 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 :frowning: especially since some of these are our worst
> abusers :frowning:
>
> -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.