October 2000 - Test - lists.nanog.org

Reminder of the DNSSEC workshop
by Edward Lewis 05 Oct '00

05 Oct '00

http://www.nanog.org/mtg-0010/dnssec.html When I first mentioned having this workshop a number of folks mentioned they were interested. But most of those haven't signed up yet! So there is still room (about a dozen have registered so far) for more. A few registrants have asked for confirmations - I hadn't planned on sending them, but if you sent in a registration, you're in (unless sendmail bounced something). If you need a confirmation (to justify spending a day, etc.) let me know and I'll send one. Please don't make me hire "extras" to make the event look crowded like they do in music videos...;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis(a)tislabs.com "It takes years of training to know when to do nothing" - Dogbert Opinions expressed are property of my evil twin, not my employer.

1 0

Informational Message - IP Addr Change for j.gtld-servers.net
by Rippe, Mark 05 Oct '00

05 Oct '00

Normally, Brad Verd posts these messages. I am posting this on Brad's behalf since he is half way around the world, and I don't wish to wake him, but I want to ensure those who do care get some advance notice. This is informational only, and should not require any action. Apologies in advance to those who are not interested. Informational message: Effective for the zones with serial number 2000100501, the IP address for j.gtld-servers.net (currently 198.41.0.21) will change to 210.132.100.101. This will not require any change to the root name server hints file and the old j.gtld-servers.net will continue to answer queries for at least a week. The purpose of this change is to move j.gtld-servers.net from its temporary location in Virginia to its permanent location in Tokyo, Japan. With this change, the authoritative servers for com/net/org will be: A.ROOT-SERVERS.NET. 198.41.0.4 G.GTLD-SERVERS.NET. 198.41.3.101 E.GTLD-SERVERS.NET. 207.200.81.69 F.GTLD-SERVERS.NET. 198.17.208.67 D.GTLD-SERVERS.NET. 208.206.240.5 J.GTLD-SERVERS.NET. 210.132.100.101 K.GTLD-SERVERS.NET. 195.8.99.11 A.GTLD-SERVERS.NET. 198.41.3.38 M.GTLD-SERVERS.NET. 210.176.152.18 C.GTLD-SERVERS.NET. 205.188.185.18 I.GTLD-SERVERS.NET. 192.36.144.133 B.GTLD-SERVERS.NET. 203.181.106.5 -------------------------------------- Mark Rippe VeriSign Global Registry Services Email - mrippe(a)netsol.com ---------------------------------------

1 0

RE: RSA Patent Expired
by Richard A. Steenbergen 05 Oct '00

05 Oct '00

On Tue, 3 Oct 2000, Richard Welty wrote: > Bill Fumerola [mailto:billf@chimesnet.com] wrote: > > OpenSSH uses RSA for ssh1, so it too benefited greatly > > from RSA's release of the code into the public domain. > > except that nobody should be using ssh1 for _anything_ if they can > possibly avoid it. even the orginal authors of ssh are strongly > advocating > consigning ssh1 to the trash heap of computer security. I think you're confused, ssh1 is still a very valid protocol. It is well tested and proven, and in many cases better implemented then ssh2 (though of course that may change eventually). Don't confuse the desire to make money with insecurity. As for the release of the RSA patent, its a "nice thing" but it hasn't changed much other then cleaning up some bad code by removing the need to use RSAREF (and good riddence), and moving some dollar signs around for commercial implementors. "Anyone is now free to rub two primes together for their own gratification" -- Unknown -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

6 8

UUNet UK network melted
by Simon Lockhart 05 Oct '00

05 Oct '00

Last night during their maintenance slot, UUNet UK renumbered from AS1849 to AS702. We came in this morning to find their network completely broken. At 8am BST, their support line said that the work had over-run and would be complete by 8:30am. Now, at 9:45am it's still completely down. (We've shut down BGP with UUNet and are making the most of nicer connectivity through our other transit providers) Expect loss of connectivity to some UK sites. 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/

2 1

BGP Confederations
by ccie10 05 Oct '00

05 Oct '00

Is there an easy way to migrate an existing network running IBGP full mesh to a Condederation based configration. Any documentation that I have come across states that current BGP configs need to be redone and all peering relationships must torn down and rebuilt. Any addtional info/links regarding confederations would be appreciated thanks

4 3

LattisCell 10114-DS3 information
by John Fraizer 05 Oct '00

05 Oct '00

Can someone point me to some documentation for the Synoptics/Bay Networks/Nortel LattisCell 10114-DS3 ATM switch? Searching Nortel's support site for 10114 comes up empty. We have aquired one of these and would like to have it do more than just look neat in the cabinet. (Yes, it came sans documentation.) Thanks, --- John Fraizer EnterZone, Inc

1 0

Redback routers
by Brett L. Hawn 04 Oct '00

04 Oct '00

I'm looking for some operational input on redback routers, specifically with regards to use for DSL aggregation over ATM of which so far I've found little information. My personal interaction with the Redback router has been pretty much nil other than being told what a nice provisioning system it has, and that at 70% utilization on the circuit it starts flaking. Now this could be a very specific situation in as much as poorly configured router (eg. lack of packet memory, munged config, etc) or it could be an issue with the hardware itself, which is of course why I'm trying to dig up something more than the standard 'our product really kicks butt' brochures from the vendor. All of this being said, if anyone has experience with this sort of situation or has pointers to better data I'd appreciate it.

1 0

MAE-East funniness
by Timothy Brown 04 Oct '00

04 Oct '00

ObDisclaimer: I might be crazy, misinformed, stupid, or clueless, since I don't directly connect at East and have no prior background to move forward on. Is there any funniness going on with interconnects between Gigaswitches at East? I'm trying to solve a customer connectivity problem (packet loss, 21% over 5K packets) that passes between what appears to be giga5 and giga7, and there is a significant amount of fingerpointing between the requisite providers, one of which is suggesting that my customer try to get someone to reroute the traffic to West. Is there something in general I should know about before I take the providers in question to task for not just fixing the problem, if it's something that can be fixed, or is this something more commonly accepted? T

1 0

Re: QAZ probes from webtv?
by Dan Hollis 03 Oct '00

03 Oct '00

On Tue, 3 Oct 2000, John Fraizer wrote: > So, Dan's ACL was trapping any TCP traffic destined to 7597 and not just > TCP SYN? Yes, although out of 50 million packets, the webtv servers/clients were the only ones to *consistently* choose 7597 over the span of several days, at different times of day and night. I've got better ACLs now. -Dan

1 0

Re: QAZ probes from webtv?
by Sami Juvonen 03 Oct '00

03 Oct '00

Dan Hollis <goemon(a)sasami.anime.net> wrote on Sun, 1 Oct 2000 20:08:03 -0700 (PDT): > Anyone else seeing webtv probing your customers for QAZ? > The following webtv hosts seem to be probing our dialup customers port > tcp/7597: WebTV Networks is not probing for QAZ. After reviewing the log files Dan Hollis provided, it appears that these packets are normal TCP communication between a WebTV terminal and the WebTV service. The client terminal initiates a connection, picking a random source port. The service is trying to establish a connection with the client using that port. This behavior is not limited to WebTV. It appears that the packet from the service was caught in Dan's perimeter router ACL. Please do not hesitate to contact us if you have any concerns about WebTV and security or network interoperability issues. Please see http://www.webtv.net/contact/contact.html for contact information. Thank you, Sami Juvonen, Systems Engineer, WebTV Networks, Operations Engineering

2 1