RE: Source address validation
I think the argument taken up for or against uRPF-loose deployment depends largely on the ability of the provider to implement it without 1) performance impact or 2) network upgrades. Argument against it on the grounds of "I can't accurately measure its value" is a smoke screen. We have implemented SAV on our customer edge routers for some time, with no ill effects, and have filtered rfc1918 on our core router interfaces facing our peering routers since early last year. We are currently discussing loose-mode application in the core as the suspenders to these two techniques. It really comes down to performance capability on a given platform, as implementation itself does not cost anything but maybe a nights sleep in a maintenance window. Can you guess what routers I have in my network? :) I fail to see how people can spend all day discussing its measurable or theoretical value, yet claim they are too busy or resource constrained to actually deploy it. So what's my excuse for waiting until now for uRPF-loose in my core? I have been happy (up until now) with just my belt. I am now reaching for the suspenders to deal with those few pieces of hardware in my network not up to the task of uRPF, and that minority percentage of attack traffic that can slip under the radar. :) Just my $.02. Back to our regularly scheduled program. Jason Lumenello IP Engineering XO Communications > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Paul Vixie > Sent: Sunday, March 07, 2004 3:22 PM > To: [EMAIL PROTECTED] > Subject: Re: Source address validation > > > [two responses here] > > 1 of 2 > > [EMAIL PROTECTED] (fingers) writes: > > > why is DDoS the only issue mentioned wrt source address validation? > > > > i'm sure there's other reasons to make sure your customers can't send > > spoofed packets. ... > > yes. for example, most forms of dns cache pollution rely on the ability > to forge a udp source address on a well-timed response. several of you > have pointed out that as long as at least one edge network is free from > uPRF, then something like dnssec will still be vitally necessary -- and > that's true. but, if the places where forged-source were possible could > be enumerated, then the fact of the forgery would be useful to a victim. > right now those places are innumerable, and so, anonymity is complete. > > 2 of 2 > > [EMAIL PROTECTED] (James Edwards) writes: > > > uRPF, strict mode, is how I control 1000+ DSL pvc's from leaking private > > address space via broken NAT. ... > > so what you're saying is, these packets (captured on one of the f-root > servers just now) wasn't from your network? THANKS! (anybody else here > want to claim this slackage?) > > tcpdump: listening on fxp0 > 21:06:42.331994 192.168.15.3.1053 > 192.5.5.241.53: 15396 A? > wustat.windows.com. (36) > 21:06:42.349184 10.1.0.15.1025 > 192.5.5.241.53: 6182 NS? . (17) > 21:06:42.427980 10.10.1.1.1041 > 192.5.5.241.53: 53830 NS? . (17) > 21:06:42.559860 10.19.1.101.1032 > 192.5.5.241.53: 8434 [1au] A? > SPPOLCD01.POL. (42) > 21:06:42.688972 192.168.7.76.1036 > 192.5.5.241.53: 14986 A? > rsthost2.ods.org. (34) > 21:06:43.793914 192.168.160.252.1024 > 192.5.5.241.53: 28233 MX? > jimaz.cz. (26) (DF) > 21:06:44.048702 10.10.10.250.53 > 192.5.5.241.53: 2051 A? > tock.usno.navy.mil. (36) > 21:06:44.123787 10.101.58.16.1120 > 192.5.5.241.53: 9741 PTR? > 169.16.187.208.in-addr.arpa. (45) > 21:06:44.394578 10.8.0.22.1036 > 192.5.5.241.53: 15001 A? > mail.inf101.net. (33) > 21:06:44.578893 10.8.0.22.1036 > 192.5.5.241.53: 15002 MX? ezrs.com. (26) > 2027 packets received by filter > > note that this particular box has dropped a fair amount of this crud since > its last reboot: > > rule#packets octets rule- > > 00400 27149821 1707500202 deny ip from 10.0.0.0/8 to any in > 005001710989109992242 deny ip from 172.16.0.0/12 to any in > 006006144955392168290 deny ip from 192.168.0.0/16 to any in > > 9:16PM up 37 days, 15:55, 1 user, load averages: 0.04, 0.01, 0.00 > > also note that it's only one of about fifty similar servers. i don't have > an easy way to aggregate the slackage numbers yet, but i sure would like > them to be zero or at least lower. (and, for my part in rfc 1918, i now > beg > forgiveness.) > > > Based on my limited experience with all of this it seems the place for > > uRPF is not at the core (core in the context of the Internet backbone) > > but at the customer edge, where the problem starts. > > that's sort of what http://www.icann.org/committees/security/sac004.txt > says. > -- > Paul Vixie
RE: UUNet Offer New Protection Against DDoS
> -Original Message- > From: Christopher L. Morrow [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 04, 2004 11:50 AM > To: Lumenello, Jason > Cc: Suresh Ramasubramanian; Randy Bush; [EMAIL PROTECTED] > 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
RE: UUNet Offer New Protection Against DDoS
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Kasten Sent: Wednesday, March 03, 2004 5:35 PM To: [EMAIL PROTECTED] 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 firstterm of my route map so the /32 does not get out. Of course my peerfacing policy requires specific communities to get out as well (belt andsuspenders). This method works very well, and you do not have to give up lengthrestrictions or maintain two sets of customer prefix/access lists. Jason -Original Message-From: Lumenello, JasonSent: Wednesday, March 03, 2004 4:52 PMTo: 'Stephen J. Wilcox'; jamesCc: [EMAIL PROTECTED]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 LumenelloIP EngineeringXO Communications -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Stephen J. WilcoxSent: Wednesday, March 03, 2004 3:48 PMTo: jamesCc: [EMAIL PROTECTED]Subject: Re: UUNet Offer New Protection Against DDoS I'm puzzled by one aspect on the implementation.. how to build yourcustomerprefix filters.. that is, we have prefix-lists for prefix and length. Thereforeat present we can only accept a tagged route for a whole block.. not good if theannouncement is a /16 etc ! Now, I could do as per the website at secsup.org which means we have a route-mapentry to match the community before the filtering .. but that would allow thecustomer 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 oneof this things I asked about. Qwest indicated they aregoing to deploy this shortly. (i.e., send routes tagged witha community which they will set to null) James EdwardsRouting and Security[EMAIL PROTECTED]At the Santa Fe Office: Internet at Cyber MesaStore hours: 9-6 Monday through Friday505-988-9200 SIP:1(747)669-1965
RE: UUNet Offer New Protection Against DDoS
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:[EMAIL PROTECTED] > Sent: Wednesday, March 03, 2004 7:21 PM > To: Randy Bush > Cc: [EMAIL PROTECTED]; 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)@outblaze.com // gpg : EDEDEFB9 > manager, outblaze.com security and antispam operations
RE: UUNet Offer New Protection Against DDoS
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: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > Stephen J. Wilcox > > Sent: Wednesday, March 03, 2004 3:48 PM > > To: james > > Cc: [EMAIL PROTECTED] > > 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 > > > [EMAIL PROTECTED] > > > At the Santa Fe Office: Internet at Cyber Mesa > > > Store hours: 9-6 Monday through Friday > > > 505-988-9200 SIP:1(747)669-1965 > > > > > >
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Stephen J. Wilcox > Sent: Wednesday, March 03, 2004 3:48 PM > To: james > Cc: [EMAIL PROTECTED] > 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 > > [EMAIL PROTECTED] > > At the Santa Fe Office: Internet at Cyber Mesa > > Store hours: 9-6 Monday through Friday > > 505-988-9200 SIP:1(747)669-1965 > > > >
RE: UUNet Offer New Protection Against DDoS
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Stephen Perciballi > Sent: Wednesday, March 03, 2004 12:25 PM > To: Andy Ellifson > Cc: [EMAIL PROTECTED] > 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:. 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 > > [EMAIL PROTECTED], 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 <[EMAIL PROTECTED]> 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
