- NANOG - lists.nanog.org

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 28 Apr '98

28 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 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