- Test - lists.nanog.org

filtering spoofed addresses cheaply
by William Allen Simpson 26 Apr '98

26 Apr '98

There has been a fair amount of discussion about where and how to filter spoofed IP Source addresses. I don't understand why this is considered so hard. Let me tell you about what Merit did nearly 15 years ago.... Every NAS (they were called SCPs in those days) knows the address assigned to each link. So, Merit code just replaced the incoming IP Source field with the known address, before calculating the IP Header checksum. Spoofed addresses -> packets discarded with bad checksum. Simple. Elegant. No additional CPU. We merely want the same thing to happen BY DEFAULT on every dial-up link. Listening Lucent/Livingston? Ascend? Et alia? Now, the ethernet spoof detection is a little harder, but since each interface is already configured with an address and subnet prefix length (or mask), every interface should simply discard all incoming packets with an IP Source prefix that does not match. The knob for accepting other extra subnets should default to "off", just as the knob for accepting RIP broadcasts defaults to "off", and the knob for BGP peers defaults to "off". KISS. You don't accept unexpected routing advertisements from your downstreams, do you!?!? The whole argument about asymmetric routing does not apply. You would not filter at those multi-homed routers in any case, and you already have to configure something special (routing policy). WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

3 2

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

26 Apr '98

Craig, I am currently looking into the feature set for this release, as I have to support SMDS, HSRP, Frame, ATM, and VIP2-50 boards. Hopefully this will work. Have you heard of any success/failure stories using dCEF on 75xx against these attacks. If so, I'd be interested to hear of them. PS I have your paper on my corkboard - very nice. Just rantin' and ravin'. Chris >-----Original Message----- >From: Craig A. Huegen [SMTP:chuegen@quadrunner.com] >Sent: Sunday, April 26, 1998 3:44 AM >To: Martin, Christian >Cc: 'nanog(a)merit.edu' >Subject: RE: Network Operators and smurf > >On Sun, 26 Apr 1998, Martin, Christian wrote: > >==>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. > >Have you read the smurf document found at >http://www.quadrunner.com/~chuegen/smurf.txt? > >I'd be interested to know what version of code you were running. > >I've seen a provider drop over 120 Mbps of smurf traffic in access-lists >for over an hour and the routers weren't affected one bit. > >IOS CA & CC code 11.1(13.5) and later have a fix to the code which handles >access-list drops--called "fast drop"--which fixes some inefficiencies in >packet handling. > >***READ*** the document at the URL above. It's amazing how much that URL >has been advertised, through all the advisories, through the NOCs, etc., >but with the ongoing thread over the last few weeks it almost appears that >a lot of people either haven't heard about it or haven't read it. > >Of course, it's been put into mail messages 9 times on NANOG already: >chuegen@quad:3:~>grep "quadrunner.com" mail/nanog | grep "smurf" | wc -l > 9 > >/cah >

1 0

Re: Traffic Shapping
by Ehab Hadi 26 Apr '98

26 Apr '98

What I meant to shape on the core: Is traffic aggregation. This is why most vendors trying to propose different solutions hence to scale core, e.g., proposed IETF MPLS. Regarding the shaping issue on the Cisco Ethernet is not appreciated while the shaping preferred to be provisioned at the outboand interface. I would like also to add Cisco has powerful tools must be studied well before installing third party solution. I agree that traffic patterns must be studied well to evaluate what approach that must be followed. Ehab H. Hadi Northern Telecom Ottawa, ON ehabh(a)hotmail.com >From owner-nanog(a)merit.edu Sat Apr 25 15:14:14 1998 >Received: from localhost (daemon@localhost) > by merit.edu (8.8.7/8.8.5) with SMTP id SAA20768; > Sat, 25 Apr 1998 18:05:57 -0400 (EDT) >Received: by merit.edu (bulk_mailer v1.5); Sat, 25 Apr 1998 18:05:28 -0400 >Received: (from majordom@localhost) > by merit.edu (8.8.7/8.8.5) id SAA20729 > for nanog-outgoing; Sat, 25 Apr 1998 18:05:27 -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 SAA20725 > for <nanog(a)merit.edu>; Sat, 25 Apr 1998 18:05:21 -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 RAA21337; > Sat, 25 Apr 1998 17:05:16 -0500 (CDT) >Message-Id: <199804252205.RAA21337(a)freeside.fc.net> >To: "Ehab Hadi" <ehabh(a)hotmail.com> >cc: no(a)frontier.net, nanog(a)merit.edu >Subject: Re: Traffic Shapping >In-reply-to: Your message of "Sat, 25 Apr 1998 01:03:28 EDT." > <19980425050329.10670.qmail(a)hotmail.com> >Date: Sat, 25 Apr 1998 17:05:16 -0500 >From: Jeremy Porter <jerry(a)freeside.fc.net> >Sender: owner-nanog(a)merit.edu > > >Traffic shaping in the core of a network won't scale. "enterprise" or private >networks haven't got much life left in them. (This is Nanog right?) >We use 2500 series ciscos for traffic shaping at T-1 and below, but that >isn't terribly related to nanog either. >One just has to look at exchange point data to see what >traffic volumes are like, I don't know of anything that >can switch VC near 2gbps/sec particuarlly with the flow life times >of Internet traffic. >It's much cheaper to shape/filter at the borders and overengineer the >core. It also increases usefull lifetime of hardware. (No forklift >upgrades). > >In message <19980425050329.10670.qmail(a)hotmail.com>, "Ehab Hadi" writes: >>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 >> > >--- >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: Network Operators and smurf
by Havard.Eidnes＠runit.sintef.no 26 Apr '98

26 Apr '98

> The other extreme is that, what if you are singly-homed? Then > it is useless again. Why, may I ask? This removes the need to maintain access lists to do the same thing, so I don't see it as entirely useless. - Håvard

3 2

Re: Network Operators and smurf
by Havard.Eidnes＠runit.sintef.no 26 Apr '98

26 Apr '98

> > This should (naturally) be implemented where routing is symmetric > > and where a "reverse-path check" (looking up the source address in > > the routing table to find the "expected" incoming interface and > > checking whether the packet did indeed enter through that interface) > > The big question is, what do you do if most of your traffic > _is_ asymetrical? Well, in that case you can't apply this method. It may however make sense to think of reengineering the network so that those boxes which can't do this check sits "behind" such a RPF-checking box. > I mean, a more basic check could be, "Does the network that > this packet was sourced from exist *at all*?", or "Do I have a > route back to the source network through *any* interface?" > > That would cut down on a good amount of spoofing, like the > idiots who spoof from 1.1.1.1 etc. It would prevent simple spoofing, yes, but that would not eliminate the Smurf attacks since to mount a Smurf attack you need to use the victim's address as your source address, and that one *is* typically "valid" according to the criteria you mention above (?). - Håvard

3 2

Re: Traffic Shapping
by Ehab Hadi 25 Apr '98

25 Apr '98

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

2 1

Re: Traffic Shapping
by Ehab Hadi 25 Apr '98

25 Apr '98

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

2 1

Re: Network Operators and smurf
by Havard.Eidnes＠runit.sintef.no 25 Apr '98

25 Apr '98

> Wait; all traffic is coming in one interface. The CEF thing > will have no effect if the spoofed source address is a real > network. "The CEF thing" configuration from my first message in this thread does the following: For each packet entering an interface with "ip verify unicast reverse-path" turned on, the router will look up the source address from the IP packet in the CEF table and find the interface (or set of interfaces) it would use to route back to the source. If the incoming interface for the actual packet is not among those returned by the "reverse-path" lookup, the packet is dropped on the floor. >From my point of view this is exactly the sort of functionality which is needed to prevent us from being the host (originator) of a Smurf attack (or more generally from attacks involving IP address spoofing), as in the case of a Smurf attack packets with the victim's source address entering from the wrong interface will be dropped on the floor. If you still think this doesn't help or isn't useful, I propose that we take it to private e-mail (?). - Håvard

1 0

Operational: MAE-EAST outage
by dlr＠bungi.com 25 Apr '98

25 Apr '98

Many of our mae-east peers went down around 11:30 PDT, and didn't come up again until nearly 12:30. When called, MFS said that they had done "scheduled maintenance", and replaced a "clocking card". MFS ticket #210855. Did anyone get notified? -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

Network Operators and smurf
by Rusty Zickefoose 24 Apr '98

24 Apr '98

-----BEGIN PGP SIGNED MESSAGE----- Hi all, <rant> If were reading this list on a professional basis, we should be a little clued, or at least attempting to get there. We're in the big leagues now, read up on CIDR, figure out classless subnetting. To advocate breaking legitimate routing because we, as an industry, don't want to put in the time and effort to educate our end users is just a little lame. </rant> Had to get that off my chest. Anyway, it's been said here several times before, but I'll say it again. To end the smurf type exploits, we need to do 2 things. 1. Routers/Gateways should be configured to prevent the transmission of echo-request packets, out an interface, to a destination address identical to the broadcast address of that interface, except in those cases where specifically required. This means getting vendors to give us a knob, and having it default to off. This is the easy one folks, figuring out net-masks aren't that hard. The transit providers might have problems with implementing this due to hardware meltdown, but that's not where it needs to be implemented. !!Educate your (our) users!! 2. Routers/Gateways should be configured to drop all packets with invalid source addresses. This is a little bit more difficult, particularly if your multi-homed, but again, it's not the transit providers that are need to implement this, its the end user. once more !!Educate your (our) users!! No. 2 has the benefit of fixing all manner of ills. The problem is us. This isn't a research network run and maintained by the knowledgable. This is a business. We're selling a product, and if we expect it to operate as advertised, it's up to us to educate those we sell it to. This is Mr. Pot, saying so long to all you kettles out there. - -- 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 iQCVAwUBNUDlvu4+ch/bGDylAQGktAQAolKXogM3Gyr/Wp/AE1h6jZo6QQOTtOIU ZkFUI+Dk7tKCoc6BPZ4VrsiPF1zslnQoIWwdceubl7kK+GwIyH4CTWtAyXGP+wr3 6EHKiYfZ19P/Wvhi0Cjxo2buxYgpLCEHeKR4GUKwnJI66HlInemlUp4zDpMQFy8R mNIdSK/Pw1k= =/Dxy -----END PGP SIGNATURE-----

9 16