- Test - lists.nanog.org

Re: Has PSI been assigned network 1?
by Guy Almes 21 Apr '95

21 Apr '95

Tim, Right on target. > > From: Vadim Antonov <avg(a)sprint.net> > > To: Daniel.Karrenberg(a)ripe.net, avg(a)sprint.net > > Subject: Re: Has PSI been assigned network 1? > > > > Daniel, it shows that you live in the world where > > 1000+ internet service providers isn't reality yet :) > > > > A half of them has to be explained how route announcement > > is different from broadcasting. Forget about good > > citizenship -- they may be willing but they must be > > educated first. > > [...] > > Educated by whom? > > It seems to me that this education is one of the services that small > ISPs ought to expect of their national service providers. > > Conversely, it seems that the rest of the community ought to expect > that national service providers will be responsible for educating > their customers, (e.g., ISPs). > > -tjs After all, if cooperation and education of new customers was important when the Internet was younger, then it's all the more important now. -- Guy

1 0

Config Run on Sunday, April 23 1000EDT
by Elise Gerich 21 Apr '95

21 Apr '95

Merit has rescheduled the configuration run which was postponed on Friday, April 21, 1995 for Sunday, April 23 at 1000 EDT. The originally scheduled configuration window was postponed because the configuration file for ENSS 147 (MAE-East) exceeded 17MB and was corrupt. We had to allocate more filesystem space in order to generate a complete configuration and in addition we worked with ASes 293, 297, 568, 1800 and 3561 to reduce the number of net lists contained in the configuration file. The result is a configuration file of a more reasonable size (9.9MB). The additional activity which was planned for April 21, 1995 was to disable peering sessions between AS 690 and others at the following ENSSes: 128 129 130 131 132 133 134 135 137 139 140 141 142 143 145 This activity has been rescheduled for 0700 EDT on Tuesday, April 25, 1995. Several organizations have taken the initiative to reduce their dependence on the NSFNET Service even though we had to postpone the planned configuration today. Thank you all for taking those actions independently. --Elise

1 0

Re: Has PSI been assigned network 1?
by salo＠msc.edu 21 Apr '95

21 Apr '95

> Date: Fri, 21 Apr 1995 14:45:58 -0400 > From: Vadim Antonov <avg(a)sprint.net> > To: Daniel.Karrenberg(a)ripe.net, avg(a)sprint.net > Subject: Re: Has PSI been assigned network 1? > Cc: nanog(a)merit.edu, rps(a)isi.edu > > Daniel, it shows that you live in the world where > 1000+ internet service providers isn't reality yet :) > > A half of them has to be explained how route announcement > is different from broadcasting. Forget about good > citizenship -- they may be willing but they must be > educated first. > [...] Educated by whom? It seems to me that this education is one of the services that small ISPs ought to expect of their national service providers. Conversely, it seems that the rest of the community ought to expect that national service providers will be responsible for educating their customers, (e.g., ISPs). -tjs

1 0

CERT Advisory - REVISED SATAN Vulnerability: Password Disclosure
by CERT Advisory 21 Apr '95

21 Apr '95

============================================================================= CA-95:07a Revised CERT Advisory April 21, 1995 SATAN Vulnerability: Password Disclosure ----------------------------------------------------------------------------- *** This is a revised CERT advisory.*** It addresses inaccurate information in CA-95:07 and contains information about SATAN 1.1.1. *** Supersedes CA-95:07 *** There was a potential vulnerability introduced into systems running SATAN 1.0 and earlier, as described below. The problem has been addressed in version 1.1 and later. The CERT team recommends that you take the precautions described in Section III below before you run SATAN and that you upgrade to the latest version of SATAN--currently 1.1.1. The following two statements from CA-95:07 are inaccurate. 1. This statement is incorrect: "Note that SATAN 1.1 is expected to check systems for this SATAN 1.0 vulnerability as part of scanning other systems." 2. This statement is misleading: "This vulnerability affects all systems that support the use of SATAN with the HTML interface." For SATAN 1.0 and earlier, whether a system is vulnerable depends on the system configuration, the net browser supporting SATAN, and how SATAN is used. The problem has been solved in later versions of SATAN. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:07a.README We encourage you to check our README files regularly for updates on advisories. For an overview of a beta version of SATAN, see CERT advisory CA-95:06. ----------------------------------------------------------------------------- I. Description In SATAN version 1.0, access to the SATAN processes is protected by a session key (also referred to as a "magic cookie" or "password"). SATAN itself never sends this session key over the network. However, depending on the configuration at your site, the supporting HTML browser, and how you use SATAN, your session key may be disclosed through the network. Local or remote users who obtain your session key can run perl scripts that are on the system running SATAN. If you use SATAN only through the command line interface, your system is not vulnerable to the problem because there is no session key. Additional details are in the "SATAN Password Disclosure" tutorial provided with SATAN. We have included the tutorial as an Appendix B of this advisory. II. Impact If the session key is disclosed while SATAN 1.0 is running, unauthorized local or remote users can execute perl scripts as the user of the process running SATAN (typically root). III. Solution 1. Obtain and install SATAN version 1.1.1, which addresses the problem. For details on how the problem is addressed, see the section entitled "Additional SATAN Defenses" in the SATAN Password Disclosure tutorial. The SATAN authors also provide guidance on protecting access; see the tutorial section, "Preventing SATAN Password Disclosure." SATAN 1.1.1 is available from many sites, including ftp://ftp.win.tue.nl/pub/security/satan-1.1.1.tar.Z ftp://ftp.win.tue.nl/pub/security/satan-1.1.1.README ftp://ftp.win.tue.nl/pub/security/satan-1.1.1.tar.Z.asc MD5 (satan-1.1.1.tar.Z) = de2d3d38196ba6638b5d7f37ca8c54d7 MD5 (satan-1.1.1.README) = 3f935e595ab85ee28b327237f1d55287 MD5 (satan-1.1.1.tar.Z.asc) = a9261070885560ec11e6cc1fe0622243 To locate other sites, you can send mail to majordomo(a)wzv.win.tue.nl and put in the body of the message (not the subject line): get satan mirror-sites There are reports of modified copies of SATAN, so ensure that the copy that you obtain is authentic by checking the MD5 checksum or SATAN author Wietse Venema's PGP signature. Appendix A of this advisory contains his PGP key. We urge you to read the SATAN documentation carefully before running SATAN. 2. We also recommend that you take the following precautions: * Install all relevant security patches for the system on which you will run SATAN. * Execute SATAN only from the console of the system on which it is installed (e.g., do not run SATAN from an X terminal, from a diskless workstation, or from a remote host). * Ensure that the SATAN directory tree is not NFS-mounted (or AFS, etc.) from a remote system. * Ensure that the SATAN directory tree cannot be read by users other than root. * Do not open any URLs outside your own system and site while running the browser started by SATAN. For example, do not use previously stored URLs such as those found in bookmarks and pull-down menus. ------------------------------------------------------------------------------ The CERT Coordination Center staff thanks Wietse Venema for his cooperation and assistance with this revised advisory. ------------------------------------------------------------------------------ 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 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 E-mail: 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 advisories, CERT bulletins, 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 noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. ------------------------------------------------------------------------------ Appendix A: Wietse Venema's PGP Key -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAirDhV8AAAED/i4LrhQ/mwOgam8ZfQpEcxYoE9kru5oRDGtoVeKae/4bUver aGX7qVtskD6vwPwr2FF6JW2c+z2oY4JGPGUArORiigoT82/q6vqT0Wm1jIPsXQSB ZCkBoyvBcmXEi+J7eDBbWLPDxeDimgrORbAIQ4uikRafs8KlpNyA8qbVMny5AAUR tCV3aWV0c2UgdmVuZW1hIDx3aWV0c2VAd3p2Lndpbi50dWUubmw+ =PQUu -----END PGP PUBLIC KEY BLOCK----- ------------------------------------------------------------------------------ Appendix B: Tutorial - SATAN Password Disclosure The following tutorial can be found in satan-1.1.1/html/tutorials/vulnerability/SATAN_password_disclosure.html SATAN Password Disclosure SUMMARY SATAN password disclosure via flawed HTML clients or environmental problems IMPACT Unauthorized users may execute commands through SATAN BACKGROUND By default, SATAN runs as a custom HTML (hypertext markup language) server, executing requests from a user-provided HTML browser, or client program. Examples of common HTML clients are Netscape, NCSA Mosaic and Lynx. An HTML client request is nothing but a network message, and network messages may be sent by any user on the network. To defend itself against requests from unauthorized users, SATAN takes the following precautions: * SATAN generates a session key, to be used as a secret password, each time it starts up an HTML client. The session key is in the form of a 32-byte quasi-random number. The number is called quasi-random because it is impossible to generate real random numbers using only software. * SATAN creates HTML files with the secret password embedded in URL (uniform resource locator) links. The HTML file access permissions are restricted to the owner of the SATAN process (and the superuser). * SATAN rejects HTML requests whose URL does not contain the current SATAN password. This requirement prevents access by unauthorized clients, provided that the current SATAN password is kept secret. The protection scheme used by SATAN is in essence the same as the scheme used by many implementations of the X Window system: MIT magic cookies. These secrets are normally kept in the user's home directory, in a file called .Xauthority. Before it is granted access to the screen, keyboard and mouse, an X client program needs to prove that it is authorized, by handing over the correct magic cookie. This requirement prevents unauthorized access, provided that the magic cookie information is kept secret. THE PROBLEM It is important that the current SATAN password is kept secret. When the password leaks out, unauthorized users can send commands to the SATAN HTML server where the commands will be executed with the privileges of the SATAN process. Note that SATAN generates a new password everytime you start it up under an HTML client, so if you are suspicious, simply restart the program. SATAN never sends its current password over the network. However, the password, or parts of it, may be disclosed due to flaws in HTML clients or due to weak protection of the environment that SATAN is running in. One possible scenario for disclosure is: * When the user selects other HTML servers from within a SATAN session, some HTML client programs (Netscape and Lynx) disclose the current SATAN URL, including SATAN password information. The intention of this feature is to help service providers find out the structure of the world-wide web. However, the feature can also reveal confidential information. With version 1.1 and later, SATAN displays a warning when the HTML client program exhibits this questionable (i.e. stupid) feature. Other scenarios for SATAN password disclosure are discussed in the next section, as part of a list of counter measures. PREVENTING SATAN PASSWORD DISCLOSURE The security of SATAN is highly dependent on the security of environment that it runs in. In the case of an X Window environment: * Avoid using the xhost mechanism, but use xauth and MIT magic cookies or better. Otherwise, unauthorized users can see and manipulate everything that happens with the screen, keyboard and mouse. Of course, this can also be a problem when you are not running the SATAN program at all. Steps that can help to keep the X magic cookie information secret: * Avoid sharing your home directory, including .Xauthority file, with other hosts. Otherwise, X magic cookie information may be captured from the network while the X software accesses that file, so that unauthorized users can take over the screen, keyboard and mouse. * Avoid running X applications with output to a remote display. Otherwise, X magic cookie information can be captured from the network while X clients connect to the remote display, so that unauthorized users can take over the screen, keyboard and mouse. Finally, steps that can help to keep the current SATAN password secret: * Avoid sharing the SATAN directories with other hosts. Otherwise, SATAN password information may be captured from the network while the HTML software accesses passworded files, so that unauthorized users can take over the SATAN HTML server. * Avoid running SATAN with output to a remote display. Otherwise, SATAN password information can be captured from the network while URL information is shown on the remote display, so that unauthorized users can take over the SATAN HTML server. ADDITIONAL SATAN DEFENSES The SATAN software spends a lot of effort to protect your computer and data against password disclosure. With version 1.1 and later, SATAN even attempts to protect you after the password has fallen into the hands of unauthorized users: * SATAN displays a warning and advises the user to not contact other HTML servers from within a SATAN session, when it finds that the HTML client program reveals SATAN password information as part of parent URL information. * SATAN rejects requests that appear to come from hosts other than the one it is running on, that refer to resources outside its own HTML tree, or that contain unexpected data. * SATAN terminates with a warning when it finds a valid SATAN password in an illegal request: SATAN assumes the password has fallen into the hands of unauthorized users and assumes the worst.

1 0

Subnetting a Class A Experiment
by postel＠ISI.EDU 21 Apr '95

21 Apr '95

Hi. This Experiment begins 1 May 95 and ends 1 Dec 95. --jon. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There appears to be some interest in experimenting with subnetting the class A addresses. There is some evidence that not all the routing software in use will deal correctly with subnetted class A addresses. It also appears that actual use of subnetted class A addresses may be necessary in the not too distant future. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. To further this experiment the IANA will temporarily designate the class A network number 39 to be used in the following way: The high order octet of the 4-octet IPv4 address is the class A network number 39. There are two cases for low order 24 bits. Case 1: In the first case, the high order bit of these 24 bits is zero and the next 15 bits are the low order 15 bits of a previously assigned Autonomous System number (AS), as registered by a network registry and listed in the RWhois database system. Using the AS number in this way allows the experiment to get underway quickly in that it automatically allocates some addresses to each service provider and does not require a registration step. One concern is that this might cause a run on AS numbers, since by getting an AS number you automatically get some address space. This concern should be offset by the fact that the amount of address space one gets under this plan is the same as one class C network number (and it should be easier to get a single class C allocated than to get an AS number allocated), and that this is a limited time experiment so that these addresses will be temporary. The low order octet of the 4-octet IPv4 address is for local use. It is expected that an address of this form will be use to identify a specific publicly accessible Internet host. +--------+-+-------+--------+--------+ | 39 |0| low 15 bits AS | local | +--------+-+-------+--------+--------+ Case 2: In the second case, the high order bit of these 24 bits is one, and the remaining 23 bits are assigned by the IANA (currently reserved for future use). +--------+-+-------+--------+--------+ | 39 |1| variable prefix + local | +--------+-+-------+--------+--------+ The general intent is to find a way to assign to experimenters prefixes of differing lengths so that a variety of experiments can be conducted with the prefix/local-address boundary at different points. It is not intended that either of these address allocation schemes is the model for how subnetted class A addresses will be actually allocated in the future. It is expected, to make the experiment interesting, that some providers will use these addresses for servers supplying popular material via the Web or FTP. For example, if the service provider registered to use AS 690 wished to use this style of address to provide access to a server of popular information on local host 7, the address would be: +--------+--------+--------+--------+ | 39 | 2 | 178 | 7 | +--------+--------+--------+--------+ The support for DNS name and address resolution should be provided. For example, if Alternet wanted to put up a database of interesting information using the hostname "Interesting.Alter.Net" using the address 39.2.189.7, they would need to put the name to address mapping in their name server using the A record Interesting.Alter.Net. IN A 39.2.189.7 Similarly the address to name PTR record should be supported 7.189.2.39.IN-ADDR.ARPA. PTR Interesting.Alter.Net. which means that the 189.2.39 branch of the IN-ADDR tree would be delegated to Alternet for the purposes of this experiment. To support this, the 39.IN-ADDR.ARPA branch is delegated to the IANA to be managed at ISI. The nameserver for this branch is IN-ADDR.EP.NET (39.17.199.10). Participants in this experiment should contact the administrator of this nameserver to have their portion of the address space further delegated. The administrator for this server can be reached at <aexpreg(a)isi.edu>. Another aspect of the testing that should be performed is to have providers interchange addresses to test the portability of subnetted class A addresses. It is not intended that this would be the model for actual use. For example, if AS 690 and AS 1800 want to try out routing holes in each others' allocations within their AS, that should be encouraged. That is, suppose AS 690 handed some address of their addresses to AS 1800, and vice-versa. This type of testing will be necessary to see if the addresses can be made portable in larger sub-A allocations. This is experiment will be of limited duration and these addresses may be reassigned to other uses when the experiment is over. This experiment will begin on 1-May-95. The current date for the termination of this experiment is 1-Dec-95. --jon. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Re: Has PSI been assigned network 1?
by Guy Almes 21 Apr '95

21 Apr '95

Daniel, Exactly. Your posting reminds me of several things: <> The Internet is a fundamentally cooperative enterprise. While we all look forward to the increasing advantages of it *also* being a highly competitive enterprise, we have to remind ourselves that it remains fundamentally cooperative. <> We in the states have benefited from the Merit PRDB effort during the last (almost) seven years. Although the PRDB has become obsolete with the rise of the current multi-backbone/exchange-point architecture, we should understand the historic contribution of the Merit PRDB effort. <> During those seven years, the RIPE community understood that, even lacking a central backbone architecture, a routing database was valuable as a means of allowing independent competitive Internet efforts in Europe to cooperate technically in a way that promoted the growth and quality of the Internet in Europe. <> We in the States often overlook the fact that the RIPE routing database effort has succeeded in a European climate that was and is highly competitive and often contentious. We in the States need to (continue to) learn that technical cooperation is essential *especially* when business competition is present. <> Every effort should be made by providers and users to help the (national and international) Routing Registry to succeed. <> While I wouldn't term the RS as an 'enforcer', I would assert that the quality of the RS will promote the acceptance and usefulness of the RR effort generally. -- Guy > > > Vadim Antonov <avg(a)sprint.net> writes: > > > > Routing Registry w/o means to enforce won't be able to keep > > a resemblance of accurate data (not with the modus operandi of > > most providers in US). > > We fundamentally disagree here. > > I agree that the more the RR is used for actual configurations, > the better the data will be. > > I disagree that "enforcement" is necessary. > > I disagree that "enforcement" by RS is necessary. > > I observe that reasonable quality data can be gathered even when > the only incentive is good citizenship and nice diagnostic tools. > > Daniel >

1 0

Re: Has PSI been assigned network 1?
by Vadim Antonov 21 Apr '95

21 Apr '95

>There is no intention of "replacing distributed computation" >with this. Do not confuse the Routing Registry with Route Servers. Routing Registry w/o means to enforce won't be able to keep a resemblance of accurate data (not with the modus operandi of most providers in US). The only feasible way to enforce it now is to use RS. RS does not support policies we need now. Hence it will be used for a very limited set of applications. Ergo, most of data in RR will be inaccurate and out of date. >Although the registry "box is not controlled by the service providers", >the content is! If RS breaks down and takes my operations with it what my management going to say? "Could the network work without it?" "Yes." "Then take it away from our configurations NOW!" --vadim

3 2

POSTPONED - NSFNET configuration
by Elise Gerich 21 Apr '95

21 Apr '95

Due to the number off changes that had to be made in the configuraton files for Friday, April 21, 1995, some of the files grew so large that they would truncate during production producing corrrupt configuration files. At this time of the evening/morning we do not have confidence that we will be able to have complete and correct configuration files produced in time for the normal configuration window. We are thereby postponing the Friday, April 21 configuration until Saturday. This means that the discontinuation of the NSFNET service that was planned for Friday, April 21 at 0900 EDT is also postponed. We anticipate rescheduling the test for Monday, April 24, and will notify the community of more concrete plans by 1300 EDT on Friday, April 21. --Elise

1 0

Chicago NAP Status
by mak＠aads.net 21 Apr '95

21 Apr '95

Chicago NAP Status April 21, 1995 Mark Knopper Ameritech Advanced Data Services General Status: The "Contingency Plan" FDDI configuration at the Chicago NAP is operational now. At the downtown Chicago site, AADS has purchased and installed routers for ANS, MCI and Sprint to support the NSFNET transition. MCI and ANS are peering and exchanging production traffic across the local FDDI. The Routing Arbiter's route server is also attached to this FDDI. The Sprint circuit order is still in progress. These FDDI-attached routers are also all attached to the ATM switch at DS-3. (The routers are cisco 7010 and the ATM switch is AT&T GCNS-2000.) The Kentrox ATM DSU buffer overflow bugs have been fixed with a new revision of the hardware. All ADSUs have been upgraded. NAP Customer Status: AGIS (circuit being installed - DS3 ATM) Alpha Net (connected - DS3 ATM to Milwaukee site) ANS (connected - DS3 ATM + FDDI) Argonne National Laboratory (connected - DS3 ATM, upgrading to OC3c) B3 (letter of intent received - DS3 ATM) Databank (circuit being installed - DS3 ATM) Fermi National Laboratory (connected - DS3 ATM) ISI/Merit Routing Arbiter (connected - DS3 ATM + FDDI) MCI Internet(connected - DS3 ATM + FDDI) MCI vBNS (circuit being installed - DS3 ATM) NETCOM On-line (circuit being installed - DS3 ATM) Network 99 (circuit being installed - DS3 ATM) Sprint (stated intent - DS3 ATM + FDDI) University of Chicago (connected - DS3 ATM) University of Illinois at Chicago (order in process - OC3c ATM) Inquiries: AT&T Bell Northern Research Compuserve Computer Masters International Concentric Research Hyperspace Computers IBM Global Network Iowa Network Services MC**2 RustNet Sprint ATM Backbone Wiltel Monitoring: Via AADS Network Operations Center, Southfield MI. Peering and Transit Agreements: Chicago NAP customers have begun meeting monthly, and are working on a multi-lateral peering agreement. This will allow mutual exchange of routes to customer networks. Also, many regional (ie. single NAP-connected) providers are working on establishing transit agreements with national (ie. multi-connected) providers. Recent Events: Argonne, Fermi and University of Chicago have upgraded from their DS3 SMDS trial to ATM NAP connections. Fermi and UOC will remain at DS3, while Argonne will upgrade to OC3c. In addition, University of Illinois at Chicago is connecting at OC3c. The AT&T switch has been upgraded with new port cards, for greater buffering capability and a new software revision. Next Steps: Many circuit installations are in progress and new orders are being taken. Peering agreements should allow many new ATM PVCs to be established. Ongoing testing of router, DSU and switch performance is occuring at the AADS lab in Hoffman Estates, IL. Bellcore is testing the cisco DS3 AIP card. It is expected that the DS3 AIP will be the next upgrade step for NAP customers, as it supports rate shaping and eliminates the ADSU. The contingency plan routers and FDDI will remain in place for at least 6 months, or until the ATM performance is proved to be satisfactory. For More Information Please contact nap-info(a)aads.net for inquiries or to place orders. ------------

1 0

Re: The plan - April 21, 1995
by salo＠msc.edu 21 Apr '95

21 Apr '95

> Date: Thu, 20 Apr 1995 18:42:49 -0400 > From: Elise Gerich <epg(a)merit.edu> > To: members(a)farnet.org, nanog(a)home.merit.edu, nwg(a)home.merit.edu, > ripe-list(a)ripe.net > Subject: The plan - April 21, 1995 > Cc: net-eng-aa(a)ans.net > [...] > These sessions will be disabled on April 21, 1995 at 0900 EDT. > > > City ENSS# Associated AS# > ----------------------------------------------------------------------------- > [...] > Champaign, IL 129 555 MSC > 698 UIRnet > 1225 CICnet > [...] MSCNet (AS555) migrated from ENSS 129 to SprintLink several months ago and all of the associated equipment was removed. I believe we notified Merit December 30, (which I think was prior to the announcement of the "first" midlevel migration...) -tjs

1 0