RE: UUNet Offer New Protection Against DDoS
-----Original Message----- 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
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
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
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
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
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
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. :) 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 this. them that propagated the details
of the
attack. An email describing further details of the attack can be
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.
--- John Obi <dalnetuzer@yahoo.com> wrote:
Hello Nanogers!
I'm happy to see this, and I hope C&W, Verio, and Level3 ..etc will do
same!
MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help IP services customers thwart and defend against Internet viruses and
sent to the threats.
http://informationweek.securitypipeline.com/news/18201396
It's the right time before it's too late!
Regards,
-J
--------------------------------- Do you Yahoo!? Yahoo! Search - Find what you're looking for faster.
--
Stephen (routerg) irc.dks.ca
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
Global Crossing has this, already in production.
Idem, Teleglobe, mh
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
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:
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
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
On Mar 3, 2004, at 4:47 PM, 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 !
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). :) 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. -- TTFN, patrick
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
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). :) 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.
On Mar 3, 2004, at 5:22 PM, 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 !
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!
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. :) -- TTFN, patrick
--- "Patrick W.Gilmore" <patrick@ianai.net> wrote:
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)?
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- __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com
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 On Wed, Mar 03, 2004 at 10:22:16PM +0000, 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 !
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
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). :) 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.
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
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@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
[..] 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. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
[..] 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
participants (11)
-
David Barak -
Deepak Jain -
james -
James -
Lumenello, Jason -
Mark Kasten -
Michael Hallgren -
Patrick W.Gilmore -
Randy Bush -
Stephen J. Wilcox -
Suresh Ramasubramanian