August 1995 - Test - lists.nanog.org

updated web pointer
by bmanning＠ISI.EDU 20 Sep '95

20 Sep '95

The ISI/RA web pointers have been updated. http://info.ra.net/div7/ra --bill

2 2

CERT Advisory CA-95:10 - ghostscript Vulnerability
by CERT Advisory 31 Aug '95

31 Aug '95

============================================================================= CA-95:10 CERT Advisory August 31, 1995 ghostscript Vulnerability ----------------------------------------------------------------------------- A large portion of the technical content of this advisory was provided by the DFN-CERT and NASIRC response teams, and is used with their permission. There is a vulnerability in older versions of ghostscript (gs) that enables users to execute commands and thus modify files. This problem involves the -dSAFER option and is present in all versions of ghostscript from 2.6 through 3.22 beta. We recommend that you apply the solution in Section III below to fix the -dSAFER PostScript code or install the latest version of ghostscript (version 3.33). In both cases, we urge you to make -dSAFER the default mode for all versions of ghostscript starting with version 2.6. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:10.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Background The PostScript language, which was designed for the expression of graphical data, is widely used for transferring images and preformatted text across the Internet. The language includes primitives for file operations, which were intended to be useful in the expression of images. Unfortunately the operations can be abused by people intentionally embedding commands within an otherwise harmless image so that when displaying that image the PostScript viewer may perform malicious file creations or deletions. This is a potentially serious problem because many images transferred on the World Wide Web are sent in PostScript. For example, a malicious person could install a booby-trapped image on a web-page, buried among useful or interesting data. The viewer "ghostscript," a PostScript interpreter, recognizes the command-line option: "-dSAFER". This option is intended to disable the file operations and the %pipe PostScript operator that could be abused to do damage. This option is intended to protect you from this type of sabotage when viewing images from untrusted sources. II. Problem Description Problems exist with the ghostscript program, which supports the kind of commands discussed above. Older versions of ghostscript do not completely disable the pipe operator that can be used execute commands that can modify files. Therefore the option -dSAFER does not provide full protection. This problem is present in all versions of ghostscript between 2.6 (when the %pipe operator was added) and 3.22beta (when a fix was made). III. Impact Attackers who have inserted malicious code into a PostScript file can cause commands to be executed and files to be modified on any system where that PostScript file is viewed with ghostscript. IV. Solutions We recommend either fixing the -dSAFER PostScript code or installing version 3.33 of ghostscript (see Sections IV.A and IV.B). In addition, we urge you to enable the -dSAFER option as the default (see Section IV.C). A. Fixing the -dSAFER PostScript code The following fix is in the form of "diff" output, which is suitable for use with the GNU patch program. This patch brings the code into conformance with the version of gs_init.ps distributed with the latest version of ghostscript (3.33) and can be applied to the GNU versions 2.6, 2.6.1, and 2.6.2. The file to be patched is in the ghostscript library. As an example, gs_init.ps could be installed in: /usr/local/lib/ghostscript/gs_init.ps Here is the patch: --------------------------------cut here-------------------------------------- *** gs_init.ps.orig Fri Aug 25 10:42:51 1995 --- gs_init.ps Fri Aug 25 11:16:24 1995 *************** *** 302,308 **** % If we want a "safer" system, disable some obvious ways to cause havoc. SAFER not { (%END SAFER) .skipeof } if /file ! { dup (r) eq { file } { /invalidfileaccess signalerror } ifelse --- 302,308 ---- % If we want a "safer" system, disable some obvious ways to cause havoc. SAFER not { (%END SAFER) .skipeof } if /file ! { dup (r) eq 2 index (%pipe*) .stringmatch not and { file } { /invalidfileaccess signalerror } ifelse --------------------------------cut here-------------------------------------- The key is to change the line that says: { dup (r) eq to one that says: { dup (r) eq 2 index (%pipe*) .stringmatch not and Here are the relevant lines in the gs_init.ps file for version 2.6.2 of ghostscript before the patch: 302 % If we want a "safer" system, disable some obvious ways to cause havoc. 303 SAFER not { (%END SAFER) .skipeof } if 304 /file 305 { dup (r) eq 306 { file } 307 { /invalidfileaccess signalerror } 308 ifelse 309 } bind odef 310 /renamefile { /invalidfileaccess signalerror } odef 311 /deletefile { /invalidfileaccess signalerror } odef 312 %END SAFER Here are the same lines after the patch has been applied: 302 % If we want a "safer" system, disable some obvious ways to cause havoc. 303 SAFER not { (%END SAFER) .skipeof } if 304 /file 305 { dup (r) eq 2 index (%pipe*) .stringmatch not and 306 { file } 307 { /invalidfileaccess signalerror } 308 ifelse 309 } bind odef 310 /renamefile { /invalidfileaccess signalerror } odef 311 /deletefile { /invalidfileaccess signalerror } odef 312 %END SAFER B. Installing version 3.33 You may wish to install Aladdin Ghostscript version 3.33. The latest version of ghostscript is version 3.33 and is available at the locations noted below. This version of ghostscript is provided by Aladdin Enterprises and is subject to their licensing agreements. Please read the "Aladdin Ghostscript Free Public License" (included in the source code distribution) which differs from the "GNU Public License." Please note that this version is not the GNU version. The latest GNU version, which is version 2.6.2, does not fix this problem. ftp://ftp.cs.wisc.edu/pub/ghost/aladdin/ghostscript-3.33.tar.gz MD5=28b78ab052dff21639c4b97051323e49 ftp://ftp.cs.wisc.edu/pub/ghost/aladdin/ghostscript-3.33jpeg.tar.gz MD5=b7dd9064dd57db8fccc306f5e4528d99 Optionally, you may need the font files for this release. They are available at these locations: ftp://ftp.cs.wisc.edu/pub/aladdin/ghostscript-fonts-std-3.0.tar.gz MD5=fe7377bb155496828a328624ae80149d ftp://ftp.cs.wisc.edu/pub/aladdin/ghostscript-fonts-other-3.0.tar.gz MD5=afe46faf7fde6518ae004a7e8d9a4af4 C. Making -dSAFER the default To make -dSAFER the default mode for ghostscript for all versions of ghostscript starting with version 2.6, the file gs_init.ps must again be changed. The PostScript commands which check the actual interpreted command are collected in one single if statement in the gs_init.ps file. By commenting out the begin and end lines of this if statement, the check is always applied meaning that the -dSAFER option is always enabled. NOTE: If you make this change, all file and %pipe operations are disabled and cannot be re-enabled. The lines which must be changed are: 303 SAFER not { (%END SAFER) .skipeof } if and 312 %END SAFER These two lines should be commented out and made to look like this: 303 % SAFER not { (%END SAFER) .skipeof } if and 312 % %END SAFER If you are using ghostscript 2.6.2, the code will look like the following when both patches noted above are installed: 302 % If we want a "safer" system, disable some obvious ways to cause havoc. 303 % SAFER not { (%END SAFER) .skipeof } if 304 /file 305 { dup (r) eq 2 index (%pipe*) .stringmatch not and 306 { file } 307 { /invalidfileaccess signalerror } 308 ifelse 309 } bind odef 310 /renamefile { /invalidfileaccess signalerror } odef 311 /deletefile { /invalidfileaccess signalerror } odef 312 % %END SAFER --------------------------------------------------------------------------- The CERT Coordination Center staff thanks the DFN-CERT and NASIRC response teams for providing a large portion of the technical content of this advisory, and we thank Wolfgang Ley for his assistance. --------------------------------------------------------------------------- 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. This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the CERT Coordination Center, DFN-CERT, and NASIRC are acknowledged. CERT is a service mark of Carnegie Mellon University.

1 0

Re: NANOG Meeting
by prue＠ISI.EDU 29 Aug '95

29 Aug '95

Hi, I will be attending the NANOG meeting in Pittsburg. Walt Prue Los Nettos USC/ISI

1 0

CERT Advisory CA-95:09 - Solaris ps Vulnerability
by CERT Advisory 29 Aug '95

29 Aug '95

============================================================================= CA-95:09 CERT Advisory August 29, 1995 Solaris ps Vulnerability ----------------------------------------------------------------------------- The text of this advisory is taken primarily from AUSCERT advisory AA-95.07, with their permission. A vulnerability exists in Solaris systems that allows a race condition to be exploited to gain root access. The essential problem is that the ps(1) program maintains a data file in the /tmp directory, and the /tmp directory is world-writable, allowing users to delete other users' files in /tmp. This vulnerability affects Solaris 2.x (SunOS 5.x) systems. An exploit program for this vulnerability has been published. We urge you to take the actions described in Section III as soon as possible. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:09.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ------------------------------------------------------------------------------ I. Description A race condition exists in at least one Solaris 2.x (SunOS 5.x) system program that can be exploited to gain root access if the user has access to the temporary files. Access to temporary files may be obtained if the permissions on the /tmp and /var/tmp directories are set incorrectly. The permissions on the /tmp directory are often reset incorrectly by the system if tmpfs (which is mounting swap as /tmp) is in use. II. Impact Users logged in to the system may gain unauthorized root privileges. III. Solution A. Determine if your system is vulnerable To determine if you are running tmpfs, the following command can be used to verify if the filesystem for /tmp is swap: % /usr/sbin/df -k /tmp Filesystem kbytes used avail capacity Mounted on swap 28348 12 28336 0% /tmp or look in the file /etc/vfstab for the configuration line: #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options swap - /tmp tmpfs - yes - If either of these two conditions exist, then you are running tmpfs and the system may automatically reset the permission bits of /tmp at the next reboot. To verify if your configuration is currently vulnerable, the following command may be used: % /usr/bin/ls -ld /tmp drwxrwxrwt 2 sys sys 61 Aug 15 12:12 /tmp If the sticky bit (t) is not set (it will be an x), then the system is vulnerable. B. Perform the following workarounds These workarounds have been verified with Sun Microsystems. Sun Microsystems expects to release a patch in the near future. 1. Immediate - fix /tmp permissions A workaround that takes effect immediately is to set the sticky bit on the /tmp directory using the following command as root: # /usr/bin/chmod 1777 /tmp Note that this command must be performed after each reboot if you are mounting swap as /tmp (using tmpfs). In addition, the ownership and group membership of the /tmp directory should be verified using /usr/bin/ls -ld /tmp, and if incorrect may be reset by: # /usr/bin/chown sys /tmp # /usr/bin/chgrp sys /tmp The AUSCERT UNIX Security Checklist addresses this issue in Section 5.5. This section is reproduced in the appendix of this advisory. The entire AUSCERT checklist may be obtained from these locations. Sites outside of Australia should use the info.cert.org FTP site. ftp://info.cert.org/pub/tech_tips/AUSCERT_checklist_1.0 ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist_1.0 2. Permanent - make the above change to /tmp permissions permanent The change noted in item B.1 above will be lost upon reboot. To make the changes permanent, create the following script as /etc/init.d/tmpfsfix: -----------------------------cut here--8<------------------------------------- #!/bin/sh if [ -d /tmp ] then /usr/bin/chmod 1777 /tmp /usr/bin/chgrp sys /tmp /usr/bin/chown sys /tmp fi ------------------------------cut here---8<----------------------------------- A symbolic link should then be created called /etc/rc3.d/S79tmpfix which points to /etc/init.d/tmpfsfix by issuing the following command as root: # /usr/bin/ln -s /etc/init.d/tmpfsfix /etc/rc3.d/S79tmpfix If you have done item B.1 above, you can reboot at your leisure. Otherwise, reboot your system now. In either case, verify the permissions of /tmp immediately after your next system reboot. 3. Check /var/tmp permissions We recommend that you also check and correct the /var/tmp directory. Note that this directory is not usually mounted as tmpfs, so it normally would not be subject to automatic resetting of its permission bits on reboot. % /usr/bin/ls -ld /var/tmp drwxrwxrwt 2 sys sys 512 Aug 15 11:35 /var/tmp ---------------------------------------------------------------------------- The CERT Coordination Center staff thanks AUSCERT, the Australian response team, for their permission to reuse text from their advisory AA-95.07 and for their cooperation and assistance. ---------------------------------------------------------------------------- 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. This material may be reproduced and distributed without permission provided it is used for noncommercial purposes, and the CERT Coordination Center and AUSCERT are acknowledged. CERT is a service mark of Carnegie Mellon University. .............................................................................. Appendix: Excerpt from AUSCERT UNIX Security Checklist (Version 1.0) 5.5 File Permissions * CHECK that the permissions of /etc/utmp are set to 644. * CHECK that the permissions of /etc/sm and /etc/sm.bak are set to 2755. * CHECK that the permissions of /etc/state are set to 644. * CHECK that the permissions of /etc/motd and /etc/mtab are set to 644. * CHECK that the permissions of /etc/syslog.pid are set to 644. * REMOVE setgid privileges on /usr/kvm/crash. A group of kmem allows users to read the virtual memory of a running system. # /bin/chmod g-s /usr/kvm/crash * DO consider removing read access to files that users do not need to access. * ENSURE that the kernel (eg. /vmunix) is owned by root, has group set to 0 (wheel on SunOS) and permissions set to 644. * ENSURE that /etc, /bin, /usr/etc, /usr/bin and /tmp are owned by root [Note from CERT Coordination Center: "root" applies to SunOS; "sys" applies to Solaris] and that the sticky-bit is set on /tmp. ie. permissions on /tmp should be: drwxrwxrwt. You should implement COPS or Tiger to check for this. Refer to section B.2 [of the AUSCERT UNIX Security Checklist] for information where to obtain these. * ENSURE that there are no unexpected world writable files or directories on your system. The following commands find world writeable files and directories. # /bin/find / -type f -perm -22 -exec ls -l {} \; # /bin/find / -type d -perm -22 -exec ls -ld {} \; * CHECK that files which have the SUID or SGID bit enabled, should have it enabled: # /bin/find / -type f $ -perm -004000 -o -perm -002000 $ \ -exec ls -l {} \; * CHECK the umask value for each user and ensure it is set to something sensible like 027 or 077. Refer to section E.1 [of the AUSCERT UNIX Security Checklist] for a shell script to check this.

1 0

Draft Agenda
by Susan R. Harris 29 Aug '95

29 Aug '95

Greetings - Here's what we've planned so far for the Pittsburgh agenda. ---------------------------------------------------------- North American Network Operators Group (NANOG) September 11-12, Pittsburgh Supercomputing Center DRAFT Agenda Topic Presenter(s) ----------------------------------------------------------- Welcome, Introductions, Bill Norton Future Meetings Update on the RA Service Elise Gerich New Routing Tools for the Internet Craig Labovitz Updates from the Interconnection Points (Sprint, AADS, PacBell, and Washington, D.C. NAPs; MAE-West) Top-Level Domains: Mark Kosters and Dave Graves the InterNIC Solution Top-Level Domains: Community Views and Discussion Auto-configuration in IPv6 Alison Mankin Experience With Route-Flap Sean Doran Dampening Nimrod Routing: How Can Michael Patton We Meet Your Needs? CA*net ATM Backbone Transition Guy Middleton RADIUS: Distributed John Vollbrecht Authentication for MichNet Proxy Aggregation: Stan Barber, Moderator Community Views and Discussion

1 0

New Dates for 6th Maryland Workshop on Very High Speed Networks
by Account of Maryland Center for Telecommunications Research 28 Aug '95

28 Aug '95

--------------------------------------------------- 6th Maryland Workshop on Very High Speed Networks --------------------------------------------------- OCTOBER 30-31, 1995 Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) and Department of Computer Science and Electrical Engineering at the University of Maryland Baltimore County (UMBC) in participation with the University of Maryland Institute for Advanced Computer Studies (UMIACS), IEEE Communication Society - Gigabit Networking Technical Committee, and IDA/Center for Computing Sciences will hold the 6th Maryland Workshop on Very High Speed Networks on October 30-31, 1995 at the UMBC campus. The Workshop will be held in Ballroom of University Center on the UMBC campus. The workshop is supported by IBM, SUN and Sprint. The goal of the Workshop is to bring together experts in related areas to discuss progress and research issues in the design and implementation of very high speed communication networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. For more information on MCTR and directions to UMBC check our home- page on WWW.(http://www.cs.umbc.edu/~mctr) A registration fee of $150 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer, Dr. Deepinder Sidhu, at Tel: (410) 455-3028, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. ------------------------------------------------------------------------------- 6th Maryland Workshop on Very High Speed Networks (October 30-31, 1995) Registration Form Name: ---------------------------------------------------------------------- Affiliation: ------------------------------------------------------------- Address: ------------------------------------------------------------- ------------------------------------------------------------- Phone: Fax: Email: ---------------- ------------- ------------ Dietary Restriction : Vegetarian Kosher ---------- ------------ ------------------------------------------------------------------------------- Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. P. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, Baltimore, MD 21228. All funds for this event will be managed by the UM foundation. We plan to provide free admission to a limited number of students if a grant application is approved. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. 1. Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 2. Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY 3. Omni Inner Harbor Hotel. Close to Downtown Baltimore / Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664

1 0

Re: Comments on draft-ietf-cidrd-ownership-01.txt
by Dave Crocker 25 Aug '95

25 Aug '95

Noel, I see that you copied all of the lists. In my original posting to them I requested that discussion move to the cidrd mailing list. Folks should send to majordomo(a)iepg.org and have subscribe cidrd in the body. I request that you and other responders follow up to cidrd (after reading my retort...) In reply to your message stating: > addressing. It then, incorrectly, asserts that the Internet topology > >Well, in fact it says that "the topology of the network is not strictly The statement in the ownership draft you quote is an afterthought completely offset by the bulk of the draft. My comments draft mentions that quote (and dismisses it.) Please re-read both documents more carefully. >You appear to have missed the distinction between a hierarchical topology, and >an address hierarchy. One can apply hierarchical addressing to a perfectly No, that's exactly what CIDR has gotten wrong. It uses an imaginary topological hierarchy to define the address hierarchy. As a result of this confusion it handles multi-homing in a fashion which does not scale and which requires users and intermediate providers to renumber every time they change suppliers. How would YOU like to change phone numbers every time you change long-distance carriers? >The point remains that use of hierarchical addressing is the *only* way known Noel, I LIKE hierarchical addressing. The problem is with the current choice of hierarchy made by cidr. >that an addressing hierarchy that is loosely isomorphic to the connectivity Too loose for comfort, Noel. Our pants are starting to fall down. >Renumbering is indeed painful. However, given past decisions, no other option CIDR was chosen, yes. Consideration of alternatives was terminated. After initial success, CIDR is now failing. The Leasing proposal is part of an effort to save cidr, but at the expense of intolerable effects on much/most of the Internet's participants. Time to review the alternatives. Multi-homing and renumbering issues make cidr just as experimental as the alternatives. Hmmm. Perhaps not. We KNOW cidr has show-stopping problems. > It is time to consider alternatives to CIDR. > >Unfortunately, it's too late to consider alternatives. The Internet has a real >problem with routing table growth. To get something organized (since the Noel, this was the claim 3 years ago, too. It's time to stop letting that line of crisis abuse be used on the community. We need to focus on finding a mechanism that works. > After some considerable initial success it is proving inadequate. > >No, it's perfectly adequate, just painful. However, no other tool is available The effect of the requirement for large-scale and REPEATED renumbering is considerably worse than just painful. The failure to handle large-scale multi-homing is considerably worse than just painful. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker(a)brandenburg.com

2 1

New Dates for 6th Maryland Workshop on Very High Speed Networks
by Account of Maryland Center for Telecommunications Research 24 Aug '95

24 Aug '95

--------------------------------------------------- 6th Maryland Workshop on Very High Speed Networks --------------------------------------------------- OCTOBER 30-31, 1995 Maryland Center for Telecommunications Research Department of Computer Science and Electrical Engineering University of Maryland Baltimore County The Maryland Center for Telecommunications Research (MCTR) and Department of Computer Science and Electrical Engineering at the University of Maryland Baltimore County (UMBC) in participation with the University of Maryland Institute for Advanced Computer Studies (UMIACS), IEEE Communication Society - Gigabit Networking Technical Committee, and IDA/Center for Computing Sciences will hold the 6th Maryland Workshop on Very High Speed Networks on October 30-31, 1995 at the UMBC campus. The Workshop will be held in Ballroom of University Center on the UMBC campus. The workshop is supported by IBM, SUN and Sprint. The goal of the Workshop is to bring together experts in related areas to discuss progress and research issues in the design and implementation of very high speed communication networks. Each of the previous workshops attracted approximately 150 researchers representing academia, industry and government. The two day meeting will include invited speakers and contributed presentations. Papers on selected presentations will appear in a special issue of the Journal of High Speed Networks. For more information on MCTR and directions to UMBC check our home- page on WWW.(http://www.cs.umbc.edu/~mctr) A registration fee of $150 will include two lunches and conference proceeding. For questions regarding the technical content of the workshop or giving a presentation, please contact the workshop organizer, Dr. Deepinder Sidhu, at Tel: (410) 455-3028, Fax: (410) 455-3969, Email: mctr(a)cs.umbc.edu. ------------------------------------------------------------------------------- 6th Maryland Workshop on Very High Speed Networks (October 30-31, 1995) Registration Form Name: ---------------------------------------------------------------------- Affiliation: ------------------------------------------------------------- Address: ------------------------------------------------------------- ------------------------------------------------------------- Phone: Fax: Email: ---------------- ------------- ------------ Dietary Restriction : Vegetarian Kosher ---------- ------------ ------------------------------------------------------------------------------- Mail checks (payable to University of Maryland Foundation) and registration form to Dr. D. P. Sidhu, Maryland Center for Telecommunications Research, University of Maryland Baltimore County, Baltimore, MD 21228. All funds for this event will be managed by the UM foundation. We plan to provide free admission to a limited number of students if a grant application is approved. Please DO NOT include hotel accommodation expenses in your payment for the Workshop Registration. Room payment should be made directly to the hotel you selected for stay. The following hotels are closest to UMBC campus. Some hotels may offer reduced rate. To obtain the reduced rate, you must identify yourself as an attendee of this workshop. BWI Airport is approximately five miles from UMBC Campus. 1. Sheraton International Hotel - BWI Airport. Closest to airport and UMBC campus. Tel: (410) 859-3300 or (800) 638-5858 2. Holiday Inn - BWI Airport. Close to airport and UMBC campus. Tel: (410) 859-8400 or (800) HOLIDAY 3. Omni Inner Harbor Hotel. Close to Downtown Baltimore / Inner Harbor. About 20 minutes drive to UMBC campus. Tel: (410) 752-1100 or (800) 843-6664

1 0

ccMail SMTPLINK Undeliverable Message
by choate＠smtpgw1.plk.af.mil 24 Aug '95

24 Aug '95

______________________________ Forward Header __________________________________ Subject: ccMail SMTPLINK Undeliverable Message Author: choate(a)smtpgw1.plk.af.mil (ccMail SMTPLINK) at smtpgw1 Date: 8/23/95 7:18 PM User pereaad is not defined SSgt Perea is no longer with us. Norm Choate cc:Mail Admin Original message header follows Return-Path: <dren-doers-request(a)sos.arl.mil> Received: from SOS.ARL.MIL (sos.arl.mil [192.5.23.34]) by ug1.plk.af.mil (8.6.10/8.6.10) with SMTP id RAA26544; Wed, 23 Aug 1995 17:37:21 -0600 Received: from SOS.ARL.MIL by SOS.ARL.MIL id aa06693; 23 Aug 95 17:17 EDT Received: from wharf.arl.mil by SOS.ARL.MIL id aa06682; 23 Aug 95 17:14 EDT Received: from merit.edu by wharf.arl.mil id aa09324; 23 Aug 95 16:38 EDT Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA27904; Wed, 23 Aug 1995 16:22:25 -0400 Resent-Date: Wed, 23 Aug 1995 16:22:25 -0400 Date: Wed, 23 Aug 1995 16:22:21 -0400 From: Pam Ciesla <pam(a)merit.edu> Message-Id: <199508232022.QAA20291(a)home.merit.edu> To: nanog(a)merit.edu Subject: Pittsburgh directions Resent-Message-ID: <"ScZMT.0.vp6.0uuEm"@merit.edu> Resent-From: nanog(a)merit.edu X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/12 X-Loop: nanog(a)MERIT.EDU Precedence: list Resent-Sender: nanog-request(a)merit.edu Return-Path: <dren-doers-request(a)sos.arl.mil> Received: from SOS.ARL.MIL (sos.arl.mil [192.5.23.34]) by ug1.plk.af.mil (8.6.10/8.6.10) with SMTP id RAA26544; Wed, 23 Aug 1995 17:37:21 -0600 Received: from SOS.ARL.MIL by SOS.ARL.MIL id aa06693; 23 Aug 95 17:17 EDT Received: from wharf.arl.mil by SOS.ARL.MIL id aa06682; 23 Aug 95 17:14 EDT Received: from merit.edu by wharf.arl.mil id aa09324; 23 Aug 95 16:38 EDT Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA27904; Wed, 23 Aug 1995 16:22:25 -0400 Resent-Date: Wed, 23 Aug 1995 16:22:25 -0400 Date: Wed, 23 Aug 1995 16:22:21 -0400 From: Pam Ciesla <pam(a)merit.edu> Message-Id: <199508232022.QAA20291(a)home.merit.edu> To: nanog(a)merit.edu Subject: Pittsburgh directions Resent-Message-ID: <"ScZMT.0.vp6.0uuEm"@merit.edu> Resent-From: nanog(a)merit.edu X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/12 X-Loop: nanog(a)MERIT.EDU Precedence: list Resent-Sender: nanog-request(a)merit.edu

1 0

Re: Comments on draft-ietf-cidrd-ownership-01.txt
by jnc＠ginger.lcs.mit.edu 24 Aug '95

24 Aug '95

From: Dave Crocker <dcrocker(a)brandenburg.com> Last week I sent detailed comments on the "Ownership" I-D to the cidrd mailing list. Your document has many problems. Here are a few: The document goes on to describe the nature and benefits of hierarchical addressing. It then, incorrectly, asserts that the Internet topology reflects a hierarchy and that addresses must be kept aligned with the hierarchy. Well, in fact it says that "the topology of the network is not strictly hierarchical". I suppose you could read that as saying that the network topology is basically hierarchical, but it turns out this is a moot point. You appear to have missed the distinction between a hierarchical topology, and an address hierarchy. One can apply hierarchical addressing to a perfectly regular topology, e.g. a North-East-West-South mesh in which each node has precisely four neighbours. (True, one doesn't need full-blown dynamic routing for that case, but it's a useful test case.) This disproves your implicit suggestion that one cannot use hierarchical routing in a network which does not have a hierarchical topology. This requirement is used to assert the need for enforcing addressing changes when (some) topological changes take place. The point remains that use of hierarchical addressing is the *only* way known to control the growth of routing overhead costs in a very large network, and that an addressing hierarchy that is loosely isomorphic to the conectivity topology is the *only* one that will do that. As such, if it of course true that as the topology changes, the addressing hierarchy will have to, as well. The document makes no effort to deal with the very real difficulties this model creates for multi-homed organizations Multi-homing provides extra capability, but it does not come without a cost (in terms of routing overhead), and this is true no matter which addressing scheme is used. Since this topic is lengthy and complex, I will pass on. The document asserts the model of customer "leasing" of addressing rather than "owning" them but does not discuss the problems this creates with large-scale requirements for renumbering, generally viewed as difficult, but potentially quite insidious for local providers who change transit providers. Renumbering is indeed painful. However, given past decisions, no other option is now available to us if we wish the keep the Internet i) growing, and ii) functioning. In the next paragraph the paper states the importance of having an address reflect the topology of the network. Since the Internet is not a simple tree, but instead is a messy mesh one must ask by what procrustean process the Internet is to be represented by (relatively) stable hierarchical addresses? Exactly. There is no way to represent a dynamic topology like the Internet with stable hierachical addresses. The paper also says that changing an address is required as the network topology changes. This simply isn't true ... Internet topology changes all the time and sites are not required to change their addresses. At best this paragraph is seriously imprecise. At worst it is seriously wrong. This is a subtle and complex technical point, one that is not possible to quantify, and certainly not in a paper intended for a non-technical audience. A given address hierarchy, for a given topology, will produce a certain degree of routing overhead (as well as non-optimal routes). If the topology is then changed, wihtout changing the addressing, the routing overhead will grow. Eventually, it will grow to the degree that changes to the address hierarchy are needed to bring routing overhead back to reasonable bounds. The problem is exactly that no single change is deadly, but rather it is the accumulation of many small changes that cannot be supported. The end effect is to aid in the myth of Internet topological hierarchy. There is no myth of toplogical hierarchy that I know of, except in this paper. The first paragraph cites concerns for routing system scaling. However there is no concern expressed for Internet local providers or users. Presumably, an Internet which no longer worked because of routing system scaling problems would be a severe concern for Internet local providers or users. It is time to consider alternatives to CIDR. Unfortunately, it's too late to consider alternatives. The Internet has a real problem with routing table growth. To get something organized (since the solution to this problem cannot be imposed piecemeal, but has to be applied throughout the core), implemented, and deployed, will take at least a year, I would guess, and probably a fair amount longer. (It took almost 3 years to get CIDR, a relatively simple solution, deployed, BTW.) We don't have that time. CIDR was chosen with the expectation that it would be a sufficient near-term answer for routing table compression. CIDR was intended to handle "[growth] of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage". It indicated that "[the] proposed solution is to topologically allocate future IP address assignment". That is what we are doing now. After some considerable initial success it is proving inadequate. No, it's perfectly adequate, just painful. However, no other tool is available to handle growth in the network. The Internet, to use my favourite analogy, is in the position of some who has jumped off a 50-story building, and about the 10th story decides it's going to hurt. Bit late now, guys... Noel

1 0