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:m.hallgren@free.fr] Sent: Wednesday, March 03, 2004 3:45 PM To: nanog@merit.edu 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 jamesh@cybermesa.com At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
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 C&W 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:m.hallgren@free.fr] Sent: Wednesday, March 03, 2004 3:45 PM To: nanog@merit.edu 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 jamesh@cybermesa.com At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
On 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 C&W 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 chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
<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 chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
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?
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 chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
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
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 chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
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?
steve@expertcity.com (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
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.
--On 06 March 2004 18:39 -0500 Sean Donelan <sean@donelan.com> 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
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
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?
sean@donelan.com (Sean Donelan) writes:
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?
the number of spoofed-source attacks is down only-slightly.
Do you have any evidence the number of attacks are decreasing?
the overall number of attacks and their volume seems to be decreasing ever-so-slightly, but the ferocity of the attacks that come through seems to be increasing more-than-slightly. and, when defending against one of these, every valid source address is worth its figurative weight in gold, and constitutes a minor compromise for the attacker, even if the host it helps to identify is disposable, easily replaced, and difficult to repair. [ of course, sean, i could just be making that part up. but since i keep saying it and since i get attacked pretty frequently, i might be telling the truth. it could be worth assuming a little credibility and seeing where that leads you. (but, we digress.) ] -- Paul Vixie
On 7 Mar 2004, Paul Vixie 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?
sean@donelan.com (Sean Donelan) writes: the number of spoofed-source attacks is down only-slightly.
the % of spoofed and bogon traffic was measured recently at several of the root nameservers. iirc it was suprisingly high. -Dan
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
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.
On Sun, Mar 07, 2004 at 08:28:53PM +0000, 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.
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)
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.
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 chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
On Sun, Mar 07, 2004 at 08:35:54PM +0000, Christopher L. Morrow wrote:
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.
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, but having gone ahead and filtered it, nothing appears to have broken, or at least nothing got called in. We've been doing it for several months now. /vijay
vgill@vijaygill.com (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
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 chris@uu.net) ####################################################### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## #######################################################
[two responses here] -------- 1 of 2 fingers@fingers.co.za (fingers) writes:
why is DDoS the only issue mentioned wrt source address validation?
i'm sure there's other reasons to make sure your customers can't send spoofed packets. ...
yes. for example, most forms of dns cache pollution rely on the ability to forge a udp source address on a well-timed response. several of you have pointed out that as long as at least one edge network is free from uPRF, then something like dnssec will still be vitally necessary -- and that's true. but, if the places where forged-source were possible could be enumerated, then the fact of the forgery would be useful to a victim. right now those places are innumerable, and so, anonymity is complete. -------- 2 of 2 hackerwacker@cybermesa.com (James Edwards) writes:
uRPF, strict mode, is how I control 1000+ DSL pvc's from leaking private address space via broken NAT. ...
so what you're saying is, these packets (captured on one of the f-root servers just now) wasn't from your network? THANKS! (anybody else here want to claim this slackage?) tcpdump: listening on fxp0 21:06:42.331994 192.168.15.3.1053 > 192.5.5.241.53: 15396 A? wustat.windows.com. (36) 21:06:42.349184 10.1.0.15.1025 > 192.5.5.241.53: 6182 NS? . (17) 21:06:42.427980 10.10.1.1.1041 > 192.5.5.241.53: 53830 NS? . (17) 21:06:42.559860 10.19.1.101.1032 > 192.5.5.241.53: 8434 [1au] A? SPPOLCD01.POL. (42) 21:06:42.688972 192.168.7.76.1036 > 192.5.5.241.53: 14986 A? rsthost2.ods.org. (34) 21:06:43.793914 192.168.160.252.1024 > 192.5.5.241.53: 28233 MX? jimaz.cz. (26) (DF) 21:06:44.048702 10.10.10.250.53 > 192.5.5.241.53: 2051 A? tock.usno.navy.mil. (36) 21:06:44.123787 10.101.58.16.1120 > 192.5.5.241.53: 9741 PTR? 169.16.187.208.in-addr.arpa. (45) 21:06:44.394578 10.8.0.22.1036 > 192.5.5.241.53: 15001 A? mail.inf101.net. (33) 21:06:44.578893 10.8.0.22.1036 > 192.5.5.241.53: 15002 MX? ezrs.com. (26) 2027 packets received by filter note that this particular box has dropped a fair amount of this crud since its last reboot: rule# packets octets ----------------rule----------------- 00400 27149821 1707500202 deny ip from 10.0.0.0/8 to any in 00500 1710989 109992242 deny ip from 172.16.0.0/12 to any in 00600 6144955 392168290 deny ip from 192.168.0.0/16 to any in 9:16PM up 37 days, 15:55, 1 user, load averages: 0.04, 0.01, 0.00 also note that it's only one of about fifty similar servers. i don't have an easy way to aggregate the slackage numbers yet, but i sure would like them to be zero or at least lower. (and, for my part in rfc 1918, i now beg forgiveness.)
Based on my limited experience with all of this it seems the place for uRPF is not at the core (core in the context of the Internet backbone) but at the customer edge, where the problem starts.
that's sort of what http://www.icann.org/committees/security/sac004.txt says. -- Paul Vixie
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 : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
--On 06 March 2004 23:02 +0000 Paul Vixie <vixie@vix.com> 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 ( A>B ) your spoofed traffic comes (statistically) from elsewhere so you don't notice. You are dealing with traffic from C, where C>>A 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
participants (13)
-
Alex Bligh -
Avleen Vig -
Christopher L. Morrow -
Dan Hollis -
E.B. Dreger -
fingers -
Laurence F. Sheldon, Jr. -
Michael Hallgren -
Paul Vixie -
Sean Donelan -
Steve Francis -
Terranson, Alif -
vijay gill