- NANOG - lists.nanog.org

Re: Lawsuit on ICANN (was: Re: A few words on VeriSign's sitefinder)
by John Neiberger 26 Feb '04

26 Feb '04

>>>> Neil J. McRae <neil(a)DOMINO.ORG> 2/26/04 3:03:52 PM >>> > >> http://biz.yahoo.com/rc/040226/tech_verisign_2.html > >can't say I'm surprised. Another nail in the Verisign coffin. They must have taken a page from the recently-released book "How to Shoot Your Company in the Foot," by SCO. * John -- The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. --

1 0

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by sgorman1＠gmu.edu 26 Feb '04

26 Feb '04

So does this mean we also need a regulator to make sure fiber providers "fess up to the actual diversity of their physical paths". The "R" word is not one to be tossed around lightly. When does it apply and when does it not, or does it never apply. The more critical you get get the more "R" creeps in, but who defines critical and when does that rise above a threshold to induce "R"? ----- Original Message ----- From: Roland Perry <nanog(a)internetpolicyagency.com> Date: Thursday, February 26, 2004 12:20 pm Subject: Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat) > > In article <200402261652.i1QGq3ln018676(a)turing-police.cc.vt.edu>, > Valdis.Kletnieks(a)vt.edu writes > >We often can't get the owners of the fiber to 'fess up to the actual > >physical path, when we're trying to build out diversity. > > > >What makes you think the Ambulance Service will have the competency > >to have any *clue* where their dial tone actually comes from and > goes to? > > You need a Regulator[tm] which insists that the Ambulance Service > demonstrates that they understand these issues, or revoke their > licence. > A bit like you do for the wetware behind the steering wheel (or > the life > support system in the back). > -- > Roland Perry > >

1 0

Microsoft on security holes
by Brian Bruns 26 Feb '04

26 Feb '04

I just saw this on slashdot, so for those of you who don't read slashdot, enjoy. http://news.bbc.co.uk/1/hi/technology/3485972.stm Yeah, its a little bit off topic, but with the recent amount of viruses, worms, trojans, etc going around the Internet that are causing havoc with general day to day operations of ISPs, this is quite an interesting read. Basically, Microsoft is claiming that security exploits only come out after patches. Uh huh, yeah right. (waiting for his list AUP violation notice, again) -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The Abusive Hosts Blocking List http://www.ahbl.org

1 0

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by Michael.Dillon＠radianz.com 26 Feb '04

26 Feb '04

> So now we have a partial X and partial >Y network, X goes down, and chances are your network got hammered >like an icecube in a blender set to Frappe. If IP networks become the single layer 2/3 telecommunications technology in the world then we can never let that Frappe happen. We will have to find ways to deliberately build networks using vendor X and vendor Y in such a way that the sum total is more reliable than a pure X or a pure Y network. --Michael Dillon

1 0

Re: Converged Networks Threat (Was: Level3 Outage)
by Michael.Dillon＠radianz.com 26 Feb '04

26 Feb '04

> Wouldn't it be great >if routers had the equivalent of 'User mode Linux' each process >handling a service, isolated and protected from each other. The >physical router would be nothing more than a generic kernel handling >resource allocation. Each virtual router would have access to x amount >of resources and will either halt, sleep, crash when it exhausts those >resources for a given time slice. This is possible today. Build your own routers using the right microkernel, OSKIT and the Click Modular Router software and you can have this. When we restrict ourselves only to router packages from major vendors then we are doomed to using outdated technology at inflated prices. --Michael Dillon

2 1

Re: Level 3 statement concerning 2/23 events (nothing to see, move along)
by Pete Templin 26 Feb '04

26 Feb '04

If an IP-based system lets you see the status of the 23 hospitals in San Antonio graphically, perhaps overlaid with near-real-time traffic conditions, I'd rather use it as primary and telephone as secondary. Counting on it? No. Gaining usability from it? You betcha. Brian Knoblauch wrote: > If you're counting on IP (a "best attempt" protocol) for critical > data, you've got a serious design flaw in your system... > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Pete > Templin > Sent: Wednesday, February 25, 2004 9:10 > To: Colin Neeson > Cc: nanog(a)merit.edu > Subject: Re: Level 3 statement concerning 2/23 events (nothing to see, move > along) > > > > > Are you sure no one died as a result? My hobby is volunteering as a > firefighter and EMT. If Level3's network sits between a dispatch center > or mobile data terminal and a key resource, it could be a factor > (hospital status website, hazardous materials action guide, VoIP link > that didn't reroute because the control plane was happy but the > forwarding plane was sad, etc.). > > And if the problem could happen to another network tomorrow but could be > prevented or patched, wouldn't inquiring minds want to know? Your life > might be more interesting when the fit hits the shan if you have the > same vulnerability. > > Colin Neeson wrote: > > >>Because, in the the grand scale scheme of things, it's really not that >>important. >> >>No one died because of it, the normal, everyday events of the world >>went >>on, >>unaffected by a Level 3 outage... >> >>Might be nice to know what happened, but my life will certainly not be >>less interesting by not having that knowledge... > > > > > > __________________________________________________________ > This message was scanned by GatewayDefender > 9:13:43 AM ET - 2/25/2004 > > > > __________________________________________________________ > This message was scanned by GatewayDefender > 9:25:39 AM ET - 2/25/2004 > >

16 23

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by W.D.McKinney 26 Feb '04

26 Feb '04

>-----Original Message----- >From: Steve Gibbard [mailto:scg@gibbard.org] >Sent: Thursday, February 26, 2004 12:30 AM >To: nanog(a)merit.edu >Subject: How relable does the Internet need to be? (Was: Re: Converged Network Threat) <snipped> >>So, it appears that among general infrastructure we depend on, there are >probably the following reliability thresholds: > >Employees not being able to get to work due to snow: two to three days per >year. >Berkeley storm sewers: overflow two to three days per year. >Residential Electricity: out two to three hours per year. >Cell phone service: Somewhat better than nine fives of reliability ;) >Landline phone service: I haven't noticed an outage on my home lines in a >few years. >Natural gas: I've never noticed an outage. > >How Internet service fits into that of course depends on how you're >accessing the Net. The T-Mobile GPRS card I got recently seems >significantly less reliable than my cell phone. My SBC DSL line is almost >to the reliability level of my landline phone or natural gas service, >except that the DSL router in my basement doesn't work when electric power >is out. I'm probably poorly qualified to talk about the end-user >experience on the networks I actually work on, even if I had permission >to. Like pretty much everybody else here, I'm always interested in doing >better on reliability. And, like many of my neighbors, I'd like to be >able to store stuff on my basement floor. In comparison to a lot of other >infrastructure we depend on, it seems to me the Internet is already doing >pretty well. > >-Steve > > With BPL on the horizon and the Electric Utils looking to de-regulate in some areas, it will be interesting to watch infrastructure adapt accordingly. I think the Internet is doing pretty well save some IOS code problems from time to time, and the typical root server hicups. Dee

3 2

Re: How relable does the Internet need to be? (Was: Re: Converged Network Threat)
by W.D.McKinney 26 Feb '04

26 Feb '04

Thanks for pointing that out. That was the wrong way to describe my standpoint. Frequent changes in DNS across the board, including edge servers make connections seem non-working, when in reality it is a mis-configured DNS zone. So whether Dee >-----Original Message----- >From: Joe Abley [mailto:jabley@isc.org] >Sent: Thursday, February 26, 2004 12:57 AM >To: 'W.D.McKinney' >Cc: nanog(a)merit.edu >Subject: Re: How reliable does the Internet need to be? (Was: Re: Converged Network Threat) > > > >On 26 Feb 2004, at 08:46, W.D.McKinney wrote: > >> I think the Internet is doing pretty well save some IOS code problems >> from time to time, and the typical root server hicups. > >I'm interested to know what you mean by "typical root server hicups". >I'm trying to think of an incident which left the Internet generally >unable to receive answers to queries on the root zone, but I can't >think of one. > >By "typical", do you mean "non-existent"? > > >Joe > >

1 0

Re: New Draft Document: De-boganising New Address Blocks
by Randy Bush 25 Feb '04

25 Feb '04

[ nick has trouble posting, so ... ] Date: Wed, 25 Feb 2004 00:27:00 -0500 From: Nick Feamster <feamster(a)lcs.mit.edu> Subject: Re: New Draft Document: De-boganising New Address Blocks To: nanog(a)nanog.org User-Agent: Mutt/1.4.1i On Tue, Feb 24, 2004 at 06:28:48PM +0100, Daniel Karrenberg wrote: > > Why can't ISPs subscribe to a feed of all new > > RIPE allocations in near real-time? > > Personally I think this is a great idea and if we hear from a lot of > operators actually willing to take such feeds it may become reality > beyond volunteer efforts like the Team CYMRU one. However there are a > number of serious issues with something like this, not the least of > which are the liability issues in case this goes wrong very dynamically > and semi-automatedly. > > It is certainly something to progress if there is enough interest. > > However I think the current proposal shold go ahead too because the false > positives are a real problem that needs to be addressed quickly. > fyi, I have written a configuration checking tool that checks for a configuration's conformance to the Cymru bogon list. See: http://nms.lcs.mit.edu/bgp/rolex/ for more information. The tool also checks for various other errors (summarized at http://nms.lcs.mit.edu/bgp/rolex/tests.html) I also have a writeup that describes the tool in further detail, as well as an empirical evaluation that supports these observations about bogon filtering practices (based on results of running the tool on several ASes). Let me know if you'd either (1) like a copy of this writeup or (2) want to help me generate more empirical data (i.e., want to run the tool on your configs, let me do so, etc.) Cheers, -Nick

1 0

Sprint midwest/NW backbone issues?
by Dave O'Shea 25 Feb '04

25 Feb '04

Anyone at sprint care to shed some light on a latency issue that's been going on since December? (While the SLA credits are always nice, there's something to be said for actually getting the traffic from A to B!) sl-bb20-fw>ping 144.228.241.75 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 144.228.241.75, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/115/172 ms sl-bb20-fw> ... and Seattle to Dallas: sl-bb20-sea>ping 144.228.241.51 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 144.228.241.51, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 76/76/80 ms sl-bb20-sea>

1 0