- Test - lists.nanog.org

RE: White House Net security summit
by Mike Bostardi 23 Sep '00

23 Sep '00

More than likely laws will be passed that gives the Feds the ability to fine you $100 US for not changing your passwords every 30days. IHMO this latest "White House Meeting" is another example of the government attempting to regulate something that they have no clue and no business in. Whats next a committee on minimum router config standards... I'm done > -----Original Message----- > From: Wayne Bouchard [mailto:web@typo.org] > Sent: Thursday, September 21, 2000 6:35 PM > To: Sean Donelan > Cc: nanog(a)merit.edu > Subject: Re: White House Net security summit > > > > Is security in an environment where new applications are installed on > an almost daily basis something you can really regulate? In some > regards, the thought of Washington getting involved here scares > me. > > On Thu, Sep 21, 2000 at 03:03:55PM -0700, Sean Donelan wrote: > > > > I guess if you snooze you loose. For anyone who didn't > know from MSNBC > > > > "A group of key high-tech executives agreed at a White > House meeting earlier > > today to move forward on a plan to set minimum security > standards for big > > companies that connect to the Internet, MSNBC.com has > learned. The meeting > > was attended by Microsoft, IBM, Oracle, Boeing, the > National Security Agency > > and U.S. Secretary of Commerce Norm Mineta." > > > > > > > > ---------------------------------------------------------------------- > Wayne Bouchard [Immagine Your ] > web(a)typo.org [Company Name Here] > Network Engineer > http://www.typo.org/~web/resume.html > ---------------------------------------------------------------------- >

3 3

Re: exponential route prefix growth, was: Re: The Cidr Report
by John Todd 23 Sep '00

23 Sep '00

>On Fri, Sep 22, 2000 at 03:44:50PM -0400, Vijay Gill wrote: > > On Fri, 22 Sep 2000, Kai Schlichting wrote: > > > > [ http://www.employees.org/~tbates/cidr.plot.html for a plot ] > > > > > of engineering experience announcing 32 /24's out of their scattered > > > POPs in addition to their /19 aggregate because they can't get their > > > load balancing right without it or have never heard of the 'NO_EXPORT' > > > attribute (I could point fingers now)? > > > > I suspect data from inside providers with aggressive filtering policies > > might prove to be interesting. > > > > Some promising local providers were past the 150k mark a while ago for sum > > (internal + global bgp) routes and were growing superlinearly the entire > > time because of the ever increasing number of customers. > > I have in one location over 100k prefixes received from >one nice large international provider: > >Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down >State/PfxRcd >a.b.c.d 4 701 10776831 107250 13024503 0 0 1w4d 105250 > > My primary concern is that the current growth is going to >outscale the medium sized providers as the one vendor that >the above output came from doesn't appear to be providing enough memory >in their equipment, or have enough memory options available. > > I am not predicting "the internet will end in 9 days, repent", >but it is some cause for concern in the next 6-12 months. > > What would be nice is if someone were to put together an >auto-nagger similar to the "your dns server is lame" of the old days >messages. Back when the network tables were about 40-45k, I would read >the output of "sh ip b" and send messages to people asking them to >aggregate, but those days are over... (at least for me..) > > - jared > >-- >Jared Mauch | pgp key available via finger from jared(a)puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. >END OF LINE | Manger of IP networks built within my own home Take a look at: http://www.fox-den.com/routes/ This is a plot of routes v. paths on a router that peers with or at least sees the tables from a few large upstreams. Please ignore the large gaps in the chart where I <ahem> did some configuration that was contrary to the correct functioning of my statistics collection. This is a crude measurement, but it's useful for trending. I'm sure someone at CAIDA has done better research than my stupid-simple MRTG graphs, but I haven't seen theirs mentioned yet so I'll throw my $.02 in first. What is interesting in the growth difference between the two growth patterns. An interesting trend shows; there is a much larger increase in the number of paths than in the number of routes. I would assume that this indicates a growth in the interweaving of networks, or at least the interweaving of transit providing relationships. I suspect the interweaving of interconnections is growing at a similar rate, but proof of this is invisible with only a few BGP perspectives. Perhaps the more vital piece of information in this discussion is not the sudden growth of routes, but the growth of paths. The de-aggregation of routes (though I have done no research to prove this) seems to me simply a response to redundancy/load distribution issues introduced by current route selection algorithms. I think we're identifying one of the symptoms, but not the root cause of the growth in routes. * It seems that we should be saying that there is a growth in paths, not _just_ routes, and path growth with current implementation methodologies and reasoning implies route growth. * We come back to "BGP only works the way most people expect it to in a multi-home situation when you de-aggregate a route from one of your upstreams and announce it all the time to all your peers." Yes, there are many other reasons that one would de-aggregate and re-announce either back into the primary with the aggregate or others; however, I think that the (obvious) basic reasoning for the bulk of path/route announcements is redundancy and load sharing. The demand for "always on" backup ("announce all the time even in directions in which you pad the path") and cost efficiency ("we're paying for that second line, so we'd better get some use out of it") lead to increase in paths that need to be visible, and thus routes that need to be visible. Why in the last year has this been so large? You've got me there, but I'll take a swing at it. Probably something to do with the collapsing prices of bandwidth, the dispersion of BGP know-how (or the "how to set up BGP for your enterprise for dummies" books/FAQs, at least,) and the sudden expectation that all Internet traffic is mission-critical and mustmustmust always be available. The bubble of hype is finally moving down the hose and causing operational issues such as this. It's the nature of the beast; as complexity grows... complexity grows. So how does this get solved? The complex solutions of multi-provider NAT are possible, but practically impossible in a business environment where FUD rules the day. This is really a matter best discussed after at least 6 hours of deep thought, which is about 5:55 short of what has occurred for this message. :) JT

4 3

RE: exponential route prefix growth, was: Re: The Cidr Report
by Sean Donelan 23 Sep '00

23 Sep '00

On Fri, 22 September 2000, John Fraizer wrote: > Who's forcing address space on customers? It's like pulling teeth to get > address space from most of them! Cable&Wireless for one. I worked with several customers who never used the /24's allocated by C&W, but even after repeatedly telling C&W we don't need them, C&W wouldn't take them back. Every circuit came with a /24 whether you needed it or not.

3 2

The Cidr Report
by Tony Bates 23 Sep '00

23 Sep '00

This is an auto-generated mail on Fri Sep 22 12:00:00 PDT 2000 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 22Sep00 0) General Status Table History ------------- Date Prefixes 150900 87093 160900 87265 170900 87208 180900 87379 190900 87348 200900 87707 210900 87719 220900 87996 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.0.0.0/14 from AS6172 *** Bogus 65.33.0.0/16 from AS10994 *** Bogus 65.128.0.0/14 from AS209 *** Bogus 65.132.0.0/15 from AS209 *** Bogus 65.134.0.0/17 from AS209 *** Bogus 65.134.128.0/19 from AS209 *** Bogus 65.160.0.0/15 from AS1239 *** Bogus 65.162.0.0/16 from AS1239 *** Bogus 66.1.16.0/20 from AS3847 *** Bogus 66.4.0.0/17 from AS11686 *** Bogus 66.4.0.0/15 from AS11686 *** Bogus 66.4.128.0/17 from AS11686 *** Bogus 66.6.32.0/20 from AS701 *** Bogus 66.6.64.0/20 from AS14480 *** Bogus 66.6.96.0/20 from AS10970 *** Bogus 66.6.128.0/20 from AS3561 *** Bogus 66.6.192.0/20 from AS11282 *** Bogus 66.7.0.0/19 from AS16484 *** Bogus 66.7.64.0/19 from AS14618 *** Bogus 66.9.0.0/19 from AS6221 *** Bogus 66.9.16.0/23 from AS16445 *** Bogus 66.10.0.0/20 from AS7132 *** Bogus 66.10.32.0/20 from AS7132 *** Bogus 66.16.0.0/17 from AS14914 *** Bogus 66.18.13.0/24 from AS3549 *** Bogus 66.20.128.0/22 from AS7892 *** Bogus 105.200.37.0/24 from AS9768 *** Bogus 217.0.0.0/13 from AS3320 *** Bogus 217.8.0.0/20 from AS1299 *** Bogus 217.8.32.0/20 from AS3220 *** Bogus 217.8.128.0/20 from AS15552 *** Bogus 217.8.160.0/20 from AS8246 *** Bogus 217.8.160.0/20 from AS15560 *** Bogus 217.9.32.0/20 from AS15563 *** Bogus 217.9.36.0/22 from AS15563 *** Bogus 217.9.42.0 from AS15563 *** Bogus 217.9.64.0/20 from AS3269 *** Bogus 217.9.96.0/20 from AS15671 *** Bogus 217.9.128.0/20 from AS12969 *** Bogus 217.9.160.0 from AS15606 *** Bogus 217.9.224.0/20 from AS13124 *** Bogus 217.10.0.0/20 from AS1270 *** Bogus 217.10.64.0/20 from AS15594 *** Bogus 217.10.96.0/20 from AS5556 *** Bogus 217.10.96.0/20 from AS5378 *** Bogus 217.10.160.0/23 from AS15641 *** Bogus 217.10.162.0 from AS15641 *** Bogus 217.10.192.0 from AS12302 *** Bogus 217.11.0.0/20 from AS9034 *** Bogus 217.11.64.0/20 from AS702 *** Bogus 217.11.160.0/20 from AS3259 *** Bogus 217.11.224.0/20 from AS15685 *** Bogus 217.12.0.0/20 from AS15635 *** Bogus 217.12.32.0/20 from AS5378 *** Bogus 217.12.96.0 from AS15632 *** Bogus 217.12.96.0/23 from AS15632 *** Bogus 217.12.97.0 from AS15632 *** Bogus 217.12.192.0/20 from AS15626 *** Bogus 217.12.224.0/20 from AS15438 *** Bogus 217.13.0.0/20 from AS15659 *** Bogus 217.13.32.0 from AS15629 *** Bogus 217.13.33.0 from AS15629 *** Bogus 217.13.34.0 from AS15629 *** Bogus 217.13.192.0/20 from AS9126 *** Bogus 217.13.224.0/20 from AS3220 *** Bogus 217.14.64.0/20 from AS3303 *** Bogus 217.14.96.0/23 from AS13099 *** Bogus 217.14.128.0/20 from AS8851 *** Bogus 217.14.192.0/20 from AS3226 *** Bogus 217.15.0.0/20 from AS13064 *** Bogus 217.15.128.0/20 from AS13118 *** Bogus 217.16.96.0/20 from AS15687 *** Bogus 217.32.0.0/12 from AS2856 *** Bogus 217.117.117.0 from AS2007 *** Bogus 220.10.56.0 from AS3215 AS Summary ---------- Number of ASes in routing system: 8534 Number of ASes announcing only one prefix: 4865 (2696 cidr, 2169 classful) Largest number of cidr routes: 892 announced by AS701 Largest number of classful routes: 1087 announced by AS701 1) Gains by aggregating at the origin AS level --- 22Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 432 155 277 64.1% BCnet Backbone AS9706 310 104 206 66.5% Pusan Metropolitan City Office of AS1221 611 451 160 26.2% TELSTRA-AS AS9269 179 40 139 77.7% Hong Kong CTI AS816 566 429 137 24.2% UUNET Canada (ASN-UUNETCA-AS4) AS2609 128 8 120 93.8% EUnet-TN AS7657 324 211 113 34.9% The Internet Group Limited AS9304 124 17 107 86.3% Hutchcity AS7046 376 270 106 28.2% COQUI-NET PRTC Internet AS7545 159 56 103 64.8% TPG Internet Pty Ltd AS705 367 266 101 27.5% UNKNOWN AS6429 209 115 94 45.0% FirstCom Internet AS7496 125 34 91 72.8% Power Up AS4755 208 118 90 43.3% Videsh Sanchar Nigam Ltd. India AS8013 490 403 87 17.8% UNKNOWN AS174 536 450 86 16.0% Performance Systems International AS6595 138 57 81 58.7% UNKNOWN AS3908 256 176 80 31.2% Supernet, Inc. AS4293 331 252 79 23.9% Internal ASN for C&W AS724 244 168 76 31.1% UNKNOWN AS1785 384 309 75 19.5% AppliedTheory Communications AS1727 172 97 75 43.6% UNKNOWN AS577 250 177 73 29.2% Bell Backbone AS7018 581 514 67 11.5% AT&T WorldNet Service Backbone AS701 1087 1021 66 6.1% Alternet AS4792 77 11 66 85.7% SK Telecom Co., Ltd. AS13999 77 11 66 85.7% UNKNOWN AS5106 99 36 63 63.6% UNKNOWN AS3749 119 57 62 52.1% UNKNOWN AS226 170 108 62 36.5% USC/Information Sciences Institut 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

12 12

RE: exponential route prefix growth, was: Re: The Cidr Report
by Sean Donelan 23 Sep '00

23 Sep '00

On Fri, 22 September 2000, "Aaron Moreau-Cook" wrote: > up getting only one /24. Then another upstream provider, quite large, forced > another /24 upon us. When we stated we didn't need/want it, they said they > could take it back but it was not standard practice; all DS3 customers get a > /24. Anyway... Think of all the other companies out there who get treated > like this? Yes, it does seem like ARIN doesn't treat everyone the same. I had the same experience. At the same time ARIN is telling me have to to divide my customers up into /27's or ARIN won't give me any more space, a very large upstream provider was making me take a minimum of a /24 for every connection whether I needed it or not. But I couldn't aggregate the /24 into anything.

1 0

RE: exponential route prefix growth, was: Re: The Cidr Report
by Roeland M.J. Meyer 22 Sep '00

22 Sep '00

> -----Original Message----- > From: Timothy Brown [mailto:tcb@ga.prestige.net] > Sent: Friday, September 22, 2000 1:32 PM > > > What 'threshold' has triggered this sudden event, with routes going > Which sucks, because the better choice for them is to ignore > the political > concerns and do the technically responsible thing, which is > bring their > content or resources, whatever they are, closer to points in > the Internet > where they are most commonly used. There's really very > little to be gained > by announcing their own space as opposed to having a > collocation provider > with good connectivity providing them blocks out of their space. au contrare. There's LOTs to be gained. > They just come from a larger enterprise mentality where they > work very hard > to make sure all the resources are centralized and controlled > by one or two > people. The key word is "control" and the right form of responsibility is "fiscal", not "technical".

1 0

Renaissance Hotel full? (fwd)
by Carol Wadsworth 22 Sep '00

22 Sep '00

Simon, Your travel agent was unfortunately misinformed by a reservation agent. As you may know, this has been a reoccurring problem. I just confirmed the following information with each hotel noted below: --------------- Renaissance Washington D.C. Hotel Since so many people have had difficulty making room reservations at the Renaissance (the NANOG meeting site), the hotel has extended the reservation cut-off date to September 28, and has the following rooms still available in the NANOG room block: Saturday, October 21 (7 rooms) Sunday, October 22 (11 rooms) Saturday, October 23 (10 rooms) Please call the hotel directly to make/change a reservation: 202-898-9000. --------------- Marriott at Metro Center (Renaissance overflow hotel) The NANOG block of rooms at the Marriott Metro Center on Saturday night, October 21, is now booked. The hotel is currently sold out at the discounted rate. --------------- Another alternative for lodging close by that currently has some open space for $179 night: Courtyard by Marriott (two blocks from the Renaissance) 900 "F" Street Washington, D.C. Telephone: 202-638-4600 Thanks for letting me know about your problem. I would have acted on it sooner, but I was out of the office yesterday. I hope you have better luck this time trying to make a room reservation. Carol Wadsworth Merit Network, Inc. ---------- Forwarded message ---------- Date: Thu, 21 Sep 2000 15:37:44 +0100 From: Simon Lockhart <simonl(a)rd.bbc.co.uk> To: nanog(a)merit.edu Subject: Renaissance Hotel full? Hi, The Renaissance Hotel have told our travel department that they have no further rooms available in the NANOG room block, and the only remaining rooms are $279/night. Can anyone confirm this, before I book with the Marriott, who apparently do have availability for the whole week. Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/ ---------- End Forwarded Message ----------

1 0

FYI- IPv6 Meeting in DC Oct 19-20
by Charles Brownstein 22 Sep '00

22 Sep '00

The IPv6 Forum and the Cross-Industry Working Team (XIWT) are hosting a meeting in downtown DC just before NANOG. info/registration: http://www.xiwt.org/XIWT-IPv6/meetingsite.html agenda so far includes: -Greg Papadopoulos, Sun -Robert Kahn, CNRI - Sue Horn, VP and Director of Raleigh Lab, IBM - Christian Huitema, Microsoft -Thomas Narten, IBM - Home Networking and IPv6 - Brian Haberman, Nortel - Michael Thomas, Cisco - Russ Mundy, Network Associates, Inc. - Charlie Perkins, Nokia - Bill Lenharth, UNH InterOperability Lab - Fred ter Haar, Ericsson - Leo Cameron, Nortel - Mark Silverberg, Compaq - Bob Fink, ESNet - Alan Halachmi, North Carolina Network Initiative - Michael Brig, US Navy - Joao da Silva, European Commission - Steven Hayes, 3rd Generation Partnership Program - Joe Barrett, Nokia - Takeshi Natsuno, NTT DoCoMo - André Cormier, Viagénie Inc - Richard Draves, Microsoft - Warren Matthews, SLAC - Steve Blumenthal, Genuity - Greg Miller, WorldCom - Steve Sim, BT - Orv Cooper, Zama

1 0

Re: o/t: Re: Root zone change -- d.gtld-servers.net
by Steven M. Bellovin 22 Sep '00

22 Sep '00

In message <39C9F363.2CCD6243(a)netmore.net>, Roland Dobbins writes: > >The point I was trying to make - and which I'm sure that you understood, >but simply chose to ignore - is that it's not a Bad Thing to be somewhat >U.S.-centric when discussing technical issues on the North American >Network Operator's Group list. > >*Technical issues*. I could care less about your juvenile political >beliefs, nor, I suspect, do the vast majority of subscribers to this >list. It's sad that you've so much trouble distinguishing between the >two. > >Your personal animus and general obnoxiousness are surprising, given >your c.v. and and the position of responsibility you hold within Verio. >It will be interesting to learn how their P.R. department respond to >questions concerning your penchant for injecting political commentary >into an unmistakably -technical- forum, all the while in your official >guise as an officer of said company. Since Verio is being purchased by NTT, I suspect that upper management really cares about international issues, and welcomes senior folks who understand that the net is not just North American... --Steve Bellovin

4 3

Hotels
by Robert Cannon 22 Sep '00

22 Sep '00

If you are looking for hotels, other areas two look are Rossyln, VA - there is a Marriot and a few other hotels there. On the Orange and Blue line one stop across the river from Wash DC North Arlington, VA along the Orange line there are a few hotels near the Ballston stop. Easy metro access into town and a few good restaurants like Mongolian Grill, Memphis BBQ, Vietnamese... Crystal City (Arlington VA near the Airport). This is where the Pentagon crowd lives. Lots of hotels, on the blue line, near the airport, and near some good restaurants and pubs. -B ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

1 0