- NANOG - lists.nanog.org

Routing Policy
by Beprojects.com 04 Mar '04

04 Mar '04

Does anybody have a list of the hot-potato/cold-potato routing policy of the 10-20 biggest ISP's (MCI, Sprint, AT&T, Verio, etc)? I know Boardwatch used to publish that in their yearly ISP guide, but I haven't been able to find it since they went out of print. Peder

1 0

RE: UUNet Offer New Protection Against DDoS
by Lumenello, Jason 04 Mar '04

04 Mar '04

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(a)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(a)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(a)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 > > > >

4 3

Re: SPAM Prevention/Blacklists
by Anne P. Mitchell, Esq. 04 Mar '04

04 Mar '04

> >>> Also, I like sender verification, but that's me. >> >> i used it for some time, and reluctantly shut it down. blocked a lot >> of email >> abuse, but too many false positives for my taste. > > Could you go into more detail? > > ... > Maybe I have others I just don't know about? How many people send > legit e-mail with return addresses which are bogus? On a related note, for those of you interested, the IADB (ISIPP Accreditation Database) is now up and running, although not publicly announced yet. You can read information about it at: http://www.isipp.com/iadb.php What is unique about the IADB is that it is designed to list not only IP addresses, but also associated domains *if* the listee is publishing an SPF record, and conversely IADB listees will be able to get a unique "accreditation code" to put into their SPF records. Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy Professor of Law, Lincoln Law School of SJ

1 0

w32/bagle variants
by Sam Stickland 04 Mar '04

04 Mar '04

For the people talking about how quickly the variants have been produced ;) http://news.bbc.co.uk/1/hi/technology/3532009.stm Seems the authors are taunting each other in the code. Sam

1 0

RE: UUNet Offer New Protection Against DDoS
by Lumenello, Jason 04 Mar '04

04 Mar '04

No, but it sounds like SLA payouts are made in the event that they fail to respond in 15 minutes after a call is made. Maybe I am misinterpreting their SLA, but this seems much different then offering blanket payments for DoS down time. I will give them credit for guaranteeing a response in 15 minutes or less. Now is a response the opening of a ticket or the null routing of the attack traffic in 15 minutes? Jason > -----Original Message----- > From: Suresh Ramasubramanian [mailto:suresh@outblaze.com] > Sent: Wednesday, March 03, 2004 7:21 PM > To: Randy Bush > Cc: nanog(a)merit.edu; Lumenello, Jason > Subject: Re: UUNet Offer New Protection Against DDoS > > 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? > > -- > srs (postmaster|suresh)(a)outblaze.com // gpg : EDEDEFB9 > manager, outblaze.com security and antispam operations

2 1

RE: UUNet Offer New Protection Against DDoS
by Lumenello, Jason 04 Mar '04

04 Mar '04

> -----Original Message----- > From: Christopher L. Morrow [mailto:christopher.morrow@mci.com] > Sent: Thursday, March 04, 2004 11:50 AM > To: Lumenello, Jason > Cc: Suresh Ramasubramanian; Randy Bush; nanog(a)merit.edu > Subject: RE: UUNet Offer New Protection Against DDoS > > > On Thu, 4 Mar 2004, Lumenello, Jason wrote: > > > > > No, but it sounds like SLA payouts are made in the event that they fail > > to respond in 15 minutes after a call is made. Maybe I am > > fail to get you in touch with 'security expertise' in 15 minutes... > > > misinterpreting their SLA, but this seems much different then offering > > blanket payments for DoS down time. > > > > downtime is seperate from this SLA. > > > I will give them credit for guaranteeing a response in 15 minutes or > > less. Now is a response the opening of a ticket or the null routing of > > the attack traffic in 15 minutes? > > Just speaking to an engineer that can help you. There is no way to > guarantee and end to a DoS in any reasonable amount of time ;( For > instance, Suresh's main 'job' is email, so null routing his MX hosts will > stop the attack, but it is hardly desirable, eh? Same for filtering tcp/25 > syn packets :( > > There is no magic here, you all are smart enough to understand how DoS > works, how to stop it and the complications inherent in both. Well, kudos to you guys for raising the SLA bar to include this provision then. Jason

1 0

RE: UUNet Offer New Protection Against DDoS
by Lumenello, Jason 04 Mar '04

04 Mar '04

This sounds like a good idea for us to consider. I think DoS attacks typically get erased in the 95% discard a lot of people use in billing though, but it still has value for the customer. Thanks! Jason -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Kasten Sent: Wednesday, March 03, 2004 5:35 PM To: nanog(a)merit.edu Subject: Re: UUNet Offer New Protection Against DDoS 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(a)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(a)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(a)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(a)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

1 0

RE: UUNet Offer New Protection Against DDoS
by Lumenello, Jason 04 Mar '04

04 Mar '04

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 > -----Original Message----- > From: owner-nanog(a)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(a)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(a)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(a)yahoo.com> wrote: > > > 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 > help IP > > > services customers thwart and defend against Internet viruses and > 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

11 12

Re: UUNet Offer New Protection Against DDoS
by Suresh Ramasubramanian 04 Mar '04

04 Mar '04

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? -- srs (postmaster|suresh)(a)outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations

2 1

RE: UUNet Offer New Protection Against DDoS
by Lumenello, Jason 03 Mar '04

03 Mar '04

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(a)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(a)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(a)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(a)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 > > > > > >

2 1