April 1998 - Test - lists.nanog.org

Re: SMURF AMPLIFIER BLOCK LIST -- VERY LARGE!!!!!!!!!!!!!!!
by Matt Ranney 30 Apr '98

30 Apr '98

Phillip Vandry <vandry(a)Mlink.NET> writes: [...] > Every router on there has had directed broadcasts disabled for a long time. > Only that network is a /25, so the broadcast address we are talking about > is 205.236.182.127. > > It turns out that not only does 205.236.182.255 unexpectedly function as > an alternate broadcast address for this network, but it is unaffected by > no ip directed-broadcast!!! We've seen this type of behavior as well, and on larger networks than /24's. On one /18 that we have, someone was sending to xx.xx.255.255, and it was heading to the first /23 that was allocated out of that block. The customer that was lucky enough to be the recipient eventually had to explicitly deny the 255.255 address because no ip directed-broadcast didn't stop it. -- Matt Ranney - mjr(a)ranney.com Let's not let the students run the High School.

1 0

Re: Two renumbering questions
by Mark Borchers 30 Apr '98

30 Apr '98

On 29 Apr 98 at 22:40, John R Levine wrote: > > > 1. I have a /24 SWIPed to me, 205.238.207.0. The ARIN listing doesn't say > > > it's non-portable, so can I take it with me? And if I do, how likely is it > > > that the new ISP's announcement will get installed in backbone routers > > > rather than filtered for being too long? It's right in the middle of the old > > > upstream's block 205.238.192/18. > > > > If you *own* the block, you can do anything you want with it. > > Well, there's the question -- I have no idea who owns it. Look it up in > ARIN, it says it's mine, but with contact info from epix, the old upstream. > Again, though, even if I own it, if the announcements don't make it into the > backbone it's not very useful, and I gather that some backbones now filter at > /19 except for the swamp. "Ownership" is not the word to be using. The 205.238.192/18 is ALLOCATED to Epix. Meaning: the are authorized to use the addresses or to assign them to someone else to use. The /24 is probably ASSIGNED to you. Meaning: you can be an end user of the addresses. The /18 is not registered with ARIN as non-portable, so the portability call is exclusively up to the administrator of that block.

2 1

Re: Router modifications to deal with smurf
by Tony Li 30 Apr '98

30 Apr '98

> Note that I'm not arguing that it *should* be the default, I'm just > arguing that vendors have implemented it this way because that's the way > they were told to in the RFC. Umm.... this is only partially true. As of the writing of 1812 (and predecessors), vendors had implemented it one particular way and argued that the spec should reflect the implementations. Of course, at the time, the net was a kinder, gentler place, and the threats of smurfing were not well known. Live and learn. ;-) Tony

1 0

FOLLOW ON TO BLOCK LIST
by NOC 29 Apr '98

29 Apr '98

All, Obviously these networks are atomic - the aggregates can easily be identified for the purposes of access-lists - unless someone wants to build a list with 1400+ entries... I will repost the list using aggregates in the context of the subnetworks involved, something like Aggregate xxx.xxx.0.0/16 Networks: x.y.z.0 a.b.c.0 g.e.f.0 etc...

1 0

feasability of stopping smurfs with cisco's CAR
by Marko Bukvic 29 Apr '98

29 Apr '98

Greetings, cisco's new Committed Access Rate feature lets you do real QoS rate limiting (as opposed to traffic shaping) with access lists. CAR could be implemented on either ingress/egress interfaces to limit bandwidth usage by ICMP to something safe like 5MBits. This would prevent an incoming ICMP flood from consuming your aggregation links, while it still might inconvenience a T1 customer. If placed on the outgoing access-list it can prevent your network from originating unfriendly amounts of ICMP. CAR can either discard or decrease the priority of the offending traffic. A couple of questions: I am unfamiliar with what tier 1 providers use as aggregation routers(routers their T3+ customers connect to). Due to CAR's potentially CPU intensive nature (when dealing with access-list based traffic limiting compared to address based limiting), would an "ICMP permit with exceed-action drop" filter constitute an unacceptable load on the CPU and memory of these routers? If I only had 1 multi-megabit transit pipe, is it reasonable(in the future) of me to ask/require my upstream provider to protect my pipe from being wasted by large amounts of ICMP? If I only put it on my side, the pipe still gets wasted. Are there any other vendors who offer a similar feature without the use of ATM? Thank you. Marko

1 0

Smurf Amplifier Block List --- Useless in some cases????
by Martin, Christian 29 Apr '98

29 Apr '98

All, Our network was recently Smurfed - HARD. Over 6000 subnets were involved (as amps.). I have all of the ARIN/RIPE/RADB entries for these networks, and guess what? 95 PERCENT of them are in China/Taiwan or Eastern Europe. I am willing to post them, but the list is LONG. Would people rather see US sites, or all sites? I ask because I am not sure how much the University of Taipei cares about reachabiliy to the US - Or do they? Awaiting replies... -Christian

3 2

NANOG 13 REMINDER
by Pam Ciesla 29 Apr '98

29 Apr '98

The hotel block expires on May 6. Be sure to reserve your room before this date. Hyatt Regency Dearborn Fairlane Town Center Dearborn, MI 48126 313-593-1234 - phone 313-593-3366 - fax $125 S/D The attendee list is up to date. If you have registered and are not on the list please contact me. All attendees are asked to register via the webpage. Payment info may be faxed or mailed. All info is available on the NANOG webpage http://www.nanog.org Any questions please contact me. Thanks xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

SMURF amplifier block list
by Jaap Kreijkamp 29 Apr '98

29 Apr '98

Hello, Domain 130.37.0.0/16 should be smurf-resistant. Please remove it from your blacklist. Greetings, Jaap Kreijkamp Vrije Universiteit Amsterdam

1 0

Average and median IP packet size over the Internet?
by Goldstein_William＠bns.att.com 27 Apr '98

27 Apr '98

Anyone know of any studies documenting this? A know that IP packets over the Internet tend to be smaller rather than larger, but I wondered if anyone has published something. Bill Goldstein Senior Internet Specialist AT&T wgoldstein(a)att.com TEL:(412)642-7288

4 3

RE: Network Operators and smurf
by Martin, Christian 27 Apr '98

27 Apr '98

All, Given the contributions to this thread have been mostly theoretical in nature, I'd like to share an experience of mine that in some ways negates some of the propsed solutions to smurf attacks in the context of smaller ISPs. Recently, one of our downstream customers was subject to a smurf attack, and we placed an access-list on our egress interface to the customers network. The customer hangs of an SMDS cloud - our link to the cloud is at 34 Mbps, his T1. We were blocking echo replies destined for his network. We are connected upstream at 45Mbps. As the attack intensified, router CPU Utilization jumped to 99%, and the input queue on our inbound HSSI was at 75/75. We started dropping packets at a rate of about 7000/sec. The attacks were coming in from all over the world. The NetFlow cache was growing at an alarming rate, and, after a while the HSSI just DIED. As the HSSI bounced, our BGP session bounced with it, causing some mild route flapping (Not vaccilating enough to be damped, but enough nonetheless). Eventually the attack subsided, and all went back to normal, but for a period of time, say 10 minutes, we had a 7507, 64megs, RSP2 WITH the HSSI on a VIP2 on its knees. We decided that parsing NetFlow logs would give us a better idea of who was amplifying the attacks, and with a simple shell script, we were able to build a database of ASNs, with admin contacts from RADB/RIPE/ARIN. We are planning on sending emails to these customers to ask them to stop amplifying smurfs (script does that too), because this is unacceptable. My point, then is this: Filtering echo replies is/can be a futile attempt at preventing this type of attack. I watched a 7507 die defending against one attack. More recently, we got hit so hard that the router was screaming without ANY access-lists blocking ICMP echo-replies, perhaps because there was no real fast-switching taking place (each source is different, so the first packet is process switched. Our NetFlow cache went from 3900 flows to 27000 flows in about 4 mins.) And, as we were not amplifying the smurfs, source address verification is a moot point. I am all for allowing these netblocks time to implement this type of filtering (layer3 to layer2 broadcast translation prevention), but not for very long. It appears the best way to light a fire under someones rear end is to publicly shame them into acting. For those who don't act quickly enough, there can be no quarter. If I appear hostile, I am... PS If anyone has similar experiences, please share them, as there has already been enough rhetoric filling this thread, and it is clear that everyone knows the solution lies at edge and beyond, not in the core. -Christian Martin

9 11