Re: UUNet Offer New Protection Against DDoS

[Mark Kasten <mark () cw net>]

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.  :-)  SNMP polling the DCU counters 
every few minutes is relatively fast and painless, and provides quick 
results.


Mark


Lumenello, Jason wrote:

> 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
>
>  
>
> > -----Original Message-----
> > 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
> >
> >    
> >
> > > -----Original Message-----
> > > 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
>  
>
> > > 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 () 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
> > > >
> > > >
> > > >        
>
>