- NANOG - lists.nanog.org

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

28 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

Re: Average and median IP packet size over the Internet?
by Ehab Hadi 28 Apr '98

28 Apr '98

Bill, Usually the Internet core routers try to keep IP packets reletivly have the same size or without Option's field in order switch packets in the hardware roueter backplane. Ther are many studies will be reflected one way or another on the IP packet size. One of them might be found on the URL http://diffserv.Ics.mit.edu. Regards, Ehab H. Hadi Nortel, LTD. Ehabh(a)nortel.ca >From owner-nanog(a)merit.edu Mon Apr 27 14:34:13 1998 >Received: from localhost (daemon@localhost) > by merit.edu (8.8.7/8.8.5) with SMTP id RAA27727; > Mon, 27 Apr 1998 17:20:36 -0400 (EDT) >Received: by merit.edu (bulk_mailer v1.5); Mon, 27 Apr 1998 17:19:53 -0400 >Received: (from majordom@localhost) > by merit.edu (8.8.7/8.8.5) id RAA27693 > for nanog-outgoing; Mon, 27 Apr 1998 17:19:52 -0400 (EDT) >Received: from att.com (cagw1.att.com [192.128.52.89]) > by merit.edu (8.8.7/8.8.5) with SMTP id RAA27686 > for <nanog(a)merit.edu>; Mon, 27 Apr 1998 17:19:41 -0400 (EDT) >From: Goldstein_William(a)bns.att.com >Received: by cagw1.att.com; Mon Apr 27 17:12 EDT 1998 >Received: from pawayn01.bns.att.com (root(a)pawayn01.bns.att.com [135.170.166.239]) > by caig1.att.att.com (AT&T/GW-1.0) with ESMTP id RAA21585 > for <nanog(a)merit.edu>; Mon, 27 Apr 1998 17:19:34 -0400 (EDT) >Received: from localhost (root@localhost) > by pawayn01.bns.att.com (8.8.6/1.3) with SMTP id RAA25124 > for nanog(a)merit.edu; Mon, 27 Apr 1998 17:19:33 -0400 (EDT) >X-OpenMail-Hops: 1 >Date: Mon, 27 Apr 98 17:19:19 -0400 >Message-Id: <H00003e40238e9c6@MHS> >Subject: Average and median IP packet size over the Internet? >TO: nanog(a)merit.edu >Sender: owner-nanog(a)merit.edu > >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 > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

VLSM and CIDR information digest and thanks...
by kbrown＠primelink.com 28 Apr '98

28 Apr '98

Everyone... I appreciate everyone's response to my basic questions on these topics. I've got a truckload of sources to read from now. :=) For the record, and the archives... the most useful documents I was referred to, or found most helpful were: RFC1518- An Architecture for IP Address Allocation with CIDR http://www.arin.net/rfc/rfc1518.txt RFC1466-Guidelines for Management of IP Address Space http://www.arin.net/rfc/rfc1466.txt RFC1519-CIDR: an Address Assignment and Aggregation Study http://www.arin.net/rfc/rfc1519.txt RFC1878-Variable Length Subnet Table for IPv4 http://www.arin.net/rfc/rfc1878.txt CIDR FAQ http://www.rain.net/faqs/cidr.faq.html Understanding IP Addressing: Everything you Ever Wanted to Know http://www.3com.com/nsc/501302.html Once again, thanks to everyone who assisted me in locating this information, and hopefully with this mail in the archives, the next "junior" won't have to ask the question.

1 0

Re: Average and median IP packet size over the Internet?
by Randolph C. Nicklas 28 Apr '98

28 Apr '98

Bill, See http://www.vbns.net/presentations/papers/index.html for the paper "Wide-Area Internet Traffic Patterns and Characteristics" by K. Thompson, G. J. Miller, and R. Wilder, IEEE Network, November/December 1997. You should find it relevant & interesting. Randy At 05:19 PM 4/27/98 -0400, Goldstein_William(a)bns.att.com wrote: >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 > > ------------------------------------------ Randolph C. Nicklas Internet Engineering/MCI 703.715.7099 1.800.SKY.PAGE 902418

1 0

Re: Router modifications to deal with smurf
by Kelly J. Cooper 27 Apr '98

27 Apr '98

There is no noise, only signal. There is no signal, only noise. On Apr 26, 3:35pm, Craig A. Huegen wrote: *On Sat, 25 Apr 1998, Rusty Zickefoose wrote: * *==> We requests that your routers be configurable, at the interface *==>level, to prevent the forwarding of an ICMP echo-request packet through an *==>interface that has a broadcast or wire address that matches the *==>destination address of that packet. We also request that the default *==>configurations of your routers be modified to prevent said forwarding. * *This is against RFC 1812. * *RFC 1812, "Requirements for IP Version 4 Routers", Section 5.3.5, *specifies: * *--- * A router MAY have an option to disable receiving network-prefix- * directed broadcasts on an interface and MUST have an option to * disable forwarding network-prefix-directed broadcasts. These options * MUST default to permit receiving and forwarding network-prefix- * directed broadcasts. *--- Yes, well, the fact that most vendors do NOT have a knob to turn this off is also against RFC 1812 (same paragraph, previous sentence) and that's a big part of the smurf problem. *Someone has stated before that editor(s) of said RFC are aware of this and *have discussed the change in default. No, jhawk said the editor(s) are "certainly aware" of the fact that the RFC could use some updating. No one said that they actually are aware, nor whether anyone is making an effort to update the document. If anyone originally associated with the document IS in fact working to change RFC 1812, I'd really like to hear about it. Privately or publicly. Please feel free to forward this note to the relevant parties if you know them. I have a keen interest in the topic. Thank you. *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. If after reading *http://www.quadrunner.com/~chuegen/smurf.txt, you think that I believe *directed-broadcasts should be on by default, go back and read agian. =) The point is that forwarding directed broadcasts should be off by default and that: 1. RFC 1812 should be changed to reflect this and 2. Vendors should modify their code to reflect this Whether these two things happen in parallel or serial is relevant only inasmuch as the vendor doth protest that they one must come before the other. They should both occur. And if a vendor wants to argue that they are in keeping with RFC 1812 by having the forwarding of directed broadcasts on by default BUT do not have a knob built in to turn it off, then that looks a bit hypocritical and they open themselves up to all sorts of taunting. *Now, since this has been beaten past the jelly stage, can we please put *the topic to sleep? Thank you. I seriously doubt that this topic is going to die until Smurf attacks get quite a bit smaller or go out of vogue. Just to be clear, Rusty asked whether requesting that the various vendors in the world create a knob to turn off the forwarding of directed broadcasts combined with requesting that it is configured off as a default setting would meet with approval by most of the readers of NANOG, not whether it was feasible or in keeping with the RFC. It is a known thing that this type of request doesn't meet the criteria of the RFC and lots of different folks are hoping that the RFC will change. I'm wondering whether there's any duplication of effort to that end (or any effort at all) going on. Kelly J. -- Kelly J. Cooper - Internet Security Officer GTE Internetworking - Powered by BBN - 800-632-7638 150 Cambridge Park Drive Fax - 617-873-5508 Cambridge, MA 02140 http://www.bbn.com

3 2

Router modifications to deal with smurf
by Rusty Zickefoose 27 Apr '98

27 Apr '98

-----BEGIN PGP SIGNED MESSAGE----- Fun with my mailor, let me try this again. So, if someone, or possibly a group of someones, were to make the following request to the various router vendors, would they be met with approval by most of the readers? We requests that your routers be configurable, at the interface level, to prevent the forwarding of an ICMP echo-request packet through an interface that has a broadcast or wire address that matches the destination address of that packet. We also request that the default configurations of your routers be modified to prevent said forwarding. We request that your routers be configurable, both globally and and the interface level, with the interface configuration overiding the global configuration, to prevent the forwarding of an IP packet with a source network address different from the network address of the interface on which it was received. We also request that the default configurations of your routers be modified to prevent, globally, said forwarding. - -- Rusty Zickefoose | The most exciting phrase to hear in science, rusty(a)mci.net | the one that heralds new discoveries, is not | "Eureka!", but "That's funny ..." | -- Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNUJVpe4+ch/bGDylAQH3uAP/ZHRdlufm9gbTUalVC9ax0H/nK7W/4S9r QLuSEfh9N8nHTbd4wSllB2GorzM46A0XFZCKAmUWzc5wFKL5lfjGbbu6Tfd8UUOF lxTQJYdda2ikmbLLBr8p+cUnb6BQLsA81Tst2twDc2BCf8GQsjxZvrCwh8sLCACe q47YHAChVLk= =htio -----END PGP SIGNATURE-----

5 4

CIDR and Classless subnetting
by kbrown＠primelink.com 27 Apr '98

27 Apr '98

This will be a real quick question, and responses should be sent directly to me, rather than the list please. I am trying to find more information about variable length subnetting. I have read the CIDR RFC, the VLS Table for IP v 4 RFC, and still am not sure about how to make it work. I have been accustomed to only subnetting class C networks. As I begin to implement the smurf amplifier blocking on our border router, it has come to be that I need to obviously get a better grasp. If any of you might suggest some recommended reading on this topic so I can quickly freshen up, it would be greatly appreciated. Thanks for answering the "junior" member of the list. Kevin Brown Huber & Associates, Inc. kbrown(a)primelink.com

1 0

Re: Traffic Shapping
by Natambu Obleton 27 Apr '98

27 Apr '98

In this situation I am about to implement data over a private fiber network in my town. Many businesses are planning to connect to this private fiber network for internet access and I want to sell Fractional usage on this private fiber network in 128k increments. I want to only limit their speed to the outside world, allowing them full Ethernet speed over the fiber to our local mail and proxy servers. We plan to use a cabletron switch to connect about 30-40 pairs of fiber to our network. That switch will be going FDDI back to my noc. So the best place to limit this is at the router where my internet connection comes in. Which is currently a Cisco 3640. I have thought about using a Aponet or Xedia box in between my FDDI switch and the router, but I would rather to the shaping on the router if possible. We would need to traffic shape up to 30-40 Ethernet speed users and 15-20 wireless users in the area. From the talk on this list about this, I do not think my Cisco router can do it. I will probably go ahead with an Aponet or Xedia solution. -- Natambu Obleton - Network Administrator - Frontier Internet Inc. 970 385 4177 - fax: 970 385 6745 - http://www.frontier.net 777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA -----Original Message----- From: Ehab Hadi <ehabh(a)hotmail.com> To: nanog(a)merit.edu <nanog(a)merit.edu>; no(a)frontier.net <no(a)frontier.net> Date: Friday, April 24, 1998 11:15 PM Subject: Re: Traffic Shapping >Natambu, >Can you please specify what platform that you are using? any why >you like to do the traffic shaping on the Ethernet which is >suppositly 10 Mbps? > >Ehab Hadi >Northern Telecom >Interprise Networks >Ottawa, ON K1Y 4H7 >Canada >ehabh(a)hotmail.ca > > >>From owner-nanog(a)merit.edu Fri Apr 24 09:59:44 1998 >>Received: from localhost (daemon@localhost) >> by merit.edu (8.8.7/8.8.5) with SMTP id MAA27417; >> Fri, 24 Apr 1998 12:51:49 -0400 (EDT) >>Received: by merit.edu (bulk_mailer v1.5); Fri, 24 Apr 1998 12:50:49 >-0400 >>Received: (from majordom@localhost) >> by merit.edu (8.8.7/8.8.5) id MAA27342 >> for nanog-outgoing; Fri, 24 Apr 1998 12:50:48 -0400 (EDT) >>Received: from home.merit.edu (home.merit.edu [198.108.60.42]) >> by merit.edu (8.8.7/8.8.5) with ESMTP id MAA27334 >> for <nanog(a)merit.edu>; Fri, 24 Apr 1998 12:50:43 -0400 (EDT) >>Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id >MAA04749 for nanog(a)merit.edu; Fri, 24 Apr 1998 12:50:43 -0400 (EDT) >>Received: from animas.frontier.net (root(a)frontier.net [199.45.141.1]) >> by merit.edu (8.8.7/8.8.5) with ESMTP id MAA27293 >> for <nanog(a)merit.edu>; Fri, 24 Apr 1998 12:49:01 -0400 (EDT) >>Received: from hermosa (hermosa [199.45.141.59]) >> by animas.frontier.net (8.8.8/8.8.8) with SMTP id KAA20190 >> for <nanog(a)merit.edu>; Fri, 24 Apr 1998 10:48:50 -0600 >>Message-ID: <00f301bd6fa1$4fdd1a70$3b8d2dc7(a)hermosa.frontier.net> >>From: "Natambu Obleton" <no(a)frontier.net> >>To: <nanog(a)merit.edu> >>Subject: Re: Traffic Shapping >>Date: Fri, 24 Apr 1998 10:52:04 -0600 >>X-Priority: 3 >>X-MSMail-Priority: Normal >>X-Mailer: Microsoft Outlook Express 4.72.2106.4 >>X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >>Sender: owner-nanog(a)merit.edu >> >>I am looking to do the shaping on Ethernet Interfaces for a large fiber >>plant. I have been looking the solution by Aponet. Anyone out there >used it? >>I believe it is what above.net uses. >> >>-- >>Natambu Obleton - Network Administrator - Frontier Internet Inc. >>970 385 4177 - fax: 970 385 6745 - http://www.frontier.net >>777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA >>-----Original Message----- >>From: Alex P. Rudnev <alex(a)Relcom.EU.net> >>To: Natambu Obleton <no(a)frontier.net> >>Cc: nanog(a)merit.edu <nanog(a)merit.edu> >>Date: Friday, April 24, 1998 10:33 AM >>Subject: Re: Traffic Shapping >> >> >>>Hmm, it depends of what do you mean as _successfully_ -:). >>> >>>It works, but creates some bugs under heavy conditions. >>> >>> >>> >>>On Thu, 23 Apr 1998, Natambu Obleton wrote: >>> >>>> Date: Thu, 23 Apr 1998 17:51:16 -0600 >>>> From: Natambu Obleton <no(a)frontier.net> >>>> To: nanog(a)merit.edu >>>> Subject: Traffic Shapping >>>> >>>> Has anyone here successfully implement the traffic shaping option on >a >>Cisco >>>> router? >>>> -- >>>> Natambu Obleton - Network Administrator - Frontier Internet Inc. >>>> 970 385 4177 - fax: 970 385 6745 - http://www.frontier.net >>>> 777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA >>>> >>>> >>>> >>> >>>Aleksei Roudnev, Network Operations Center, Relcom, Moscow >>>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) >239-10-10, >>N 13729 (pager) >>>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) >>> >> >> >> > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com >

1 0

Re: Traffic Shapping
by Natambu Obleton 27 Apr '98

27 Apr '98

IOS (tm) 3600 Software (C3640-I-M), Version 11.2(7a)P, SHARED PLATFORM, RELEASE SOFTWARE (fc1) cisco 3640 (R4700) processor (revision 0x00) with 49152K/16384K bytes of memory. -- Natambu Obleton - Network Administrator - Frontier Internet Inc. 970 385 4177 - fax: 970 385 6745 - http://www.frontier.net 777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA -----Original Message----- From: Ehab Hadi <ehabh(a)hotmail.com> To: no(a)frontier.net <no(a)frontier.net>; jerry(a)freeside.fc.net <jerry(a)freeside.fc.net> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Friday, April 24, 1998 11:03 PM Subject: Re: Traffic Shapping >I think traffic shaping is very importent. I agree to the point >that the new traffic shaping approches tends to shape on near the >edges, but that would not prevent applying such approches in the >core especially if its an interprise net. >The shapping implemintation preferred to be implemented in switch >because the hardware is simply fast and efficient. >Jeremy, >Would you please specify what kind of Cisco platform that you are >using? > >Ehab Hadi >Northern Telecom. >Interprise Networking >Ottawa, Ontario K1Y 4H7 >Canada > > >>From owner-nanog(a)merit.edu Fri Apr 24 09:39:40 1998 >>Received: from localhost (daemon@localhost) >> by merit.edu (8.8.7/8.8.5) with SMTP id MAA26391; >> Fri, 24 Apr 1998 12:27:05 -0400 (EDT) >>Received: by merit.edu (bulk_mailer v1.5); Fri, 24 Apr 1998 12:25:12 >-0400 >>Received: (from majordom@localhost) >> by merit.edu (8.8.7/8.8.5) id MAA26259 >> for nanog-outgoing; Fri, 24 Apr 1998 12:25:11 -0400 (EDT) >>Received: from freeside.fc.net (freeside.fc.net [207.170.70.2]) >> by merit.edu (8.8.7/8.8.5) with ESMTP id MAA26217 >> for <nanog(a)merit.edu>; Fri, 24 Apr 1998 12:24:37 -0400 (EDT) >>Received: from freeside.fc.net (localhost.fc.net [127.0.0.1]) >> by freeside.fc.net (8.8.8/8.8.8) with ESMTP id LAA14282; >> Fri, 24 Apr 1998 11:24:30 -0500 (CDT) >>Message-Id: <199804241624.LAA14282(a)freeside.fc.net> >>To: "Natambu Obleton" <no(a)frontier.net> >>cc: nanog(a)merit.edu >>Subject: Re: Traffic Shapping >>In-reply-to: Your message of "Thu, 23 Apr 1998 17:51:16 MDT." >> <072601bd6f12$b4f15050$3b8d2dc7(a)hermosa.frontier.net> >>Date: Fri, 24 Apr 1998 11:24:29 -0500 >>From: Jeremy Porter <jerry(a)freeside.fc.net> >>Sender: owner-nanog(a)merit.edu >> >> >>Sure we do it all the time. There are CPU limitations on the >>amount of total traffic that can be pushed through a router that >>is traffic shaping. I'm assuming because all the shaped traffic is >>process switched. Also you will probably want to dedicate a router >>to it. >> >>Typically these are only useful near the customer connection, as >>you can really only shape outbound packets. (unless you >>traffic shape at your boarders, and have a "large" network, you've >>already paid for the traffic by the time you discard it.) >> >>In message <072601bd6f12$b4f15050$3b8d2dc7(a)hermosa.frontier.net>, >"Natambu Oble >>ton" writes: >>>Has anyone here successfully implement the traffic shaping option on a >Cisco >>>router? >>>-- >>>Natambu Obleton - Network Administrator - Frontier Internet Inc. >>>970 385 4177 - fax: 970 385 6745 - http://www.frontier.net >>>777 Main St. - Suite #201 - Durango - Colorado - 81301 - USA >>> >>> >> >>--- >>Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net >>PO BOX 80315 Austin, Tx 78708 | 512-458-9810 >>http://www.fc.net >> > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com >

1 0

Re: SMURF amplifier page
by Kyle C. Bacon 27 Apr '98

27 Apr '98

I didn't see you on the list, but I can send you a copy of the page and you can double check...:) K On Apr 27, 12:47pm, Eric Germann wrote: > Subject: Re: SMURF amplifier page > Uhhh, is it just me, or does the below imply that if you are on the list, > you can't read the page to find out > > a) you're on the list > b) how to get off the list > > Kind of a catch-22 here, isn't it? > > :) > > Eric > > > At 07:21 PM 4/26/98 -0500, Karl Denninger wrote: > > > >As promised, we now have a web page for this. > > > >The current smurf list is at http://www.mcs.net/smurf > > > >This will be updated roughly weekly, or whenever major changes are made > >to the list of blocked networks. It contains, in addition to dialogue on > >the Smurf issue, a list of network numbers and "whois" lookups on the > >owners. > > > >IF YOU APPEAR ON THIS LIST YOU CANNOT TRANSPORT PACKETS INTO OUR > >INFRASTRUCTURE. > > > >Instructions for what you must do to get the block removed are contained > >within this page. Bitching and moaning is pointless - the only fix is > >to FIX THE PROBLEM. > > > >Thank you! > > > >-- > >-- > >Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin > >http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV > > | NEW! Corporate ISDN Prices dropped by up to 50%! > >Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS > >Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost > > >-- End of excerpt from Eric Germann -- | Kyle C. Bacon | kbacon(a)fnsi.net | Vice President - Operations | Fiber Network Solutions, Inc.

1 0