May 2000 - Test - lists.nanog.org

Re: New Internet-draft on DDOS defense...
by Vipul Shah 12 May '00

12 May '00

> >Another point that hasn't been mentioned in this thread is that this type >of attack is very easy to track down, since all the echo-reply packets >will have addresses in the same subnet. A good portion of the problem >with smurf attacks is not so much the attack itself as the painful process >of tracking it to it's source. > By the time you trace the packets, identify the subnet, and convince the Network Administrator to detach the compromized system from the network, the victim's router might have crashed. Especially, when there are more than one DDoS agents are compromized over different networks, the victim site may loose several hours of business! Vipul >Brandon Ross 404-522-5400 >VP Engineering, NetRail http://www.netrail.net >AIM: BrandonNR ICQ: 2269442 >Read RFC 2644! >Stop Smurf attacks! Configure your router interfaces to block directed >broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details. > > >

2 1

Asia Pacific problems?
by Roeland Meyer (E-mail) 12 May '00

12 May '00

Does anyone know what's happening across the pacific? root@falcon#> traceroute www.pcchips.com traceroute to www.pcchips.com (210.176.102.130), 30 hops max, 40 byte packets 1 dslnet.gw.mhsc.net (199.108.175.1) 2.777 ms 2.907 ms 2.486 ms 2 monster-paix-atm-1.dslnetworks.net (199.108.168.1) 28.128 ms 29.948 ms 33.144 ms 3 fe2-0.sjc-bb3.cerf.net (134.24.23.1) 21.246 ms 20.800 ms 21.761 ms 4 pos0-2-155M.sjc-bb2.cerf.net (134.24.29.25) 21.676 ms 21.776 ms 21.622 ms 5 pos1-1-155M.sfo-bb3.cerf.net (134.24.32.89) 23.185 ms 24.678 ms 23.141 ms 6 pos3-0-0-155M.sfo-bb1.cerf.net (134.24.29.202) 23.296 ms 22.669 ms 23.374 ms 7 atm11-0-0.BR1.SCL1.ALTER.NET (137.39.23.137) 26.055 ms 24.776 ms 25.761 ms 8 105.at-5-0-0.XR4.SCL1.ALTER.NET (152.63.48.182) 25.336 ms 25.956 ms 26.089 ms 9 152.63.51.141 (152.63.51.141) 25.685 ms 42.531 ms 26.274 ms 10 188.ATM11-0-0.GW2.PAO1.ALTER.NET (146.188.147.237) 25.532 ms 27.583 ms 26.757 ms 11 hkt-gw.customer.ALTER.NET (157.130.193.134) 29.935 ms 27.987 ms 28.247 ms 12 h2-0-0.tmhbr01.hkt.net (202.84.128.229) 439.046 ms 476.217 ms 432.080 ms 13 f1-1.tmh100.imsbiz.com (205.252.128.234) 452.217 ms 432.152 ms 463.321 ms 14 tmh103.imsbiz.com (206.161.62.7) 528.569 ms 506.871 ms 480.182 ms 15 210.176.102.158 (210.176.102.158) 4470.295 ms * 4259.799 ms 16 210.176.102.130 (210.176.102.130) 3683.300 ms 4523.936 ms 3898.093 ms --- R O E L A N D M . J . M E Y E R

2 2

Re: New Internet-draft on DDOS defense...
by Steven M. Bellovin 12 May '00

12 May '00

In message <Pine.LNX.3.96.1000512075212.812B-100000(a)ogre.atl.netrail.net>, Bran don Ross writes: > >On Thu, 11 May 2000, Owen DeLong wrote: > >> Right answer, wrong reason. The originating host will be easy to identify >> because the MAC address of the originating machine of the ECHO-REQUEST >> packets will be contained in the packets. > >I have to strongly disagree, MAC addresses don't make it across router >boundaries, source IP addresses do. Besides, MAC addresses are quite often changeable. --Steve Bellovin

1 0

Re: New Internet-draft on DDOS defense...
by Brandon Ross 12 May '00

12 May '00

On Thu, 11 May 2000, Owen DeLong wrote: > Right answer, wrong reason. The originating host will be easy to identify > because the MAC address of the originating machine of the ECHO-REQUEST > packets will be contained in the packets. I have to strongly disagree, MAC addresses don't make it across router boundaries, source IP addresses do. Brandon Ross 404-522-5400 VP Engineering, NetRail http://www.netrail.net AIM: BrandonNR ICQ: 2269442 Read RFC 2644! Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

1 0

New Internet-draft on DDOS defense...
by Vipul Shah 12 May '00

12 May '00

Hi All, I'd like to bring your attention to a recent Internet-draft. The URL is: http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt This draft proposes a specific (simple) change to RFC1122 which would help reduce the use of Smurf amplification in DDOS attacks. This is augments ingress filtering; it is designed specifically for the case where the attacker (source) is using broadcast on the local LAN as part of a DDOS attack. This is a case where ingress filtering does not help. We are proposing that it be an addition to the standard set by RFC1122. We'd very much like to hear comments from people on this draft. Vipul

4 5

Re: New Internet-draft on DDOS defense...
by Vipul Shah 12 May '00

12 May '00

>I have some concerns with this draft. The proposed change does lower the >risk of damages if one system on a shared-media LAN is compromised, but >only for this one type of attack. It seems to me it'd be possible to >generate other types of packets which are broadcast/multicast which >could elicit an ICMP response, and such attacks are not something which >can be cured without breaking a lot of functionality. While ICMP ECHO >packets are a preferred mechanism today, they're far from the only types >of packets which are problematic. > >Where RFC2644 prevents ALL types of directed broadcast traffic, this >draft will only have a useful impact on ICMP ECHO, and only in a limited >case. I have to question whether there's sufficient benefit here to >warrant opening up the IP stacks on end stations. > Will you please list down the other types of packets (apart from ICMP ECHO packets) used to generate broadcast response and can lead to an attack. We can extend our solution further to include other types of packets, if possible. >An alternative to the suggested approach is the use of packet filters on >end stations. For example, with Linux systems (and probably others) >ipchains can be used to filter the types of traffic a host will respond >to, regardless of what a border router or firewall ahead of it allows. I >generally advocate the use of such facilities where possible as it adds >an extra line of defense. > >Rate limiting of certain types of traffic (e.g. ICMP) is also a way to >address the type of problem this draft is concerned with, and again is >capable of addressing all ICMP, rather than just ICMP ECHO/ECHO REPLY. Rate limiting and filtering may reduce the impact of Smurf attack, but the attack itself is not prevented! Vipul > >Overall impression of the draft: not a terrible idea, but unclear if >it's sufficiently beneficial to warrant the effort to implement. > >Dan >-- >----------------------------------------------------------------- >Daniel Senie dts(a)senie.com >Amaranth Networks Inc. http://www.amaranth.com

1 0

Re: Optical Crossconnects and IP
by Tony Li 11 May '00

11 May '00

| In technology, an attempts to calculate traffic floods _before_ real | congestion appear cause a lot of useless work - and sometimes simple | models (like liquid etc) are working best. Correct. Most traffic engineering work uses historical data to determine where the hot spots already are. No prediction is necessary. Given the law of large numbers and the periodicity of Internet traffic, this seems to be a very good predictor of future behavior. Of course, this is congestion in the large, with only low frequency components. It says nothing about high frequency congestion. Tony

1 0

Re: New Internet-draft on DDOS defense...
by Vipul Shah 11 May '00

11 May '00

The solution suggested by RFC2644 is for routers only, while the proposed solution is intended for end-nodes. If DDoS Smurf attack is generated using local broadcast, RFC2644 solution won't prevent the attack. Read carefully the last paragraph of Section 1 of the draft. Vipul >>> Paul Ferguson <ferguson(a)cisco.com> 05/11/00 05:14PM >>> How is this substantially different than RFC2644, "Changing the Default for Directed Broadcasts in Routers"? http://www.ietf.org/rfc/rfc2644.txt - paul At 10:13 PM 05/10/2000 -0600, Vipul Shah wrote: >Hi All, > >I'd like to bring your attention to a recent Internet-draft. The URL is: > >http://www.ietf.org/internet-drafts/draft-vshah-ddos-smurf-00.txt > >This draft proposes a specific (simple) change to RFC1122 which would >help reduce the use of Smurf amplification in DDOS attacks. This is >augments ingress filtering; it is designed specifically for the case >where the attacker (source) is using broadcast on the local LAN as >part of a DDOS attack. This is a case where ingress filtering does >not help. > >We are proposing that it be an addition to the standard set by >RFC1122. We'd very much like to hear comments from people on this draft. > >Vipul > >

2 1

Los Alamos Fire, Internet helping People......
by John M. Brown 11 May '00

11 May '00

The raging fire in Los Alamos, New Mexico is devistating. Many of our states ISP's and IT folks are helping pitch in with computers, connectivity and know-how to help track and locate people. The ABQ Journal saw a 400 percent increase in bandwith, inside of 6 hours today. They are now running between 4 to 6 Mb/s I personally want to thank Verio and Cable and Wireless, our backbone vendors in New Mexico. Everything is running perfect. I also want to thank those many members of the New Mexico Internet Professional Assoc. They have put together a wonderful site to track and locate people. This is one of the things we as Internet Professionals must not forget. The "Net" is also here to help our fellow people out. If anyone that is affected by this fire needs help, please contact me offline. For more information check out: www.abqjournal.com fire.nmipa.org www.nmipa.org

1 0

Re: Level 3 is reporting fiber cuts in San Jose and San Francisco
by William Sommers 11 May '00

11 May '00

11:08 PDT -- All of our MFS circuits died simultaneously. 11:42 PDT -- All but one returned to service. 11:53 PDT -- I arrive at 444 Market in SF, having seen *nothing* telltale along the way or in the vicinity. 15:47 PDT -- Current time, one DS1 (to PAIX) still down. No PacBell-provided circuits affected. FWIW. -wfs At 04:07 PM 5/11/00 -0400, Pete Rohrman wrote: > MFS is also reporting that there are 37 DS-3's down in that area. > The trouble taker said that it was a satellite issue. MFS Ticket > 2008362. > > >On Thu, 11 May 2000, Majdi S. Abbas wrote: > >> >> > BTW, should this >> > >> Level 3 is reporting fiber cuts in San Jose and San Francisco >> > have read: >> > Level 3 is reporting cutting fiber in San Jose and San Francisco >> >> I doubt it; last time I saw L3 trenching anywhere near >> Market was about two months ago (down Bush to Market); MCI did the >> same around the same time. >> >> I haven't seen anyone in that vicinity recently >> (MFN already had their stuff in place, and TCG's been there >> for quite a while), and I definitely haven't seen anybody >> cutting on Market.

1 0