<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
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.<br>
<br>
<br>
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.<br>
<br>
<br>
Mark<br>
<br>
<br>
Lumenello, Jason wrote:<br>
<blockquote type="cite"
cite="mid0A6515AF81DFD84582280B1E2666FEAE024BDFB7@ILCHICVEXC006.mail.inthosts.net">
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: Lumenello, Jason
Sent: Wednesday, March 03, 2004 4:52 PM
To: 'Stephen J. Wilcox'; james
Cc: <a class="moz-txt-link-abbreviated" href="mailto:nanog@merit.edu">nanog@merit.edu</a>
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
</pre>
</blockquote>
<pre wrap=""><!---->first
</pre>
<blockquote type="cite">
<pre wrap="">term looks for the community. The customer also has a prefix-list on
</pre>
</blockquote>
<pre wrap=""><!---->their
</pre>
<blockquote type="cite">
<pre wrap="">neighbor statement allowing their blocks le /32. The following terms
</pre>
</blockquote>
<pre wrap=""><!---->(term
</pre>
<blockquote type="cite">
<pre wrap="">2 and above) in the route-map which do NOT look for the customer
</pre>
</blockquote>
<pre wrap=""><!---->discard
</pre>
<blockquote type="cite">
<pre wrap="">community, have a different standard/generic prefix-list evaluation
</pre>
</blockquote>
<pre wrap=""><!---->which
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->prefix-list
</pre>
<blockquote type="cite">
<pre wrap="">when it has the DOS discard community, otherwise I catch them with the
</pre>
</blockquote>
<pre wrap=""><!---->ge
</pre>
<blockquote type="cite">
<pre wrap="">8 le 24 in the following terms.
Jason Lumenello
IP Engineering
XO Communications
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-nanog@merit.edu">owner-nanog@merit.edu</a> [<a class="moz-txt-link-freetext" href="mailto:owner-nanog@merit.edu">mailto:owner-nanog@merit.edu</a>] On Behalf
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->Of
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Stephen J. Wilcox
Sent: Wednesday, March 03, 2004 3:48 PM
To: james
Cc: <a class="moz-txt-link-abbreviated" href="mailto:nanog@merit.edu">nanog@merit.edu</a>
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
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->length.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Therefore
at present we can only accept a tagged route for a whole block.. not
</pre>
</blockquote>
<pre wrap="">good
</pre>
<blockquote type="cite">
<pre wrap="">if the
announcement is a /16 etc !
Now, I could do as per the website at secsup.org which means we have
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->a
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">route-map
entry to match the community before the filtering .. but that would
</pre>
</blockquote>
<pre wrap="">allow
</pre>
<blockquote type="cite">
<pre wrap="">the
customer to null route any ip.
What we need is one to allow them to announce any route including
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->more
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">specifics of the prefix list - how are folks doing this?
Steve
On Wed, 3 Mar 2004, james wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:jamesh@cybermesa.com">jamesh@cybermesa.com</a>
At the Santa Fe Office: Internet at Cyber Mesa
Store hours: 9-6 Monday through Friday
505-988-9200 SIP:1(747)669-1965
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>