North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Effective ways to deal with DDoS attacks?

  • From: Steven W. Raymond
  • Date: Mon May 06 21:01:14 2002

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.

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

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

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

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