November 2000 - Test - lists.nanog.org

Internet access in Honolulu, HI ?
by Joe McGuckin 28 Nov '00

28 Nov '00

Anyone know of a public library (or a friendly ISP) that will allow me to drop by and plug in my laptop to check email, etc ? Thanks, Joe -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-969-2203 Cell: 650-207-0372 Fax: 650-969-2124

1 0

ANN: New List: usdomreg
by jamie rishaw 27 Nov '00

27 Nov '00

Announcement: Mail list to discuss .US domain changes Everyone, In light of recent changes with ISI, VeriSign(NSI) and the .US TLD, and because of recent discussion that has come up on an (oops) unmoderated ISI mail distribution, I have created a mail list for those interested to discuss the changes to the .US domain name structure, privatization, and the like. *** To subscribe: echo subscribe | mail usdomreg-request(a)arpa.com (Translated: send a blank email to usdomreg-request(a)arpa.com) *** To post: (you must be a member) mail usdomreg(a)arpa.com

1 0

Re: Limits of reliability or is 99.999999999% realistic
by Sean Donelan 27 Nov '00

27 Nov '00

On Mon, 27 November 2000, Robert Cooper wrote: > On the other hand the data is somewhat conservative since it counts > total number of subscribers, not the total number of active or would-be > active users during the outage. The data does include overloads which > in the PSTN manifest themselves through call admission control > (e.g. network busy signal). Like most statistical studies, understanding the data collection process is key. Using the FCC outage reports has some good features. In theory all carriers are under the same obligation to report outages meeting the defined thresholds, so you should be able to compare the data across carriers. There are some data anomolies, which makes it difficult to compare the data more widely. The failure to report a reportable outages is difficult to detect in the FCC data. And even among carriers reporting, there is tremendous variation in the amount of information supplied. Outages in leased, rather than owned facilities are occasionally reported. Shared leased facilities can also result in a very wide-spread, but unreported outage because the owner may not have 30,000 direct customers although the downstream carriers may have far more customers impacted. The various Illuminet SS7 problems are an example of wide-spread, unreported problems. And finally, data or packet switched outages are only reportable in so far as they affect the voice network. For example, when AT&T's frame-relay network failed the analysis done was the impact of lots of ISDN dial-backup devices simultaneously attempting to re-establish the data connection across the switched telephone network. And finally, the FCC outage data excludes most outages less than 30 minutes in length. So it is impossible to claim 99.999% reliability based on just the FCC data because the resolution of the data isn't fine enough to detected outages of 5 minutes. At most you can claim is four-nines. > What data exists for the Internet? There are several sets of data for the Internet. As a starting point, I point people to Labovitz and Ahuja study "Experimental Study of Internet Stability and WideþArea Backbone Failures" http://www.eecs.umich.edu/techreports/cse/1998/CSE-TR-382-98.pdf One interesting piece of data they found is the mean time to repair an Internet problem is 20 minutes. If we followed the FCC outage reporting thresholds of thirty minutes or more, most (mean? half?) of the Internet problems wouldn't be counted as an outage. Also see the list of references at the end of the paper. Other sources of data include provider traffic reports, such as http://traffic.cw.net/ http://ipnetwork.bgtmo.ip.att.net/ provider status pages, such as http://www.noc.uu.net/ http://help.mindspring.com/netstatus/ and third-party performance reporting, such as http://average.miq.net/ http://internetpulse.com/ http://www.whatsdown.com/

2 1

Network Design and Planning Tools
by Bradley Dunn 27 Nov '00

27 Nov '00

Hi, Anyone who's using the network design and planning tools from WANDL or Make Systems care to comment on them? Any other tools people are using? http://www.wandl.com/ http://www.makesystems.com/ Thanks, Bradley

2 1

script kiddie probes
by Dan Hollis 27 Nov '00

27 Nov '00

http://www.dshield.org/top10.php http://www.dshield.org/topports.php Interesting stuff. -Dan

5 4

Limits of reliability or is 99.999999999% realistic
by Toby_Williams＠enron.net 27 Nov '00

27 Nov '00

SLAs are the point where commercial & operational worlds collide. The numbers being offered should: Reflect the targeted quality of the service Tie in with meaningful damages for not achieving them In a market where I can offer 99.7% or 100% and the difference is a whole day's service credit, I know what I'd be offering. No question. If on the other hand, the expectation is that I pay out a year's contract value in cash upfront every time I miss a target in a month, then I'd only want to offer a target that will *always* be achieved. In the market at the moment, the situation is much closer to the first scenario than the second - ie damages for SLAs do not mean anything to either: the buyer, as compensation for not receiving the service that they have contracted for; or the seller as a motivation to work within the targets, because capped service credit agreements do not touch the bottom line Today, in the IP market, it is irrelevant whether services come with 99.0 or 99.99999 SLAs & at some point the market needs to address the responsibility that if they are to offer a service of a certain "guaranteed" quality, then they should stand-by that guarantee with their money and give this guarantee meaning. I don't think this is the case at the moment, and that's why we even see 100% SLA in the market - because the level of pay-outs on SLAs don't matter to the seller. No. I'm not suggesting that sellers offer guarantees for consequential losses. Simply ones that: 1. give the buyer the peace of mind that if the service they've contracted to is below par, that they will have enough money put back in their pocket for them to have replaced their service, like-for-like in the market, to cover themselves over the period. 2. enable the market players to truly differentiate their service offerings by quality, rather than marketing. Toby [std. disclaimer of responsiblity here] Date: 25 Nov 2000 20:24:48 -0800 From: Sean Donelan <sean(a)donelan.com> Subject: Limits of reliability or is 99.999999999% realistic <snipped for brevity> But back to my question. What is the real requirement? Amazon.COM had system problems on Friday, and their site was unusuable for 30 minutes, definitely not 99.999%. But what did that really mean? The FAA loses its radar for several hours in various parts of the country. What did that really mean? Essentially every system given as an example of "high- availability, high-reliability" I've looked at, doesn't hold up under close examination. Is 99.999% just F.U.D. created by consultants? Instead of pretending we can build systems which will never fail, should we work on a realistic understanding of what can be delivered?

8 7

Re: Limits of reliability or is 99.999999999% realistic
by Robert Cooper 27 Nov '00

27 Nov '00

At 08:24 PM 11/25/00 -0800, Sean Donelan <sean(a)donelan.com> wrote: >But back to my question. What is the real requirement? Amazon.COM had >system problems on Friday, and their site was unusuable for 30 minutes, >definitely not 99.999%. But what did that really mean? The FAA loses >its radar for several hours in various parts of the country. What did >that really mean? Essentially every system given as an example of "high- >availability, high-reliability" I've looked at, doesn't hold up under >close examination. > >Is 99.999% just F.U.D. created by consultants? > >Instead of pretending we can build systems which will never fail, should >we work on a realistic understanding of what can be delivered? For some actual *data* on reliability in the US phone system take a look at: "Sources of Failure in the Public Switched Telephone Network" D. Richard Kuhn IEEE Computer Magazine, April 1997, Vol 30, No 4. pp31-36. OK, it's not actual data but a summary of it. It's culled from data that the phone companies have to supply to the feds for every outage that affects more than 30,000 subscribers -- about the number supported by a central office. Measured in user-outage-minutes (duration of outage * number of subscribers) he shows availability in the range of 99.999% for data from the 1992 and 1993. More interesting is the summary of the sources of outages and how much they contribute to the total picture. For instance, if you were one of the average of 250,000 customers who lost service for an average of 500 minutes due to vandalism, you might not think 99.999% means very much. On the other hand the data is somewhat conservative since it counts total number of subscribers, not the total number of active or would-be active users during the outage. The data does include overloads which in the PSTN manifest themselves through call admission control (e.g. network busy signal). What data exists for the Internet? [ Standard disclaimer ] Robert Cooper Ironbridge Networks 55 Hayden Ave, Lexington MA 02421 www.ironbridgenetworks.com

1 0

Traffic statistic collector
by Jason Lixfeld 27 Nov '00

27 Nov '00

I'm working on a proposal to run some OCx circuits southbound to connect to the NAPs and IX's of the world. I need to calculate how much traffic I'm sending to each member and to each members' customers. I'm using cflowd to gather info from the routers but I'm wondering if anyone knows of a script/proggy/hack that can take an AS or a series of netblocks, run them against the multiple cflowd data files, parse it out and spit out a MB/sec figure of some sort.

5 4

RE: ISPs as content-police or method-police
by Mathew Butler 27 Nov '00

27 Nov '00

The use of the phone isn't that difficult, it's the use of the phone to get someone -clueful- enough to a) recognize the request as valid, b) log the request for their records, and c) disable the filter. Customer service at many of the Tier-2 and Tier-3 providers usually isn't, in my experience. -Mat Butler -----Original Message----- From: Stephen Sprunk [mailto:ssprunk@cisco.com] Sent: Tuesday, November 21, 2000 11:16 AM To: Roeland Meyer; 'Shawn McMahon'; nanog(a)merit.edu Subject: Re: ISPs as content-police or method-police Then again, nobody here seems to be suggesting mandatory filtering. Why is there such a strong objection to opt-out filters, where a single call or email can get the filters turned off? Is using a phone really that difficult?

1 0

RE: Carnivore Update - Washington Post 11/21/00
by Mathew Butler 27 Nov '00

27 Nov '00

The _NSAKEY symbol in Windows does not affect the keys used or generated for WinInet() or CryptoAPI calls. 128-bit open source is subject to a license exception, and can thus be examined to a fare-thee-well. I agree that the close-source nature of the CryptoAPI (and thus, crypto smart cards, and the underlying crypto libraries) is detrimental to its security evaluation. Thus, I am unwilling to state categorically that it is a secure implementation. But, Carnivore doesn't have the capability of decrypting anything, merely decoding the packet headers. It can capture all traffic by a suspect, including the SSL-encrypted payload; however, this means that the full protocol exchange must be analyzed and cracked, and any session renegotiations must be analyzed and cracked as well. SSLv2 was (and is) insecure. Now that the RSA patent has fallen out of protection, it's going to be more possible to use open-source (and other) software that implements SSLv3 and TLS1.0; regardless, old standards die hard. However, I could get into a debate over whether 'self-signed certificates are insecure'. This is not the place. Just clearing up some misapprehensions, -Mat Butler -----Original Message----- From: Philippe Landau [mailto:lists@A-Z-Internet.com] Sent: Thursday, November 23, 2000 1:26 PM To: nanog(a)merit.edu Cc: Eric Murray Subject: Re: Carnivore Update - Washington Post 11/21/00 >> of course carnivore has no problem decrypting SSL. >Source, please. (this seems obvious for the still widely distributed 40 bit versions. there are many sources discussing the NSA key in windows and apple is likely to have implemented similar backdoors. there could be a reason why 128 bit SSL encryption has been approved by the US for export in december 1999. the question is if we have to prove they can decrypt SSL communications or if the government agencies have to show they can't (don't hold your breath). how strong 128 bit encryption is is another question.) this discussion is probably getting off-topic on this list. i have just received some thoughts about it from security expert Eric Murray and while he is less pessimistic, please see below. kind regards philippe, http://A-Z-Internet.com --- *** --- http://remus.prakinf.tu-ilmenau.de/ssl-users/archive14/0158.html http://www.mail-archive.com/cryptography-digest%40senator-bedfellow.mit.edu/ msg02375.html http://www.tinhat.com/surveillance/code_breaking.html SSL Server Security Survey - A random sample of 8081 different secure web servers (servers running the SSL protocol) in active use on the Internet shows that 32% are dangerously weak. These weak servers either support only the flawed SSL v2 protocol, use too-small key sizes ("40 bit" encryption), or have expired or self-signed certificates. Data exchanges with all types of weak servers are vulnerable to attack. http://www.meer.net/~ericm/papers/ssl_servers.html --- *** --- On Thu, Nov 23, 2000 at 08:55:52PM +0100, Philippe Landau wrote: > Hello > > Is there a possibility that a government > has a backdoor to decrypt SSL communications ? > > kind regards philippe, http://A-Z-Internet.com Yes it is possible, in the code that calls SSL. It's not very possible in the SSL protocol itself since that has been well investigated by security researchers. It's a little more possible in open-source SSL implementations but still not very likely. It's most possible in closed-source implementations, where the code that calls SSL is only known to the author(s). A backdoor that say reduced the entropy going into session keys would be difficult to detect-- even decompiling the code and stepping through it might not show it. -- Eric Murray Consulting Security Architect SecureDesign LLC http://www.securedesignllc.com PGP keyid:E03F65E5

1 0