- Test - lists.nanog.org

Agenda for next week
by Susan R. Harris 06 Sep '95

06 Sep '95

North American Network Operators Group (NANOG) Agenda Monday, September 11 Time Topic Presenter(s) ---- ----- ------------ 9:00 a.m. Welcome, Introductions, Bill Norton Future Meetings 9:15 a.m. RA Project Update Elise Gerich 10:00 a.m. New Routing Tools for the Craig Labovitz Internet 10:30 a.m. Break 10:45 a.m. Updates from the Interconnection Points AADS NAP Mark Knopper PacBell NAP Current status Warren Williams ATM Testing Kent England Washington, D.C. NAP Steve Feldman MAE-West Steve Feldman 12:30-1:30 p.m. Lunch 1:30 p.m. Top-Level Domains: the Mark Kosters and InterNIC Solution Dave Graves 2:00 p.m. Top-Level Domains: Milo Medin, Moderator Community Views and Discussion 2:45 p.m. Nimrod Routing: How Can Michael Patton We Meet Your Needs? 3:15 p.m. Break 3:30 p.m. Experience With Route-Flap Sean Doran Dampening 4:00 p.m. Auto-configuration in IPv6 Alison Mankin Tuesday, September 12 9:00 a.m. Proxy Aggregation: Stan Barber, Moderator Community Views and Discussion 10:00 a.m. CA*net ATM Backbone Guy Middleton Transition 10:30 a.m. Break 10:45 a.m. RADIUS: Distributed John Vollbrecht Authentication for MichNet 11:15 a.m. GateD Consortium Martyne Hallgren 11:30 a.m. Classless DNS Delegations in Daniel Karrenberg IN-ADDR.ARPA 12:00 p.m. Adjourn

1 0

NEW Tool Announcement
by labovit＠MERIT.EDU 06 Sep '95

06 Sep '95

MRT-1.0-ALPHA README Last updated 9/6/95 The first official alpha release of the Multi-threaded Routing Toolkit (MRT) tools is now available: (SunOS) ftp://ftp.merit.net/net-research/mrt/mrt-1.0.alpha.sunos.tar.gz (Solaris) ftp://ftp.merit.net/net-research/mrt/mrt-1.0.alpha.solaris.tar.gz For more information on the MRT toolkit, see: http://www.merit.net/net-research/mrt/mrt.html MRT is an easy-to-use, extensible platform for developing and debugging routing protocols and routing code. MRT's Unix programs and C-library routines separate routing into its key component pieces of routing protocol, routing engine, and routing policy services. The MRT tools greatly improve the ability of network providers to monitor, troubleshoot, and analyze networks, and provide protocol developers or researchers with a useful vehicle for quick prototyping and experimentation. You can use MRT tools to: --Capture a BGP peering session and monitor it in real time --Input a binary file to the routing stream to replicate a problem or create any desired routing condition --Use a real-time dump to perform statistical analyses, prototype a new protocol, or test a routing engine --Record and replay sequences of events, in order to reproduce scenarios such as routing failures --Collect routing statistics and analyze route flapping The Alpha release contains the following tools: * SBGP A simple BGP4 speaker and listener * Route_BtoA Convert binary MRT messages to ASCII * Route_AtoB Convert ASCII descriptions of MRT messages to binary * CiscoBGP Check cisco routing tables against IRR * BGPCheck Check BGP updates against IRR * Route_Flap Perform route flap analysis and statistics collection 1.0 ALPHA RELEASE NOTES ----------------------- 1. This is an ALPHA release. The code is still a bit buggy and unstable. Depending on the number of bugs that turn up, we hope to make a BETA release available in late October. 2. MRT was designed to run on native kernel-level multi-threaded machines. If you run MRT on older machines, you will not achieve nearly the same level of performance. In addition, some MRT features will not work. 3. The complete set of MRT programming libraries and documentation will be released with MRT-1.0 BETA in late October. 4. MRS, XMRS, SRIp, PortMapper and MSGServer are included in this release as undocumented, unsupported prototypes.

1 0

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