Effective ways to deal with DDoS attacks?

In the referenced message, Steven W. Raymond said:

Stephen Griffin wrote:
> where for RPF, or traditional traffic filter is
> access-list foo {permit|deny} ip source wildbits dest wildbits

Hrrmm, since uRPF checks only the source address, the "standard ACL"
seems most appropriate to me.

true, although I'ld still use extended acl or prefix-list for

> I guess you could use a "standard acl" however I wouldn't recommend
> it for filtering routes. Even if you could use prefix-lists for
> uRPF, you would want to match more-specifics, whereas generally you
> don't want to match (unbounded) more-specifics on route filters.
> RtConfig can generate either style from IRR data. It isn't too hard
> to generate either style from a manual list either.

It certainly wouldn't hurt to have both a prefix-list for route
filtering and ACL for the uRPF exceptions. It's just that I am lazy and
thought it would be "neat" for one list to fulfill both requirements,
since it is essentially the same input data in two different formats.

I prefer to think of it as optimal, rather than lazy. :slight_smile:

> How would uRPF respond to the following prefix-list?
> ip prefix-list foo deny ge 25

The implicit deny @ the end of the prefix-list seems a better way to
accomplish the same result as above (deny anything longer than /24). In
other words, instead use a prefix-list containing an explicit list of
the permitted networks, rather than pattern matching to deny what bad
stuff might be announced.

I agree that explicit matches are good. My concern is when you build
in safeguards for a customer-input stream (any automated system not
requiring clued review).

> ip prefix-list foo permit
> ip prefix-list foo permit le 16
> Would it accept all sources within What about
> I guess it could ignore "ge" and "le". Although how it would resolve
> conflicts is an unknown. It might try to correspond to actual prefixes, but
> that seems unlikely.

To restate above, just permit explicit networks customer plans to
announce & source traffic from. Don't wildcard in customer prefix-lists
inbound. Every source packet address received "should" be covered by
his prefix-list (even if not the FIB entry best path choice). Every
other source IP address packet is dropped. In fantasy land, uRPF
"could" confirm that each packet source address matches at least one of
the networks in the prefix-list.

Well, I could see having a safety-net of denies at the top built-in,
since you wouldn't necessarily want your customer to register things like
rfc1918, your aggregates, or long prefixes. This would lead to optimzing
with deny ge 25 (or whatever you consider too long).

I agree that it would be nice, but I don't see it happening.

> Yes, I think there are definitely legitimate reasons why a customer
> would source traffic from prefixes where the actively selected route
> does not point back at the interface. This is why acl exceptions and
> the loose match came to be. With customers, the acl exception is
> probably appropriate.

Would you agree it is indeed necessary for every BGP customer-facing
interface to implement exception checking with strict uRPF?
Customer-set communities can change local pref easily enough to break
strict uRPF lacking exception checking. But with the ACL permitting
exceptions based upon every possible network customer may be sourcing
from, the entry doesn't even have to be best path in the FIB to permit
the packet. Customer needed only to have gotten the ISP to include it
in his prefix-list at some point.

It may not be necessary, but it is (imho) advisable, for the
reasons you mention. Other, general cases would be multi-homed static
customers, where you may statically route an aggregate to all locations,
and route smaller chunks to individual locations. Others would be
specific cases, based upon combined customer/provider needs.

If a BGP customer was providing transit to others, and actively
doing RPF checks themselves (and you trust them) I could see just
doing loose checks against them.