- Test - lists.nanog.org

FWD: Quantum computer cracks crypto keys quickly
by Dave Bartlett 01 Apr '98

01 Apr '98

Does Zimmerman know about this?! ;-) Begin forwarded message: RISKS-LIST: Risks-Forum Digest Wednesday 1 April 1998 Volume 19 : Issue 64 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ------------------------------ Date: Wed, 1 Apr 1998 -05:00:00 -0500 From: andrew(a)greenehouse.com Subject: Quantum computer cracks crypto keys quickly A small team of researchers has succeeded in building a prototype of the so-called "quantum computer" that can factor large numbers quickly and defeat public-key cryptosystems. The researchers cracked the DES-IV-1 challenge, revealing the message "Can't anyone around here keep a secret?" Since the new computer is based on superconducting quantum interference devices, it is not bound by conventional temporal limits on computation. In fact, the researchers were able to use their system to crack challenges that had not yet been created. These future secret messages included, "God in Heaven, what have we done?" and the cryptic "tsopyadslooflirpanasisihtsey" -- which clearly shows that future challenges are going to use multiple layers of encryption. President Clinton congratulated the researchers, but said that he was considering a proposal to ban the export of quarks from the United States until the NSA could implement a quark escrow system, by which each quark in the universe would be uniquely numbered. When asked if their invention would enable scientists to foretell the future, the researchers pointed out that they can only decrypt messages that are encrypted using certain methods that are known today. Furthermore, there is no way for them to determine if the messages that they receive are authentic or if unknown people are sending false messages to confuse us. "If only there were a reliable way to digitally sign a transmission," bemoaned one of the researchers. ------------------------------

1 0

Re: Fwd: Quantum device brings end to the "World Wide Wait"
by Andrew Staples 01 Apr '98

01 Apr '98

> Time to close the shop? > > --vadim Cisco is missing the big picture (pun intended)- Selectively dampen only the quantum carrier waves from the present, keep the ones eminating from the future and the past, and put all the gamblers, fortune-tellers, and wall-street types out of business. Half duplex rules! Stock market picks to follow...now registering omniscient.com Andrew "more worried about schroedinger's kittens....."

1 0

Re: NSI Bulletin 098-008 | New Registration Agreement
by Dean Robb 01 Apr '98

01 Apr '98

At 15:08 3/30/98 -0800, you wrote: >On Mon, 30 Mar 1998, Deepak Jain wrote: > >NSI contends that the court has not found it to be an illegal tax yet, and >that they (the courts) simply have issued an injunction to stop NSI from >collecting it. This statement was in a reply to me when I inquired about >the domain fee for domains registered prior to 4/1/98; apparently, those >domains will still be $50 per year. It will be interesting to see how >that extra $15 will be accounted for--since it can no longer go into the >infrastructure fund (via court ruling), where will it go? > >(I had also heard that the final ruling was that it indeed was an illegal >tax...) There is no "final ruling", just an opinion and temporary injunction. NSI is technically correct, however: "C. Conclusion Therefore, plaintiffs have demonstrated that they have a substantial likelihood of eventual success on the merits of these claims. They have made a significant showing that the Preservation Assessment is an illegal tax. Furthermore, they have shown that Congress has not yet ratified that assessment. Therefore, plaintiffs have made a substantial showing that defendants may have collected, and may currently be collecting, the assessment illegally." ----"Memorandum of Opinion" issued in conjuction with Temporary Injunction; full text at http://WWW.bode.com/nsi/jh1.html. It should also be noted on this issue, though that: "In contrast, defendants face no harm whatsoever. Defendant NSI is merely the caretaker for the Preservation Assessment Fund, therefore, it has no interest in what happens to the money. Defendant NSF also has no tangible interest in the money; it may only spend the funds at the direction of Congress, for purposes specified by Congress. Therefore, NSF is not harmed by a delay in the expenditure of these funds." ---ibid I'm not known to be a big fan of NSI, but on this issue, it's not THEIR money. Therefore, they should not be liable for refunds. They just collected the bucks and held it in trust; even the interest earned went back into the funds. Of course, it's not like NSI NEEDS the money, they made net profit of over $45 million in 1997 (http://www.netsol.com/news/pr_19980210.html) Spam: it's not just for breakfast anymore.... Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]

1 0

Re: Root name server
by shields＠crosslink.net 01 Apr '98

01 Apr '98

In article <E0yK4f3-0000Kd-00@rhenium>, "Dave Haywood" <D.Haywood(a)btinternet.com> wrote: > I need to setup an internal root name server in my private network. Maybe you should ask on a DNS list. NANOG is about the Internet and you are asking about a private network. I think this is covered in Cheswick and Bellovin anyway, but I haven't looked in a long time. -- Shields, CrossLink.

2 1

RE: Operational issue: Packet loss at Pacbell NAP
by Goldstein_William＠bns.att.com 01 Apr '98

01 Apr '98

TO ALL NANOG PROPELLERHEAD TYPES MAKIN' REMARKS ON ATM: Da switch makers, ya know, dese guys had a problem. No matter how good business was, da stock keeps goin' down. Wid MPOA solvin' alla da problems, dey figured dis was unfair, dat dey should be solid, steadily growing stocks now dat dey no longer had to live life in da fast LANE. So, da ATM Forum has decided to sorta upgrade da public relations approach. Please be advised dat all youse geniusues makin' skeptical an' udderwise unsundry remarks on ATM is now subject to a personal interview from a special representative udda ATM Forum. On da boat. On a nice, long ocean voyage... (And alla youse gigabit ethernet wanks--ya know what we can do wid a little ether, heh, heh, heh!) Bill "The Mangler" Goldstein Chief Crusher and Mixer Dept. of Concrete Overshoes Enforcement Division The ATM Forum ;-) ---------- From: dlr Sent: Monday, March 30, 1998 6:41 PM To: nanog Cc: dlr Subject: Operational issue: Packet loss at Pacbell NAP Received: from wayne1.bns.att.com (wayne1.bns.att.com [135.170.166.240]) by pawayn01.bns.att.com (8.8.6/1.3) with ESMTP id SAA13273 for <Goldstein_William/bcs_pawayn01(a)pawayn01.bns.att.com>; Mon, 30 Mar 1998 18:49:24 -0500 (EST) Received: from caig1.att.att.com (caig1.att.att.com [192.128.52.73]) by wayne1.bns.att.com (8.7.3/2.5) with ESMTP id TAA19164 for <goldstein_william(a)bns.att.com>; Mon, 30 Mar 1998 19:01:20 -0500 (EST) Received: (from nuucp@localhost) by caig1.att.att.com (AT&T/GW-1.0) id SAA11015; Mon, 30 Mar 1998 18:49:21 -0500 (EST) >Received: by cagw1.att.com; Mon Mar 30 18:42 EST 1998 Received: by cagw1.att.com; Mon Mar 30 18:42 EST 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id SAA24784; Mon, 30 Mar 1998 18:44:17 -0500 (EST) Received: by merit.edu (bulk_mailer v1.5); Mon, 30 Mar 1998 18:41:07 -0500 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA24671 for nanog-outgoing; Mon, 30 Mar 1998 18:41:06 -0500 (EST) Received: from daver.bungi.com (daver.bungi.com [207.126.97.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA24666 for <nanog(a)merit.edu>; Mon, 30 Mar 1998 18:41:01 -0500 (EST) Received: by daver.bungi.com via sendmail with stdio id <m0yJoAm-0000DnC(a)daver.bungi.com> for nanog(a)merit.edu; Mon, 30 Mar 1998 15:41:00 -0800 (PST) (Smail-3.2.0.94 1997-Apr-22 #8 built 1997-Jun-19) Message-Id: <m0yJoAm-0000DnC(a)daver.bungi.com> From: dlr(a)bungi.com (Dave Rand) Date: Mon, 30 Mar 1998 15:41:00 PST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: nanog(a)merit.edu Subject: Operational issue: Packet loss at Pacbell NAP Sender: owner-nanog(a)merit.edu Content-Type: text -------------------------------------------------- Several of my peers at PB NAP are reporting significant loss (>10%) over the PB NAP. All are OC3 connected, and it seems that PB doesn't have the ability to look too closely at OC3 connections. Death of the 'net predicted: film at 11. So, does this mean that ATM NAPs also have problems with high traffic load? -- Dave Rand dlr(a)bungi.com http://www.bungi.com

2 1

RE: Operational issue: Packet loss at Pacbell NAP
by dlr＠bungi.com 01 Apr '98

01 Apr '98

[In the message entitled "RE: Operational issue: Packet loss at Pacbell NAP" on Mar 31, 16:49, "Ellis, Stephen C (PTSS-scellis)" writes:] > > Nope. The problem is link congestion between SJC and SFO. Pacbell > > was apparently not monitoring this. By rerouting some traffic, they > > were able to shift the peers that it affected. It, with 100% > > certainty, > > is within the cloud that makes up the PB NAP. > > > > > We've identified the facts that occured in this particular situation. > The problem was definitely **not** due to link congestion as we have > stats on the utilization of the OC3s. The rerouting which occured as a > result of this problem has been corrected. Not to beat you too badly, but the situation yesterday I was told was due to saturated trunks between SJC and SFO. Moving traffic from those saturated trunks immediately alleviated the problem on those peers. The problem identified today (with different peers) I was told was due to an ATM routing problem. There are several different problems active, I suspect. As each of the NAPs get to high utilization levels, various failure modes will manifest. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

RE: Seattle Sprint outage - update?
by Peter Murray 31 Mar '98

31 Mar '98

I've not had any problems recently getting through to knowledgeable people at Sprint via their Virginia call center. Try (800) 232-6895, and select option 3. I was talking with one of the fellows there on Friday afternoon, and he was fully aware of the fiber cut. Best Regards, -Pete Pete Murray - FASTNET(tm) / You Tools Corporation > pete(a)fast.net (610) 954-5200 - http://www.fast.net > FASTNET - Business and Personal Internet Solutions > > > -----Original Message----- > From: Joe Rhett [SMTP:jrhett@ISite.Net] > Sent: Tuesday, March 31, 1998 2:00 PM > To: randy(a)psg.com > Cc: nanog(a)merit.edu > Subject: Re: Seattle Sprint outage - update? > > > > > Any one from Sprint care to enlighten us on the major fiber cut in > > > > Seattle? > > > Isn't it a damned shame that a company the size of Sprint does not > have a > > NOC. <sigh> > > Try sarcasm that isn't true. It is a damn shame, and they don't have > anything to speak of. Their response center is downright useless, even > when > you pay them for the priveledge. > > The only way to get something out of Sprint is to know someone. If you > don't know someone, it would seem that lists like Nanog are your only > choice. > > I don't agree, but I don't see a better path either. > > -- > Joe Rhett Systems > Engineer > JRhett(a)ISite.Net ISite > Services > > PGP keys and contact information: > http://www.navigist.com/Staff/JRhett

1 0

Re: Operational issue: Packet loss at Pacbell NAP
by dlr＠bungi.com 31 Mar '98

31 Mar '98

[In the message entitled "Re: Operational issue: Packet loss at Pacbell NAP" on Mar 31, 14:53, "Kent W. England" writes:] > > I wouldn't jump to conclusions. Not likely that the ATM switches are > backplane loaded like the MAEs. These are Stratacom BPXs that replaced the > Newbridge 36150s over three years ago. Correct. > High bandwidth-delay product paths on a heavily loaded OC-3 to OC-3 virtual > circuit will strain the ATM switch buffers. If you can detect regularly > recurring losses on a high BDP path across an all-OC3 virtual circuit, then > look for buffer exhaustion on the OC3 interfaces. If no one at Pac Bell > knows what to do, tell them to look in the files in Fred Chang's Network > Engineering Group for Kent England's ATM NAP switch test plan and go out and > get some test gear that will stress an OC3 link in the lab. Mike Rudik in > the lab knows what to do to test for this. But my recollection was that the > BPX had enough buffers to run UBR over a full OC3. Nope. The problem is link congestion between SJC and SFO. Pacbell was apparently not monitoring this. By rerouting some traffic, they were able to shift the peers that it affected. It, with 100% certainty, is within the cloud that makes up the PB NAP. > > If the loss is on DS3-OC3 virtual circuits then perhaps you are pushing more > than 45 Mbps toward the DS3. There might be a Kentrox ADSU or two left on > the NAP that could have trouble with the cisco OC3 interface at much less > than 45 Mbps. Again, these are OC3 to OC3 in all cases. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: Operational issue: Packet loss at Pacbell NAP
by Kent W. England 31 Mar '98

31 Mar '98

>Several of my peers at PB NAP are reporting significant loss (>10%) over the >PB NAP. All are OC3 connected, and it seems that PB doesn't have the >ability to look too closely at OC3 connections. > >Death of the 'net predicted: film at 11. > >So, does this mean that ATM NAPs also have problems with high traffic load? > >-- >Dave Rand >dlr(a)bungi.com >http://www.bungi.com > I wouldn't jump to conclusions. Not likely that the ATM switches are backplane loaded like the MAEs. These are Stratacom BPXs that replaced the Newbridge 36150s over three years ago. High bandwidth-delay product paths on a heavily loaded OC-3 to OC-3 virtual circuit will strain the ATM switch buffers. If you can detect regularly recurring losses on a high BDP path across an all-OC3 virtual circuit, then look for buffer exhaustion on the OC3 interfaces. If no one at Pac Bell knows what to do, tell them to look in the files in Fred Chang's Network Engineering Group for Kent England's ATM NAP switch test plan and go out and get some test gear that will stress an OC3 link in the lab. Mike Rudik in the lab knows what to do to test for this. But my recollection was that the BPX had enough buffers to run UBR over a full OC3. If the loss is on DS3-OC3 virtual circuits then perhaps you are pushing more than 45 Mbps toward the DS3. There might be a Kentrox ADSU or two left on the NAP that could have trouble with the cisco OC3 interface at much less than 45 Mbps. If the cisco OC3 interfaces haven't been thoroughly shaken down, you might look there for things like buffer exhaustion. If the ciscos are losing, my test plan should show that effect if the ciscos are included in the test path. If no one at PacBell seems interested in the problem, you can talk to the Texans who run the place now. I can give you some names to call in Richardson, Texas but I wouldn't hold my breath. If you happen to be a Texan, then you can probably get something to happen, but if you are an avocado-sucking Hawaiian-shirt-wearing ears-pierced laid-back California dude, then you won't get far with the prime-rib-for-lunch crowd. ;-) --Kent

1 0

Root name server
by Dave Haywood 31 Mar '98

31 Mar '98

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I need to setup an internal root name server in my private network. I am using bind v8.1.1 (Solaris 2.5.1). Does anyone have any pointers on how to achieve this? For those of you not already asleep, the primary nameserver for the root domain and the organisation domain are the same server (I know this is a bad idea but that's just how it is). The nameserver starts up OK (no errors) but when I query the nameserver (dig xxx) it returns zero responses. If I use a FQDN (dig xxx.org.dom) I get the correct result. I do have "domain org.dom" in /etc/resolv.conf and "dns hosts" in /etc/nsswitch.conf. If I dump the nameserver database it looks OK. Perplexed, England. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBNSEjwFtv3tEWY+eVEQKR2ACfdOYy65pzhwQ4RfybTQ7UyZD1f7cAoNLU h9DPr9cYJdPhmPOwGr/zJzAZ =PNJx -----END PGP SIGNATURE----- --- Dave Haywood Network Manager ICL-CFM +44 194 223 5609 C85A 41F5 350F 0F5B 1489 C4BA 5B6F DED1 1663 E795

2 1