Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Mon, Mar 08, 2004 at 12:40:18AM -0500, Sean Donelan wrote: No. The work you've done is expected of you, as a good Internetwork neighbour. If you're not a good neighbour, next time you need my help, or the help of anyone else I know, please expect the finger. But I keep trying to do good work; and you keep giving me the finger. Why should I keep trying to do good work? Remember it works both ways. No I don't! You're a good Internet Neighbour. If I can expect you to do the right thing, you can expect it of me. And if I don't, you give me the finger instead. But don't give it to everyone, as a side of effect of wanting to just flip me off. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only)
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
Here is some insight on this issue What is Unicast Reverse Path Forwarding (uRPF)? Can a default route 0.0.0.0/0 be used to perform a uRPF check? http://www.cisco.com/warp/public/105/44.html#Q18 -Henry
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
Christopher L. Morrow wrote: 2. I've not seen large networks talking about their awful experiences with SAV. it melts routers, good enough for you? Specifically it melts linecards :( my experience is only on Cisco equipment though, so the linecard/ios/rev games must be played. If you upgrade, or initially install, E3 cards a large portion of this care is not necessary though. This is a problem that could be migrated out as new equipment/capabilities hit everyone's networks. I suspect that market pressure will push things in this direction anyway over time. That was exactly what I was doing by saying I will only get service from ISPs that run loose-uRPF in cores. (or all edges, including peering links.) I will not take service from ISP X, who is cheaper than ISP Y, if ISP X cannot assure me that I will not get bogon sourced traffic on my link. What you are saying above is not a technical argument against uRPF (as you grant that there is equipment that will do uRPF at core speeds.) - its a business one. So I am giving you a business incentive to take to your managers. Customers want this service which we cannot deliver w/o upgrades. Customers will not give us money unless we spend this money, and they will go to our competitors who have infrastructure that can do it. If your vendors cannot deliver equipment that meets your requirements to meet your customers' needs, you need to say the same thing to your vendors, and vote with dollars for those that can.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Mon, 8 Mar 2004, Steve Francis wrote: That was exactly what I was doing by saying I will only get service from ISPs that run loose-uRPF in cores. (or all edges, including peering links.) I will not take service from ISP X, who is cheaper than ISP Y, if ISP X cannot assure me that I will not get bogon sourced traffic on my link. Why do you care how a provider does X? Your requirement doesn't seem to be run loose-uRPF in cores, although that may be one way a provider chooses to solve the problem. You requirement is not get bogon sourced traffic on your link. I know its tempting to tell other people how to run their networks. But specifying the solution sometimes cuts out alternative solutions which work just as well or maybe better.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
Sean Donelan wrote: On Mon, 8 Mar 2004, Steve Francis wrote: That was exactly what I was doing by saying I will only get service from ISPs that run loose-uRPF in cores. (or all edges, including peering links.) I will not take service from ISP X, who is cheaper than ISP Y, if ISP X cannot assure me that I will not get bogon sourced traffic on my link. Why do you care how a provider does X? Your requirement doesn't seem to be run loose-uRPF in cores, although that may be one way a provider chooses to solve the problem. You requirement is not get bogon sourced traffic on your link. I know its tempting to tell other people how to run their networks. But specifying the solution sometimes cuts out alternative solutions which work just as well or maybe better. Correct. I was overstating my requirement. What I really want is as you described: I want assurance that any packet I receive on my proposed circuit is NOT sourced from a patently false IP address. (i.e. no packets sourced from reserved IP addresses, RFC 1918 IP addresses; addresses from blocks not yet allocated by routing registries, or addresses from blocks that are not currently being announced via BGP to the Internet.) I would also prefer that such packets be dropped as far as possible from the POP I am connected to, to minimise the chance of such packets overloading the carriers circuits into that POP. I know of no way to do this other than loose-uRPF in the core, or at least loose-uRPF on all edges, including peering connections. Can any of the operators that are arguing against loose-uRPF in the core state if they run loose uRPF on all peering connections, regardless of speed, as well as on all their edges? Or propose another way to achieve the same thing?
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, Mar 07, 2004 at 02:13:38AM -0500, Sean Donelan wrote: Try saying that after running a major DDoS target, with HIT ME your forehead. No offense Sean but I'd like you to back your claim up with some impirical data first. Has the number of DDOS attacks increased or decreased in the last few years has uRPF has become more widely deployed? Do you have any evidence the number of attacks are decreasing? Without any data to back this up, I'm estimating based on the attacks I've dealt with. I don't believe the number have gone down at all. If it has, it's done that for someone else, not me, I don't have any evidence. Nor do I *believe* the number of attacks is decreasing. If anything, its staying the same or going up, as more people decide it's fun to take networks offline through the greater and greater number of compromised hosts. If you want to do a little test, try this: In the last 5 years, compromised hosts have become a favourite for launching DDoS attacks from. If the number of compromised hosts with outbound Internet access has gone up, then either the frequency of attacks, or the amplitude of said attacks, or both have gone UP. We all know the number of compromised hosts continues to go up. The rest is simple logic. -- Avleen Vig Systems Administrator
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
just a question 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. they might not always be as news-worthy, but i feel it's a provider's duty to do this. it shouldn't be optional (talking specifically about urpf on customer interfaces, loose where needed)
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
fingers wrote: just a question 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. they might not always be as news-worthy, but i feel it's a provider's duty to do this. it shouldn't be optional (talking specifically about urpf on customer interfaces, loose where needed) Because _Distributed_ is the hot buzzword of the day. At least one of us thinks clean traffic is a Good Thing all the time. Packets that can't possibley be used for anything ought to be dumped at the earliest possible opportunity as soon as it is apparent (or could be if anybody looked) that they are from addresses that can't be reached or have any other obviously fatal defect.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
SD Date: Sat, 6 Mar 2004 22:04:58 -0500 (EST) SD From: Sean Donelan SD Would you rather ISPs spend money to SD 1. Deploying S-BGP? SD 2. Deploying uRPF? SD 3. Respond to incident reports? Let's look at the big picture instead of a taking a shallow mutex approach. If SAV were universal (ha ha ha!), one could discount spoofed traffic when analyzing flows. But, hey, why bother playing nice and helping other networks, eh? Am I the only one who's had IWFs -- even legitimate entities -- complain about packets from your network that weren't? It certainly would have been nice if $other_networks had used SAV. SAV doesn't take long to implement. Considering the time spent discounting spoofing when responding to incidents, I think there would be a _net_ savings (no pun intended) in time spent responding to incidents. Alas, that requires cooperation and doesn't provide instantaneous gratification. If it doesn't make/save a quick buck, why bother? Detection of sarcasm is left as an exercise to the reader. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
SD Date: Sun, 7 Mar 2004 02:13:38 -0500 (EST) SD From: Sean Donelan SD Has the number of DDOS attacks increased or decreased in the SD last few years has uRPF has become more widely deployed? Number of life guards on duty increases in the summer. So does drowning. Therefore, having life guards on duty is not an effective measure to prevent drowning. Ice cream consumption increases in the summer. So does drowning. Therefore, it is ice cream consumption that causes drowning. (Time for arguments over who has the best and worst analogies!) SD Do you have any evidence the number of attacks are decreasing? Is number of attacks the sole metric? Are all attacks created equal? Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 2004-03-07 at 11:08, fingers wrote: just a question why is DDoS the only issue mentioned wrt source address validation? uRPF, strict mode, is how I control 1000+ DSL pvc's from leaking private address space via broken NAT. Also, all other customer facing interfaces run uRPF, strict mode. It is a very powerful tool; null route some trouble causing customer space and traffic destined to this space is dropped via this null route AND traffic sourced from this space is dropped via uRPF, strict check. An AS112 NS also takes care of another facet of this problem. As to the question of DDoS'es and spoofed address space; once we close the hole of allowing DDoS'es to come from untraceable address space I feel we gain something very useful. We now know where the bad stuff is coming from. The solution to DDoS is not a black box that will go to Def Con 1 at the first sign of a port scan. You don't put out a fire with more fuel. Criminal investigation techniques are quite advanced. We cannot start to put them to use if attacks come from addresses that do not point back to the attacker. I am just as jaded as the next person with the present lack of law enforcement support in abuse issues but all of this is a quite new form of crime through a new medium. A push back system would give us the ability to quickly bring DDoS/DoS'es under control and complement a system to track down, gather evidence, and prosecute to persons in control of a DDoS/DoS. 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. -- James H. Edwards Routing and Security At the Santa Fe Office: Internet at Cyber Mesa [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
actually, it would. universal uRPF would stop some attacks, and it would remove a plan B option for some attack-flowcharts. i would *much* rather play defense without facing this latent weapon available to the offense. I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to be non-existent these days so shall we stop disabling 'ip directed-broadcast' on our routers? Steve
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, Avleen Vig wrote: On Sun, Mar 07, 2004 at 02:13:38AM -0500, Sean Donelan wrote: Try saying that after running a major DDoS target, with HIT ME your forehead. No offense Sean but I'd like you to back your claim up with some impirical data first. Has the number of DDOS attacks increased or decreased in the last few years has uRPF has become more widely deployed? Do you have any evidence the number of attacks are decreasing? Without any data to back this up, I'm estimating based on the attacks I've dealt with. I don't believe the number have gone down at all. If it has, it's done that for someone else, not me, Is this attacks on 'known magnets' or 'random stuff'. From what I've seen the frequency of attacks on 'all customers' seems to be slowing SOME. There are the normal nuisance points which attract attacks for whichever reason. So, Avleen, can you seperate the 'known magnets' from 'random stuff' and say which direction the trend is moving? As to the 'strength' of attacks. It seems that bandwidth and pps rates have incresed over time. This COULD BE because you can own up 10,000 xp machines in a heartbeat, or it could be a reflection of bigger/better/faster single hosts being taken over. It's hard to tell from my end of the party :( I don't have any evidence. Nor do I *believe* the number of attacks is decreasing. If anything, its staying the same or going up, as more people decide it's fun to take networks offline through the greater and greater number of compromised hosts. The greater number of compromisable hosts seems to be the constant in this arguement. So, like we've said for several years, until the end station is secured 'better' the consistency and strength of attacks will continue that upward trend.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, fingers wrote: just a question why is DDoS the only issue mentioned wrt source address validation? its easier to discuss than other things... for instance the number of broken vpn/nat systems out there that uRPF will break. Also, the folks with private addressed cores that will start appearing 'broken' when traceroute/unreachables stop working across their networks... i'm sure there's other reasons to make sure your customers can't send spoofed packets. they might not always be as news-worthy, but i feel it's a provider's duty to do this. it shouldn't be optional (talking specifically about urpf on customer interfaces, loose where needed) I'm not sure that anyone would argue that uRPF is bad, the arguement is in it's placement. I do think that part still needs to be worked out, that and making sure that your equipment can handle the task. There are certainly some people hampered by early adoption of some technologies which they can't get out from under in any reasonable fashion. --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, Laurence F. Sheldon, Jr. wrote: fingers wrote: just a question 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. they might not always be as news-worthy, but i feel it's a provider's duty to do this. it shouldn't be optional (talking specifically about urpf on customer interfaces, loose where needed) Because _Distributed_ is the hot buzzword of the day. and people offten seperate 'ddos' from 'dos', even though the end is the same as far as your customer is concerned... it's kinda funny really :) At least one of us thinks clean traffic is a Good Thing all the time. Packets that can't possibley be used for anything ought to be dumped at the earliest possible opportunity as soon as it is apparent (or could be if anybody looked) that they are from addresses that can't be reached or have any other obviously fatal defect. Here is a sticky point... There are reasons to allow 10.x.x.x sources to transit a network. Mostly the reasons come back to 'broken' configurations or 'broken' hardware. The reasons still equate to customer calls and 'broken' networking fromm their perspective. I think the thing you are actually driving at is the 'intent' of the packet, which is quite tough for the router to determine. --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, Stephen J. Wilcox wrote: actually, it would. universal uRPF would stop some attacks, and it would remove a plan B option for some attack-flowcharts. i would *much* rather play defense without facing this latent weapon available to the offense. I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to be non-existent these days so shall we stop disabling 'ip directed-broadcast' on our routers? smurf attacks are far from 'non-existent' today, however they are not as popular as in 1999-2000-2001. In fact netscan.org still shows almost 9k networks that are 'broken'.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, E.B. Dreger wrote: If SAV were universal (ha ha ha!), one could discount spoofed traffic when analyzing flows. But, hey, why bother playing nice and helping other networks, eh? SAV doesn't tell you where the packets came from. At best SAV tells you where the packets didn't come from. Am I the only one who's had IWFs -- even legitimate entities -- complain about packets from your network that weren't? It certainly would have been nice if $other_networks had used SAV. You still need to spend the same amount of time tracing the flows because you can't tell from the packet itself if something went wrong with SAV. Even if everyone said they did SAV (and meant it), things like uRPF rely on a number of things to work correctly. If any of those break or aren't secure, you still can't rely on the source address being accurate. Even if you deployed SAV/uRPF on 100% of your network, you probably wouldn't want to tell people about it due to the idiots with firewalls. SAV doesn't take long to implement. Considering the time spent discounting spoofing when responding to incidents, I think there would be a _net_ savings (no pun intended) in time spent responding to incidents. You would be wrong. There are networks that have deployed SAV/uRPF. They saw no _net_ savings. In the real world, it costs more to deploy and maintain SAV/uRPF. Have you noticed this thread is full of people who don't run large networks saying other people who do run networks should deploy SAV/uRPF. But there hasn't been anyone who does run large networks saying they deployed SAV/uRPF and it saved them money, made their network run better or improved the world?
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, Mar 07, 2004 at 08:28:53PM +, Christopher L. Morrow wrote: Without any data to back this up, I'm estimating based on the attacks I've dealt with. I don't believe the number have gone down at all. If it has, it's done that for someone else, not me, Is this attacks on 'known magnets' or 'random stuff'. From what I've seen the frequency of attacks on 'all customers' seems to be slowing SOME. There are the normal nuisance points which attract attacks for whichever reason. So, Avleen, can you seperate the 'known magnets' from 'random stuff' and say which direction the trend is moving? If we class popular websites, servers / networks at major ISPs, IRC servers and the latest popular thing as magnets, and small business sites, personal pages etc as the random stuff, then I don't believe attacks on magnets have gone down at all. On the random stuff I cannot comment, as I've had surprisingly little dealing with that. As to the 'strength' of attacks. It seems that bandwidth and pps rates have incresed over time. This COULD BE because you can own up 10,000 xp machines in a heartbeat, or it could be a reflection of bigger/better/faster single hosts being taken over. It's hard to tell from my end of the party :( I don't think it would be unfair to assume it is both. Again that stands to simple logic. More hosts on the internet = more potential drones. More availible global bandwidth = larger volume output from each drone. I don't have any evidence. Nor do I *believe* the number of attacks is decreasing. If anything, its staying the same or going up, as more people decide it's fun to take networks offline through the greater and greater number of compromised hosts. The greater number of compromisable hosts seems to be the constant in this arguement. So, like we've said for several years, until the end station is secured 'better' the consistency and strength of attacks will continue that upward trend. Indeed. I believe the ISP of the end user is the party responsible here. If the ISP is allowing access through their network, they need to be responsible for the data leaving their networl which originates in their network.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
smurf attacks are far from 'non-existent' today, however they are not as popular as in 1999-2000-2001. thats interesting, i've not seen/heard of one for ages.. (guess u have a wider testing ground :) In fact netscan.org still shows almost 9k networks that are 'broken'. actually i just ran that file thro a quick awk and sort to see to what extent these networks exist.. as you can see almost all only reply two or three times, not like in the old days with 100 replies being commonplace.. 5224 2 1834 3 897 4 334 5 167 6 56 7 19 8 15 9 7 10 11 11 6 12 3 13 6 14 1 15 1 16 4 17 5 18 1 23 1 26 1 28 1 100
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
removed paul from the direct reply since his mailserver doesn't like uunet mail servers :) On Sun, 7 Mar 2004, Stephen J. Wilcox wrote: smurf attacks are far from 'non-existent' today, however they are not as popular as in 1999-2000-2001. thats interesting, i've not seen/heard of one for ages.. (guess u have a wider testing ground :) just last week we had one... they do still happen. In fact netscan.org still shows almost 9k networks that are 'broken'. actually i just ran that file thro a quick awk and sort to see to what extent these networks exist.. as you can see almost all only reply two or three times, not like in the old days with 100 replies being commonplace.. Sure, but a list of 9k networks with this leve of response is still enough to do damage. It's getting better, no doubt about it but it's still a factor. --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
SD Date: Sun, 7 Mar 2004 16:17:50 -0500 (EST) SD From: Sean Donelan SD SAV doesn't tell you where the packets came from. At best SD SAV tells you where the packets didn't come from. If SAV were universal, source addresses could not be spoofed. If source addresses could not be spoofed... SD You would be wrong. There are networks that have deployed SD SAV/uRPF. Some. I said all. SD They saw no _net_ savings. SD SD In the real world, it costs more to deploy and maintain SD SAV/uRPF. The benefit is to other networks. When other networks make your life easier, you benefit. If you want others to help you, help them. SD Have you noticed this thread is full of people who don't run SD large networks saying other people who do run networks should SD deploy SAV/uRPF. 1. SAV is most effective at the edge, which often implies the smaller networks should be doing it 2. I've not seen large networks talking about their awful experiences with SAV. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Mon, 8 Mar 2004, E.B. Dreger wrote: SD Date: Sun, 7 Mar 2004 16:17:50 -0500 (EST) SD From: Sean Donelan SD SAV doesn't tell you where the packets came from. At best SD SAV tells you where the packets didn't come from. If SAV were universal, source addresses could not be spoofed. If source addresses could not be spoofed... in a perfect world yes, for today we still have LOTS of folks that firewall in one direction only. A great example of this is the great firewall of China :( How, if they are filtering every packet that leaves their country, can I still get attacked from them? :( Until this is a default behaviour and you can't screw it up (ala directed-broadcast) this will be something we all have to deal with. SD Have you noticed this thread is full of people who don't run SD large networks saying other people who do run networks should SD deploy SAV/uRPF. 1. SAV is most effective at the edge, which often implies the smaller networks should be doing it excellent, the original point of the conversation has been satisfied... uRPF for the core is not a good plan, edge networks are a great place for this. Doing this on single homed customers is a great step in the right direction. However, as you say, the best place for this is on the edge of the network. So this implies that each edge LAN router will/should have uRPF or atleast an acl permitting only local LAN traffic to source from it, right? I have a question, I wonder if uRPF works on low end platforms without running CEF? Do all low-end platforms gracefully support CEF along with the other things enterprises typically do on routers? (just a question really...) 2. I've not seen large networks talking about their awful experiences with SAV. it melts routers, good enough for you? Specifically it melts linecards :( my experience is only on Cisco equipment though, so the linecard/ios/rev games must be played. If you upgrade, or initially install, E3 cards a large portion of this care is not necessary though. This is a problem that could be migrated out as new equipment/capabilities hit everyone's networks. I suspect that market pressure will push things in this direction anyway over time.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
CLM Date: Mon, 8 Mar 2004 01:32:51 + (GMT) CLM From: Christopher L. Morrow CLM in a perfect world yes[...] CLM Until this is a default behaviour and you can't screw it up CLM (ala directed-broadcast) this will be something we all have CLM to deal with. Yes. But the only way we'll get there is 1) a flag day or 2) if we gradually work in that direction. CLM it melts routers, good enough for you? Specifically it CLM melts linecards :( :-( CLM This is a problem that could be migrated out as new CLM equipment/capabilities hit everyone's networks. I suspect CLM that market pressure will push things in this direction CLM anyway over time. ...and hopefully will be safe-by-default. Anyone who has multihomed downstreams should be clued enough to disable strict SAV as needed -- similar to, yet the opposite of, manually configuring OSPF to treat interfaces as passive by default. As for low-end routers, uRPF is supported on 26xx. I don't know about a 16xx or 25xx... a scary thought, but chances are such a router would have a very small list of reachable netblocks to check. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Mon, 8 Mar 2004, E.B. Dreger wrote: SD They saw no _net_ savings. SD SD In the real world, it costs more to deploy and maintain SD SAV/uRPF. The benefit is to other networks. When other networks make your life easier, you benefit. This confirms my statement. You save nothing by deploying SAV on your network. There may be some indeterminate benefit at some indeterminate time in the future after everyone else in the world correctly implements SAV. But there is no way to verify if every other network in the world has correctly deployed SAV. Even if everyone deploys SAV/uRPF you never know when someone may misconfigure something, so you still have to keep doing everything you were doing. In the mean time, you get to pay for the extra costs for deploying SAV/uRPF in addition to doing everything you were already doing. http://www.rhyolite.com/anti-spam/you-might-be.html If you want others to help you, help them. I've already done my part. I'm still waiting for others to help me. Should I be expecting a check in the mail?
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
Sean Donelan wrote: On Mon, 8 Mar 2004, E.B. Dreger wrote: SD They saw no _net_ savings. SD SD In the real world, it costs more to deploy and maintain SD SAV/uRPF. The benefit is to other networks. When other networks make your life easier, you benefit. This confirms my statement. How much do you save by putting handrails on your stairways? Restrooms in you lobby? Precipitators on your smoke stacks?
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, Sean Donelan wrote: This confirms my statement. You save nothing by deploying SAV on your network. This isnt the point. The point is, why should others suffer the burden of your clients spewing bogon/spoofed/nonsense garbage at them? The effect is cumulative. If everyone takes this lazy apathetic approach to network administration, it hurts everyone. Its the difference between being a good neighbor and being the fat beerbelly neighbor with dogs barking all night and rusting camaro with no tires up on cinderblocks on his beercan littered lawn. Just because everyone else doesnt maintain a good network doesnt mean you shouldnt. -Dan
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
SD Date: Sun, 7 Mar 2004 21:24:44 -0500 (EST) SD From: Sean Donelan SD This confirms my statement. You save nothing by deploying SD SAV on your network. There may be some indeterminate benefit Unless, of course, the traffic originated from your network and it simplifies your backtrace. Tracing flows isn't difficult, but it's more time consuming than a traceroute. SD at some indeterminate time in the future after everyone else SD in the world correctly implements SAV. But there is no way SD to verify if every other network in the world has correctly SD deployed SAV. Even if everyone deploys SAV/uRPF you never s/SAV/AS_PATH filtering and netblock adverts/ in your above statement. While technically true, it's highly disingenuous. Should providers quit filtering those simply because not everyone does it? It's extra cost with no selfish benefit, right? If you want a network to extend that courtesy to you, extend it to them. If you extend the courtesy to them, demand it in return. SD know when someone may misconfigure something, so you still SD have to keep doing everything you were doing. Perhaps on a lesser scale, though. There's benefit in knowing something did not originate from certain sources. SD In the mean time, you get to pay for the extra costs for SD deploying SAV/uRPF in addition to doing everything you were SD already doing. Just like AS_PATH and netblock announcement filters. Just like flow monitoring. Just like chasing down spammers. Just like dealing with pwned systems. Just like most anything else that wouldn't be necessary in a perfect world. Also note various posters' interest in shifting costs to responsible parties. One can argue what is reasonable, but consequences boost motivation. Perhaps if lack of certain precautions were considered [legally] negligent, failure would be the more expensive option. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, Mar 07, 2004 at 09:24:44PM -0500, Sean Donelan wrote: On Mon, 8 Mar 2004, E.B. Dreger wrote: SD They saw no _net_ savings. SD SD In the real world, it costs more to deploy and maintain SD SAV/uRPF. [snip] In the real word, there are different networks with different tools and different gear. In some networks, it is a flip of the switch, you are done, and can move on. The direct benefit to my network is eliminating a category of crap from it. I save having to deal with that category. Yes there is other crap, but reducing the workload... reduces the workload. [snip] has correctly deployed SAV. Even if everyone deploys SAV/uRPF you never know when someone may misconfigure something, so you still have to keep doing everything you were doing. You mean internally to the network? Config management must exist for a huge number of reasons. Drop the right knob in your standards and move on. I don't follow 'having to keep doing everything' when I have one less things to do. In the mean time, you get to pay for the extra costs for deploying SAV/uRPF in addition to doing everything you were already doing. I'm sorry your network has such huge costs for trivial changes that follow simple logic.Actually, I've lost track of how many tiers of soapboxes are involved here, so I'm not sure what level of hypothetical-vs-real this [sub]thread is tackling. I'll encourage my competators to let more crap on their networks. I'll take out the trash at the points where I can. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, Mar 07, 2004 at 09:24:44PM -0500, Sean Donelan wrote: If you want others to help you, help them. I've already done my part. I'm still waiting for others to help me. Should I be expecting a check in the mail? No. The work you've done is expected of you, as a good Internetwork neighbour. If you're not a good neighbour, next time you need my help, or the help of anyone else I know, please expect the finger. Yes, I suppose this does sound somewhat like a cross between an old-school network, and rule by bullying. But we don't have a better way (yet). -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only)
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
[EMAIL PROTECTED] (vijay gill) writes: Putting rubber to the road eventually, we actually went ahead and packetfiltered rfc1918 space on our edge. I know paul and stephen will be crowing with joy here, as we had several arguments about it in previous lives, ... fwiw, in retrospect you were right at the time, but in my defense it was only because of things neither of us could have known. given only what we actually knew and could prove, you were deadass wrong :-). -- Paul Vixie
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, Avleen Vig wrote: No. The work you've done is expected of you, as a good Internetwork neighbour. If you're not a good neighbour, next time you need my help, or the help of anyone else I know, please expect the finger. But I keep trying to do good work; and you keep giving me the finger. Why should I keep trying to do good work? Remember it works both ways.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
Sean Donelan wrote: On Sun, 7 Mar 2004, E.B. Dreger wrote: SAV doesn't take long to implement. Considering the time spent discounting spoofing when responding to incidents, I think there would be a _net_ savings (no pun intended) in time spent responding to incidents. You would be wrong. There are networks that have deployed SAV/uRPF. They saw no _net_ savings. In the real world, it costs more to deploy and maintain SAV/uRPF. Have you noticed this thread is full of people who don't run large networks saying other people who do run networks should deploy SAV/uRPF. But there hasn't been anyone who does run large networks saying they deployed SAV/uRPF and it saved them money, made their network run better or improved the world? Where do you draw the line between large and not large? Does a university with a /16 count as large? We do both SAV and a version of uRPF. It makes our network run better, saves us money (reduces the amount of time we spend on support and makes troubled/distressed/evil/mean/nasty boxes easier to track down) and reduces backbone congestion making the network run better. Another benefit is it improves the world (betcha' were wondering if I'd squeeze all that in). We're now blocking all SMTP traffic leaving the campus from non-blessed sources (read mail servers). The first day doing this we had comments about less junk mail traffic. We block traffic we consider harmful that shouldn't leave the campus. We're trying to do our part. Any suggestions how we can do better? Ken
Re: UUNet Offer New Protection Against DDoS
Christopher L. Morrow wrote: miniscule amounts of traffic in uunet's core is still enough to ddos many a victim into oblivion. anyone who has been ddos'd by uunet customers can appreciate that. miniscule is enough to cause problems in anyone's network the point here was: Core isn't the right place for this I wasn't really trying to argue the 'urpf is good' or 'urpf is bad' arguement, just the placement. Sorry if I made that confusing earlier. So we all agree that in the ideal world, everyone has anti-spoofing ACLs and route map filters and what not on every link into their network. But in the real world...given that you are going to be peering with ISPs (or their upstreams) that do not do uRPF or anything at all on their edges, if you want to drop the patently bogus traffic, or your customers don't want to pay you for delivering it to them over links they don't want congested with it, what do you do? I guess you can say peering links are not core, and that's fine if you run loose-uRPF there, and can be assured that all access to your network has filters on all links.I was thinking of large peering routers as part of the core of an ISP, so loose-uRPF is sufficient on those routers, if edges are protected. But if you are going to run loose-uRPF on your peering routers, why not run it on your core? Is there a technogical reason not to? Cisco OC48 line cards not support it (at least some do.), I'm almost sure Juniper does too. But I don't play in that area. And given that there are ISP's running it in the core; that it will block some malicious traffic; and spoofed traffic may well be used as an attack vector again (sometime people are going to have to catch on and patch machines, or worms will patch them for them, and reduce the botnet farm size. Maybe not this year, but sometime...), I still don't see why you are against it. I accept that filtering on all edges, including peering, is a better place to do it. So do you filter on, say, peering links to other tier 1's? Even so, why not have belt AND suspender, and run it in the core?
Re: UUNet Offer New Protection Against DDoS
[EMAIL PROTECTED] (Steve Francis) writes: ... But in the real world...given that you are going to be peering with ISPs (or their upstreams) that do not do uRPF or anything at all on their edges, ... ok, i'll bite. why do we still do this? see the following from june 2001: http://www.cctec.com/maillists/nanog/historical/0106/msg00681.html (and according to that text, it was a 9-year-old idea at that time.) it's now 2004. how much longer do we want to have this problem? -- Paul Vixie
Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sat, 6 Mar 2004, Paul Vixie wrote: (and according to that text, it was a 9-year-old idea at that time.) it's now 2004. how much longer do we want to have this problem? Source address validation (or Cisco's term uRPF) is perhaps more widely deployed than people realize. Its not 100%, but what's interesting is despite its use, it appears to have had very little impact on DDOS or lots of other bad things. Root and other DNS servers bear the brunt of misconfigured (not necessarily malicious attack) devices. So some people's point of view may be different. But relatively few DDOS attacks use spoofed packets. If more did, they would be easier to deal with. After all these years, perhaps its time to re-examine the assumptions.
Re: UUNet Offer New Protection Against DDoS
--On 06 March 2004 23:02 + Paul Vixie [EMAIL PROTECTED] wrote: ok, i'll bite. why do we still do this? see the following from June 2001: http://www.cctec.com/maillists/nanog/historical/0106/msg00681.html Having had almost exactly that phrase in my peering contracts for $n years, the answer is because if you are A, and peer is B, if ( AB ) your spoofed traffic comes (statistically) from elsewhere so you don't notice. You are dealing with traffic from C, where CA else you've signed their peering agreement, and are 'peering' on their terms instead. Was I going to pull peering with $tier1 from whom the occasional DoS came? Nope. The only way this was ever going to work was if the largest networks cascaded the requirements down to the smallest. And the largest networks were the ones for whom (quite understandably) rpf was most difficult. DoS (read unpaid for, unwanted traffic) is one of the best arguments against settlement-free peering (FX: ducks runs). Alex
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
--On 06 March 2004 18:39 -0500 Sean Donelan [EMAIL PROTECTED] wrote: Source address validation (or Cisco's term uRPF) is perhaps more widely deployed than people realize. Its not 100%, but what's interesting is despite its use, it appears to have had very little impact on DDOS or lots of other bad things. ... But relatively few DDOS attacks use spoofed packets. If more did, they would be easier to deal with. AIUI that's cause effect: the gradual implementation of source-address validation has made attacks dependent on spoofing less attractive to perpetrators. Whereas the available of large pools of zombie machines has made the use of source spoofing unnecessary. Cisco et al have shut one door, but another one (some suggest labeled Microsoft) has opened. Those with long memories might draw parallels with the evolution of phreaking from abuse of the core, which became (reasonably) protected to abuse of unprotected PABXen. As I think I said only a couple of days ago, there is nothing new in the world. Alex
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
After all these years, perhaps its time to re-examine the assumptions. it's always fun and useful to re-example assumptions. for example, anyone who assumes that because the attacks they happen to see, or the attacks they hear about lately, don't use spoofed source addresses -- that spoofing is no longer a problem, needs to re-examine that assumption. for one thing, spoofed sources could be occurring outside local viewing. for another thing, spoofed sources could be plan B when other attacks aren't effective. the last thing is, this is war. information warfare. the enemy knows us better than we know them, and their cost of failure is drastically lower than our cost of failure. don't be lulled into some kind of false sense of security by the fact that YOU are not seeing spoofed packets TODAY. let's close the doors we CAN close, and give attackers fewer options.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, Paul Vixie wrote: don't be lulled into some kind of false sense of security by the fact that YOU are not seeing spoofed packets TODAY. let's close the doors we CAN close, and give attackers fewer options. sadly the prevailing thought seems to be 'we cant block every exploit so we will block none'. this (and others) are used as an excuse to not deploy urpf on edge interfaces facing singlehomed customers. its a fatalistic approach to dealing with network abuse, and its retarded. -Dan
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sun, 7 Mar 2004, Paul Vixie wrote: don't be lulled into some kind of false sense of security by the fact that YOU are not seeing spoofed packets TODAY. let's close the doors we CAN close, and give attackers fewer options. I don't have a false sense of security. We have lots of open doors and windows and even missing walls. Let's close the doors we can close, but buying screen doors for igloos may not be the best use of resources. uRPF doesn't actually prevent any attacks. Would you rather ISPs spend money to 1. Deploying S-BGP? 2. Deploying uRPF? 3. Respond to incident reports?
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
Sean Donelan wrote: Would you rather ISPs spend money to 1. Deploying S-BGP? 2. Deploying uRPF? 3. Respond to incident reports? Why are we limited to that set?
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sat, 6 Mar 2004, Dan Hollis wrote: sadly the prevailing thought seems to be 'we cant block every exploit so we will block none'. this (and others) are used as an excuse to not deploy urpf on edge interfaces facing singlehomed customers. This is one of the few locations SAV/uRPF consistently works. SAV/uRPF is widely (but not 100%) deployed int those location. However I think you are mis-stating the issue. I do not know of anyone that has stated your reason as the reason not to deploy SAV/uRPF on non-routing interfaces. The issue which prompt this thread was deploying uRPF on multi-path backbone interfaces using active routing. How many exploits does uRPF block? Biometric smart cards may do wonders for credit card fraud. Why don't credit card companies replace all existing cards with them? Does uRPF solve more problems than it causes, and saves more than it costs?
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
... buying screen doors for igloos may not be the best use of resources. uRPF doesn't actually prevent any attacks. actually, it would. universal uRPF would stop some attacks, and it would remove a plan B option for some attack-flowcharts. i would *much* rather play defense without facing this latent weapon available to the offense. Would you rather ISPs spend money to 1. Deploying S-BGP? 2. Deploying uRPF? 3. Respond to incident reports? yes. and i can remember being sick and tired of competing (on price, no less) against providers who couldn't/wouldn't do #2 or #3. i'm out of the isp business at the moment, but the race to the bottom mentality is still a pain in my hindquarters, both present and remembered.
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sat, Mar 06, 2004 at 06:39:21PM -0500, Sean Donelan wrote: Source address validation (or Cisco's term uRPF) is perhaps more widely deployed than people realize. Its not 100%, but what's interesting is despite its use, it appears to have had very little impact on DDOS or lots of other bad things. Try saying that after running a major DDoS target, with HIT ME your forehead. No offense Sean but I'd like you to back your claim up with some impirical data first. From experience the majority of TCP based denial of service attacks (which usually seem to be balanced with UDP, but ICMP is not as frequent as it once was), use spoofed sources. -- Avleen Vig Systems Administrator Personal: www.silverwraith.com
Re: Source address validation (was Re: UUNet Offer New Protection Against DDoS)
On Sat, 6 Mar 2004, Avleen Vig wrote: On Sat, Mar 06, 2004 at 06:39:21PM -0500, Sean Donelan wrote: Source address validation (or Cisco's term uRPF) is perhaps more widely deployed than people realize. Its not 100%, but what's interesting is despite its use, it appears to have had very little impact on DDOS or lots of other bad things. Try saying that after running a major DDoS target, with HIT ME your forehead. No offense Sean but I'd like you to back your claim up with some impirical data first. Has the number of DDOS attacks increased or decreased in the last few years has uRPF has become more widely deployed? Do you have any evidence the number of attacks are decreasing?
Re: UUNet Offer New Protection Against DDoS
Terranson, Alif wrote: As long as we're doing Me Too... Savvis has had prefix:666 for around 18 months as well. Do you know if CW does? Or will that wait until the integration? This thread has caused me to add this as a requirement for a new gigabit ISP circuit I am ordering, as well as uRPF in the core, etc. I've had two ISPs say We don't do this yet, but based on the fact you are making it a requirement, we will role those functions out into our core. Steve Voting with his money for better net-security Alif Terranson OpSec Engineering Manager Operations Security Department Savvis Communications Corporation (314) 628-7602 Voice (314) 208-2306 Pager (618) 558-5854 Cell -Original Message- From: Michael Hallgren [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 3:45 PM To: [EMAIL PROTECTED] Subject: RE: UUNet Offer New Protection Against DDoS 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 [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
On Fri, 5 Mar 2004, Steve Francis wrote: Terranson, Alif wrote: As long as we're doing Me Too... Savvis has had prefix:666 for around 18 months as well. Do you know if CW does? Or will that wait until the integration? This thread has caused me to add this as a requirement for a new gigabit ISP circuit I am ordering, as well as uRPF in the core, etc. uRPF in the core seems like a bad plan, what with diverse routes and such. Loose-mode might help SOME, but really spoofing is such a low priority issue why make it a requirement? Customer triggered blackholing is a nice feature though. --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
RE: UUNet Offer New Protection Against DDoS
snip uRPF in the core seems like a bad plan, what with diverse routes and such. Loose-mode might help SOME, but really spoofing is such a low priority issue why make it a requirement? Customer triggered blackholing is a nice feature though. /snip Shared view, mh (Teleglobe, btw) --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
Re: UUNet Offer New Protection Against DDoS
Christopher L. Morrow wrote: uRPF in the core seems like a bad plan, what with diverse routes and such. Loose-mode might help SOME, but really spoofing is such a low priority issue why make it a requirement? Customer triggered blackholing is a nice feature though. Obviously loose-mode. Spoofing may not be the current weapon of choice, but why not encourage the best net infrastructure?
RE: UUNet Offer New Protection Against DDoS
Terranson, Alif wrote: As long as we're doing Me Too... Savvis has had prefix:666 for around 18 months as well. Do you know if CW does? Or will that wait until the integration? While I am not 100% certain (and there are plenty of new-Savvis folks here who *do* know for sure ;-), I believe the CW network does support a BH tag. This thread has caused me to add this as a requirement for a new gigabit ISP circuit I am ordering, as well as uRPF in the core, Woah! Never said *anything* about that! No plans for it that I am aware of. No reason I can think of to do this either. etc. I've had two ISPs say We don't do this yet, but based on the fact you are making it a requirement, we will role those functions out into our core. This is really not new, and considering how easy it is to implement, I'm surprised it isn't *much* more widely implemented. Steve Voting with his money for better net-security Go Steve! Go!! Alif Terranson OpSec Engineering Mgr. Operations Security Dept. Savvis Communications Corp. (314) 628-7602 Voice (618) 558-5854 Cell (314) 628-7710 Fax
Re: UUNet Offer New Protection Against DDoS
On Fri, 5 Mar 2004, Steve Francis wrote: Christopher L. Morrow wrote: uRPF in the core seems like a bad plan, what with diverse routes and such. Loose-mode might help SOME, but really spoofing is such a low priority issue why make it a requirement? Customer triggered blackholing is a nice feature though. Obviously loose-mode. Spoofing may not be the current weapon of choice, but why not encourage the best net infrastructure? Loose mode will not save you very much, many larger backbones route lots of 'unused' or 'unallocated' ip space internally for various valid reasons, some even related to security issues for their customers. So, does stopping rfc-1918 (maybe) space help much? not really... atleast not that I can see. Many flooding tools now flood from legittimate space, so the ONLY way to limit this is by filtering as close to the device sourcing the packets as possible. Nebulous filtering and dropping of miniscule amounts of traffic in the core of a large network is just a waste of effort and false panacea. --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
Re: UUNet Offer New Protection Against DDoS
On Fri, 5 Mar 2004, Christopher L. Morrow wrote: the packets as possible. Nebulous filtering and dropping of miniscule amounts of traffic in the core of a large network is just a waste of effort and false panacea. uunet does operate lots of dialup RAS though correct? any reason why urpf is not reasonable there? just because its not perfect and doesnt solve every problem doesnt mean its useless. miniscule amounts of traffic in uunet's core is still enough to ddos many a victim into oblivion. anyone who has been ddos'd by uunet customers can appreciate that. -Dan
RE: UUNet Offer New Protection Against DDoS
On Fri, 5 Mar 2004, Christopher L. Morrow wrote: the packets as possible. Nebulous filtering and dropping of miniscule amounts of traffic in the core of a large network is just a waste of effort and false panacea. Agreed. uunet does operate lots of dialup RAS though correct? any reason why urpf is not reasonable there? Nobody I know terminates a dial connection on a *core router* ;-) //Alif Alif Terranson OpSec Engineering Mgr. Operations Security Dept. Savvis Communications Corp. (314) 628-7602 Voice (618) 558-5854 Cell (314) 628-7710 Fax
Re: UUNet Offer New Protection Against DDoS
On Fri, 5 Mar 2004, Dan Hollis wrote: On Fri, 5 Mar 2004, Christopher L. Morrow wrote: the packets as possible. Nebulous filtering and dropping of miniscule amounts of traffic in the core of a large network is just a waste of effort and false panacea. uunet does operate lots of dialup RAS though correct? any reason why urpf is not reasonable there? For some sure, for others perhaps not :( We have some customers with dedicated networks over dial, some with dial-backup and even some with dsl backup. just because its not perfect and doesnt solve every problem doesnt mean its useless. Sure, I'm just not really sure that the core is the right place to do this... I agree that the edge is a fine place, I'd prefer not my edge :) but the edge is the right place. You can make all the decisions correctly there, you can not in the core. miniscule amounts of traffic in uunet's core is still enough to ddos many a victim into oblivion. anyone who has been ddos'd by uunet customers can appreciate that. miniscule is enough to cause problems in anyone's network the point here was: Core isn't the right place for this I wasn't really trying to argue the 'urpf is good' or 'urpf is bad' arguement, just the placement. Sorry if I made that confusing earlier. --Chris (formerly [EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ###
Re: UUNet Offer New Protection Against DDoS
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 +, 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 JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
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
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 DDoSI 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 DDoSI'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?SteveOn 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
-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
They also are not guaranteeing that opening up the ticket won't take more than 15 minutes. I know a number of networks (when they hear you want to open a ticket for something important), put you on hold, call/page whoever it is and then take 10 minutes to open a ticket. I know I may be nitpicking, but having been on hold BEFORE I've opened a ticket doesn't make me very happy with time-sensitive SLAs. DJ 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 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
On Thu, Mar 04, 2004 at 03:39:30PM +, Alex Bligh wrote: A lot of people seem to be doing this. there is nothing (well very little) new in the world: http://www.merit.edu/mail.archives/nanog/1999-07/msg00083.html Does anyone know if Cogent offer such a community? Anyone from Cogent on the line? -- Avleen Vig Systems Administrator Personal: www.silverwraith.com EFnet:irc.mindspring.com (Earthlink user access only)
Re: UUNet Offer New Protection Against DDoS
- Original Message - From: william(at)elan.net [EMAIL PROTECTED] To: John Obi [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 3:42 AM Subject: Re: UUNet Offer New Protection Against DDoS On Tue, 2 Mar 2004, John Obi wrote: Hello Nanogers! I'm happy to see this, and I hope CW, Verio, and Level3 will do the same! http://informationweek.securitypipeline.com/news/18201396 MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help IP services customers thwart and defend against Internet viruses and threats. --- snippety snip --- Blah, blah, blah I would say this is a lot more like a self-ad then press-release of new service. UUNET already responded within 15 minutes or less to DoS attacks, at least this is what it was several years ago. Possibly this changed when they went ch11 and now they are just trying to get back to normal. But I would not say that this is anything special. Of course, I would be happy to see others say the same too in their SLA, but how about that they simply would just RESPOND in 15 minute to customer request. (And actually one of my upstreams does exactly that they respond and have that in their SLA. And they usually respond within 1-3 minutes and not only do I not have to call them, but they actually call me if the link is down or if there is serious congestion on it. Quite a a bit overzellous actually!) agreed, not very spectacular. in fact, i expect most ddos attack issues to be *resolved* within 15 minutes, for reasonable values of 'most' and 'resolved'. i would probably be very dissatisfied if i could not get to a warm, clueful and enabled body in under 10 minutes in an emergency, but then we are a reasonably large customer of a good smaller carrier so my expectations may be invalid in big boy customer land. paul
Re: UUNet Offer New Protection Against DDoS
- Original Message -
From: Deepak Jain [EMAIL PROTECTED]
To: william(at)elan.net [EMAIL PROTECTED]
Cc: John Obi [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, March 03, 2004 2:56 AM
Subject: Re: UUNet Offer New Protection Against DDoS
william(at)elan.net wrote:
On Tue, 2 Mar 2004, John Obi wrote:
Hello Nanogers!
I'm happy to see this, and I hope CW, Verio, and Level3 will do the
same!
http://informationweek.securitypipeline.com/news/18201396
And what kind of response to DOS are we talking about? Blackholing the
target IP to allow your pipe to pass packets and so that your router is
pingable (which is probably the measure for whether you are up or not?)
cant speak for them, but this would be my preferred first step. next step
is, of course, an attempt to filter on {source, unique characteristics, what
have you} and removing the blackhole.
paul
Re: UUNet Offer New Protection Against DDoS
On Wed, 2004-03-03 at 09:26, Paul G wrote:
cant speak for them, but this would be my preferred first step. next step
is, of course, an attempt to filter on {source, unique characteristics, what
have you} and removing the blackhole.
What most people seem to forget is that neither of these steps actually
counter the DoS...they merely make the DoS as invisible as possible to
customers while the traffic keeps hitting the carrier in question. For
the large carriers this is only a minor inconvenience.
For smaller carriers or for co-location facilities/NSP's that are
relying on not-so-clueful carriers (read: carriers not supporting any
kind of communities with possible lack of pro-active network management
and/or bad communications) this is a BIG problem. Even though they might
take the heat off the targeted customer, they could be in for a rough
ride themselves as the DoS keeps going and going.
I haven't seen any major press-releases on actually solving the problem
instead of hiding it... (granted...I haven't put out one either :-)
Cheers,
--
---
Erik Haagsman
Network Architect
We Dare BV
tel: +31.10.7507008
fax: +31.10.7507005
http://www.we-dare.nl
Re: UUNet Offer New Protection Against DDoS
erik,
- Original Message -
From: Erik Haagsman [EMAIL PROTECTED]
To: Paul G [EMAIL PROTECTED]
Cc: Deepak Jain [EMAIL PROTECTED]; william(at)elan.net [EMAIL PROTECTED];
John Obi [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, March 03, 2004 3:47 AM
Subject: Re: UUNet Offer New Protection Against DDoS
On Wed, 2004-03-03 at 09:26, Paul G wrote:
cant speak for them, but this would be my preferred first step. next
step
is, of course, an attempt to filter on {source, unique characteristics,
what
have you} and removing the blackhole.
What most people seem to forget is that neither of these steps actually
counter the DoS...they merely make the DoS as invisible as possible to
customers
correct. from our pov, it is gone. given that 'solving the problem' is not
always possible, this is almost as good as it gets in the real world.
while the traffic keeps hitting the carrier in question. For
the large carriers this is only a minor inconvenience.
For smaller carriers or for co-location facilities/NSP's that are
relying on not-so-clueful carriers (read: carriers not supporting any
kind of communities with possible lack of pro-active network management
and/or bad communications) this is a BIG problem. Even though they might
take the heat off the targeted customer, they could be in for a rough
ride themselves as the DoS keeps going and going.
we tend to get small ddos (a few hundred megs) that are more of an annoyance
than anything else, at least before they hit the customer-in-question 's
faste handoff.
I haven't seen any major press-releases on actually solving the problem
instead of hiding it... (granted...I haven't put out one either :-)
grin. in other news, noone has solved the perpetuum mobile problem either.
as a carrier, your job is to solve the problem for the customer. this
includes staying up afterwards.
paul
RE: UUNet Offer New Protection Against DDoS
From: On Behalf Of John Obi Sent: Wednesday, March 03, 2004 2:21 AM MCI/WorldCom Monday unveiled a new service level agreement (SLA) At the risk of sounding thoroughly underwhelmed... Uhm, where's the beef? All I see is the opportunity to get a service credit should one complain loud enough after a DoS attack. Maybe I'm missing something here, but I doubt it. I've never seen an SLA that guarantees 5 9's of reliability keep a T1 from going down - but the paper it was written on was nice... somewhat soft, and you didn't have to worry about your finger poking through it. -- Douglas A. Dever ACI/IT Network Services ALLTEL Communications Inc. 330.963.1720 ** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else.
Re: UUNet Offer New Protection Against DDoS
Hi Paul, snip correct. from our pov, it is gone. given that 'solving the problem' is not always possible, this is almost as good as it gets in the real world. Fully agree, and this is basically the way it should be: a customer shouldn't be concerned about the carrier solving the problem or not, as long as service isn't interrupted the carrier is doing the job he's promised to do in his SLA we tend to get small ddos (a few hundred megs) that are more of an annoyance than anything else, at least before they hit the customer-in-question 's faste handoff. This is a bit more problematic IMHO. A small DoS is very geographically dependent and very supporting party dependent: in Ghana with BT as the only provider running over DS3, a few hundred megs means the entire network is cut-off for ages :-) I know this is NANOG and bandwidth is a simple commodity, but even in our parts of the western world bandwidth can be hard to come by and a few hundred megs might be a bigger deal to a smaller NSP's network. grin. in other news, noone has solved the perpetuum mobile problem either. as a carrier, your job is to solve the problem for the customer. this includes staying up afterwards. Hehe...sadly this perpetuum mobile keeps on running and running (which is what it's supposed to do literally :-) but you're completely right: cutomers should always come first and hiding the problem is our only option at the moment. I'm still waiting for that press-release though :-) Regards, Erik paul -- --- Erik Haagsman Network Architect I haven't seen any major press-releases on actually solving the problem instead of hiding it... (granted...I haven't put out one either :-) We Dare BV tel: +31.10.7507008 fax: +31.10.7507005 http://www.we-dare.nl
Re: UUNet Offer New Protection Against DDoS
The key here is that it is part of the SLA. Customers are elligible for credit based on outages depending on the circumstance. In the past this was only telco and backbone related outages. Therefore, depending on the nature of the attack and the cooperation of the customer, they ~may~ be elligible for partial credit. [Wed, Mar 03, 2004 at 12:42:05AM -0800] william(at)elan.net Inscribed these words... On Tue, 2 Mar 2004, John Obi wrote: Hello Nanogers! I'm happy to see this, and I hope CW, Verio, and Level3 will do the same! http://informationweek.securitypipeline.com/news/18201396 MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help IP services customers thwart and defend against Internet viruses and threats. The new SLA is focused on Denial of Service (DoS) attacks and is extended immediately for free to all current customers of the telecommunications company, according to MCI. It ensures that all MCI Internet customers will have immediate access to the company's security staff to help them rapidly address and mitigate DoS attacks According to Santarelli, MCI will guarantee a response to suspected DoS attacks within 15 minutes of a customer-generated trouble-ticket through MCI Customer Support Blah, blah, blah I would say this is a lot more like a self-ad then press-release of new service. UUNET already responded within 15 minutes or less to DoS attacks, at least this is what it was several years ago. Possibly this changed when they went ch11 and now they are just trying to get back to normal. But I would not say that this is anything special. Of course, I would be happy to see others say the same too in their SLA, but how about that they simply would just RESPOND in 15 minute to customer request. (And actually one of my upstreams does exactly that they respond and have that in their SLA. And they usually respond within 1-3 minutes and not only do I not have to call them, but they actually call me if the link is down or if there is serious congestion on it. Quite a a bit overzellous actually!) -- William Leibzon Elan Networks [EMAIL PROTECTED] -- Stephen (routerg) irc.dks.ca
RE: UUNet Offer New Protection Against DDoS
Hi John, While the formalities of the CW acquisition have yet to kick in, I have no reason to believe that anything will change here: Savvis pioneered the 15 minute response time for DoS issues - whether or not it's our customer calling in. If it involves Savvis customers in any way, we will have the oncall security person on the phone and working the issue in less than 15 minutes - *always* (usual times are closer to 3 minutes because of the oncall cell phone). //Alif Alif Terranson OpSec Engineering Manager Operations Security Department Savvis Communications Corporation (314) 628-7602 Voice (314) 208-2306 Pager (618) 558-5854 Cell -Original Message- From: John Obi [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 1:21 AM To: [EMAIL PROTECTED] Subject: UUNet Offer New Protection Against DDoS Hello Nanogers! I'm happy to see this, and I hope CW, 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 youre looking for faster.
Re: UUNet Offer New Protection Against DDoS
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 CW, 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 youre looking for faster.
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 CW, 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 youre looking for faster. -- Stephen (routerg) irc.dks.ca
Re: UUNet Offer New Protection Against DDoS
On Mar 3, 2004, at 11:24 AM, Stephen Perciballi wrote: 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. Indeed. One could even get fancy and set of different community sets to allow customers to drop traffic only on peering routers (as opposed to customer or all routers, etc..). The Customer-Triggered Real Time Blackhole tutorial that Chris, Tim and I gave in Miami talks about how to go about doing this. One step further is uRPF coupling with blackhole routing for sourced- based drops, though I suspect you probably won't want to do this with customers :-) Finally, the BGP Flow Specification stuff provides a start at a more granular BGP-based method by employing new AFI/SAFI. If you've got feedback please pass it along. http://www.tcb.net/draft-marques-idr-flow-spec-00.txt -danny
Re: UUNet Offer New Protection Against DDoS
Hi, NANOGers. ] 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: UUNET/MCI has had that capability since circa 2002, I believe. Several ISPs borrowed heavily from the following page to create similar services. http://www.secsup.org/CustomerBlackHole/ Kudos to Chris and Brian. :) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
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 CW, 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
Re: UUNet Offer New Protection Against DDoS
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
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 [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'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
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 [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
As long as we're doing Me Too... Savvis has had prefix:666 for around 18 months as well. Alif Terranson OpSec Engineering Manager Operations Security Department Savvis Communications Corporation (314) 628-7602 Voice (314) 208-2306 Pager (618) 558-5854 Cell -Original Message- From: Michael Hallgren [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 3:45 PM To: [EMAIL PROTECTED] Subject: RE: UUNet Offer New Protection Against DDoS 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 [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
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
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 ! 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.
Re: UUNet Offer New Protection Against DDoS
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
Re: UUNet Offer New Protection Against DDoS
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 CW^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 [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
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
On Mar 3, 2004, at 5:51 PM, Lumenello, Jason wrote: 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. A lot of people seem to be doing this. Mind if I ask what's the harm of letting customers announce /32 or /29s into your core as long as you filter at your borders? The additional prefixes are not going to kill your routers, and it allows the customer more finely tuned traffic controls. IOW: Seems there is some utility and no harm. -- TTFN, patrick
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: [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
[..] 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
Re: UUNet Offer New Protection Against DDoS
[..] 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
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
- Original Message - From: Suresh Ramasubramanian [EMAIL PROTECTED] To: Randy Bush [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 8:21 PM 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? 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
Re: UUNet Offer New Protection Against DDoS
--- Patrick W.Gilmore [EMAIL PROTECTED] 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 youre looking for faster
http://search.yahoo.com
UUNet Offer New Protection Against DDoS
Hello Nanogers! I'm happy to see this, and I hope CW, 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 youre looking for faster.
Re: UUNet Offer New Protection Against DDoS
On Tue, 2 Mar 2004, John Obi wrote: Hello Nanogers! I'm happy to see this, and I hope CW, Verio, and Level3 will do the same! http://informationweek.securitypipeline.com/news/18201396 MCI/WorldCom Monday unveiled a new service level agreement (SLA) to help IP services customers thwart and defend against Internet viruses and threats. The new SLA is focused on Denial of Service (DoS) attacks and is extended immediately for free to all current customers of the telecommunications company, according to MCI. It ensures that all MCI Internet customers will have immediate access to the company's security staff to help them rapidly address and mitigate DoS attacks According to Santarelli, MCI will guarantee a response to suspected DoS attacks within 15 minutes of a customer-generated trouble-ticket through MCI Customer Support Blah, blah, blah I would say this is a lot more like a self-ad then press-release of new service. UUNET already responded within 15 minutes or less to DoS attacks, at least this is what it was several years ago. Possibly this changed when they went ch11 and now they are just trying to get back to normal. But I would not say that this is anything special. Of course, I would be happy to see others say the same too in their SLA, but how about that they simply would just RESPOND in 15 minute to customer request. (And actually one of my upstreams does exactly that they respond and have that in their SLA. And they usually respond within 1-3 minutes and not only do I not have to call them, but they actually call me if the link is down or if there is serious congestion on it. Quite a a bit overzellous actually!) -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: UUNet Offer New Protection Against DDoS
william(at)elan.net wrote: On Tue, 2 Mar 2004, John Obi wrote: Hello Nanogers! I'm happy to see this, and I hope CW, Verio, and Level3 will do the same! http://informationweek.securitypipeline.com/news/18201396 And what kind of response to DOS are we talking about? Blackholing the target IP to allow your pipe to pass packets and so that your router is pingable (which is probably the measure for whether you are up or not?) Deepak Jain AiNET
