- NANOG - lists.nanog.org

ASO mailing list announcement/reminder
by Kim Hubbard 11 Feb '00

11 Feb '00

Reminder: ICANN ASO - Website and Discussion Lists This is an announcement to all parties with interests in management of Internet Address space and related resources. The Address Supporting Organisation of ICANN (the Internet Corporation for Assigned Names and Numbers) was established last year, and has assumed its responsibilities under the ICANN Bylaws for coordination of global policy development in relation to Internet Addresses and related resources. The nine-member Address Council has also been established, in accordance with the ASO MoU and ICANN Bylaws. Since its establishment, the ASO has established mailing lists and a website to ensure that its processes are open and transparent, and accessible to all parties with an interest in Internet resource management issues. Three ASO mailing lists are now available for public access to ASO information, and for input into the ASO process: aso-announce - for announcements and other information relating to the ASO (read only list) aso-policy - for open discussion on policy and other ASO matters (open subscription list) aso-comment - for comment and input of any kind (no subscription necessary) The ASO website is also now available, at http://www.aso.icann.org, and carries information relating to the ASO, Address Council, and policy matters which may be under consideration; as well as complete archive of the above mailing lists. At this time the Address Council is seeking participants in the ASO process, and encourages all interested parties to subscribe to the mailing lists above. For information on how to subscribe, please visit the ASO website. We look forward to your participation! Paul Wilson for the Address Council and ASO Secretariat.

1 0

Re: Yahoo! Lessons Learned
by Vadim Antonov 11 Feb '00

11 Feb '00

Just a thought - strict RPF at all ingress points, in combination with Fair Queueing keyed on something like 24 high-order bits of source IP address in transit routers would render any high-rate flooding attack pretty much harmless. --vadim

13 12

Re: Yahoo! Lessons Learned
by Sean Donelan 11 Feb '00

11 Feb '00

On Thu, 10 February 2000, Vijay Gill wrote: > Of course, given that we can get netflow type packet histories, plotting > the src/dest pairs for a while and then if there is a _large_ change (some > n std dev) from the norm for some particular dst (nominally the one under > attack), and then raising an alarm on that router/pipe, would make it > trivial to trace these type of attacks. With history storage, it would > make it easier to trace back after the fact. I've wondered what type of statistical sampling could be used to find these attacks, but not require huge amounts of storage. The theory is these are very large traffic flows which congest the pipe and push other traffic out of the way. If you sample 1% of the traffic, and 99% of the sample is the same src/dest pair, something may be fishy.

3 2

Re:FBI / NIPC released a DDoSD detection tool? (Look in the binary)
by mpotter＠atpco.com 10 Feb '00

10 Feb '00

At 10:44 AM 02/10/2000 -0600, you wrote: > >I'm not sure if this is news or not, but looking at >http://www.fbi.gov/nipc/trinoo.htm - it seems the NIPC has released this has been out about since late Dec >binaries, (no source code, the jerks), for tools to detect if a box has >trin00, tribal flood net, tfn2k and some other DDoSD's on it. Heh, who in their right mind installs something w/o source.... Especially from the FBI ;)They are the ones that want to BACKDOOR every crypto product... It looks like a packet sniffer that just looks for the fingerprints of these attacks. Nothing really special. It even looks like it has the exploit compiled in(strings , nm -Du, ldd the binary), probably cut and paste work. The fact that they have it only for Solaris(SPARC and x86) and Red Hat tells you those are the only types of boxes they have, or the only thing they could get it to work on. Matt

2 1

Yahoo! Lessons Learned
by Sean Donelan 10 Feb '00

10 Feb '00

As much as I enjoy finding out about Yahoo & GlobalCenter issues by reading the newswires, I wonder if there are any lessons we can learn from these events. Or was this not big enough to get attention of upper management? Was there something Yahoo!, GlobalCeneter or other providers could have done, either individually or in cooperation, to prevent the problem? Likewise, could they, individually or in cooperation with other providers, have shortened the duration or severity by doing something different? And finally, would they be more successfull in tracking the source the the problem by doing something different?

9 10

Re: Fair Queuing combats DDoS? [was Re: Yahoo! Lessons Learned ]
by Alex Bligh 10 Feb '00

10 Feb '00

Alexei Roudnev (alex(a)genesyslab.com) said: > [deploy WFQ and RPF universally] > Then , if someone want to kill yahoo (for example), he need a few > thousands different data streams to do it - which is impossible. Several thousand different data streams is exactly what DDoS is. Also there is a presumed high correlation with people who do not secure their servers adequately againts intrusion (and thus turning these things into DDoS clients) and people who do not run RPF right next to those servers. Therefore this is only 'impossible' if there are not more than 2000 servers sitting on clueless or fallible peoples network. Recent experiences with internet scaling suggest even if this were true now (which it isn't), it won't last long. -- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)

1 0

Re: [Re: Which Part(s) Failed in the recent DOS Attacks?]
by Toplez Razer 10 Feb '00

10 Feb '00

Joe, Firewall-1 has the SynDefender and Cisco IOS 12.0 has TCP Intercept for stopping TCP DOS. Could these features stop massive TCP DOS attacks? Thanks, Audie Onibala ****************************** Joe Shaw <jshaw(a)insync.net> wrote: On 9 Feb 2000, Toplez Razer wrote: > 1. Was it the firewall DOS filter? With packet based DoS attacks, filters don't matter. Bandwidth and saturation are what matters. > 2. No firewall in Yahoo, EBay, ETrade, etc? Yes, there are, and no, they wouldn't have helped for the reason stated above. > 3. Firewall DOS filter worked, but the links were still clogged with massive > ACKs/NACKs? Not exactly, but fairly close. -- Joseph W. Shaw - jshaw(a)insync.net Computer Security Consultant and Programmer Free UNIX advocate - "I hack, therefore I am." ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

3 3

Re: Info on the DoS attacks.
by Sean Donelan 10 Feb '00

10 Feb '00

On Wed, 09 February 2000, Joe Shaw wrote: > I'd be worried if they didn't have theories or know about the known DDoS > attacks, but not if they didn't have specifics. Tier1 NSP's seem to be > very tight lipped about these sorts of things when they are the > victim. I'm sure there are GC employees on this list, but none have come > forward to give any details. Could be a gag order, which wouldn't shock > me at all. Hopefully we'll know something eventually, but for now we're > all mushrooms when it comes to official information. I guess the techies reduced to reading the New York Times for technical details. Today's NYT has a description from GlobalCenter's PR person. The Yahoo attack was a large number of ICMP EchoReplies(PINGs) coming via GlobalCenter's 50 peering connections (about half of GlobalCenter's total peering connections). Which may explain the "50" number I've been hearing. The original ICMP EchoRequests listed Yahoo as the source address and were directed to other networks which replied to Yahoo. GlobalCenter installed rate-limits, but didn't know if they are effective in preventing attacks. Yahoo's spokesperson confirmed GlobalCenter's account. (free NYT registration required) http://www.nytimes.com/library/tech/00/02/biztech/articles/10attack.html Note: other people have sent me private mail saying it was actually a different method, but this appears to be the official statement out of GlobalCenter and Yahoo.

2 1

Re: identifying ASN
by Ramin Sepehr Rad 10 Feb '00

10 Feb '00

On Thu, 10 Feb 2000, Mark Kent wrote: > > With all this talk of tracing attacks I just noticed that > whois -h whois.arin.net > seems to not be as informative as it used to be. > > When looking up various ASN I sometimes get the information I want, > but frequently I get: > > Sorry, you shouldn't see this record. > > or > > No match for ASN "..." > > (Sample ASes are 2855, 5400, 9057, 11486) > > Did I miss some policy change? > > -mark > > P.S. Fortunately, various radb-like entities still list > information for a lot of ASes. Hello Mark, ARIN is aware one of our servers was not reporting proper results to some WHOIS queries. This has been fixed and measures have been taken to ensure this does not occur in the future. Best Regards, ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | Ramin Sepehr Rad American Registry for Internet Numbers | | raminr(a)arin.net 4506 Daly Drive | | (703) 227-9876 Suite 200 | | (703) 227-0676 (FAX) Chantilly, VA 20151 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Yahoo! Lessons Learned
by Henry Kilmer 10 Feb '00

10 Feb '00

owen(a)exodus.net writes: >> Last time I tested it, RPF would still fail if it wasn't the way >> packets would flow (not *could* flow). If that has changed, then this >> would work. >> >> >If it hasn't changed, then I think there's a pretty good case for pressuring >the various vendors to make it so. I have to admit, I always thought that >was the case, that there had to be a route out the reverse path, whether >it was preferred or not. > >Thoughts? It would definately make it more useful.

1 0