- Test - lists.nanog.org

Re: Internet FUD Abound
by Sean Donelan 27 Jul '00

27 Jul '00

On Wed, 26 July 2000, Scott Marcus wrote: > Sean, I don't think that they were arguing that EVERY failure would cause > this kind of collapse. They were saying that a scale-free system might be > particularly vulnerable to a systematic attempt to cripple its most > critical elements. A failure of a single public NAP is probably well below > that threshhold. I agree the failure of a single public NAP is below the threshhold stated in the article. But I think we can use data from actual failures at NAPs to help with the forcast. One interesting, and I think important piece of missing data is when a major NAP does fail new paths become visible in the network. The physical destruction of a NAP eliminates some paths, but I'm not sure how well the NLANR data really shows what happens with the connectivity. Of course the 'new' physical paths aren't created out of thin air. They are just lost in the shadows behind the hot glare of the big pipes. An open question is there enough shadow paths in the Internet to heal it, or are we just talking about degrees until total failure. I'm not sure the article author's took this into account. Secondly, must of the popular discussion (i.e. comments from the FBI's National Information Protection Center, SRI's Atomic Tangerine, etc) has used the article to support the theory the net is very vulnerable to terroristic attacks. However, destroying 2.5% of the nodes in the Internet is a big number. Its not just a matter of blowing up a parking garage outside Washington DC, a Gigaswitch in San Jose, etc. Launching a coordinated attack against 25, 250, 2500 different physical locations worldwide is hard for even an organized military operation. If terrorists blew up the top 2.5% of the largest cities in the USA, would the country would break up into feudal segements. I don't know. I agree things would be very grim if 2.5% of the cities were destroyed. But that is not small terroristic attack. I don't think the article supports the notion the Internet is exceptionally vulnerable to physical attack by terrorists. Actually, I think the article supports exactly the opposite view, it takes a rather large physical attack to partition the net. On the other hand, I think the current operational practices make the net less resiliant to certain forms of attack. But that is a different discussion.

2 1

RE: whois databases and null fields
by Carter, Gregory 27 Jul '00

27 Jul '00

-----BEGIN PGP SIGNED MESSAGE----- Just thought you all might be interested to know that these null fields that are showing up may seem innocent but they are affecting some other registrars. I had a customer use my company to transfer their domain names from NSI, out of the three domain names only one of them successfully sent him the admin contact email address the OpenSRS confirmation. Unfortunately I had to wait another 3 to 4 days before the requests expired so that they could be sent again. Wanted to give you all a heads up for those of you that use the OpenSRS system. I haven't heard any reports of any other registrars having this problem but still worth keeping a close eye on. Greg +(gcarter(a)infoDNS.com)-------------------------------------------------+ | infoDNS http://www.infodns.com/ | | Senior Network Administrator bits/keyID 1024/7DF9C285 | | Register your domain name today for only $25/yr. | +--------[ DC 50 57 59 C3 76 46 E8 EB 75 A8 94 FE 96 9E D3 ]----------+ - -----Original Message----- From: Nathan Lane [mailto:nathan@terminus.com] Sent: Wednesday, July 26, 2000 7:24 PM To: nanog(a)merit.edu Subject: Re: whois databases and null fields A few nights ago it was worse. Instead of nulls, the registrar fields were incorrect indicating a completely different server and registrar (many of which did not exist or were non-functional.) The registrant and nameservers appeared correctly. Hopefully they will become driven to operational excellence and I've seen a few steps that way, but money, not process and service, seems to be driving them for the short term. - -Nathan Lane Network Engineer -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.3 iQCVAwUBOX+2YW2piax9+cKFAQHZewQAnjcx9XWb4JvnPWtX7Y+ht8mzw5LERD4h e165qqSPaMvsmlTgPREozx1komeSZwyvRuR33qfkxxuJFhCehWmOpaBCVPIDxNcX KBDPml34XFt8wHNoHGyysGXBwsz1sjeuLGxqSTgauki5OaHpAT3DTd9LhX9wN67/ sWdLURDuViE= =AgDS -----END PGP SIGNATURE-----

1 0

whois databases and null fields
by Timothy Brown 27 Jul '00

27 Jul '00

Hey, folks. Maybe a dumb question. How does any registrant with null fields for their contact data manage to modify their registry records, outside of sending a letter on their company letterhead? For that matter, how do they get bills from the aforementioned registry? :) -- Registrant: Apple Computer, Inc. (APPLE-DOM) 1 Infinite Loop Cupertino, CA 95014 Domain Name: APPLE.COM Administrative Contact: [No name] (NA4189-ORG) [No mailbox] [No address] [No phone] Technical Contact, Zone Contact: [No name] (KE557) [No mailbox] [No address] [No phone] Billing Contact: [No name] (BC478-ORG) [No mailbox] [No address] [No phone] Record last updated on 11-Jul-2000. Record expires on 20-Feb-2001. Record created on 19-Feb-1987. Database last updated on 26-Jul-2000 20:11:40 EDT. Domain servers in listed order: NSERVER.APPLE.COM 17.254.0.50 NSERVER2.APPLE.COM 17.254.0.59 NSERVER.EURO.APPLE.COM 194.151.19.41 NSERVER.ASIA.APPLE.COM 203.120.14.5 -- Timothy Brown tcb(a)ga.prestige.net

4 3

Re: whois databases and null fields
by Nathan Lane 27 Jul '00

27 Jul '00

A few nights ago it was worse. Instead of nulls, the registrar fields were incorrect indicating a completely different server and registrar (many of which did not exist or were non-functional.) The registrant and nameservers appeared correctly. Hopefully they will become driven to operational excellence and I've seen a few steps that way, but money, not process and service, seems to be driving them for the short term. -Nathan Lane Network Engineer

1 0

Re: Sonet protection usage
by smd＠clock.org 27 Jul '00

27 Jul '00

Bill Simpson writes to the "expertise list": | > This is typically 50ms, but one has to add the one-way delay to that. | > | I haven't seen anything about adding one-way delay to make it longer, | could you cite, please? My reading was that the 50 milliseconds | included delay, as 50 milliseconds would include a one-way trip | around the world, and section regenerators are much closer together | than that.... Your photons seem pretty damn fast to me. An ADM doing LSR will listen to N different copies of the same data, and buffers the first-arriving data so that it can compare at least one subsequent copy as a means of verifying data integrity. If the data checksums do not compare identically, then the ADM must make a decision about which copy to send onwards (if any). If both sets of data are sane, the frames received on the working interface are forwarded, the others are discareded, and an alarm is raised. If the working copy is not sane, then a protection switch is negotiated using the K1/K2 bytes in BLSR mode, or via other means if the receiver is not the K1/K2 master in unidirectional mode. The comparison threshold is 50ms, which gives ample wiggle room for large path-propagation-delay mismatches, while bounding the per-section delay inherent in this type of protection switching. It seems natural to me that the _fastest_ a receiving ADM can even in theory make an informed decision about whether to force a line switch is the difference in propagation delay between a working and protect pair. ADMs are not psychic! Finally, with a given comparison threshold, even a conceptually zero-length fibre, with zero propagation delay, will incur a time penalty between a physical cut and a line-switch. | Now, it appears to me that the question was about metro-area circuits | (recalling that these are usually called "intermediate" in the | specification) -- not short circuits inside a single facility, and | not transoceanic -- for "router redundancy". OK? Yes, and I answered Steve privately (because it was him). I merely intervened in this not to impart expertise upon competitors, but rather to correct your conflating ADM between a pair of routers and a single ADM with actual 1+1 protection along a multi-hop LSR-protected trail. As has been noted by other people in the thread, there are sound reasons why one might want to set up the latter, even on a circuit which is otherwise completely unprotected. Likewise, a higher-order container can be protected in the two router + one ADM scheme, even if the lower-order containers within it are otherwise wholly unprotected and only loosely related. | In giving a cogent answer, I've noted the carrier problems, and given | examples and rationale. In my experience, multiple circuits with | diverse topology is the best answer Protecting 12 DS3-mapped STS-1s inside an OC12 is cheaper and protects against a much more common failure mode than the kind of failures having 24 unprotected DS3s additionally protects against, and has the advantage of not making token-bucket-style or DSU-to-DSU style rate limiting much more difficult to implement in pay-for-available-bandwidth environments. This is independent of the length or locality of the DS3-mapped STS-1s (or, indeed, DS3-bearing VC3s (hi Neil!)). No charge for the partial implementation suggestion. Consult your vendor for further details. Sean.

1 0

Re: Internet FUD Abound
by Sean Donelan 27 Jul '00

27 Jul '00

On Wed, 26 July 2000, Andrew Bender wrote: > Another lapse in editorial integrity... this time, Reuters: > > http://www.techweb.com/wire/story/reuters/REU20000726S0007 The Reuters article skips over some of the important qualifiers in the Nature letter. Read the entire letter on the Nature website. http://www.nature.com/ The conclusions are interesting, but I think missing a few pieces of data. Every major public NAP has had service affecting incidents, and so far we have not seen the partioning effect Albert et al write about. I've also followed a fair number problems in the private connections, also without major network partion beyond those networks. Further, the source data from NLANR doesn't pick up every possible connection between networks. You should view source data as a floor(), not a ceil(), on the connectivity. And finally, coordinating a physical attack on more than a few physical locations is hard, even with perfect information. Of course, this is a false argument because it has never happened doesn't mean it can never happen. But I think its important to understand why such an attack is hard, as well as understanding why it is possible. On the other hand, there have been accidents (and perhaps some attacks) on the logical layer which have severely disrupted the Internet. The interesting thing about logical attacks is you don't need perfect information about the network because the critical points of the network almost act as natural gravity wells pulling the attack towards them (using a physical analogy in cyberspace).

6 5

Internet FUD Abound
by Andrew Bender 26 Jul '00

26 Jul '00

Another lapse in editorial integrity... this time, Reuters: http://www.techweb.com/wire/story/reuters/REU20000726S0007 R/ Andrew Bender thrupoint.net

2 1

PGPKEY Reminder
by gerald＠merit.edu 26 Jul '00

26 Jul '00

On 7/30/00 between 5 AM - 8 AM EDT Merit will convert from 'PGP-FROM' to 'PGPKEY' authentication as described in RFC 2726. All maintainer object 'PGP-FROM' instances will be converted to a 'PGPKEY' instance and a 'key-cert' object will be created for each unique 'PGPKEY' instance. After the conversion all public keys used for signing DB submissions will be visible in the registry as 'key-cert' objects. Registering public keys allows users to verify a maintainer's identity and to submit, update and maintain their own public keys like any other DB object. Normal PGP signing of DB submissions will continue to work exactly as before the conversion. The conversion should be seamless to our DB user community and no action is required. Merit has sent email to all users who will be affected by the conversion. The new 'PGPKEY' scheme makes it easier for users to integrate PGP signing into their DB update process. It is our wish that into the future all registry users will PGP sign their DB submissions. Please see www.radb.net/docs/keyfaq.html for additional information on the conversion process and tutorial information regarding the use of 'PGPKEY' authentication. Please consult RFC 2726 for the authoritative specification. IRRd team --Gerald Winters

1 0

Re: Internet FUD Abound
by Martin Cooper 26 Jul '00

26 Jul '00

Danny McPherson <danny(a)tcb.net> writes: > Just another subtle reminder that prefix-filtering (@ access and > inter-provider -- at least well-known address space) could have > a significant impact -- if/when this does occur. Whilst I have no quarrel with the excellent positions espoused by the likes of Paul Ferguson et al. about ingress filtering of transit customers, or for that matter similar positions on ingress prefix-filtering of BGP customers, I wonder why it is that there is not more support amongst the transit ISP fraternity for the use of route-servers for implementing prefix- filtering. All I hear is, "But the routers aren't up to full prefix-filtering; AS-path based filtering (if that) is the best we can hope for" etc. What were route-servers invented for if it wasn't for implementing routing policy, and leaving core routers to the job of advertising and accepting prefixes according to local policy, and IP packet forwarding? Yes, I realise there are resiliancy issues to be considered here... M.

1 0

Multiple incidents (NYC, Illinois, N.California)
by Sean Donelan 26 Jul '00

26 Jul '00

There is a fiber cut in central illinois. Uunet has equipment problems in New York City. And there seems to be something down between San Jose and San Francisco (parts of Yahoo dailynews.yahoo.com and some frame-relay service are down).

1 0