Re: Effective ways to deal with DDoS attacks?

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

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

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

> > How would uRPF respond to the following prefix-list?
> > ip prefix-list foo deny 0.0.0.0/0 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 1.2.3.0/24
> > ip prefix-list foo permit 0.0.0.0/0 le 16
> >
> > Would it accept all sources within 1.2.3.0/24? What about 10.0.0.0/8?
> > 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 0.0.0.0/0 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.