December 1995 - NANOG - lists.nanog.org

Re: Sprint Service Problems
by sgoldste＠nsf.gov 20 Dec '95

20 Dec '95

First, if you are getting SPAMmed with <furlough> messages from NSF, sorry. The server does it automagically. I am still reading my mail from home, though now in an UNOFFICIAL capacity, as I am forbidden from performing gummint service... Next, please realize that the operational and implementor folks at Sprint are held hostage to the big bureaucrazy problem: they have to wait each year for the next budget cycle to play catch-up with their performance needs. So, do your best to help them by sending constructive comments to them for them that they might show to their top-level management that is still living in the days of voice telephony with 25-year depreciation cycles on central office gear. Don't stop complaining, but try to give the clueful guys within Sprint something to help them win the good fights internally. This, obviously goes for other service providers, too. --SG (Furloughed Fed) ____________________________________________ Steve Goldstein, National Science Foundation +1(703)306-1949 Ext. 1119 "Let's not procrastinate until tomorrow!"

5 5

Re: Sprint Service Problems
by Melise 20 Dec '95

20 Dec '95

Mr. Lewis, If you are a Sprint customer and are not calling these service lapses to their Network Management Center's attention, you are not giving them the opporturnity to serve you properly. Escalate the problem. respectfully, Melise Jones Sustaining Engineer BBN Systems and Technologies

3 2

Sprint Service Problems
by dlewis＠Teir.COM 19 Dec '95

19 Dec '95

Its days like this when I just love sprint: 8 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 12 msec 16 msec 12 msec 9 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 20 msec 16 msec 10 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 24 msec 16 msec 12 msec 11 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 16 msec 12 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 12 msec 20 msec 12 msec 13 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 12 msec 16 msec 16 msec 14 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 20 msec 24 msec 16 msec 15 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 20 msec 16 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 20 msec 16 msec 17 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 20 msec 16 msec 18 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 16 msec 16 msec 19 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 12 msec 16 msec 20 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 20 msec 16 msec 21 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 20 msec 16 msec 16 msec 22 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 16 msec 12 msec 23 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 20 msec 16 msec 16 msec 24 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 20 msec 28 msec 20 msec 25 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 16 msec 26 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 12 msec 12 msec 16 msec 27 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 20 msec 16 msec 16 msec 28 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 24 msec 16 msec 12 msec 29 sl-dc-6-F0/0.sprintlink.net (144.228.20.6) 16 msec 16 msec 16 msec 30 sl-dc-8-F0/0.sprintlink.net (144.228.20.8) 16 msec 20 msec 24 msec Sadly this is all too common of an occurrence. What is sprint doing to help keep problems like this from becoming chronic? Is it just me or is Sprint particularly bad about this? I guess the reason that I'm bringing this up here is I wonder if these types of problems are the result of any particular choices Sprint made in their design.... If so I would like to know how to avoid them. :) I know that hardware fails and things break, but Sprint has had (in my opinion) more than it's share of problems. -D Darrel Lewis Network Engineer Thomson Electronic Information Resources dlewis(a)teir.com

3 2

Re: Pacific Bell NAP Upgrade
by Warren K. Williams 19 Dec '95

19 Dec '95

Pushpendra: > >Do you plan to connect the SF and the S. California NAP together or will the >S. California NAP be a standalone exchange point ? > >How do you plan to work with the MAE-LA , deployment for which is already >underway, or will this be another MAE-West/SF NAP like situation ? > We are exploring all our alternatives at this point. Kind regards, Warren ------------------------------------------------------------------------------ Warren K. Williams, Director - Network Access Point Pacific Bell Business Communications Services Email: wkwilli(a)pacbell.com Phone: 510.867.9065 ------------------------------------------------------------------------------

1 0

NANOG input to Renumbering (PIER) WG
by wel＠faline.bellcore.com 19 Dec '95

19 Dec '95

The experience and advice of the NANOG community is requested: A new working group (Procedures for Internet/Enterprise Renumbering) is being created in the IETF to support the immediate need for renumbering networks and organizations. Our focus is on what needs to be done with the existing real world, and what's available now to help with the task. Towards this end, we are asking for case studies: actual experience with renumbering networks. tools: information on what tools helped and how they were used. application problems: information on applications that required special attention, and what solutions you may have come up with. We want to get our documents out by this summer at the latest, so we're asking for as much as possible in the way of input by the start of February (so we can put some preliminary work together for the March IETF, and shape our further efforts based on your advice), with all input by May 15. Please send your information to the PIER discussion list, pier(a)isi.edu You may also send it to the editors of the documents directly, without its appearing on the public discussion list, at pier-solicit(a)bellcore.com An Internet Draft, draft-ietf-pier-solicitation-00.txt, describes our request in more detail. Besides the standard I-D servers, it is also available at ftp://ftp.bellcore.com/pub/wel/PIER/solicit.txt With appreciation for your help, Will Leland wel(a)bellcore.com

1 0

Re: Not to beat a dead horse
by William Allen Simpson 19 Dec '95

19 Dec '95

> From: Avi Freedman <freedman(a)netaxs.com> > But I still see 4 /24s advertised in 208/8: > > Now, besides the fact that 208.0.4.0 & 208.0.5.0 could be 208.0.4.0/23 > (grin), what IS the appropriate way to deal with an ongoing situation > where un-NIC-allocated IP space is advertised on the Internet? > My solution would be to filter the routes based on AS. Someday, those routes will be announced from a valid provider, and you will need to know the valid AS from which they should be announced to ignore the bogons. > We have no plans to implement incoming route filters on 208/8 - who > knows when the NIC will start allocating out of it. > The RA knows? Maybe this is a valid use of the RADB? Cannot the NIC update the RA with both prefix and AS? Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Pacific Bell NAP Upgrade
by Warren K. Williams 19 Dec '95

19 Dec '95

Folks, As you all know, from the past two NANOG meetings, Pacific Bell has been working on identifying and evaluating a new ATM switch architecture for the NAP. After looking at several alternatives, I am pleased to announce that we have decided to deploy Stratacom BPX switches. We are very confident that this decision will greatly increase the throughput perfomance of traffic over our ATM environment for the NAP. The performance issues that we have presented have fallen into two categories: buffering capacity and backplane speed. The BPX's buffering is amongst the largest available with a 64,000 cell buffering capacity per port. It also has a 9.6 Gigabit per second backplane. Our engineering group has worked extremely hard in testing the performance of the switch in a TCP/IP environment, with several rigorous test plans. The Stratacom's performance was very impressive. At our next customer meeting and at the next NANOG, we will present a detailed analysis of the results of our testing and of the capabilities of the new switches. This new switch architecture will also allow us to offer a solid OC3 access to the NAP. Along with the new switch announcement, I would also like to inform you of our plans to add an additional exchange point in Southern California. This effort is targetted to those providers who foresee their traffic needs exceeding DS3 access and would be available to both OC3 and DS3 customers. The exact location and timing has yet to be determined. More to follow, most likely at the next NANOG. Warren ------------------------------------------------------------------------------ Warren K. Williams, Director - Network Access Point Pacific Bell Business Communications Services Email: wkwilli(a)pacbell.com Phone: 510.867.9065 ------------------------------------------------------------------------------

2 1

Re: Are the Route Servers Viable Solutions That Are Being Held Hostage?
by Sean Doran 18 Dec '95

18 Dec '95

Sorry, Alan, I don't follow you. Besides, I personally don't think of Suits Are In Charge or its new subsidiary Network Dissolutions to be bad guys at all. In fact, looking back, the whole InterNIC idea is much more of a success on the RS front than on the IS or DS fronts, and that is largely because NSI is staffed and controlled by clueful people. Sean.

1 0

CERT Vendor-Initiated Bulletin VB-95:10 - Vulnerability in elm 2.4
by CERT Bulletin 18 Dec '95

18 Dec '95

CERT Vendor-Initiated Bulletin VB-95:10 December 18, 1995 Topic: Vulnerability in elm 2.4 PL 24 Source: Bill Pemberton, University of Virginia To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Bill Pemberton, who is the coordinator of the group that maintains elm. Mr. Pemberton urges you to act on this information as soon as possible. His contact information is included in the forwarded text below; please contact him if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ I. Description Elm will follow symlinks in /tmp when opening temp files. All systems that support symlinks are vulnerable. II. Impact Users on the system can create files in the directories of other elm users. You can determine what version of elm you are running with the -v command line option (run "elm -v"). III. Solution Upgrade to elm 2.4 PL 25. The patch to upgrade from elm 2.4 PL 24 to PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.p25 MD5 (elm2.4.p25) = 5ec93595c7573be4d0cb4ce7097b6e83 The full distribution of elm 2.4 PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.tar.Z MD5 (elm2.4.tar.Z) = e5bdc4492a4931402c57ac9a8cf111b2 IV. Contact information Bill Pemberton wfp5p(a)virginia.edu ITC/Unix Systems flash(a)virginia.edu University of Virginia uunet!virginia!wfp5p =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University. CERT Vendor-Initiated Bulletin VB-95:10 December 18, 1995 Topic: Vulnerability in elm 2.4 PL 24 Source: Bill Pemberton, University of Virginia To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Bill Pemberton, who is the coordinator of the group that maintains elm. Mr. Pemberton urges you to act on this information as soon as possible. His contact information is included in the forwarded text below; please contact him if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ I. Description Elm will follow symlinks in /tmp when opening temp files. All systems that support symlinks are vulnerable. II. Impact Users on the system can create files in the directories of other elm users. You can determine what version of elm you are running with the -v command line option (run "elm -v"). III. Solution Upgrade to elm 2.4 PL 25. The patch to upgrade from elm 2.4 PL 24 to PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.p25 MD5 (elm2.4.p25) = 5ec93595c7573be4d0cb4ce7097b6e83 The full distribution of elm 2.4 PL 25 is available at: ftp://ftp.myxa.com/pub/elm/elm2.4.tar.Z MD5 (elm2.4.tar.Z) = e5bdc4492a4931402c57ac9a8cf111b2 IV. Contact information Bill Pemberton wfp5p(a)virginia.edu ITC/Unix Systems flash(a)virginia.edu University of Virginia uunet!virginia!wfp5p =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University.

1 0

Re: Are the Route Servers Viable Solutions That Are Being Held Hostage?
by Sean Doran 18 Dec '95

18 Dec '95

| I asked Bud, "Bud, will your I/R to RF transcievers send data at | greater than 2.4kps?". "Yes", replied Bud, "but it will take some work, and cost $X". | "And will your I/R to RF transcievers send data bidirectionally?" | I asked Bud. "Yes", replied Bud, "but it will take some work, and cost $X". So you paid him $X and he set about his business. Some months later, you are wondering why you haven't had a fully-working, delivered, useful, marketable product. "What happened?", you ask Bud. Bud explains that the problem was that there were some other organizations who didn't put in the (unpaid-for by Bud) effort needed to get Bud the information Bud needed to make things work as planned, even though those organizations might get some benefit from the work Bud was doing. "But given $X or even $X times N, could you have accumulated all the information yourself, in principle, in this time?", you ask Bud. "And could you not have foreseen this problem, or even explained to me earlier than now that it was a difficulty that could be overcome by more resources for you to gather up this information more independently?" Hm, I wonder what the answers are. Sean.

2 1