- Test - lists.nanog.org

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 12 May '00

12 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 12 May '00

12 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 12 May '00

12 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

Re: Optical Crossconnects and IP
by Jerry Scharf 11 May '00

11 May '00

[...] > > I both fly (although tiny stuff only and otherwise only simulations ;-) > and do the networks stuff so here's a little comparison: > > Your airplane metapher almost works BUT if you talk about running even 300-400 > nodes with a link-state, you should compare it to flying an F18 formation of 30-40 > airplanes. A single one can turn well, yes, but try to get a coordinated, standard rate, announced > speed turn of 30 aircrafts and you start to understand the dynamics. There is a theory > that deals with that stuff (it's called in german "Schwarmtheorie", english equivalent to "swarm" > or "flock" probably) and it speaks about thing like center of a flock and it's mass ASIR but I never > saw it applied to networking, funny enough. So my point being, it's not like single-mass > Newtonian physics, > you basically get into the problem of Laplace grids (I think that's what the grids of masses > with springs inbetween were called ;-) and changing traffic characteristics are probably equivalent > to kinetic energy pumped into the system from its edges. > That's where your differential equation systems start to look > hard and pretty soon you're on the border of chaos theory. Somebody in Santa Fe should start > looking into that ;-) > [...] > > -- tony > Your point being that I have grossly underestimated the difficulty. A 20x20 grid transformed out of LaPlace space should generate thousands of significant partial differentail terms, then add the chaotic and discontinuous nature of the input. Gee, I wonder why the feeback loops are hard to stablize in networks. Add yet more by the fact that the faster you go, the higher the accelerations and the more unstable the system and the brute force stuff just keeps on looking better and better. jerry

1 0

uunet europe outage
by JP Donnio 11 May '00

11 May '00

Hi, Although this is not a new problem (it started on 27 april), I wanted to let you know there are recurring transatlantic problems for UUnet networks in France, Uk, The Netherlands and Belgium (ASes 702, 3259, 1890, 2822, 1849). Symptom is that periodically transatlantic IP connectivity stops for periods between a few minutes to a few dozen minutes but BGP sessions are not interrupted. From UUnet France we have measured 13 outages of over 4 minutes since 1st May for a total of 168 minutes, including 6 outages today! More than just the problems that such connectivity failures cause, the fact that UUnet BGP sessions continue to announce unreachable networks prefixes during outages prevent all multihomed networks to efficiently handle those problems. As you might guess, UUnet has been providing no explanation at all except 1 fax sent to all its customers. The national NOCs seem totally unaware and unable to cope as the problem is transatlantic and handled in the US. There is no equivalent of www.noc.uu.net for european networks... What you should also know is that European UUnet networks are peering with very few networks other than their transit customers and that they rely on AS701. When transatlantic connectivity fails like this, most of the internet becomes unreachable. This message is not sent here in order to make UUnet react; we have already put the necessary pressure locally including public statements with no reaction at all. This is just to inform the community how european UUnet customers are treated. It is significant of the general low level of communication that European ISPs have with their customers, at least compared to the US. JP Donnio network consultant

1 0