- Test - lists.nanog.org

Re: The CIX and the NSFNET regionals - a dilemma
by zawada＠ncsa.uiuc.edu 11 Feb '92

11 Feb '92

> > Right now the performance of the NSFnet is pretty bad (even the T3 > network performance is worse than a CIX provided connection) so you > are probably doing your customers a service by using the CIX to route > packets instead of the NSFnet. But let's look into the future where > ANS finally gets its technical act together and the T3 NSFnet really > starts to hum. Add in much greater use of the CIX and I can see an > inverted picture where the CIX is more of a bottleneck than the > NSFnet. Really? What do you base your assertions on? I can tell you right now that the NSFNET T3 backbone has come a long, long way since last October. (Mark Knopper and his gang must have been in hell back then!) The reliablity has been extremely good. I will admit that the traffic probably isn't taking full advantage of the speed of the T3 pipes right now, but the upgrade of the T3 cards in the NSSes will hopefully improve that situation. The throughput is still definitely higher than a T1 though... So, are there people still having problems with the T3 backbone? I have failed to see any evidence that "the NSFnet is pretty bad," at least worse than a CIX T1 connections. --zawada __

4 8

Additions to the NSFNET policy-based routing database -- postponed
by Steven K. Widmayer 11 Feb '92

11 Feb '92

Due to problems with the operating system used to generate the NSFNET routing configuration files, the normal Tuesday morning update has been rescheduled for Wednesday morning during the 05:00 - 08:00 EST window. Apologies for any inconvenience this delay will cause. --Steve Widmayer Merit/NSFNET

1 0

CERFnet Weekly Report for the week of Monday, February 3, 1992.
by Donna Bigley 10 Feb '92

10 Feb '92

############################################################################### This is the CERFnet weekly activity report for the period of Monday, February 3rd through Sunday, February 9th, 1992. This report is also available through anonymous FTP from NIC.CERF.NET [192.102.249.3] in the cerfnet/cerfnet_stats subdirectory. The filename is: 9-february-92.txt All times are in Pacific Standard Time, and in the 24-hour format. Please direct any questions or comments to: donnab(a)cerf.net or help(a)cerf.net ****************************************************************************** NETWORK OUTAGES: SITE: KOREA SITES AFFECTED: KOREA TIME STARTED: MON. 1-27-92 10:08 TIME ENDED: FRI. 2-7-92 23:23 TIME ELAPSED: 12 days 13 hours 15 min (Intermittant Outages) REASON: Link Failure (Korea Local Line Problem) SITE: DATAPRODUCTS SITES AFFECTED: DATAPRODUCTS TIME STARTED: TUE. 2-4-92 09:00 TIME ENDED: TUE. 2-4-92 15:22 TIME ELAPSED: 6 hours 22 min REASON: Link Failure SITE: QUALCOMM SITES AFFECTED: QUALCOMM TIME STARTED: TUE. 2-4-92 09:58 TIME ENDED: WED. 2-5-92 10:20 TIME STARTED: WED. 2-5-92 10:36 TIME ENDED: WED. 2-5-92 10:50 TIME ELAPSED: 24 hours 36 min REASON: Equipment Trouble SITE: UCLA SITES AFFECTED: UCLA Dial n' CERF, UCSB, ISX, Dataproducts, Santa Monica College, Quotron, Pepperdine, and Los Nettos. TIME STARTED: THU. 2-6-92 07:38 TIME ENDED: THU. 2-6-92 07:40 TIME ELAPSED: 2 min REASON: CERFnet Scheduled Maintenance SITE: CERFnet SITES AFFECTED: CERFnet TIME STARTED: THU. 2-6-92 12:00 TIME ENDED: THU. 2-6-92 15:30 TIME ELAPSED: 3 hours 30 min REASON: Routing Troubles SITE: CICESE SITES AFFECTED: CICESE TIME STARTED: THU. 2-6-92 15:28 TIME ENDED: THU. 2-6-92 16:30 TIME ELAPSED: 1 hour 2 min REASON: Unknown SITE: QUALCOMM SITES AFFECTED: QUALCOMM TIME STARTED: THU. 2-6-92 18:35 TIME ENDED: FRI. 2-7-92 06:51 TIME ELAPSED: 12 hours 16 min. REASON: Equipment Trouble SITE: UCLA SITES AFFECTED: UCLA Dial n' CERF, UCSB, ISX, Dataproducts, Santa Monica College, Quotron, Pepperdine, and Los Nettos. TIME STARTED: FRI. 2-7-92 10:14 TIME ENDED: FRI. 2-7-92 10:32 TIME ELAPSED: 18 min REASON: CERFnet Scheduled Maintenance SITE: UCOP SITES AFFECTED: UCOP Dial n' CERF, CIX-WEST, Cisco, Farallon, Apple, Intel-SC, LSIL, and NetLabs. TIME STARTED: SAT. 2-8-92 09:48 TIME ENDED: SAT. 2-8-92 16:19 TIME ELAPSED: 7 hours 11 min REASON: Site Scheduled Maintenance SITE: UCR SITES AFFECTED: UCR TIME STARTED: SUN. 2-9-92 00:06 TIME ENDED: SUN. 2-9-92 00:38 TIME ELAPSED: 32 min REASON: Unknown ------------------------------------------------------------------------ CERFNET TRAFFIC CAPACITY USAGE AT EACH CIRCUIT LINK LINK SPEED CAPACITY PEAK HOUR (PDT) SDSC/CALTECH 1.544 mbps 11.4% 19:00 SDSC/UCI 1.544 mbps 04.8% 11:00 SDSC/UCLA 1.544 mbps 05.2% 16:00 SDSC/UCOP 1.544 mbps 03.7% 16:00 UCI/UCLA 1.544 mbps 10.0% 20:00 SDSC/UCR 512 kbps 02.9% 17:00 UCLA/UCSB 512 kbps 08.1% 16:00 SDSC/AGI 1.544 mbps 00.1% 12:00 SDSC/BIOSYM 1.544 kbps 00.2% 12:00 SDSC/GA 1.544 mbps 00.1% 13:00 SDSC/GD 1.544 mbps 02.1% 10:00 SDSC/SAIC 1.544 mbps 10.0% 13:00 SDSC/SCAQMD 1.544 mbps 00.02% 10:00 SDSC/SDSU 1.544 mbps 01.2% 20:00 UCI/CSU CO(SWRL) 1.544 mbps 02.1% 20:00 UCOP/APPLE 1.544 mbps 00.7% 09:00 UCOP/CISCO 1.544 mbps 00.4% 08:00 UCR/LLUMC 1.544 mbps 00.01% 09:00 CALTECH/CADAM 56 kbps 00.6% 16:00 CALTECH/CLAREMONT 56 kbps 18.7% 14:00 CALTECH/DISNEY 56 kbps 03.4% 07:00 CALTECH/OXY 56 kbps 04.8% 15:00 SDSC/AJS 56 kbps 02.1% 16:00 SDSC/KOREA 56 kbps 04.0% 16:00 SDSC/QUALCOMM 56 kbps 07.6% 14:00 SDSC/SCIH 56 kbps 05.6% 01:00 SDSC/USD 56 kbps 06.0% 17:00 SDSC/USIU 56 kbps 01.9% 11:00 SDSC/XEROX 56 kbps 00.9% 08:00 UCI/CMD 56 kbps 05.3% 20:00 UCI/EMULEX 56 kbps 01.3% 15:00 UCI/FULLERTON 56 kbps 01.8% 13:00 UCI/HUGHES 56 kbps 10.6% 15:00 UCI/MTI 56 kbps 03.5% 19:00 UCI/SPARTA 56 kbps 04.4% 05:00 UCI/UNOCAL 56 kbps 08.3% 05:00 UCLA/ISX 56 kbps 00.8% 13:00 UCLA/PEPPERDINE 56 kbps 01.7% 07:00 UCLA/QUOTRON 56 kbps 08.4% 13:00 UCLA/SMC 56 kbps 01.1% 19:00 UCOP/FARALLON 56 kbps 03.2% 10:00 UCOP/INTEL 56 kbps 12.4% 15:00 UCOP/LSIL 56 kbps 07.7% 22:00 UCOP/NETLABS 56 kbps 20.1% 19:00 ------------------------------------------------------------------------------ SITE CISCO BOX UPTIME SINCE LAST REBOOT (as of 00:15 PST on Feb. 10, 1992): CERFnet BACKBONE CALTECH [131.215.139.253] Up: 11 days 16 hours 29 minutes SDSC Drzog [132.249.16.13] Up: 57 days 08 hours 25 minutes SDSC Hang10 [132.249.16.15] Up: 03 days 09 hours 52 minutes [Routing Troubles] UCI [128.200.1.101] Up: 31 days 16 hours 07 minutes UCLA [128.97.130.10] Up: 02 days 13 hours 42 minutes [CERFnet Scheduled Maintenance] UCOP [134.24.52.112] Up: 01 days 08 hours 57 minutes [Site Scheduled Maintenance] UCR [134.24.108.105] Up: 86 days 12 hours 36 minutes CERF 1544 AGI [134.24.202.110] Up: 44 days 17 hours 54 minutes APPLE [134.24.70.200] Up: 105 days 06 hours 15 minutes BIOSYM [134.24.57.200] Up: 07 days 06 hours 48 minutes CISCO Systems [134.24.54.200] Up: 68 days 14 hours 09 minutes CSUCO/SWRL [130.150.102.200] Up: 26 days 12 hours 46 minutes GA [134.24.221.200] Up: 09 days 16 hours 37 minutes GD [134.24.60.200] Up: 39 days 04 hours 14 minutes LLUMC [134.24.208.200] Up: 82 days 12 hours 22 minutes SAIC [134.24.53.208] Up: 36 days 08 hours 34 minutes SCAQMD [134.24.234.200] Up: 52 days 14 hours 27 minutes SDSU [192.77.100.101] Up: 62 days 16 hours 31 minutes UCSB [134.24.107.107] Up: 82 days 07 hours 38 minutes CERF 56 AJS [134.24.225.101] Up: 23 days 14 hours 17 minutes CADAM [134.24.229.200] Up: 05 days 13 hours 01 minutes [Site Activity] CLAREMONT [134.24.206.109] Up: 04 days 12 hours 32 minutes [Site Activity] CMD [134.24.218.200] Up: 13 days 13 hours 14 minutes DATAPRODUCTS [134.24.211.104] Up: 16 days 15 hours 19 minutes DISNEY [134.24.207.211] Up: 11 days 00 hours 33 minutes EMULEX [134.24.209.212] Up: 57 days 15 hours 48 minutes FARALLON [134.24.56.200] Up: 02 days 06 hours 24 minutes [Unknown] FULLERTON [134.24.214.217] Up: 55 days 15 hours 33 minutes HUGHES [134.24.204.200] Up: 87 days 07 hours 21 minutes INTEL [134.24.55.200] Up: 43 days 03 hours 19 minutes LSIL [134.24.72.200] Up: 01 days 13 hours 08 minutes [Site Activity] MTI [134.24.216.100] Up: 37 days 13 hours 39 minutes NETLABS [134.24.71.200] Up: 65 days 15 hours 07 minutes OXY [134.24.205.108] Up: 06 days 17 hours 13 minutes [Unknown] PEPPERDINE [134.24.203.218] Up: 36 days 13 hours 24 minutes QUALCOMM [134.24.200.201] Up: 02 days 17 hours 23 minutes [Equipment Trouble] QUOTRON [134.24.230.202] Up: 76 days 13 hours 44 minutes SANTA MONICA [134.24.210.219] Up: 31 days 01 hours 22 minutes SCI-HOR [134.24.109.205] Up: 73 days 11 hours 15 minutes SERI/KOREA [134.24.223.200] Up: 139 days 00 hours 00 minutes SPARTA [134.24.215.200] Up: 23 days 14 hours 57 minutes UNOCAL [134.24.217.200] Up: 18 days 14 hours 24 minutes USD [134.24.201.106] Up: 11 days 15 hours 45 minutes USIU [134.24.222.215] Up: 218 days 17 hours 07 minutes XEROX [134.24.51.207] Up: 102 days 23 hours 22 minutes DIAL n' CERF DNC-SDSC [134.24.1.2] Up: 26 days 04 hours 51 minutes DNC-UCI [134.24.2.2] Up: 33 days 03 hours 24 minutes DNC-UCLA [134.24.3.2] Up: 18 days 12 hours 38 minutes DNC-CALTECH [134.24.4.2] Up: 11 days 16 hours 28 minutes DNC-UCOP [134.24.5.2] Up: 01 days 08 hours 58 minutes [Site Scheduled Maintenance]

1 0

Merit NOC manager position
by mak 10 Feb '92

10 Feb '92

Hi. Dale Johnson is moving to a different position at Merit, the "Network Management Systems" group manager. So this opens up the following position, FYI. Mark The University of Michigan and Merit Network, Inc. are seeking applications for the position of Network Operations Center Manager. The NOC is located at the University of Michigan, and the candidate will be employed by the University. Send applications to Tina Pryor, ITD-Resource Administration, University of Michigan, 519 W. William, Ann Arbor, MI 48109. The University of Michigan is an equal opportunity employer. Refer to the University's posting number: A-121032-TP ---------------------------------------------------------------- TITLE: Manager, Information Technology Division-Network Operations Center BASIC FUNCTION Provide management, leadership and vision in network operations for national, state, and campus networking within The University of Michigan-ITD Network Systems, including UMnet, MichNet, and the NSFNET and ANS networks. The primary focus of the Network Operations Center is hour-to-hour and day-to-day operations of the various networks, including the development and reliable execution of standard operating procedures in a 24-hour per day, 7 day per week operations environment. The Center also manages large amounts of critical configuration information, and production of routine reports on Network Performance. CHARACTERISTIC DUTIES Provide leadership and management of the Network Operations Center. Produce and guarantee reliable execution of Center responsibilities, given the resources available. Arrange for new procedures to meet the operational requirements of rapidly changing technology. Define the support needs for the Network Operations Center. Work with the Center's customers and engineering support groups to establish their operational needs. Arrange for resources to meet those needs. Respond to network and Operations Center emergencies as needed on a twenty-four hour basis. Evaluate and report on the Center's technical performance for administrative and customer audiences. Coordinate projects with other groups and managers in Network Systems and the with the Center's vendors and corporate partners. Develop staffing plans and goals, hire and train new staff, assign and prioritize projects, promote professional development and provide general functional and administrative supervision of Network Operations Center staff to meet unit objectives. Represent the Network Operations Center, Merit, and the University of Michigan on national and international committees, standards bodies, and other appropriate organizations, including providing leadership of such groups. Present the Network Operations Center, Merit, and the Networks to varied audiences via tours, lectures, and other presentations. Arrange for maintenance and physical improvements to the Network Operations Center facility. QUALIFICATIONS A Bachelor's degree in computer science, electrical engineering, applied mathematics or other related discipline. A Master's degree or an equivalent combination of education and experience is preferred. Significant knowledge and experience in the Internet and Unix environments, including knowledge and experience in managing networks using the TCP/IP protocol suite is required. Considerable knowledge of and five years experience in data networking. Three years of operations coordination experience is required, with at least two at a staff management level preferred. Ability and vision to supervise the design and coordination of large scale, complex projects, establish goals, and meet objectives is required. Ability to communicate well with technical and administrative people, and work cooperatively with staff, peer managers and upper management is required. Ability to delegate responsibility and be accessible to technical staff is required. Active participation in networking organizations at a national level is desirable. Three or more years of computer programming experience is desirable. Commitment to quality operations and a vision of the future is required.

1 0

Additions to the NSFNET policy-based routing database
by Belinda Sue Blair 07 Feb '92

07 Feb '92

The following networks have been added to the NSFNET policy-based routing database: T1 Network: Net # Net Name Primary Secondary Location -------- ----------- ------- --------- -------- 192.146.147 DGSD 195 Digital Sound Corporation, 6307 Carpinteria Ave., Carpinteria, CA 93013, USA 192.146.101 LEXMARK-DMZ 750 756 Lexmark International Inc., 740 New Circle Road, Northwest, Lexington, KY 40511, USA 192.138.207 CRIC-NET 560 281 Collaborative Research Incorporated, 1365 Main Street, Waltham, MA 02154, USA 192.138.179 NEMC-NET3 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.178 NEMC-NET2 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.177 NEMC-NET1 1384 1383 Tufts University, 169 Holland Street, Somerville, MA 02144, USA 192.138.168 UTEXAS-MSI 281 114 University of Texas at Austin, Marine Science Institute at Port Aransas, 750 Channel View Drive, Port Aransas, TX 78373, USA 192.138.161 STEDWARDS 280 114 St. Edwards University, 3001 S. Congress Ave., Austin, TX 78704, USA 192.136.128 LABCOM-IG 184 164 US Army Laboratory Command, US Army LABCOM, 2800 Powder Mill Rd., Adelphi, MD 20772, USA 192.136.127 WSMR-NET13 164 184 USAISC-TWS-V, Commander, USAISC-WS, White Sands Missle Range, NM 88002, USA 192.136.126 WSMR-NET12 164 184 US Army Atmospheric Sciences Lab, Commander/Director, US Army Atmospheric Sciences Lab, SLCAS-D, WSMR, NM 88002, USA 192.136.125 WSMR-NET11 164 184 USAISC-TWS-V, Commander, USAISC-WS, White Sands Missle Range, NM 88002, USA 192.136.124 MCPH-NET4 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.123 MCPH-NET3 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.122 MCPH-NET2 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 192.136.121 MCPH-NET1 184 164 DAIG, HQDA, Attn: SAIG-IR, Washington, DC 20310-1730, USA 134.184 VUB-ULB 590 Vrije Universiteit Brussel + Universite Libre de Bruxelles, Rekencentrum; Pleinlaan 2; B-1050 Brussels, BELGIUM 132.209 UQTR-IP-NET 603 601 Universite du Quebec a Trois-Rivieres, 3351 Boulevarde Des Forges, Quebec G9A 5H7, CANADA 192.135.195 NT02 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 192.135.194 NT01 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 192.82.158 VMU-NET 590 Veterinaermedizinische Universitaet Wien, EDV-Zentrum; Linke Bahngasse 11; A-1030 Wien, AUSTRIA 192.71.193 UHA-LAN 1238 701 University Council (UHA), UHA, Box 45501, S-104 30 Stockholm, SWEDEN 192.31.114 DRINET 200 201 Novell, Inc., 2180 Fortune Drive, San Jose, CA 95131, USA 157.238 SESQUI-2 114 280 Rice University-Sesquinet, 6100 South Main, Houston, TX 77251, USA 156.106 ITU-GVA-1 590 1238 International Telecommunications Union, Place de Nations, CH-1211 Geneva 20, SWITZERLAND 156.26 SHOCKNET 93 Wichita State University, 1845 Fairmount, Wichita, KS 67208-1595, USA 192.112.84 AGSIMNET 210 209 American Graduate School of International Management, 15249 North 59th Avenue, Glendale, AZ 85306, USA 192.109.58 FRIEDE 701 1238 Friede Beratungsgesellschaft mbH, Westendstr. 117, D-W-8000 Muenchen 2, GERMANY 192.109.31 EMBNET-HH 293 291 n/a, GERMANY 192.92.69 INFOLAN 174 Infonet, Inc., 2100 E. Grand Avenue, M/S B237, P.O. Box 1022, El Segundo, CA 90245, USA 192.135.215 NTBNR 114 280 Northern Telecom/Bell Northern Research, 2201 Lakeside, Richardson, TX 75081, USA 192.135.196 NT03 1238 701 Norwegian Telecom Research, NTR, P.O box 83, N-2007 Kjeller, NORWAY 155.222 RIA-6-NET 164 184 USAISC-AMCCOM, Attn: ASQNC-ARI-IOC-N, Rock Island Arsenal, Rock Island, IL 61299-7210, USA 152.88 DDETH 590 1238 EMA-EAWAG, Ueberlandstrasse 129/133, CH-8600 Duebendorf, SWITZERLAND 147.191 USWSIS 209 210 US West Inc., 9785 Maroon Circle #160, Englewood, CO 80112, USA 144.197 LADC 174 750 Lockheed Advanced Development Company, P.O. Box 250, Plant B6 Building 311, Sunland, CA 91041-3702, USA 142.76 SUNNYBROOK 601 602 Sunnybrook Health Science Centre, Rm S-131, 2075 Bayview Ave., North York, Ontario M4N 3M5, CANADA 141.61 MPIB-NET 293 291 Max-Planck-Institut fuer Biochemie , Rechenzentrum Am Klopferspitz D-W- 8033 Martinsried, GERMANY 192.88.203 PGWKS 701 279 PageWorks, 36 John F. Kennedy Street, Cambridge, MA 02138, USA 192.86.8 MUSE-ETHER2 200 754 MicroUnity Systems Engineering, Incorporated, 4699 Old Ironsides, Suite 410, Santa Clara, CA 95054, USA 192.84.1 BBN-SYSENGRC1 1384 1383 BBN Communications, 150 Cambridge Park Drive, Cambridge, MA 02140, USA 192.136.41 TREVANO 590 1238 Scuola Tecnica Superiore, CH-6952 Canobbio, SWITZERLAND Total NSFNET T1 announced networks: 4601 T3 Network: Network IP: 192.31.114 Network Name: DRINET Location: Novell, Inc., 2180 Fortune Drive, San Jose, CA 95131, USA Country Code: US 1:200 BARRNet 2:201 BARRNet Network IP: 192.84.1 Network Name: BBN-SYSENGRC1 Location: BBN Communications, 150 Cambridge Park Drive, Cambridge, MA 02140, USA Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Network IP: 192.86.8 Network Name: MUSE-ETHER2 Location: MicroUnity Systems Engineering, Incorporated, 4699 Old Ironsides, Suite 410, Santa Clara, CA 95054, USA Country Code: US 1:200 BARRNet Network IP: 192.88.203 Network Name: PGWKS Location: PageWorks, 36 John F. Kennedy Street, Cambridge, MA 02138, USA Country Code: US 42:702 Alternet Router Network IP: 192.108.246 Network Name: ARD-NET Location: Federal Bureau of Investigation, 10th & Pennsylvania Ave., Washington D.C. 20535, USA Country Code: US 42:702 Alternet Router Network IP: 192.138.177 Network Name: NEMC-NET1 Location: Tufts University, 169 Holland Street, Somerville, MA 02144, USA Country Code: US 1:560 NEARnet Regional Network 2:281 NEARnet Regional Network Network IP: 192.146.101 Network Name: LEXMARK-DMZ Location: Lexmark International Inc., 740 New Circle Road, Northwest, Lexington, KY 40511, USA Country Code: US 1:1751 Lexmark, Lexington, KY Total NSFNET T3 announced networks: 1174 The configuration reports, map information sheets, and configuration files which reflect these changes are available for anonymous ftp on nis.nsf.net as usual. nsfsites - configuration reports latest report for: - NSFNET T1 has the file extension .now - NSFNET T3 has the file extension 3.now nsfconfg - configuration files for the routing software for each NSS latest report for: - NSFNET T1 has the file format config.nss# - NSFNET T3 has the file extension .t3p Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nis.nsf.net machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfsites" and grab the files TEMPLATE.NET, TEMPLATE.GATE, and TEMPLATE.AS. ************** -B. Sue Blair Merit Network Operations

1 0

CERT Advisory - Michelangelo PC Virus Warning
by CERT Advisory 06 Feb '92

06 Feb '92

=========================================================================== CA-92:02 CERT Advisory February 6, 1992 Michelangelo PC Virus Warning --------------------------------------------------------------------------- The Computer Emergency Response Team/Coordination Center (CERT/CC) has received information concerning a personal computer virus known as Michelangelo. The virus affects IBM PCs and compatibles. A description of the virus, along with suggested countermeasures, is presented below. --------------------------------------------------------------------------- I. Description The Michelangelo virus is a computer virus that affects PCs running MS-DOS (and PC-DOS, DR-DOS, etc.) versions 2.xx and higher. Note, however, that although the virus can only execute on PCs running these versions of DOS, it can infect and damage PC hard disks containing other PC operating systems including UNIX, OS/2, and Novell. Thus, booting an infected DOS floppy disk on a PC that has, for example, UNIX on the hard disk would infect the hard disk and would probably prevent the UNIX disk from booting. The virus infects floppy disk boot sectors and hard disk master boot records (MBRs). When the user boots from an infected floppy disk, the virus installs itself in memory and infects the partition table of the first hard disk (if found). Once the virus is installed, it will infect any floppy disk that the user accesses. Some possible, though not conclusive, symptoms of the Michelangelo virus include a reduction in free/total memory by 2048 bytes, and some floppy disks that become unusable or display "odd" graphic characters during "DIR" commands. Additionally, integrity management products should report that the MBR has been altered. Note that the Michelangelo virus does not display any messages on the PC screen at any time. II. Impact The Michelangelo virus triggers on any March 6. On that date, the virus overwrites critical system data, including boot and file allocation table (FAT) records, on the boot disk (floppy or hard), rendering the disk unusable. Recovering user data from a disk damaged by the Michelangelo virus will be very difficult. III. Solution Many versions of anti-virus software released after approximately October 1991 will detect and/or remove the Michelangelo virus. This includes numerous commercial, shareware, and freeware software packages. Since this virus was first detected around the middle of 1991 (after March 6, 1991), it is crucial to use current versions of these products, particularly those products that search systems for known viruses. The CERT/CC has not formally reviewed, evaluated, or endorsed any of the anti-virus products. While some older anti-virus products may detect this virus, the CERT/CC strongly suggests that sites verify with their anti-virus product vendors that their product will detect and eradicate the Michelangelo virus. The CERT/CC advises that all sites test for the presence of this virus before March 6, which is the trigger date. If an infection is discovered, it is essential that the user examine all floppy disks that may have come in contact with an infected machine. As always, the CERT/CC strongly urges all sites to maintain good backup procedures. --------------------------------------------------------------------------- The CERT/CC wishes to thank for their assistance: Mr. Christoph Fischer of the Micro-BIT Virus Center (Germany), Dr. Klaus Brunnstein of the Virus Test Center (Germany), Mr. A. Padgett Peterson, P.E., of the Technical Computing Center at Martin-Marietta Corp., and Mr. Steve R. White of IBM's Thomas J. Watson Research Center. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact CERT/CC or your representative in FIRST (Forum of Incident Response and Security Teams). Internet E-mail: cert(a)cert.sei.cmu.edu Telephone: 412-268-7090 (24-hour hotline) CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4), on call for emergencies during other hours. Computer Emergency Response Team/Coordination Center (CERT/CC) Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous ftp from cert.sei.cmu.edu (192.88.209.5).

1 0

The CIX and the NSFNET regionals - a dilemma
by Vince Fuller 05 Feb '92

05 Feb '92

As some of you are probably aware, BARRNet is in the process of establishing a connection to the CIX. While working out the details of how routing will work between BARRNet member sites and customers/members of other CIX-connected networks, I have run into some difficulty which may indicate a fundamental problem for use of the CIX to interconnect research-oriented networks. In short, I believe that such networks face a serious dilemma if they connect to the CIX: how to provide unrestricted commercial-to-commercial access to the CIX-reachable networks while at the same time providing optimal routing over high-bandwidth NSFNET paths for research-oriented traffic. All, of course, while not creating large amounts of management overhead or strange routing anomalies. I would very much appreciate feedback from this community on the enclosed message, which I originally sent to the CIX tech group. Of particular interest to me is whether this group considers the assymetric routing which would be engineered by my proposed "solution" to this dilemma to be an issue and whether or not the "solution" would adequately address any NSFNET AUP concerns (I use the world "solution" loosely as I am neither proud nor very pleased with the described scheme). Thanks, Vince Fuller/BARRNet --------------- As you are probably aware, BARRNet is in the process of establishing a connection to CIX-WEST in Santa Clara. At this time, pretty much all of the administrative details of doing so have been finalized. While thinking about how routing will work, however, it occurred to me that there are some major technical details which remain unresolved. In particular, how are we to deal with routing between research-oriented networks which should use the T3 NSFNET but which will use the CIX due to the way routing is set up (as I understand it, current CIX members prefer all CIX-advertised routes over those which they may learn via the NSFNET, either by weighting advertisements or simply by only using the NSFNET as a default path). This will be a problem (politically severe immediately, technically eventually) for certain paths, such as for BARRNet sites which wish to access the San Diego Supercomputer center (and I assure you that there are several universities attached to BARRNet which have high bandwidth requirements for this particular case), and will become more severe as the T3 NSFNET becomes fully deployed. To solve this problem, it is necessary to determine whether a given network conversation is affectted by the NSFNET AUP or not. Since conformance to the AUP is based on the content of the conversation, it is not possible for the routing system to do this in an automated way - the best approximation we can make is to divide the world into those networks which are unaffected by the AUP (I'll call them "research" sites) and those which are. Routing via the NSFNET would then be preferred for all traffic which inolves a "research" site and via the CIX for all else. Unfortunately, I don't believe such a routing plan is implementable using current technology, as it requires that routing decisions be based on both traffic source and destination. The best that could be done would be to bias routing such that the each CIX-connected midlevel prefers any NSFNET path it has to "research" sites over the CIX path. This could be done in two ways: 1. Configure each CIX-connected mid-level to suppress advertisement of "research" sites to the CIX, guarenteeing that those networks are only reachable via the NSFNET. 2. At each CIX-connected mid-level, adjust metrics such that advertisements for other mid-levels' "research" networks are preferred via the NSFNET. Either "solution" creates a number of problems: 1. Routing must be coordinated among the CIX-connected mid-level networks to establish which networks are "research". Not a technical problem, but procedurally a pain in the neck. 2. Both are unwieldy in that each CIX-connected midlevel will need to maintain a list of all of "research" sites, either within its own network (solution #1, painful) or from all other CIX-connected midlevels (solution #2, more painful) 3. Both engineer route assymetry into the system. This is ugly and may or may not be acceptable. To expand on point #3, here are examples involving real sites, one "research" (Berkeley) and one "commercial" (InterOP) site in BARRNet and one "research" (ISI) and one "commercial" (Hughes Aircraft) site in CERFNet/Los Nettos (I picked these out of a hat, so to speak; I have no idea how much actual traffic flows among these four). In order to allow the NSFNET path to be used for the "research" sites, both CERFNet and BARRNet will need to hack their routing configurations to prefer the NSFNET path for Berkeley and ISI. This generates symmetric and "appropriate" paths for two of the possible communication pairs: Berkeley<->ISI and InterOP<->Hughes, but codifies assymetry for the mixed "commercial" and "research" pairs. For Interop<->ISI, BARRNet will route to ISI via the NSFNET but CERFNet will route back to InterOP via the CIX. In the Berkeley<->Hughes case, BARRNet will use the CIX to route to Hughes but CERFNet will route back to Berkeley via the NSFNET. Not pretty. There is also another policy problem with the presence of the NSFNET and it's AUP - even if all CIX-connected organizations are configured to prefer routing via the CIX for "commercial" networks, what happens if the path between two "commercial" networks via the CIX fails? If the networks are also advertised via the NSFNET, suddenly what was an unrestricted path between the two is now subject to the NSFNET AUP, without the knowledge of any user. It seems to me that the only way to prevent this is to never advertise to the NSFNET those networks which may wish to transmit any non-AUP traffic. Have these problems been previously addressed by the CIX membership? Are there solutions which I am missing? Does no one else consider these issues to be a problematic? When I explained this to my management, there was very serious concern voiced, in particular over the use of the non-T3 path for AUP-conformant sites (i.e. between BARRNET members and SDSC), since traffic between purely research-oriented sites (such as universities) should use the network which has been expressly provided for it - the T3 NSFNET. Your comments and thoughts on this matter would be greatly appreciated.

3 2

The CIX and the NSFNET regionals - a dilemma
by brian＠lloyd.com 05 Feb '92

05 Feb '92

> From: Martin Lee Schoffstall <schoff(a)psi.com> > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). Right now the performance of the NSFnet is pretty bad (even the T3 network performance is worse than a CIX provided connection) so you are probably doing your customers a service by using the CIX to route packets instead of the NSFnet. But let's look into the future where ANS finally gets its technical act together and the T3 NSFnet really starts to hum. Add in much greater use of the CIX and I can see an inverted picture where the CIX is more of a bottleneck than the NSFnet. Let me bring this closer to home for you. The federal government is paying to provide a T3 network for research and education. I suspect that NYSERnet is intended to be a beneficiary of this service. I also presume that PSI is still the carrier for NYSERnet (please correct me if I am wrong). In that case, by running traffic through the CIX you are circumventing a federal resource. Not a problem now but what if the NSFnet gets its act together? In that case you, PSI, will be doing your clients who may legitimately use the NSFnet, a GREAT disservice. Were I them I would become POWERFULLY annoyed. How are you going to deal with the problem then? Bottom line here Marty is that you and every other service provider who carries both CO and RE traffic had better have a DAMNED good answer to this problem. I would recommend you begin to think about it NOW. I have been harping about dropping AUPs on the NSFnet but that is unlikely to ever happen so we are going to have to live with the detritus. Now one last item: don't get on Vince's case. He has been tasked with solving a problem and he is doing his best. He has identified a problem that clearly ought to be dropped in your lap (collective "your" because I suspect that CERFNet and possibly UUnet/Alternet are in the same boat). Perhaps you ought to say "thank you" and work with him instead of pooh-poohing his posting. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian(a)lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392

2 1

Re: The CIX and the NSFNET regionals - a dilemma
by Martin Lee Schoffstall 05 Feb '92

05 Feb '92

John, Could you elaborate on your technical criteria for this? For instance is it 10Mbps - 45Mbps pipe access? 4Mbps spikes? what? Are these commercial or academic organizations? Marty PS: I note that your NSFNet T3 has a 10Mbps ethernet interface as of 2 weeks ago, do things change if/when it goes to FDDI? -------- > From: Martin Lee Schoffstall <schoff(a)psi.com> > Subject: Re: The CIX and the NSFNET regionals - a dilemma > Date: Tue, 04 Feb 92 22:47:42 -0500 > > > I've deferred responding publicly to the com-priv message since I hoped > others would. But I will respond to this.... > > there isn't a routing "problem". there are gigapackets/month running > through the CIX reliably, with little latency, and very inexpensively. > > What vaf wants is some tuning for the high bandwidth path that he and > a very few others have by the grace of nsf and tax $'s. it is a > reasonable request given that people don't want to ante up quite yet > for t3 cix interconnects. This tuning to my knowledge is driven > by a fairly small % of the total CIX networks (10 out of 500?). I am providing the following data based on NEARnet's current membership in order to put the situation in perspective. I would expect that the ratios would vary significantly from one network service provider to another. Of NEARnet's 115 members, we would require such "tuning" (as mentioned above) for at least 20 organizations. This represents 60-70 network routes out of about 250. This considers only bandwidth; certainly reliability and latency might also force transit network selection. The routing issue is very real for any network which serves the academic and research community. Providing for their needs, while preventing the Internet from segmenting, is the significant challenge before us. /John

1 0

Re: The CIX and the NSFNET regionals - a dilemma
by Joe Ragland 05 Feb '92

05 Feb '92

One additional comment... Aside from CIX/NSFNET routing problems, we have seen some of the consequences of multiple backbones with the current T1 and T3 NSFNET backbones and the interconnect between the two. That's how we find routes from the East Coast to the West Coast and back again, especially when the active interconnect is at SDSC. The routing arbitrator in this case is the same as the operator of both backbones but that doesn't help since the problems are fundamental to basic routing design. --joe

3 2