January 2003 - NANOG - lists.nanog.org

Network Design Consultant
by K. Scott Bethke 20 Jan '03

20 Jan '03

Can anyone here recommend an individual or company who would analyze a working network design from head to toe, suggesting changes and improvements where needed. This would include overall design from a high level but also analyze actual router/switch config's. Looking for someone/somecompany who is not vendor specific, and experienced with high performance, redundant networks. Please respond offlist. I am happy to summarize for anyone interested. -Scotty

1 0

quick note on hash based tracebacks
by Craig Partridge 20 Jan '03

20 Jan '03

The capabilities of hash-based tracebacks has come up a few times in the past couple of days. Most of the discussion has been quite accurate (always nice to see one's work understood!) but there are two points that I thought might benefit from clarification: > The SPIE hash-based > traceback is a much cooler idea, but it has some practical limitations, > including the need to do the trace in more or less real-time (once the > hash table fills up, it becomes useless), and the need for very large > amounts of very fast memory on the tracing routers. So that folks understand this point. SPIE requires a fast memory that equals a fraction of a second (fraction varies depending on configuration) times about .2% of link bandwidth to store its hash information. It then expects each router to cache (on disk) all the hash tables recorded for some period of time. You can actually reduce the router's storage needs by simply sending old hash tables off to an archive (say at your operations center). [Remember, the amount of data kept is a fraction of a percent of the link speed -- so even if you've got ten lines into a box, the total bandwidth required to copy their tables to an archive is, *at worst*, around 1%-2% of the bandwidth of the fastest link]. > There was an IETF > BoF on it, but the folks behind it haven't been pushing it much. > (Randy, do you know the status of it?) Randy encouraged us to go off and write a spec on our own and just bring it to IETF when done. Since we've got a customer paying us to work on a deployable system in his network, we figured we'd take advantage of the experience (something about "running code" :-)). Craig PS: For more info, see the paper in the lastest issue of IEEE/ACM Trans. on Networking, or read the (somewhat less detailed) paper from ACM SIGCOMM 2001. The SIGCOMM paper is available on-line at no charge: http://doi.acm.org/10.1145/383059.383060

1 0

RE: uunet
by Chad Skidmore 20 Jan '03

20 Jan '03

Last week we experienced a significant (for us anyway) DDOS against one of our customers and UUNET was one of the quickest to respond. No, we are not a UUNET customer but Chris (with UUNET) responded very quickly (within 30min I believe) to a post we made to a mail list and began blackholing traffic in UUNET's network. BTW, this was at about 10:30pm on a Monday night his time. WorldCom/UUNET is an easy company to beat on (and probably deserves it some of the time) but the UUNET security team is, in my opinion, top notch. They have been very willing to share information and techniques and been very willing to help others implement DDOS/DOS tracking. I'm not disputing the fact that you probably had a bad experience getting through to the right person. It sounds like the UUNET NOC (like many NOCs) was not terribly helpful. Other forms of communication like NANOG and nsp-sec are often times better forms of communication when it comes to DOS/DDOS attacks and other security issues. Hopefully that will change over time. Regards, Chad ----------------------------------- Chad Skidmore One Eighty Networks http://www.go180.net 509-688-8180 -----Original Message----- From: Scott Granados [mailto:scott@wworks.net] Posted At: Sunday, January 19, 2003 2:27 PM Posted To: NANOG Conversation: uunet Subject: Re: uunet Its just unfortunate that some companies not mentioning names feel this is good practice. Others don't feel this way which is a good thing. Just a note, uunet wouldn't take my call when a ddos attach originated on their network either. Same response with the exception of "Well we don't have security persons available after hours so write us an e-mail and you may get a response within 48 hours". Which to me sounded just plain wrong because I've seen threds onhere to the contrary. ----- Original Message ----- From: "blitz" <blitz(a)macronet.net> To: "Scott Granados" <scott(a)wworks.net> Cc: <nanog(a)merit.edu> Sent: Sunday, January 19, 2003 1:24 AM Subject: Re: uunet > I'll copy this email, and keep it for reference when someone asks > about buying service from UUnet...thanks... > > At 17:17 1/18/03 -0800, you wrote: > > >What's interesting is that I just tried to call the noc and was told > >"We have to have you e-mail the group" > > > >my response, I can't I have no route working to uunet > > > >"Well you have to" > > > >my response, ok I'll use someone elses mail box where do I mail? > > > >"We can't tell you your not a customer" > > > >My response its a routing issue do you have somewhere I can e-mail > >you. > > > >"Your not my customer I really don't care" *click* > > > >Nice. professional too. > > > >Anyone have a number to the noc that someone with clue might answer? > > > >----- Original Message ----- > >From: "David Diaz" <techlist(a)smoton.net> > >To: "Scott Granados" <scott(a)wworks.net>; <nanog(a)merit.edu> > >Sent: Saturday, January 18, 2003 4:35 PM > >Subject: Re: uunet > > > > > > > Im not seeing anything coming from qwest. > > > > > > > > > > > > At 16:55 -0800 1/18/03, Scott Granados wrote: > > > >Is something up on uunet tonight? > > > > > > > >It looks to me that dns is broken forward and reverse but more > > > >likely it > > > >looks like a bad bogan fiilter popped up suddenly. I have issue > > > >as soon > >as > > > >I leave mfn's network and hit uunet. > > > > > > -- > > > > > > David Diaz > > > dave(a)smoton.net [Email] > > > pagedave(a)smoton.net [Pager] > > > www.smoton.net [Peering Site under development] > > > Smotons (Smart Photons) trump dumb photons > > > > > > > > > > >

1 0

Tracking a DDOS
by Roger Marquis 20 Jan '03

20 Jan '03

One of our clients sustained a severe SMTP DDOS attack on New Years' Day. The DDOS was caused by a bulk mailing which had forged their domain name in the return address. The attack was staged over several days from dial-up lines at fast.net (Bethlehem, PA). We contacted fast.net shortly after the massmail began but it continued unabated for two additional days. Some of the source IPs were eventually listed by MAPS and Wirehub and they're still listed to this date. 5 minutes after our call to fast.net's support desk we tracked a portscan from one of their netblocks (206.245.164.0-206.245.164.255, Internet Unlimited, at nearly the same address in Bethlehem, PA). A quick check of the reverse DNS revealed nearly exclusive use by porn, throw-away, and otherwise spam domains. Though we're still tabulating damages and collecting evidence it appears the DDOS was hosted by and allowed to continue unabated by fast.net (aka iuinc.com) after they had knowledge of the problem, knowledge of its source, and knowledge of its effects. Since fast.net/iuinc.com has not replied to our email or phone calls we're looking for anyone with information on this company, its owners or operators, and any history of network or SMTP abuse. All help will be appreciated and kept confidential. Thanks in advance, -- Roger Marquis Roble Systems Consulting http://www.roble.com/

4 4

Re: Is there a line of defense against Distributed Reflective attacks?
by John Kristoff 19 Jan '03

19 Jan '03

On Thu, Jan 16, 2003 at 08:48:03PM -0500, Brad Laue wrote: > Having researched this in-depth after reading a rather cursory article > on the topic (http://grc.com/dos/drdos.htm) only two main methods come > to my mind to protect against it. There are a few more methods, some have already mentioned including something called pushback. Very few solutions, particularly elegant ones are widely deployed today. At some point, sophisticated (or even not so sophisticated) DoS attacks can be hard to distinguish between valid traffic, particularly if widely distributed and traffic is as valid looking as any other bit of traffic. > By way of quick review, such an attack is carried out by forging the > source address of the target host and sending large quantities of > packets toward a high-bandwidth middleman or several such. It doesn't have to be forged, that step just makes it harder to trace back to the original source. There are some solutions that try to deal with this, including an IETF working group called itrace. UUNET also developed something called CenterTrack. BBN has something called Source Path Isolation Engine (SPIE). There are probably other things I'm forgetting, but generally are similar in concept to these. > To my knowledge the network encompassing the target host is largely > unable to protect itself other than 'poisoning' the route to the host in > question. This succeeds in minimizing the impact of such an attack on This is true, the survivability of the victim largely depends on the security of everyone else, which makes solving the problem so exceptionally difficult. > the network itself, but also acheives the end of removing the target > host from the Internet entirely. Additionally, if the targetted host is > a router, little if anything can be done to stop that network from going > down. I'm not sure I fully understand what you're saying here, but a router can be effectively be taken out of service as any other end host or network can by simply overwhelming it with packets to process (for itself or to be forwarded). > One method that comes to mind that can slow the incoming traffic in a > more distributed way is ECN (explicit congestion notification), but it > doesn't seem as though the implementation of ECN is a priority for many > small or large networks (correct me if I'm wrong on this point). If ECN ECN cannot be an effective solution unless you trust all edge hosts, including the attacking hosts, will use it. Since it is a mechanism that is used to signal transmitting hosts to slow down, attackers can choose not to implement ECN or ignore ECN signals. Unless you could control all the ends hosts, and as long as there is intelligence in the end hosts a user could modify, this won't help. > is a practical solution to an attack of this kind, what prevents its > implementation? Lack of awareness, or other? It is still fairly new and not widely deployed. Routers need not only to support it, but also have to be enabled to use it. It is a fairly significant change to the way congestion control is currently done in the Internet and it will take some time before penetration occurs. > Also, are there other methods of protecting a targetted network from > losing functionality during such an attack? Many are reactive, often because you can't know what a DoS is until its happening. In that case, providers can use BGP advertisements to blackhole hosts or networks (though that can essentially finish the job the attacker started). If attacks target a DNS name, the end hosts can change their IP address (though DNS servers may still get pounded). If anything unique about the attack traffic can be determined, filters or rate limits can be placed as close to the sources as possible to block it (and that fails as attack traffic becomes increasingly dispersed and identical to valid traffic). If more capacity than attack traffic uses can be obtained, the attack could be ignored or mitigated (but this might be expensive and impractical). If the sources can be tracked, perhaps they can be stopped (but large number of sources make this a scaling issue and sometimes not all responsible parties are as cooperative or friendly as you might like). There is also the threat of legal response, which could encourage networks and hosts to stop and prevent attacks in the future (this could have negative impacts for the openness of the net and potentially be difficult to enforce when multiple jurisdiations are involved). >From a proactive approach, hosts could be secured to prevent an outsider from using it for attack. The sorry state of system security doesn't seem to be getting better and even if we had perfect end system security, an attacker could still use their own system(s) to launch attacks. Eventually it all boils down to a physical security problem. Pricing models can be used to make it expensive to send attack traffic. How to do the billing and who to bill might not be so easy. ...and there may always be a provider who charges less. Rate limits can be used on a per source, per protocol or per flow basis. Given enough hosts and not enough deployment in the network, this has yet to be effective. Similarly, network based queueing mechanisms (e.g. RED), or pushback approaches already mentioned, which penalize or limit high rate flows are not widely deployed yet. It often takes a combination of techniques used by as many people as possible. Good incident response teams for as many responsible network operators as possible and continued, quicker deployment of best practices to as many network operators, end users and systems developers as possible. ...or you architecturally change the Internet or not use the Internet. For example, go back to dumb end systems and place all the control into the network operated by a select few (e.g. the traditional telephone model). You potentially lose all the good properties the current architecture has and you aren't going to get everyone to change with you anytime soon. I highly recommend Bruce Schneier's book Secrets and Lies, which applies to so much of all these problems and gives you a lot more to think about in a much more readable way than what I have said here. It is especially insightful with regards to all the non- technical problems and non-technical responses to the problems. John

7 9

RE: FW: Re: Is there a line of defense against Distributed Reflective attacks?
by Ray Burkholder 19 Jan '03

19 Jan '03

This whole 'Internet Thing' is a one of the wonders of the modern world. A public transport system that has handled growth easily and efficiently for many years. Some people get leisure from it, some make money from it, some do research on it, some communicate on it,.... It is one of the most pervasive things I've seen. Because of the internet's inherent distributed nature, legislation will get you no where, and besides,l legislation is the easy way out, and not very effective at that. Market forces and the golden rule (if that combo actually works, I'd be amazed) should drive the direction of this dynamic animal we call 'The Internet'. If we lived in Nirvana, the Internet would be a beautiful thing. But as we live in reality, we have to take the good with the bad. But overall, I think the Good is winning over the Bad. I say: Cool. Ray Burkholder > -----Original Message----- > From: todd glassey [mailto:todd.glassey@worldnet.att.net] > Sent: January 19, 2003 12:02 > To: Christopher L. Morrow; Stewart, William C (Bill), RTLSL > Cc: nanog(a)trapdoor.merit.edu > Subject: Re: FW: Re: Is there a line of defense against > Distributed Reflective attacks? > > > You nor any of the ISP's may like this but the facts of the > matter are pretty clean and easily discerned and they all > point to the Governance Model for developing and releasing > protocols whole cloth on the Internet, no matter what they > enable people to do. Its time to take a close accounting of > what this "Internet" thing really is and put some stronger > legislation in place. > > Todd Glassey > > ----- Original Message ----- > From: "Christopher L. Morrow" <chris(a)UU.NET> > To: "Stewart, William C (Bill), RTLSL" <billstewart(a)att.com> > Cc: <nanog(a)trapdoor.merit.edu> > Sent: Friday, January 17, 2003 6:29 PM > Subject: Re: FW: Re: Is there a line of defense against > Distributed Reflective attacks? > > > > > > > > On Fri, 17 Jan 2003, Stewart, William C (Bill), RTLSL wrote: > > > > > > > > > > > > > > -----Original Message----- > > > From: Stewart, William C (Bill), RTLSL > > > Sent: Friday, January 17, 2003 5:35 PM > > > To: 'nanog-post(a)trapdoor.merit.edu' > > > Subject: Re: Is there a line of defense against Distributed > > > Reflective attacks? > > > > > > > > > Many of these attacks can be mitigated by ISPs that do > anti-spoofing > > > filtering on input - only accepting packets from user > ports > > > > Sure, but this is a proven non-scalable solution. HOWEVER, > filtering > > as close to the end host is scalable and feasible... do it > there, it > > makes MUCH more sense to do it there. > > > > > that have IP addresses that are registered for that port, and not > > > accepting incoming packets from outside their network > that claim to > > > be from inside (except maybe from registered dual-homed > hosts.) > > > This cuts down on many opportunities for forgery, > > > and means that SYN Flood attacks have a much more limited set of > > > addresses they can forge (e.g. an attacker or zombie can only > > > impersonate other ips sharing its /24 or /29, so it can't > pretend to > > > be its victim in a reflection or smurf attack.) > > > > > > That doesn't stop all reflection attacks; a zombie on a > network that > > > doesn't do anti-spoofing can send SYNs to a big server on > a network > > > that also doesn't anti-spoof, so the server will still SYN-ACK > > > > its not the 'server' that needs 'anti-spoof' its the end host, the > > machine in your livingroom that is on a cable modem for instance... > > the server in this instance is a simple, innocent, machine > doing its > > business. > > > > > to the victim. This cuts out a lot of potential zombie/server > > > pairs. If the server that's being used for reflection is > someone the > > > victim would often talk to, that's a problem (you'd > rather not block > > > connections to Yahoo), but if it's someone the victim > doesn't care > > > about talking to (like router23.example.net) you don't > mind blocking > > > it. (Also, why is router23.example.net SYNACKing somebody > it doesn't > > > know?) > > > > > > > This is an interesting point. The routers shouldn't really > syn-ack (in > > this example) bgp from 'unknown' places... unless you are a > neighbor > > you get squat, or that would be a nice feature, eh? :) For > some folks, > > the problems aren't confined to just bgp, telnet or ssh on > routers are > > also problemmatic, vty acl's are important :) > > > > > But there are probably 20 million web servers or Kazaa or > IM clients > > > out > there, > > > and probably half of them are on networks that don't > spoof-proof, so > > > blocking those is much tougher than blocking the big > ones. And next > > > stop - reflection attacks using big domain servers... > > > > > > > Hmm, I'm not sure, again, that the spoof proof needs to be on the > > kazaa server network, it needs to be on the network where the > > originating attacke is, preferrably as close to that host > as possible, > > like it's default router... Now, the problems with 60million kazaa > > clients openning the floodgates on you are a whole nother problem :) > > > > >

1 0

[Article] RIAA: ISPs should pay for music swapping
by Hank Nussbacher 19 Jan '03

19 Jan '03

http://news.com.com/2100-1023-981281.html?tag=fd_top "CANNES, France--A top music industry representative said Saturday that telecommunications companies and Internet service providers will be asked to pay up for giving their customers access to free song-swapping sites." It gets better. Read the whole thing! -Hank

1 0

FW: Re: Is there a line of defense against Distributed Reflective attacks?
by Stewart, William C (Bill), RTLSL 19 Jan '03

19 Jan '03

-----Original Message----- From: Stewart, William C (Bill), RTLSL Sent: Friday, January 17, 2003 5:35 PM To: 'nanog-post(a)trapdoor.merit.edu' Subject: Re: Is there a line of defense against Distributed Reflective attacks? Many of these attacks can be mitigated by ISPs that do anti-spoofing filtering on input - only accepting packets from user ports that have IP addresses that are registered for that port, and not accepting incoming packets from outside their network that claim to be from inside (except maybe from registered dual-homed hosts.) This cuts down on many opportunities for forgery, and means that SYN Flood attacks have a much more limited set of addresses they can forge (e.g. an attacker or zombie can only impersonate other ips sharing its /24 or /29, so it can't pretend to be its victim in a reflection or smurf attack.) That doesn't stop all reflection attacks; a zombie on a network that doesn't do anti-spoofing can send SYNs to a big server on a network that also doesn't anti-spoof, so the server will still SYN-ACK to the victim. This cuts out a lot of potential zombie/server pairs. If the server that's being used for reflection is someone the victim would often talk to, that's a problem (you'd rather not block connections to Yahoo), but if it's someone the victim doesn't care about talking to (like router23.example.net) you don't mind blocking it. (Also, why is router23.example.net SYNACKing somebody it doesn't know?) But there are probably 20 million web servers or Kazaa or IM clients out there, and probably half of them are on networks that don't spoof-proof, so blocking those is much tougher than blocking the big ones. And next stop - reflection attacks using big domain servers...

3 2

Re: NYT on Thing.net (fwd)
by Paul Wouters 19 Jan '03

19 Jan '03

(Some more background on the Flashback censorship issue) Paul ---------- Forwarded message ---------- Date: Tue, 14 Jan 2003 01:08:20 +0100 From: Zenon Panoussis <oracle(a)provocation.net> Cc: Kurt Erik Lindqvist <kurtis(a)kurtis.pp.se>, batz <batsy(a)vapour.net>, nanog(a)merit.edu To: Paul Wouters <paul(a)xtdnet.nl> Subject: Re: NYT on Thing.net Paul Wouters wrote: > > Perhaps Zenon (Whom I cc:ed just because he knows the details) can > shed some more light on this. I hosted and am still hosting a partial mirror of the old Flashback, including the nazi site that caused the controversy, I know Jan Axelsson personally and I got the story mainly straight from him. Whether this makes the story more accurate or more biased is an open issue for you to decide. In any case, much of the correspondence between Axelsson and the upstreams, as well as between Axelsson and the authorities, rolled out on my fax at some point. All the paperwork I saw corroborated Axelsson's story and none contradicted it. In the first round, Björn Fries, a social-democratic city council member in Karlskrona, demanded that Flashback would remove the nazi site. Flashback refused and advised Fries to report the site to the prosecutor. Fries did so, but he was not the first one; others had filed reports too. The prosecutor found no reason to act. Fries, claiming that he was acting as a private individual and as a social-democratic polititian but *not* as a city council member, turned to Flashback's upsteam and demandedaction against Flashback. In fact, he did so on the letterhead of the city of Karlskrona and had the city lawyer do all the paperwork. The upstream (Air2net?) basically shrugged their shoulders. Fries went to the upstream's upstream while at the same time he mounted a broad and rather populistic media campaign in which all the issues were blurred down to "the nazis are bad". At approximately the same time, some corporations (notableSE Banken) stated to the upstream's upstream (I am almost sure that was UUnet, but I can't swear on it) that they would only use the services of "nazi-free" providers. The top upstream gave an ultimatum to the bottom one and the bottom one told Axelsson that they were extremely sorry, but it was either Flashback off the air or Flashback *and* the upstream off the air. Flashback was cut off. In the second round, Axelsson went shopping for connectivity. He got the one quote after the other with the standard "we will be pleased to welcome you as a customer", but shortly later the one ISP after the other backed off until none was left. At this time, at the initiative of Fries and through letters written by the Karlskrona city lawyer, the Swedish association of ISPs (I forget its name; something like the Dutch NLIP, a non-mandatory, non-regulatory private body in which all major and many minor ISPs are represented) took up the issue. At first they issued some kind of statement saying that they had all agreed to refuse nazi content and anybody carrying it. Later they took that back and refused to comment. Since they are a private body, nobody can force them to show their minutes (and nobody has leaked them so far). The end result was that not one single ISP was willing to host Flashback and Axelsson got a rather remarkable collection of subterfuges, "not in, he'll will call you" from people who never called, unreplied letters and the like. In the third round Axelsson mounted his own media offensive and attacked the ISPs, the city of Karlskrona and Fries himself. He filed complaints with the competition authority (the Swedish NMa) for the agreement of the ISPs across competition borders to boycott him, demanded stacks of public documents from Karlscrona, complained to the national ombudsman against the city exceeding the statutory limits of its authority and against Fries for using the city for his "private" campaigns. The affair became pretty big, to the extent that questions were asked in parliament and the prime minister,who previously had congratulated Fries for his "courage in the fight against nazism", had to weasle his way out of a possibly hot spot. Part of Flashback was hosted in Holland. The anti-trust complaint was not investigated (lack of evidence). I don't know the outcome of the other complaints. In the third round - or rather in the break - Axelsson got some "throwaway" connectivity from someone who didn't care if he would get cut off. Flashback went back online and stayed there for two days before it was cut off again. In the fourth round, more than a year later, Axelsson dumped the web hosting, got connected, and put his main site and the webfora online. No static nazi websites, no big problems. There must have been nazi entries in the discussion fora, but there is usually so much opposition to them that the whole ends up being quite the opposite of nazi promotion. * In effect, the one website that caused all this never made it back on the air in Sweden. The partial and partially fucked-up mirror of the original Flashback is still available from my server in the Netherlands. Most Swedish nazi sites have moved to the US and many have bundled their efforts in nazi portals, where they have better and cheaper technical resources and get help with better design, ending up with much better sites than their original make-a-site-while-drunk-in-the-garage variants. They can show the finger to people like Fries and to the whole Swedish establishment and they feel, rightly, that they won this fight and have come stronger out of it. The big loser in all this is the Swedish democracy. Cheerio. Z

3 2

Re: Is there a line of defense against Distributed Reflective attacks?
by Steven M. Bellovin 19 Jan '03

19 Jan '03

In message <20030117062954.GK61038(a)lcs.mit.edu>, "David G. Andersen" writes: > >On Fri, Jan 17, 2003 at 01:11:14AM -0500, David G. Andersen mooed: >> >> b) Ioannidis and Bellovin proposed a mechanism called "Pushback" >> for automatically establishing router-based rate limits to >> staunch packet flows during DoS attacks. >> [NDSS 2002, "Implementing Pushback: Router-Based Defense >> Against DDoS Attacks"] > > I should have been a bit more accurate here. The proposal for >pushback is actually earlier than the implementation paper I cited above: > > "Controlling High Bandwidth Aggregates in the Network. Ratul Mahajan, > Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott > Shenker. July, 2001." > >and it also included an internet-draft: > > http://www.aciri.org/floyd/papers/draft-floyd-pushback-messages-00.txt > >I believe that Steve Bellovin gave a talk about it at NANOG 21: > > http://www.research.att.com/~smb/talks/pushback-nanog.pdf Here are the citations to the published papers: # Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidis, Vern Paxson, and Scott Shenker, Controlling High Bandwidth Aggregates in the Network, Computer Communications Review 32:3, July 2002, pp. 62-73. http://www.research.att.com/~smb/papers/pushback-CCR.ps # John Ioannidis and Steven M. Bellovin, "Implementing Pushback: Router-Based Defense Against DDoS Attacks", NDSS, February 2002. http://www.research.att.com/~smb/papers/pushback-impl.ps The publication dates notwithstanding, Mahajan et al. came first. As for the I-D -- we haven't had the cycles to work on it. There's reason to hope that activity will pick up. Re: I'm not sure its all that practical. I don't see that its helpful if it turns off services 'automatically' In theory, it doesn't turn off the service to all comers; it turns off the service along pipes from which the attack is coming. Just how good a job it will do at stopping collateral damage will depend on how far back there are pushback-enabled routers. If an ISP deployed it, but didn't speak pushback to its neighbors, clients on that same ISP's network should be able to access the service, as could peers who weren't the source of the garbage. But if some peer is sending an OC-12's worth of DDoS packets -- yes, all clients (or transit users) of that peer would be shut out. ICMP traceback is the subject of the IETF itrace working group. draft-ietf-itrace-03.txt just came out yesterday. The SPIE hash-based traceback is a much cooler idea, but it has some practical limitations, including the need to do the trace in more or less real-time (once the hash table fills up, it becomes useless), and the need for very large amounts of very fast memory on the tracing routers. There was an IETF BoF on it, but the folks behind it haven't been pushing it much. (Randy, do you know the status of it?) Both itrace and hash-based trace have some technical issues. itrace can handle only DoS-type attacks, since it's statistical in nature; hash-based traceback can, in theory, trace a single packet. But the real problem with either idea is this: suppose that you know, unambiguously and unequivocally, that 750 zombies are attacking you. What do you do with that information? --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

3 2