- Test - lists.nanog.org

Re: links on the blink (fwd)
by Scott Bradner 05 Nov '95

05 Nov '95

> > Well, I don't think I will need to be reminded not to buy Internet service > > from your organization. > > Why not? We don't run the Internet, we just connect people to it. As has been said about New Yorker cartoons, if you don't get it, no amount of explanation will help. Scott

3 2

Re: links on the blink (fwd)
by Scott Bradner 05 Nov '95

05 Nov '95

> 10% packet loss is quite within the normal range of parameters for a > packet switching network such as the Internet. Well, I don't think I will need to be reminded not to buy Internet service from your organization. Here is a bit of context. At home I am a beta site for the PSI Internet service via cable TV. I generally use a computer at Harvard University to read my mail. Although the Harvard network is about 1.5 miles away from my house the sparse distribution of connections between Internet service providers and the current routing policies mean that packets from my house to Harvard take 20 hops and go through San Francisco and packets from Harvard to my house, (also 20 hops) go through Washington DC. Here are the results of some reliability tests I just ran. from my house to San Francisco via PSI Net: 209 packets transmitted, 209 packets received, 0% packet loss round-trip min/avg/max = 99.996/268.978/983.334 ms from Harvard to Washington DC via BBN Planet and MCI 204 packets transmitted, 204 packets received, 0% packet loss round-trip (ms) min/avg/max = 16/46/249 from my house to Harvard via PSI, MAE-west, MCI, BBN Planet and back via BBN Planet, MCI, MAE-east and PSI. 505 packets transmitted, 497 packets received, 1% packet loss round-trip min/avg/max = 116.702/192.69/3000 ms (Note this is being tested at a time when Harvard's service provider (BBN planet) is busily working on one of the links in its backbone because they do not think the quality is high enough.) I consider it a problem when the loss exceeds 1% through this long path - as do the people who run the networks that my traffic passes through. The normal loss through this path is less than 1% and, much of the time it is 0. > But nothing is broken. There is no inter-ISP level. It is so much easier to just say it is the other guy's problem. Hans-Werner suggests that most phone companies do not take this attitude, lucky for some of us, not all Internet "service" providers do. Scott (just in case you might think I'm off on some other world, there are other paths I could have used which would have shown far higher loss, those paths would have gone through service providers who apparently feel the way that the person quoted here does or who are unable to make the investment in their infrastructure warranted by the level of traffic their customers would like to exchange.)

3 3

Re: links on the blink (fwd)
by hwb＠upeksa.sdsc.edu 05 Nov '95

05 Nov '95

>I think you're confusing "quality" with "locked into contract." If >you have quality, being locked in with fixed rates and service is a good >thing. If you don't have quality it's a bad thing. > >Try real hard not to blame the provider, but the idiot who signed a contract >that doesn't have performance guarantees. We [ACES Research] offer our >clients contracts, and if they want to pay for performance guarantees, those >too. None of them whine, so I assume they're happy and not upset. Some of >them have locked rates till '98 that are just too good to mention. This is a reasonable and appropriate response. The problem, I guess, is that the environment is young and people do not know what is reasonable to ask for in terms of service metrics, and service providers may not know what is reasonable to offer. Do you (or others) have suggestions about those, that could be used to address many of the concerns? We do not have to fix things 100%, I guess, but it would be nice to get to some high degree, rather than retaining status quo. Can we use them in the inter-ISP realm?

3 3

Re: links on the blink (fwd)
by William Allen Simpson 05 Nov '95

05 Nov '95

> From: rrv(a)uiuc.edu (Ross Veach) > At 2:48 PM 11/4/95, Michael Dillon wrote: > >10% packet loss is quite within the normal range of parameters for a > >packet switching network such as the Internet. > > Sorry Michael, wrong answer. 1% packet loss is intolerable. 10% packet > loss is all but useless for serious work. > And the 40% reported here (at MAE-East) is excrable. Except at the older MAE-East, it's not _links_ that are on the blink. It's the (too few) exchanges, and the very bad routing policies. Of course, the idiocy of choosing ATM kept most of the NAPs off-line, until they switched to FDDI. My solution is to take the contracts away from MFS and Ameritech effective immediately, and grant them to someone who knows what they are doing. I may not agree with all the older CIX policies, but at least it worked! 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

3 2

Re: links on the blink (fwd)
by sob＠academ.com 05 Nov '95

05 Nov '95

> Yes, there is no formal mechanism to my knowledge, but should we really > make one? There was a document written by Paul A. Flahery called "NSFNET Trouble Reporting Standards". It was published in August of 1994 as an outgrowth of the NSFNET RAC. It is not a formal standard, but might be a place to start work towards some mechanism to effectively deal with trouble reporting and resolution. I don't know if a copy of this document is available on-line or not. Perhaps someone else in the groups knows. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

CERT Vendor-Initiated Bulletin VB-95:08 - X Authentication Vul
by CERT Bulletin 02 Nov '95

02 Nov '95

CERT Vendor-Initiated Bulletin VB-95:08 November 2, 1995 Topic: X Authentication Vulnerability Source: X Consortium To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from the X Consortium. The X Consortium urges you to act on this information as soon as possible. X Consortium contact information is included in the forwarded text below; please contact them if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ Two widely used X Window System authorization schemes have weaknesses in the sample implementation. These weaknesses could allow unauthorized remote users to connect to X displays and are present in X11 Release 6 and earlier releases of the X11 sample implementation. There are reports that systems have been broken into using at least one of these weaknesses and that there are now exploit programs available in the intruder community. MIT-MAGIC-COOKIE-1 Description: On systems on which xdm is built without the HasXdmAuth config option, the MIT-MAGIC-COOKIE-1 key generated by xdm may be guessable. If you use MIT-MAGIC-COOKIE-1 to authenticate X connections, and your keys are generated by xdm, and xdm does not also support XDM-AUTHORIZATION-1 authentication (that is, your X tree was not built with the HasXdmAuth config option), you may be at risk. On systems with poor pseudo-random number generators, the key may be guessable by remote users. On other systems, users with access to the file system where xdm stores its keys for use by local servers may be able to use information in the file system to guess the key. If your xdm program was built with HasXdmAuth set to YES (the compiler command line includes the -DHASXDMAUTH flag), MIT-MAGIC-COOKIE-1 keys generated by xdm are not vulnerable; the DES code is used to generate cryptographically secure keys. Impact Remote users anywhere on the Internet may be able to connect to your X display server. It is NOT necessary that they be able to snoop your key first. XDM-AUTHORIZATION-1 Description: The X server does not correctly check the XDM-AUTHORIZATION-1 data and can be fooled into accepting invalid data. A user who can snoop the encrypted authorization data of a valid connection can create fake auth data that the X server will accept. If you do not use XDM-AUTHORIZATION-1, you are not vulnerable. Determining whether your server is vulnerable: this problem is fixed in X servers from the X Consortium with a vendor release number of 6001 or higher. Impact Remote users may be able to connect to your X display server. SOLUTIONS A. Install a vendor supplied patch if available. B. If your site is using X11 built from X Consortium X11R6 sources, install public patch #13. This patch is available via anonymous FTP from ftp.x.org as the file /pub/R6/fixes/fix-13. It is also available from the many sites that mirror ftp.x.org. Apply all patches not already applied, up to and including fix-13. The file xc/bug-report shows what public patches have been already applied to your source tree. The MD5 checksum of fix-13 is as follows: MD5 (fix-13) = 0d81d843acf803a8bedf90d3a18b9ed6 C. If your site is using an earlier version of the X Consortium's X11, upgrade to X11R6. Install all patches up to and including fix-13. D. Work arounds. 1. Building with HasXdmAuth will eliminate the first vulnerability. The necessary DES code is available for FTP from both inside the US (for US sites only) and outside (for non-US sites). Read <ftp://ftp.x.org/pub/R6/xdm-auth/README> for details on obtaining this code. 2. If you cannot use DES, you can determine your exposure to remote attackers by testing the strength of your rand() function using the program rand-test; the source is available as <ftp://ftp.x.org/pub/DOCS/rand-test/rand-test.c>. 3. Limiting use of X connections using XDM-AUTHORIZATION-1 to trusted networks will prevent unauthorized parties from snooping X protocol traffic, thus preventing exploitation of the second vulnerability. Acknowledgements: The X Consortium would like to thank Chris Hall of the University of Colorado for analyzing these problems and bringing them to our attention. ----------------------------------------------------------------- Vendor Status The following information was supplied by vendors for this bulletin. The X Consortium and CERT have not verified this information. Cray Research UNICOS 8.0 and 9.0 are not vulnerable. These systems have robust pseudo-random number generators, making them not vulnerable to the first problem, and do not support an X server, making them not vulnerable to the second problem. GSSC (formerly Solbourne) Has concluded they are not vulnerable. Hewlett-Packard All versions of X on HP-UX 9.x and 10.x (based on X11R5) do not have the first vulnerability. X Consortium (Sample implementation of X.) You can patch X11R6 by applying all public patches up to and including fix-13. Patches are available via FTP from ftp.x.org in /pub/R6/fixes/ and from mirroring sites. You can check that the X server has fix-13 installed by verifying that the server has a vendor release number of 6001 or higher. General questions about the X Window System can be asked on the xpert mailing list hosted at x.org. Send a "subscribe" message to xpert-request(a)x.org to subscribe. This list is gatewayed with the comp.windows.x newsgroup. The FAQ for this newsgroup is available from <ftp://ftp.x.org/contrib/faqs/FAQ.Z> and other locations. <http://www.x.org/consortium/news_and_mail.html> describes other newsgroups and mailing lists for the discussion of issues related to the X Window System. Bugs encounted in X Consortium code can be reported to xbugs(a)x.org using the format in xc/bug-report. Please see the X11R6 Release Notes for additional details. XFree86 Project The XFree86 Project, Inc has patched binaries for XFree86 version 3.1.2 running on FreeBSD 1.1.5, FreeBSD 2.0.5, ISC, NetBSD and SVR4. They are available from ftp://ftp.xfree86.org/pub/XFree86/3.1.2/binaries/. The files are: FreeBSD-1.1.5/X312Sxdm.tgz FreeBSD-2.0.5/X312Sxdm.tgz ISC/X312Sxdm.tgz NetBSD/X312Sxdm.tgz SVR4/X312Sxdm.tgz The MD5 checksums are: MD5 (FreeBSD-1.1.5/X312Sxdm.tgz) = 43166109c88fcd623d27de1fa90e8f5b MD5 (FreeBSD-2.0.5/X312Sxdm.tgz) = 3314a623b2c31a9130445e9237ff65f9 MD5 (ISC/X312Sxdm.tgz) = e4e16fc5f4d06ad455e572a2e1eb0eb5 MD5 (NetBSD/X312Sxdm.tgz) = 0bc74cbee0214366ac15658bf5436853 MD5 (SVR4/X312Sxdm.tgz) = bf5dfea2a86cdf92621421e3f68af203 Installation instructions (assuming X312xdm.tgz is in /tmp): Kill any xdm processes that are running, then: For FreeBSD 1.1.5 and FreeBSD 2.0.5: cd /usr mv X11R6/bin/xdm X11R6/bin/xdm-3.1.2 chmod 0500 X11R6/bin/xdm-3.1.2 gzip -d < /tmp/X312xdm.tgz | tar vxf - For NetBSD: mv /usr/X11R6/bin/xdm /usr/X11R6/bin/xdm-3.1.2 chmod 0500 /usr/X11R6/bin/xdm-3.1.2 pkg_add /tmp/X312Sxdm.tgz For ISC and SVR4: cd /usr/X11R6 mv bin/xdm bin/xdm-3.1.2 chmod 0500 bin/xdm-3.1.2 gzip -d < /tmp/X312xdm.tgz | tar vxf - =========================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: cisco BGP aggregation bug
by Sean Doran 02 Nov '95

02 Nov '95

Hm, ok, weird. Thanks for pointing this out, Mitch. Sean.

1 0

38.0.0.0 subnets still getting advertised
by Alec H. Peterson 02 Nov '95

02 Nov '95

I thought Mitch said he'd fixed this problem for now. Sure doesn't look like it... Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie(a)panix.com | Panix Public Access UNIX and Internet| |Network Administrator | New York City, NY | +------------------------------------+--------------------------------------+

1 0

Re: Professionalism, etc...
by Steven J. Richardson 02 Nov '95

02 Nov '95

Tim: Can we please actually practice some professionalism by getting back to technical topics? This list is for Network Operators. Thank you, Steve Richardson/Merit == >From list-admin(a)merit.edu Thu Nov 2 11:14:40 1995 >Received: from merit.edu (merit.edu [35.1.1.42]) by home.merit.edu (8.6.12/merit-2.0) with ESMTP id LAA08939; Thu, 2 Nov 1995 11:14:35 -0500 >Received: from dune.silkroad.com (bass(a)dune.silkroad.com [165.209.1.2]) by merit.edu (8.6.12/merit-2.0) with ESMTP id KAA05890 for <nanog(a)merit.edu>; Thu, 2 Nov 1995 10:29:01 -0500 >Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id KAA10570; Thu, 2 Nov 1995 10:26:28 -0500 >From: Tim Bass <bass(a)dune.silkroad.com> >Message-Id: <199511021526.KAA10570(a)dune.silkroad.com> >Subject: Re: Professionalism, etc... >To: young(a)mci.net (Jeff Young) >Date: Thu, 2 Nov 1995 10:26:28 -0500 (EST) >Cc: nanog(a)merit.edu >In-Reply-To: <199511021309.IAA24793(a)foghorn.reston.mci.net> from "Jeff Young" at Nov 2, 95 08:09:35 am >X-Mailer: ELM [version 2.4 PL24 PGP2] >MIME-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Length: 1376 >Status: R > > >This is getting personal and way off topic, so I'll take the >'middle road' with Jeff before we drag this down more, > give a short response, and end it. > >( with my financee in Germany for over a month, and absolutely > no sleep last night, I cannot find the 'high road' this AM, > sorry ... ) > >Whomever is superhuman, always speaks and rights exactly what >they intend, always void of emotion and in complete understanding >of all past and present (not to mention future) events and >actions please continue this discussion without me :-) > >I am human and therefore not worthy to discuss professionalism >nor any human condition. Thanks Jeff, for pointing that out. >I need to be constantly reminded of my imperfections. I >realize them myself, but appreciate your reminder and tact. > >.... we should all follow Jeff's example and when any human >forwards or advocates an idea, no matter what the position, >lets look for a human fault and or some 'not so perfect' >assembly of symbols of expression (words) with 'not so perfect' >foundation (human emotions) and use them to counter argue. > >It certainly works very well to defocus the discussion from >one of ideas and aspirations and to create an interesting >side show. Excellent counterpoint Jeff. It is impossible >for me, unworthly, soiled, and defeated to continue in the >' has professionalism been redefined ?' thread. > > >Tim > >

1 0

cisco BGP aggregation bug
by levinn＠noc.psi.net 02 Nov '95

02 Nov '95

Hi there, We've been tracking a problem with our cisco's screwing up aggregation of net38 at our borders. Cisco finally issued a bug ID for the problem today (CSCDI-43165). We had been holding off announcing the problem to the world until cisco confirmed where the problem is though we have explained the situation to many that have complained directly to us about the various side-effects of the bug and its workarounds. The symptom is that our statically aggregated announcement of net38 ("aggregate-address 38.0.0.0 255.0.0.0 summary-only") which we had thought had been working for many months apparently had been flapping, as seen by our neighbors (though not by us). This was undetected until Sprint enabled the route-dampener and discovered that net38 was being deleted from their routing tables due to flaps. It should be impossible, with the static aggregation, to have this flap, we thought. Not so, apparently. Cisco suggested many variations of work-arounds, some of which were not completely successful (the most notable of which resulted in announcement of many net38 subnets, as pointed out last week on the nanog list). Our current config, which seems to be working fine, forces us to allow auto summary, resulting in us withdrawing from the net39 experiment until a real bug fix is generated by cisco. Our environment includes many interior routing protocols and there may be lots of inter-related issues coming together here. We have not isolated the issues sufficiently to tell you what to look for, but perhaps cisco can comment here on what might tickle this. At any rate, we believe the current situation is stable as far as our announcements go. We hope to be able to rejoin the net39 effort again soon... -Mitch

4 3