RE: UUNet Offer New Protection Against DDoS

Mailman List Mirror (Read Only)
1

Oh, and I strip their communities, and apply no-export, on the first
term of my route map so the /32 does not get out. Of course my peer
facing policy requires specific communities to get out as well (belt and
suspenders).

This method works very well, and you do not have to give up length
restrictions or maintain two sets of customer prefix/access lists.

Jason

From: Lumenello, Jason
Sent: Wednesday, March 03, 2004 4:52 PM
To: 'Stephen J. Wilcox'; james
Cc: nanog@merit.edu
Subject: RE: UUNet Offer New Protection Against DDoS

I struggled with this, and came up with the following.

We basically use a standard route-map for all customers where the

first

term looks for the community. The customer also has a prefix-list on

their

neighbor statement allowing their blocks le /32. The following terms

(term

2 and above) in the route-map which do NOT look for the customer

discard

community, have a different standard/generic prefix-list evaluation

which

blocks cruft and permits 0.0.0.0/0 ge 8 le 24.

By doing this, I only accept a customer /32 from his dedicated

prefix-list

when it has the DOS discard community, otherwise I catch them with the

ge

8 le 24 in the following terms.

Jason Lumenello
IP Engineering
XO Communications

> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf

Of

> Stephen J. Wilcox
> Sent: Wednesday, March 03, 2004 3:48 PM
> To: james
> Cc: nanog@merit.edu
> Subject: Re: UUNet Offer New Protection Against DDoS
>
>
>
> I'm puzzled by one aspect on the implementation.. how to build your
> customer
> prefix filters.. that is, we have prefix-lists for prefix and

length.

> Therefore
> at present we can only accept a tagged route for a whole block.. not
good
> if the
> announcement is a /16 etc !
>
> Now, I could do as per the website at secsup.org which means we have

a

> route-map
> entry to match the community before the filtering .. but that would
allow
> the
> customer to null route any ip.
>
> What we need is one to allow them to announce any route including

more

2

We actually accept up to the customers aggregate. So if they have a /16, they can tag the whole /16. And we do not tag no-export. I saw some time ago on a list, and I think Bill Manning suggested it, that if you are getting bits for unused address space, to announce that address space (up to host specific) with the DDoS community string. That keeps the packets off of your link and thus you don’t get charged for them. The same can be done in reverse. We have a customer that is advertising their larger block with the DDoS community string, and then advertising the addresses they are actually using more specifically, so we blackhole everything less specific. These are a couple of applications that can be utilized if you don’t tag no-export and accept more than just /32’s within their address space. FWIW.

Also, we are utilizing Juniper’s DCU for tracebacks, which makes life MUCH easier when tracing an attack. :slight_smile: SNMP polling the DCU counters every few minutes is relatively fast and painless, and provides quick results.

Mark

Lumenello, Jason wrote: