- NANOG - lists.nanog.org

Fiber cut in SJ 1:54 EST
by Richard Irving 14 Feb '98

14 Feb '98

There has been a fiber cut in SJ region affecting several carriers. The fiber carriers (WC) will be keeping everyone informed. Expect unusual flows. :( Darn these pesky natural disasters. ;)

1 0

A Nap is a Nap is a Nap
by Alex Rubenstein 14 Feb '98

14 Feb '98

Since I have seen a couple NAP annoucements lately, I figured I'd at least tell people about this one. It is called the NY-IIX, or the New York Internation Internet Exchange. It is located in neutral space, not operated or owned by and ISP or any Internet related company. It is operated by a co-lcoation known as Telehouse (http://www.telehouse.com) The switch itself is a Catalyst 5000, with switched 10 or switched 100 ethernet, or switched 100 FDDI. It has some peers in it already, and has the potential for being a very good XP; in the telehouse space alone are decent sized ISPs; us (nac.net) lightning.net, KDD Japan, Internet Initiative Japan, Mindspring, ANS, wisper, etc. (I am not saying they are all in the NAP, but they are in the co-lo, and have the potential to connect to the NAP). If you are interested, try Rick Mataka at 718.355.2500.

3 2

Re: Smurfing
by William Allen Simpson 14 Feb '98

14 Feb '98

Wow, I was glad to see that all these wonderful folks are reading the router requirements (RFC-1812, June 1995). Good, good. What I'd like to understand is how smurf attacks can work, even with directed broadcast on? Isn't there a requirement (RFC-1122) from ages past (October 1989) that ICMP not respond to broadcast or multicast [page 38 et seq]? What pressure is being put on host vendors? Which host vendors are the problem? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

2 2

Re: Smurfing
by Steve Hultquist 13 Feb '98

13 Feb '98

Don't these answers answer a different question? Isn't the question how to filter *outbound* attacks, not inbound ones? Filtering the inbound ones is pretty easy on a Bay or anything with filters (drop packets bound for the broadcast addresses). Filtering outbound is another story, especially with CIDR. I would like to set up my routers to make sure I'm protecting as much of the 'net as possible from attempts by my customers to do evil. However, it's not clear to me how to do that. Does "no ip directed-broadcast" somehow filter the *outbound* attacks or just the inbound ones? -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

4 3

Re: Smurfing
by Chris A. Icide 13 Feb '98

13 Feb '98

At 02:52 PM 2/13/98 PST, Randy Bush wrote: > >why should this not have become the default mode for all vendor diustributed >router code? > was that meant to be "distrusted" code, or distributed? :) either way, we may want to do a quick list of such commands, including the following: ip classless ip subnet-zero what ones did I miss? ************************************************************** Chris A. Icide voice: +1-650-482-2840 Chief Technology Officer fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "Tommorrow's Performance Today." - Notice: NVRAM invalid, possibly due to write erase. Press RETURN to get started! - PGP Keys located at pgpkeys.mit.edu **************************************************************

1 0

Re: Multicast and Digex?
by Steve Hultquist 13 Feb '98

13 Feb '98

--On Thursday, February 12, 1998, 1:28 PM -0500 "Eric Germann" <ekgermann(a)cctec.com> wrote: > Anyone from Digex here? Send me a note to discuss multicast routing. Your > Private Network Services client said "Huh?" when asked about setting me up > for multicast. I asked this of them during the most recent meeting and received this in reply: > Steve, > > Mbone is not supported robustly enough by the versions of Cisco IOS that > DIGEX runs on our core routers. We run standard unicast packages, and > multicast support is not in demand enough to see stable releases. > Additionally, bandwidth problems with current multicast routing structures > are high enough to warrant additional waiting before we implement this > service across our backbone after software stability has been achieved. > > Let us know if you have any questions. > > Richard White, Shift Mgr. > Business Connectivity Technical Support -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

2 1

Re: Smurfing
by Steve Hultquist 13 Feb '98

13 Feb '98

Havard, --On Friday, February 13, 1998, 11:45 PM +0100 Havard.Eidnes(a)runit.sintef.no wrote: > getting Smurfing "under control" takes two things: > > o All router administrators on the immediately reachable > Internet needs to turn off directed broadcasts on their router > interfaces. > o Making sure source IP address spoofing isn't as easily done as > it is now. Also an easy one, right? ;-) I agree, and this is what we have done. The earlier post (from someone else) was asking about how to filter *outbound* directed broadcasts, and I didn't understand how this could be done. A number of my NANOG colleagues have adamantly agreed that it can't! > o While we struggle with the above two, at least some service > providers need to become more responsive in tracking these > sort of events back to their real source. No names mentioned, > none forgotten. Agreed. Would it make sense to come up with a cooperative mechanism for this similar to CERT only faster? > o Lastly, I think that better tools are needed to track this > sort of attacks back to their source (?). That would be very difficult, effectively requiring the ability to query routers and ask if they are seeing packets bound for a specific address. I'd love to see some tools that would help us do that, however! -- Steve Hultquist, Chief Technology Officer HSAnet providing high-speed Internet access Boulder, Colorado mailto:ssh@HSAnet.net +1.303.581.0800 http://www.HSAnet.net/

1 0

RA/RV Feeds from RBN
by Jeffrey Payne 13 Feb '98

13 Feb '98

Time to take a moment and describe today's feed from the encoding perspective. We do lots of on-site coverage, and usually bring in a dedicated ISDN for the encoder feed back to the server(s) and out to the network. In UDP mode, our encoder and server can buffer quite deeply (say, 300 seconds) to accommodate some pretty significant network outages. Until today, we couldn't imagine a scenario where this wasn't good enough, but as luck would have it, we were wrong. Fortunately today's net problem was resolved by the end of the general session and Tuesday *should* be much cleaner. On the subject of camera positioning and exposure, we know, it was not good. I think we can pull together a somewhat more coherent set of post-produced presentations with what we have on tape -- we'll find out when we get a look at them. But we should have better cameras, a video switcher, and somewhat better lighting to do this virtual conference thing right. Next meeting? I heard lots of questions on multicast today...here's how it works with RealMedia. If you have decent MBONE connectivity, you'll negotiate multicast when you connect to the audio or video stream. If you don't, the client falls back to unicast UDP mode. If even that fails (say you're behind a firewall), it rolls to TCP mode, and will ultimately resort to HTTP "cloaking" if nothing else works. Users can override the automated fall-back through the preferences dialog if there's a strong preference for a particular mode. Jeffrey Payne, GM Broadcast Operations RealNetworks, Inc.

9 9

Re: Smurfing
by Joe Provo - Network Architect 13 Feb '98

13 Feb '98

> ==>Perhaps some of the folks on NANOG that use equipment other than Cisco > ==>would like to share how they "configure their router for that"? It would > ==>be a nice service to everyone... > > http://www.quadrunner.com/~chuegen/smurf.txt > > It has Bay Networks and Proteon information, and I'm adding Ascend > information as well within the next week. ...and I've given Craig FORE, Livingston and DEC info. I'm looking to get some more CPE-ish vendors out to him as well. > With Ascend, you must filter traffic to the broadcast address. Am I the only one who thinks them not setting the knob to turn this off is nuts? To have to cut filters specific to each address on a case-by case basis is a lot of work that some people won't take on, and clue- challenged custromers will have difficulty with... Joe

1 0

The Cidr Report
by Tony Bates 13 Feb '98

13 Feb '98

This is an auto-generated mail on Fri Feb 13 12:00:00 PST 1998 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 13Feb98 0) General Status Table History ------------- Date Prefixes 290198 50396 300198 50242 310198 49848 010298 49715 020298 49739 030298 49600 040298 49877 050298 49484 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 2407 Number of ASes announcing only one prefix: 718 (0 cidr, 718 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1044 announced by AS701 1) Gains by aggregating at the origin AS level --- 13Feb98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 691 368 323 46.7% iSTAR Internet, Inc. AS6235 495 252 243 49.1% Intermedia Communications, Inc. AS4293 430 210 220 51.2% IMCI AS174 874 673 201 23.0% Performance Systems International AS816 635 444 191 30.1% UUNET Canada (ASN-UUNETCA-AS4) AS3602 455 304 151 33.2% Sprint Canada Inc. AS3749 202 61 141 69.8% TECNET AS701 1044 931 113 10.8% Alternet AS3336 109 19 90 82.6% Internet Services, Kolumbus proje AS3751 125 48 77 61.6% SNET-AS AS5668 107 40 67 62.6% Century Telephone Inc. AS3804 204 142 62 30.4% WORLDLINX AS2048 154 92 62 40.3% LaNet AS1239 596 534 62 10.4% SprintLink Backbone AS3221 92 33 59 64.1% EENet Autonomous System AS1 840 782 58 6.9% BBNPLANET AS271 110 55 55 50.0% BCNET-AS AS719 519 468 51 9.8% LANLINK autonomous system AS549 214 163 51 23.8% ONET-AS AS3464 115 64 51 44.3% Alabama Research and Education Ne AS1221 263 214 49 18.6% AARNET-AS AS72 84 36 48 57.1% Schlumberger Information Network AS4763 128 80 48 37.5% Telstra New Zealand AS7545 114 69 45 39.5% TPG Internet Pty Ltd AS684 86 42 44 51.2% MBNET-AS AS4740 354 312 42 11.9% ASN-OZEMAIL (Ozemail Pty Ltd) AS2711 97 55 42 43.3% SUNBELT-AS AS7046 130 89 41 31.5% UUNET-CUSTOMER AS3561 897 857 40 4.5% MCI AS852 156 117 39 25.0% CANET-ASN For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 1