Effective ways to deal with DDoS attacks?

Tue May 7 00:05:17 UTC 2002

In the referenced message, Steven W. Raymond said:
> 
> Stephen Griffin wrote:
> > > > 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.
> > >
> > 
> > not route-filtering. You use the irr-data to populate the exceptions
> > to strict-mode rpf. The irr is more of a flight-plan of possibility.
> > If the customer registers both sets of routes, and you use that
> > data to build the acl, then it doesn't matter what the customer announces
> > to you. Anything which fails the actual rpf check, will then be
> > passed through the acl to selectively override the rpf check.
> 
> What about existing customers that don't yet use the IRR?  Say you
> filter some BGP customers' route announcements using manually-built
> prefix-lists.  Have found that by using distribute-list in (instead of
> prefix-list), one can simply refer the distribute-list # in the strict
> uRPF configuration and accomplish both functions (route filtering +
> uRPF) easily with one ACL.

the IRR is merely an input vector. an alternate input vector is manual
entry. the output would be an acl or prefix-list. I don't believe the
format of a routing-use acl and an RPF-use acl is the same.

My recollection is that when used for route filtering you have:
access-list foo {permit|deny} ip network wildbits netmask wildbits

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

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.

> e.g.:
>  ip verify unicast source reachable-via rx 49
>  access-list 49 permit x.x.x.x 0.0.0.255
>  access-list 49 permit y.y.y.y 0.0.0.252
>  access-list 49 deny   any log
> 
> Prefix-lists are preferable over ACL-based distribute-lists.  Hey Cisco,
> please make uRPF configuration accept either distribute-lists or
> prefix-lists for the exception branching.  I realize that to IOS ACLs
> and prefix-lists are not the same, but the benefits of prefix-lists vs.
> distribute-lists are many.

How would uRPF respond to the following prefix-list?
ip prefix-list foo deny 0.0.0.0/0 ge 25
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.

> It sounds that a lot of networks rely on IRRs for building BGP customer
> route filters.  What method then is used for the cases where a customer
> is not already using the IRR?  Forced IRR registration before BGP
> turnup?  Or do you fallback on filtering by using prefix- or
> distribute-lists?

In my experience, providers that require IRR registration often allow
the customer to register their own objects, or offer to proxy-register
their customers objects. The preference generally being on the customer
registering their own objects, since it gives the customer the greatest
degree of control (especially should they change providers.)

> What's NANOG's opinion: assuming that uRPF is implemented on all
> customer interfaces, are there any legitimate purposes for a customer to
> forward packets with source IP addresses not currently routed by the
> transit provider towards the customer (either static or BGP)?

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. If the customer exhibits sufficient clue, and
demonstrates that they are doing RPF checks, I could definitely see
relaxing restrictions against them. If they are providing transit to
other BGP-speakers, this is probably the case. As in all things, you
know your customer best, so you know how loose you are willing to
make things, with the potential that it may make you look bad.