- NANOG - lists.nanog.org

ISP.au Winter '98 - June 25th to June 27th
by andrew khoo 27 Apr '98

27 Apr '98

(apologies for multiple copies sent) MEDIA RELEASE (FOR RELEASE 28-April-98) ISP.au returns in 1998 even BIGGER and BETTER! ---------------------------------------------- Ourworld Global Network is proud to announce the return of ISP.au after the successful first conference run last December. ISP.au Winter '98 is a conference specifically focused on ISPs (Internet Service Providers) in Australia. This will be held in Sydney, Australia from June 25th to 27th, 1998 at the Sydney Hilton. ISP.au remains the only ISP-orientated conference in the Asia-Pacific region. ISP.au is a 3 day conference held on a seminar/tutorial basis with a focus on the business and networking operations sides of operating ISPs. Speakers include leading technologists and business people in the ISP business in Australia and USA. Dr Wayne Nowland, an internationally recognized expert in the telco and satellite fields, will be presenting the keynote speech entitled "Heading into the Millenium". Dr Nowland will be speaking on the emerging tranmission technologies that will directly affect delivery of the Internet in the coming years. The seminars cover a series of contemporary topics including legislative and regulatory issues affecting Australian ISPs; ISP industry associations; issues with settlement-based and settlement-free peering; and various other issues relating to the business development of the ISP market. The tutorial series includes sessions on basic and advanced network operations held by routing gurus Avi Freedman and Justin Newton; deployment of HFC/DSL solutions; scaling large dial access POPs; implementation of satellite delivery mechanisms; deployment of Voice Over IP technologies and other hands-on technical issues. A "pre-conference" seminar will also be held for people interested in becoming ISPs on June 24th. This is a wonderful forum for ISPs-to-be to learn about various aspects of the industry from the more established business and technical people who have gone through the initial difficult stages of operating ISPs. This is a unique seminar not offered anywhere before. A highlight of this conference is a dinner and social to be held at Barcode in Star City on the Friday evening (June 26th) which will promote networking amongst ISPs and other parties in the industry. There are also other opportunities for networking during the conference, in particular during the various breaks throughout the days. The intended audience for this conference are technical and business staff at ISPs, vendors supplying the Internet market, people intending to become ISPs, and telco staff wanting to learn more about the emerging IP technologies. The registration charge for ISP.au Winter '98 is A$350 per attendee. An early-bird registration special of A$250 applies for registrations paid by May 15th. All registration is done via an online form. An agenda and additional information on this conference can be obtained from http://www.isp-au.org/. Further details can also be obtained from Rob Bridger or Sharyn Driscoll via telephone to +61-2-9223-2777. ---

1 0

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

27 Apr '98

> > 2. Routers/Gateways should be configured to drop all packets > > with invalid source addresses. > > > > 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. > > The problem isn't us. It's cicso, and Bay, and Ascend, > and... everyone who won't put an anti-forging filter on their > border routers so we _can_ turn it on. The first time someone > co-sues cisco, it'll get fixed with 30 days. Current recipe for anti-forging with Cisco hardware: o Pick up CEF code (11.1(17)CC, which doesn't yet (?) exist for all Cisco platforms, unfortunately) o Configure: ! ip cef switch ! or "ip cef distributed switch" for an RSP+VIP2 based box ! interface whatever ip verify unicast reverse-path ! 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) makes sense. If you have Ascend/Livingston or other dial-up equipment this check should probably be implemented in the closest up-stream router which has this capability, and definately not in a router which could take part in asymmetric traffic patterns. - Håvard

5 4

RE: Traffic Shapping
by Hank Nussbacher 27 Apr '98

27 Apr '98

At 03:25 PM 4/25/98 -0400, Mark R. Lindsey wrote: >: >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? >: >: He may well want to shape on an ethernet where he has multiple >: customer machines that are each paying for different amounts of bandwidth. >: >: Shaping a-la cisco is uni-directional out on an interface, and so >: poorly answers many needs. > >Xedia Corporation makes a nifty device specifically for IP traffic >shaping. It seems fairly well evolved, and can act as a bridge or a >router, though it's definitely built for the edges of a network. > >(I'm not affiliated with Xedia; just played with their product.) One can find a number of PPT files from a conference ISOC-IL held in 1/98. Three bandwidth mgmt products were discussed (Floodgate, Classdata & Bandwiz): http://www.isoc.org.il/conf98/pres.html -Hank > >--- >Mark R. Lindsey, mark(a)datasys.net DSS Online >Voice: +1 912 241 0607; Fax: +1 912 241 0190 Valdosta, Georgia, USA > >

1 0

RE: Traffic Shapping
by mark＠vielle.datasys.net 26 Apr '98

26 Apr '98

: >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? : : He may well want to shape on an ethernet where he has multiple : customer machines that are each paying for different amounts of bandwidth. : : Shaping a-la cisco is uni-directional out on an interface, and so : poorly answers many needs. Xedia Corporation makes a nifty device specifically for IP traffic shaping. It seems fairly well evolved, and can act as a bridge or a router, though it's definitely built for the edges of a network. (I'm not affiliated with Xedia; just played with their product.) --- Mark R. Lindsey, mark(a)datasys.net DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190 Valdosta, Georgia, USA

2 1

Re: cflowd - seems OK now ;-)
by Matt Ranney 26 Apr '98

26 Apr '98

Leigh Porter <leigh(a)wisper.net> writes: [...] > > Unfortunately it looks like this is only in 11.1(?) > > It sure does, does anybody have an details about what is differant onthe new > version (Version 6?)? You need flow export version 5 on your routers to use cflowd. It sure would be handy if the error message that cflowd printed lead you believe this instead of that your IP stack is broken somehow. In addition to version 5 of the export format, newer IOS versions also let you do good things like expire flows more frequently then 30 minutes (the old default) and set the source address. -- Matt Ranney - mjr(a)ranney.com Let's not let the students run the High School.

2 1

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