- Test - lists.nanog.org

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

Pittsburgh directions
by Pam Ciesla 23 Aug '95

23 Aug '95

Can be found on the Web http://www.psc.edu/~kbiscan/home.html. If you need directions by e-mail let me know and I can send them. I will be out of the office until Monday, 8/28. Pam Ciesla

1 0

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

23 Aug '95

Folks, Last week I sent detailed comments on the "Ownership" I-D to the cidrd mailing list. Scott Bradner (Ops AD) asked me to submit the comments that I wrote as an I-D for wider dissemination. I added an introduction (summary) and an ending (recommendations) around the original comments on the Ownership (leasing) proposal. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the CIDR Deployment Working Group >of the IETF. > > Title : The Myth of Topological Hierarchy: Comments on > <draft-ietf-cidrd-ownership-01.txt> > Author(s) : D. Crocker > Filename : draft-ietf-cidrd-myth-00.txt > Pages : 4 > Date : 08/22/1995 > >This note offers comments on the technical and operational aspects of the >proposal for large-scale use of "address leasing" recommended in "On the >Implications of Address Ownership for Internet Routing", I-D ><draft-ietf-cidrd-ownership-01.txt>, by Rekhter & Li. The draft has been >produced within the cidrd working group and is intended for publication as >a Best Current Practices official IETF document. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-cidrd-myth-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-ietf-cidrd-myth-00.txt -------------------- 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

Short walk off a Long PIER
by bmanning＠ISI.EDU 22 Aug '95

22 Aug '95

We would like to host an BOF on this whole renumbering thing. The paperwork is wending its way through the IETF now, but thought you would like to know. Proceedures for Internet and Enterprise Renumbering (PIER) Charter Chair(s) Bill Manning <bmanning(a)isi.edu> Roger Fajman <raf(a)cu.nih.gov> Area Director(s) Scott Bradner <sob(a)harvard.edu> Mike O'Dell <mo(a)uunet.uu.net> Mailing List Information General Discussion: pier(a)isi.edu To Un/Subscribe: pier-request(a)isi.edu Archive ftp://ftp.isi.edu/pier-archive Description of Working Group PIER will fill the niche between the ADDRCONF, CIDRD and DNSIND working groups in identifying processes and procedures, tools and techniques for renumbering in both the IPv4 and IPv6 environments. Emphasis will be placed on identifying the places where hardcoded IP addreses are used and documenting those places. If there are viable alternatives to hardcoded IP addresses, the working group will document those as well. The end results of these investigations will be a series of documents on renumbering issues and recommendations on what actions might be taken to address those issues where there is no currently viable alternative. These recommendations will be to other working groups and/or areas regarding possible improvements to protocols that would aid in renumbering. The PIER working group will not develop such protocols itself. --bill

1 0