UUNet Offer New Protection Against DDoS

Wed Mar 3 22:45:27 UTC 2004

We still implement exact match prefix filtering, but also generate a 
second "aggregated" prefix-list for customers to match more specifics.  
If a prefix matches 3561:666 _and_ falls within the DDoS/aggregated 
prefix-list, we accept it and blackhole it.  If a customer announces the 
more specific without the community, we won't accept it.  (No flame wars 
about exact match filtering please).  Yes, that means we maintain two 
prefix-lists for each customer. 

uRPF is another matter.  We use policies for prefix-lists on Junipers 
and prefix-lists on Cisco's, which means that if we want to do strict 
uRPF for customers we have to generate a third prefix-list/acl?  <sigh>

Regards,
    Mark Kasten
    C&W^H^H^H^Savvis

.

Stephen J. Wilcox wrote:

>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 
>specifics of the prefix list - how are folks doing this?
>
>Steve
>
>On Wed, 3 Mar 2004, james wrote:
>
>  
>
>>Global Crossing has this, already in production. 
>>I was on the phone with Qwest yesterday & this was one
>>of this things I asked about. Qwest indicated they are
>>going to deploy this shortly. (i.e., send routes tagged with
>>a community which they will set to null)
>>
>>
>>James Edwards
>>Routing and Security
>>jamesh at cybermesa.com
>>At the Santa Fe Office: Internet at Cyber Mesa
>>Store hours: 9-6 Monday through Friday
>>505-988-9200 SIP:1(747)669-1965
>>
>>
>>    
>>
>
>  
>