- Test - lists.nanog.org

Re: links on the blink (fwd)
by Michael Dillon 08 Nov '95

08 Nov '95

On Wed, 8 Nov 1995, Dave Mills wrote: > Devious would it be for me to monkey in this debate; however, I'm sure > HWB will pick up on these points. Ten percent loss is most definitely > not within the envelope of acceptable service. The protocol models I > have participated in developing and evaluating perform best at loss rates > not exceeding one percent on average. My access is now from London, > where the transatlantic loss rates are more like 30 percent. I would > recommend a sentence to any advocate/employee/consultant making a claim > such as yours to live with these rates for any length of time. You'll be pleased to know that I, living in Canada, did have a consulting engagement in London for a couple of weeks via telnet and know just what that kind of loss rate is like. > Second, you suggest patience and that the problems should go away in > ten years. Excuse me, I heard (and even said myself as NSF advisor and > researcher) the identical words ten years ago. Sooner or later, someone who says "wait ten years" will be right. I base my statement on the knowledge that cable ships are furiously plowing the oceans and girdling the planet with large bundles of fibre. There was also the Sprint announcement at Telecom 95 that they will be operating a globe girdling fully meshed backbone. No doubt several other companies will do the same. I believe that the only real lasting solution to packet loss problems is a combination of bandwidth and topology. When each backbone company uses high bandwidth fibre throughout and operates their own fully meshed topology that is interconnected not only at NAPS but at numerous two-way interchange points with other backbone providers, then we have a chance at getting lower packet loss rates. If nasty video protocols get deployed on the Internet then I could be wrong about the ten years. But if video migrates to a parallel globe-girdling ATM network then the Internet could be much better in ten years. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com

1 0

CERT Advisory CA-95:15 - SGI lp Vulnerability
by CERT Advisory 08 Nov '95

08 Nov '95

============================================================================= CA-95:15 CERT Advisory November 8, 1995 SGI lp Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has had several security incidents reported to us involving the lp account on the Silicon Graphics, Inc. (SGI) IRIX system. As distributed by SGI, the lp account, as well as other accounts, has no password on a newly installed system. The lp account, which is used by the lp(1) program for remote printing, and other accounts are initially configured without passwords to provide easy "plug-and-play" install and operation. However, these password-less accounts are well known by intruders and allow unintended access to your system. In the documentation that SGI distributes with their systems, these password-less accounts are specifically addressed in the "IRIX Advanced Site and Server Administrative Guide" in the chapter on System Security. The documentation recommends disabling the login for the lp account. It also recommends that you create passwords for the following accounts immediately: demos, guest, lp, nuucp, root, tour, tutor, and 4Dgifts. The documentation includes guidelines for choosing good passwords. To determine if your system is vulnerable, use the following command as root to display the status of all password-less accounts: # /bin/passwd -sa | /bin/awk '$2 == "NP" {print $0}' If this command displays any accounts, especially the lp account, then your system is vulnerable. To address this vulnerability, we recommend using the workarounds in Section III below. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:15.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description The SGI IRIX system as distributed has some accounts without passwords. Among the accounts that are password-less is the lp account. This account is used in part by the lp(1) program to manage object and spooled data files in the /var/spool/lp directory (for IRIX 4.X, this directory is /usr/spool/lp). The account is created without a password because lp(1) uses rsh(1) to transfer files from print clients to print servers. II. Impact Remote users can gain access to systems without authentication. The level of privilege gained depends on the password-less account used to access a system. Although the scope of this advisory is the lp account, keep in mind that any account without a password (or with an easy-to-guess password) is a point for access without authentication. III. Solution The general solution is to lock all accounts that do not have passwords. Section A below describes how to do that. Section B suggests one way to re-enable print client to print server communication. A. Lock each password-less account. Store the following script in /tmp/CheckPasswords for example and then run it as root on your machine to lock each password-less account. The password installed will not allow the accounts to be used as login accounts. See the passwd(1) manual page for more details. Note that this script only locks accounts on the local machine. If there are password-less accounts in NIS, those accounts will not be locked by this script. ------------------------cut here--8<------------------------ #!/bin/sh for account in `/bin/passwd -sa | /bin/awk '$2 == "NP" {print $1}'` do /bin/echo Locked the $account account /bin/passwd -l $account done ------------------------cut here--8<------------------------ The first time the script is run, it should display something similar to the following: # sh /tmp/CheckPasswords Locked the tutor account Locked the tour account Locked the lp account ... If the script locked an account, run the script again. This time it should produce no output because all password-less accounts have now been locked. B. Re-enable print client to print server communication. (We have verified with SGI that you can use the script in this section to re-enable the print client to print server communication. SGI has asked us to make it clear, however, that they do not have the resources to handle issues relating to the use of wrappers.) Note that, in general, the CERT Coordination Center recommends that the rlogin and rsh services be blocked at your Internet routers and turned off on all of your machines. If you have turned the rsh service off on your print server, you will need to turn it back on on that machine. If you decide to do this, we strongly recommend that you install and use a TCP/IP wrapper program to restrict the set of machines that can connect to your print server's rsh service. A TCP/IP wrapper program is available from ftp://info.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.2.tar.Z MD5 (tcp_wrappers_7.2.tar.Z) = 883d00cbd2dedd9bfc783b7065740e74 Once the rsh service is turned on on your print server and a TCP/IP wrapper program installed and configured, you then need to define the set of machines that can communicate with your print server. For each IRIX system that controls a printer, the lp account needs to be changed to re-enable print client to print server communication. To do this, the lp account on each print server needs a .rhosts file in lp's home directory, typically /var/spool/lp (for IRIX 4.X, this directory is /usr/spool/lp). The owner and group of this file must be the same as that of the lp account. Its contents are lines of the form: print_client_name lp Each line identifies the name of the print client and indicates that the lp account is the account that is allowed to rsh from the print client to the print server. The following shows an example of configuring communication from a print client (named "client") to a print server. This configuration need only be done on a print server. The ping command is used to determine the print client's formal name according to whatever host resolution scheme is in place. That name is stored in the .rhosts file. The last two lines, the ping and the echo, need to be repeated for each client of a print server. # /bin/awk -F: '$1 == "lp" {print $0}' /etc/passwd lp:*LK*:9:9:Print Spooler Owner:/var/spool/lp:/bin/sh # cd `/bin/awk -F: '$1 == "lp" {print $6}' /etc/passwd` # /bin/touch .rhosts # /bin/chown lp .rhosts # /bin/chgrp lp .rhosts # /bin/chmod 600 .rhosts # /usr/etc/ping -c 1 client | /bin/awk '$1 == "PING" {print $2}' client.YourDomain # /bin/echo client.YourDomain lp >> .rhosts --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Silicon Graphics Inc. and Christopher Kranz of Princeton University for their support in responding to this problem. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email 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 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT advisories and bulletins are 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. Past CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for non commercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University.

1 0

Re: links on the blink (fwd)
by rrv＠uiuc.edu 08 Nov '95

08 Nov '95

At 2:48 PM 11/4/95, Michael Dillon wrote: >On Sat, 4 Nov 1995, Hans-Werner Braun wrote: >> Just let me ask you, as a customer who fairly >> frequently experiences 10% packet loss between major Internet locations >> across major service providers (no mom and pop shops in the middle or >> at the end points), how would you suggest I deal with that? > >Uh... Ignore it? >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.

4 3

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

08 Nov '95

I think Dave has the right idea here. Given the lousy overall network performance that I (and others) are often seeing for months from varieties of service providers, I think the service providers should be forced to provide rebates. I frequently have 10% packet losses to get from where I am to the Bay area (via New York). And my service provider (CERFnet) is telling me that their service provider (Sprint) is not even answering to their trouble reports. Forwarded message: >From nobody Thu Nov 2 04:40:21 1995 X-Authentication-Warning: upeksa.sdsc.edu: nobody owned process doing -bs Message-Id: <199511021201.AA05016(a)quark.isi.edu> To: Kate Lance <clance(a)sol.newcastle.edu.au> Cc: J.Crowcroft(a)cs.ucl.ac.uk, end2end-interest(a)ISI.EDU Subject: Re: links on the blink In-Reply-To: Your message of "Thu, 02 Nov 95 15:26:44 +1100." <199511020426.PAA22322(a)lily.newcastle.edu.au> Date: Thu, 02 Nov 95 11:55:17 +0000 From: Dave Mills <D.Mills(a)cs.ucl.ac.uk> jon, Kate, Lack of specific performance data is surely disappointing; however, I used to work for COMSAT, so understand the corporate mentality of such dinosaurs. Let me suggest we mount an ongoing experiment in which representative links of deserving carriers are monitored, perhaps with pings launched from cron jobs, and the results submitted for publication in respected national media, like ISOC, ACM CCR, NY Times, etc. One of my (failed) missions at COMSAT was to persuade the lawyers to approve a tariff filing for a packet satellite service. Their stated opposition was based on an assumption that COMSAT would have to rebate charges for those packets not actually delivered to the destination gateway. Our course is clear. File requests for refund with the cognizant public utilities commission. The FCC would of course laugh; however, the reaction of the <state> PUCs would be most interesting, especially if it was pointed out that the rationale for granting the license in the first place was service to the public sector. Dave

11 19

Re: links on the blink (fwd)
by Jeff.Ogden＠um.cc.umich.edu 08 Nov '95

08 Nov '95

I beleive in more accountability and less blame, but in my experience more ink on paper does not necessarly give you that result. Ink on paper often seems to be what lawyers use when the go to court and you go to court after the other less formal methods have failed. Now having some standards for what acceptable performance is and keeping some statistics showing what performace has historically been for a given network and having some good way for one network to work with others to resolve problems -- all of that seems to offer more hope than working on legal contracts. -Jeff Ogden Merit/MichNet

1 0

Re: links on the blink (fwd)
by Sean Donelan 08 Nov '95

08 Nov '95

>worked so hard on achieving. My hope was that you guys would do better >than we did, and provide a ubiquitous high quality network (we did high >quality, but not ubiquitous). Are you going to get to work and fix it, >or continue to screw it up and whine around about the heat in the >kitchen? Your choice. It may just be culture shock going from the role of Internet insider, to Internet outsider. But from the point of view of someone who has always been an outsider, things don't really seem that different than they have in the past. The net goes through cycles of good bandwidth headroom years, and lean bandwidth headroom years. The engineers have always been too busy trying to hold the whole mess together to explain to the Internet populace what was going on. End-to-end network usability has been a persistent problem for the decade+ I've been using the net. The Internet insiders may have been working very hard on management issues. But from the outsider's point of view, the historical net cycle goes something like this. The net's usability slowly declined over the years until reaching a level even network engineers couldn't hand over, then it would suddenly take a leap to a new bandwidth plateau. Yes, network engineers have a long history of finger-pointing and handwaving. But in the past there wasn't anyone who could give a second-opinion. The few end-users who try to measure their perception of the network usability have historically been shouted down. It doesn't seem to matter if there is a high correlation between ping loss rate, and user perception of network performance. All the network engineers know this is a "flawed" testing methodology. This isn't unique to the Internet community. End-users who have the audacity to test their own electrical, telephone, or water service are usually greeted with equal scepticism in by those industries' engineers. Ok, maybe "Internet Management" is an oxymoron. But the lack of centralized management isn't always a bad thing, as long as we can find some invisible hand to guide us. NOC trouble ticket practices, accounting, measurements, and so forth have been on and off the IETF agenda for years. If they were easy problems, I suppsoe they would be solved by now. How about a few positive suggestions which could be implemented in the short-term. The NSFNET Newsletter, Network Status Report list, monthly statistics, and the asnnn(a)merit.edu and techs contact lists were helpful in generating a consensual reality. Perhaps IDG would be interested in publishing a NANOGWorld, free to "qualified" subscribers chock full with exciting cisco advertisements :-). In the meantime, Sprint's outage list, and UUNET's uunet.status newsgroup, and PSI's and UUNET's World Wide Web pages keep folks informed their network status. I wish more network providers had these services. I wish my own network providers provided these services. Statistics seems to be the toughest issue. But also an important one for communicating the state the net with Internet outsiders. AT&T always tells the world how many phone calls were made through its network on Mother's day, or after an earthquake. There are two reasons for this. One is to say how important AT&T is. The second, more important reason, is to help generate a state of mind in their customers why the network may have flaked out on those days. Yes, statistics can lie. But even hard lies are better than hand-waving. And finally, a plea for a common method of notifying a network provider's NOC of a potential problem. If you never hear about the problem, how can you fix it. I understand everyone gives their own customer calls priority. But sometimes even my provider's provider's provider can't figure out how to contact different noc's. noc@somewhere, trouble@whatever, engineer@wherever, action@whoever, etc, etc, etc. My rolodex is crumbling under the weight of keeping track of who works where this week. If folks want to write a Best Common Practice, this is one area that could really use it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: links on the blink (fwd)
by Steven J. Richardson 07 Nov '95

07 Nov '95

>From list-admin(a)merit.edu Sat Nov 4 15:13:10 1995 >Date: Sat, 4 Nov 1995 12:48:36 -0800 (PST) >From: Michael Dillon <michael(a)memra.com> >X-Sender: michael(a)okjunc.junction.net >To: Hans-Werner Braun <hwb(a)upeksa.sdsc.edu> >cc: Mike <mn(a)tremere.ios.com>, nathan(a)netrail.net, nanog(a)merit.edu, > D.Mills(a)cs.ucl.ac.uk >Subject: Re: links on the blink (fwd) >In-Reply-To: <199511041859.KAA08467(a)upeksa.sdsc.edu> >Message-ID: <Pine.LNX.3.91.951104123440.12997A-100000(a)okjunc.junction.net> >On Sat, 4 Nov 1995, Hans-Werner Braun wrote: > >> I will not go into a point by point rebuttal here, even though I >> generally do not subscribe to your arguments. I am not planning on >> "winning" here, I just want to get the issues on the table and evaluate >> the solution space. Just let me ask you, as a customer who fairly >> frequently experiences 10% packet loss between major Internet locations >> across major service providers (no mom and pop shops in the middle or >> at the end points), how would you suggest I deal with that? > >Uh... Ignore it? >10% packet loss is quite within the normal range of parameters for a >packet switching network such as the Internet. If you want 0% packet loss, >you can lease your own private point-to-point lines. Uh... Michael, when we were running the NSFNET, as Hans-Werner and many readers of this list are well aware, we did _not_ accept 10% packet loss on any link or across the network. These problems stayed with the NSFNET NOC until resolution by the provider, MCI. We only considered -0%- loss to be acceptable. Sorry if others also responded to this, Steve Richardson/Merit >Michael Dillon Voice: +1-604-546-8022 >Memra Software Inc. Fax: +1-604-542-4130 >http://www.memra.com E-mail: michael(a)memra.com

3 2

clarification: Re: links on the blink (fwd)
by Curtis Villamizar 07 Nov '95

07 Nov '95

btw, That's 10^-5 packet loss (0.001%). I just got email asking what the units were. I think the acceptance test uses 1000 byte packets. Curtis ------- Forwarded Message Received: from interlock.ans.net (interlock.ans.net [147.225.5.2]) by brookfield.ans.net (8.6.12/8.6.12) with SMTP id AAA18009 for <curtis(a)brookfield.ans.net>; Tue, 7 Nov 1995 00:09:43 -0500 Received: from merit.edu by interlock.ans.net with SMTP id AA29086 (InterLock SMTP Gateway 3.0 for <regional-techsers(a)ans.net>); Tue, 7 Nov 1995 00:09:41 -0500 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.6.12/merit-2.0) with ESMTP id XAA11602; Mon, 6 Nov 1995 23:15:13 -0500 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id XAA17732; Mon, 6 Nov 1995 23:14:47 -0500 Message-Id: <199511070414.XAA17732(a)brookfield.ans.net> To: "Steven J. Richardson" <sjr(a)merit.edu> Cc: hwb(a)upeksa.sdsc.edu, michael(a)memra.com, D.Mills(a)cs.ucl.ac.uk, mn(a)tremere.ios.com, nanog(a)merit.edu, nathan(a)netrail.net Reply-To: curtis(a)ans.net Subject: Re: links on the blink (fwd) In-Reply-To: Your message of "Mon, 06 Nov 1995 15:18:15 EST." <199511062018.PAA08597(a)home.merit.edu> Date: Mon, 06 Nov 1995 23:14:45 -0500 From: Curtis Villamizar <curtis(a)ans.net> In message <199511062018.PAA08597(a)home.merit.edu>, "Steven J. Richardson" write s: > > Uh... Michael, when we were running the NSFNET, as Hans-Werner and > many readers of this list are well aware, we did _not_ accept 10% packet > loss on any link or across the network. These problems stayed with > the NSFNET NOC until resolution by the provider, MCI. We only considered > -0%- loss to be acceptable. Steve, Enough of your wild stories of -0%- loss. :-) The correct figure was 10^-5 for acceptance with 10^-4 being the maximum threshold we would accept on a running circuit before contacting MCI to take the circuit in a maintenance window for diagnostics. That doesn't mean we wouldn't bug MCI to get the circuits back perfectly clean. ;-) We still have the same criteria. I think MCInet is also as vigilant. Curtis ------- End of Forwarded Message

1 0

one typo correction...
by Steve Heimlich 06 Nov '95

06 Nov '95

Change "aggregate" to "advisory" as below. Steve ------- > Date: Mon, 06 Nov 1995 18:43:22 -0500 > From: Steve Heimlich <heimlich(a)kingbee.ans.net> > To: nanog(a)merit.edu > Subject: AS690 policy configuration changes > > > All, > > Starting with Friday morning's config run, AS690 will pick up any > route listed in various routing registries, including both those > routes with advisories and those routes without advisories. > > ANS customers will not be affected by this change. > > Routes without advisories will be examined for origin AS and will > inherit the most popular policy currently used for that AS. For > example, if a route for 147.225/16 (origin AS1660) were listed > without an advisory, we would configure ourselves to listen for > 147.225/16 in the same way that we listen to most other AS1660 > routes (only from AS 1324 in this case). > > If a route is registered in an AS for which we don't have existing > policy, it will not be routed. In the example above, if 147.225/16 > were registered without an aggregate, and it were the only route ^^^^^^^^^ This should be "advisory." [...]

1 0

AS690 policy configuration changes
by Steve Heimlich 06 Nov '95

06 Nov '95

All, Starting with Friday morning's config run, AS690 will pick up any route listed in various routing registries, including both those routes with advisories and those routes without advisories. ANS customers will not be affected by this change. Routes without advisories will be examined for origin AS and will inherit the most popular policy currently used for that AS. For example, if a route for 147.225/16 (origin AS1660) were listed without an advisory, we would configure ourselves to listen for 147.225/16 in the same way that we listen to most other AS1660 routes (only from AS 1324 in this case). If a route is registered in an AS for which we don't have existing policy, it will not be routed. In the example above, if 147.225/16 were registered without an aggregate, and it were the only route registered with origin 1660, then we will not route it. We have a tool which flags such new ASes, and policy toward them will be created regularly. The rate of growth in number of ASes is not high, particularly relative to the rate of growth in number of routes. For now, we will continue to build our policy dynamically from the advisory attributes. Assuming that this hybrid deployment goes well, we intend to freeze our policy and convert to a system which ignores advisories altogether. With this system, the mechanics of shifting policy will be quite easy (essentially involving only ANS). I expect to announce that freeze and shift in the next week or so. At that point, those folks who want to strip AS690 advisories from any database may do so without a problem; as mentioned above, any advisories registered after that time will be ignored. Steve

1 0