RE: UUNet Offer New Protection Against DDoS

Mailman List Mirror (Read Only)
1

XO set up a similar customer community last year for our customers to
trigger their own black hole at our edge. There is no such thing as an
original idea. :slight_smile: This "promised response" probably means if you press 3
on your phone, you will get a CSR to open a ticket within 15 minutes.
Sounds like nice marketing.

Jason

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

Of

Stephen Perciballi
Sent: Wednesday, March 03, 2004 12:25 PM
To: Andy Ellifson
Cc: nanog@merit.edu
Subject: Re: UUNet Offer New Protection Against DDoS

To the best of my knowledge, MCI/UUNET ~was~ the first to implement

this.

I've
been using it for well over a year now.

The community is 701:9999. Any route you tag with that community gets
dropped
accross the entire 701 edge. Feel free to contact support and tell

them

you
want to setup the blackhole community if you are having any troubles.

[Wed, Mar 03, 2004 at 08:34:00AM -0800]
Andy Ellifson Inscribed these words...

>
> When I first saw this post I thought that MCI/UU.Net implemented

some

DDOS
> BGP community strings like CW implemented a month ago. If only all

of

my
> upstreams would have this type of BGP Community string my life would

be

made
> easier. Here is the customer release letter from from CW dated

Januray

23,
> 2004:
>
> Dear Customer,
>
> If you have received this email, you are either a direct customer of
> AS3561, (i.e. you have registered a route object for a customer of
AS3561),
> or are listed in the maintainer of a customer of AS3561.
>
> AS3561 has implemented a blackhole/DDoS community string based

solution

to
> aid customers in the mitigation of DoS attacks. If you are currently
running
> BGP with us, you will be able to use this feature.
>
> If you advertise a prefix (route) to us with the community string
> 3561:666, we will NULL route or 'blackhole' all traffic destined to

that

> prefix. The prefixes accepted are based on the current prefix-list
generated
> for you. Instead of doing exact match filtering, we will accept any
prefix
> (more "specific") within your address block(s). e.g. if you have
> 192.168.0.0/16 registered, we will accept 192.168.0.0/16 upto /32 as
long as
> the 3561:666 community string is attached.
>
> Please ensure you are configured to send community strings and
understand
> the impact of errant advertisements. Diligence should be used when
> administrating this feature. Once the prefix is received and

propagated

> within AS3561, all traffic destined to the prefix will be discarded

and

the
> blackholing of traffic will continue as long as DDoS community

string is

> being advertised. Neither Cable & Wireless nor AS3561 will be held
liable
> or responsible for customers who errantly advertise prefixes with

the

> blackhole community string.
>
> If you wish to utilize this feature, you can verify our acceptance

of

the
> advertised prefix by querying the AS3561 route server located at
> http://lg.cw.net.
>
> Please remember, we require you to complete a priority one incident
report
> at http://www.security.cw.net (Report an Incident) and include

details

of the
>
> attack. An email describing further details of the attack can be

sent to

> security@cw.net, please include the incident report number in the
subject to
> assist in the tracking and documentation of the incident. This will
ensure
> the attack is properly administrated handled by our Security and

Legal

> Groups.
>
>
>
> > Hello Nanogers!
> >
> > I'm happy to see this, and I hope C&W, Verio, and Level3 ..etc

will do

the
> > same!
> >
> > MCI/WorldCom Monday unveiled a new service level agreement (SLA)

to

2

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

3

Global Crossing has this, already in production.

Idem, Teleglobe,

mh

4

So maybe a guy with customer connections to each of these networks will offer a BGP-redirector whereby you can send it 1 prefix and it will send it to all the customer networks.

Boy. Is that abusable. eesh.

Deepak Jain
AiNET

james wrote:

5

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

6

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 !

MCI handles this by only filtering on prefix, not length. Well, allowing you to only announce up to your length, not shorter, but longer is allowed.

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?

It's not hard. I think the old UUNET just used standard ACLs (1->99). :slight_smile: But with prefix filters, you can set gt & lt prefix lengths on the filters trivially.

Of course, your customers can then deaggregate to their hearts content. If they do, you should hunt them down and LART them. But it is useful for some things, especially when combined with no_export, the black-hole communities, or other communities.

7

> 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 !

MCI handles this by only filtering on prefix, not length. Well,
allowing you to only announce up to your length, not shorter, but
longer is allowed.

Hmm not keen, have moved acl->prefix w/len to stop folks from doing this, in
addition we have an extra filter which overrides anything that would deny
anything longer than a /24. I'm not keen to change that.. LART appears to have
little or no effect with my customers, preemption appears to be the only way!

Steve

8

What's wrong with letting customers announce /32s into your network, as long as you do not pass it to anyone else (including other customers)?

Here is what I did (when I had a network =) :
   * Prefix filter customers in, allowing more specifics
   * Filter > /24s & Bogons out to customers
   * Bogon & /24 filter peers in
   * Bogon, /24, and cust-only community filter peers out

Theoretically, the Bogon out filters are irrelevant, since your table should be clean from the inbound filters, but I like "belt and suspenders". (Plus one day I leaked a slew of 10-net from a NOC test LAN and hit one of the Merit instability mailing lists. Burned once, twice shy. :slight_smile:

9

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:

10

[..] set up a similar customer community last year for our customers to

[snip a whole bunch of "we've been doing this for some time" posts]

Yeah - lots of ISPs have been advertising blackhole communities for over a year now. However, UUNET did say they'd got an SLA set up for this.

So, presumably, now there's an implication if you suffer any downtime caused by a DoS, beyond what the SLA specifies.

11

[..] set up a similar customer community last year for our
customers to

[snip a whole bunch of "we've been doing this for some time"
posts]

Yeah - lots of ISPs have been advertising blackhole communities
for over a year now. However, UUNET did say they'd got an SLA
set up for this.

So, presumably, now there's an implication if you suffer any
downtime caused by a DoS, beyond what the SLA specifies.

i think the north american idiom is putting your money where your
mouth is.

randy, just a bozo on this bus

12

Randy Bush [3/4/2004 6:40 AM] :

i think the north american idiom is putting your money where your
mouth is.

Thank you. That's exactly what I was driving at.

Hmm.. one of the people in that "we've been doing this too" thread was XO. Do I take it then that XO provides for DDoS downtime in its SLA?

13

correct me if i am wrong, but uunet's sla extends to response time - the
efficacy of the response is not guaranteed, yes? hence, it is not downtime
that is compensated for, but rather unavailability of support.

paul

14

Theoretically nothing. However, you do need to watch
out, because there are a certain percentage of
clue-impaired folks who believe that {traffic
engineering | load-balancing | whatever mojo they're
calling it now} can be best accomplished by announcing
every /32 out of their legitimate /16 block.

While there are certainly vendors who can take an
extra 60,000 routes with impunity, there is a lot of
gear out there which can't.

Moral: if you let your customers advertise more
specifics to you, use maximum-prefix filters...

-David Barak-
-Fully RFC 1925 Compliant-

15

in our case, we do the following setup:

  1. allow up to /32 within customer's prefix(es)
  2. check for 27552:666 (null comm), if matched, set to null'd nexthop
  3. now match any prefixes that are longer than /22 on 0.0.0.0/1,
     that are longer than /22 on 128.0.0.0/2, that are longer than /24
     on 192.0.0.0/3. if any of these longer prefixes are matched, tag
     them with 27552:31337 (which is our equivalent of no-export).

       If a customer has a legitimate reason to send a /24 within say,
           0.0.0.0/1, then we can always override it by adding a deny rule to
     the matching prefix-list used by the route-map.

  4. finally, add maximum-prefix limit to 500

I'll be more than glad to provide config template if anyone is interested. Also
have ipv6 version of it as well if interested.

-J