- Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 02 Feb '96

02 Feb '96

On Fri, 2 Feb 1996 14:16:18 +1100 (EST) you said: >> >> > We are working on the 192.x.x.x swamp right now. >> > Rough estimates (with much more accurate data @ NANOG) >> > >> > 60% - invalid or missing contact information >> >> This is interesting. How about a policy that says if nobody can contact you >> and none of your addresses are reachable, then after some period, your >> addresses get recycled. > >How about a policy which says that if you fail to pay an annual amount >by a due date then a process is commenced with an outcome such that >your registration details expire and the associated number space is no >longer registered to you. and how about a waive of the fee if you return smaller aggregates for a larger one (I started doing something similiar in Israel 3 months ago). > >Geoff > Hank

1 0

Re: Policy Statement on Address Space Allocations
by Scott Huddle 01 Feb '96

01 Feb '96

> > It only gets really touchy if few of the backbones touch down in the area. > > > >Unfortunately, this is exactly the case in which geographic addressing doesn't > >work so well any more, and we have no way to mandate that backbones touch down. > > Name a backbone which doesn't come into the San Francisco Bay Area. Um, all of the rest of the world's providers. > This is the area I want to try the idea out in. In terms of physical > touchdowns, they are all in place. The only barrier is getting most > of the backbones to willingly participate in the experiment. And whats your business case that'll do this? > A very significant chunk of new domains and new ISPs are here, > in the 415/408/510 area code regions (and 707, which is next door > and could be included if we wanted...). So build it. -scott

3 3

Re: Policy Statement on Address Space Allocations
by sob＠academ.com 01 Feb '96

01 Feb '96

Well, John... I have received two of these emails. So, I disagree with you. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 01 Feb '96

01 Feb '96

From: George Herbert <gherbert(a)crl.com> It only gets really touchy if few of the backbones touch down in the area. Unfortunately, this is exactly the case in which geographic addressing doesn't work so well any more, and we have no way to mandate that backbones touch down. Noel

2 1

CERT Vendor-Initiated Bulletin VB-96.02 - Silicon Graphics
by CERT Bulletin 01 Feb '96

01 Feb '96

============================================================================= CERT(sm) Vendor-Initiated Bulletin VB-96.02 February 1, 1996 Topic: Incorrect Permissions on Packing Subsystem Source: Silicon Graphics, Inc. To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Silicon Graphics, Inc. (SGI), who urges you to act on this information as soon as possible. SGI contact information is included in the forwarded text below; please contact them if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ ______________________________________________________________________________ Silicon Graphics Inc. Security Advisory Title: Incorrect Permissions on Packing Subsystem Number: 19960102-01-P Date: January 29, 1996 ______________________________________________________________________________ Silicon Graphics provides this information freely to the SGI community for its consideration, interpretation and implementation. Silicon Graphics recommends that this information be acted upon as soon as possible. Silicon Graphics will not be liable for any consequential damages arising from the use of, or failure to use or use properly, any of the instructions or information in this Security Advisory. ______________________________________________________________________________ Silicon Graphics has discovered a security vulnerability within the "ATT Packaging Utility" (eoe2.sw.oampkg) subsystem available for the IRIX operating system. SGI has investigated this issue and recommends the following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED that these measures be implemented on ALL SGI systems running IRIX 5.2, 5.3, 6.0, 6.0.1, 6.1. This issue has been corrected for future releases of IRIX. - -------------- - --- Impact --- - -------------- The "ATT Packaging Utility" (eoe2.sw.oampkg) subsystem is not installed as part of the standard IRIX operating system. It is optionally installed when manually selected to be installed when using the IRIX inst program. Therefore, not all SGI systems will have this subsystem installed. For those systems that the subsystem installed, both local and remote users may be able to overwrite files and/or become root on a targeted SGI system. - ---------------- - --- Solution --- - ---------------- To determine if the packaging system is installed on a particular system, the following command can be used: % versions eoe2.sw.oampkg | grep oampkg I eoe2.sw.oampkg 03/25/94 ATT Packaging Utility % In the above case, the packaging system is installed and the steps below should be performed. If no output is returned by the command, the subsystem is not installed and no further action is required. *IF* the packaging subsystem is installed, the following steps can be used to neutralize the exposure by changing permissions on select programs of the eoe2.sw.oampkg subsystem. There is no patch for this issue. 1) Become the root user on your system. % /bin/su Password: # 2) Change the permissions on the following programs. # /sbin/chmod 755 /usr/pkg/bin/pkgadjust # /sbin/chmod 755 /usr/pkg/bin/abspath 3) Return to the previous user state. # exit % - ----------------------------------------- - --- SGI Security Information/Contacts --- - ----------------------------------------- Past SGI Advisories and security patches can be obtained via anonymous FTP from sgigate.sgi.com or its mirror, ftp.sgi.com. These security patches and advisories are provided freely to all interested parties. For issues with the patches on the FTP sites, email can be sent to cse-security-alert(a)csd.sgi.com. For assistance obtaining or working with security patches, please contact your SGI support provider. If there are questions about this document, email can be sent to cse-security-alert(a)csd.sgi.com. For reporting *NEW* SGI security issues, email can be sent to security-alert(a)sgi.com or contact your SGI support provider. A support contract is not required for submitting a security report. =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other security-related information are available for anonymous FTP from ftp://info.cert.org/pub/ CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request(a)cert.org 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 you to encrypt your message. We can support a shared DES key or PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://info.cert.org/pub/CERT_PGP.key CERT Contact Information ------------------------ Email cert(a)cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-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 is a service mark of Carnegie Mellon University.

1 0

InterNIC News Newsletter
by Tom Newell 01 Feb '96

01 Feb '96

Hello folks, the InterNIC is preparing to again publish a monthly newsletter (remember the NSFNet Newsletter?). We plan to include a regular "User Support/Training" column and thought it would be useful for the upcoming issue to include some discussion of how a person should go about seeking an ISP, what sort's of service issues they should consider, and what resources are available towards this end. It doesn't have to be too long nor must it answer the usual range of "New-Internet-User" questions, but should serve as a starting point for an interested reader. This sort of question is typical of those we receive on a *REGULAR* basis and I thought perhaps, that an explantion ought most appropriately (and who better qualified) come from the ISP community itself. If you are interested and can provide material (graphics welcome) within a somewhat short timeframe (7-10 days), please feel free to contact me. The newsletter will be strictly electronic (WWW-based initially). Good day, Tom -- Tom Newell liaison(a)internic.net +1 703 742 4796 NIC Liaison InterNIC Support Services

1 0

Draft NANOG agenda
by Susan R. Harris 01 Feb '96

01 Feb '96

Greetings - here's our draft agenda. ------------------------------------------------------------------------ North American Network Operators Group (NANOG) DRAFT Agenda Thursday, February 15 Time Topic Presenter(s) ---- ----- ------------- 9:00 a.m. Welcome, Introductions, Bill Norton, Merit Future Meetings 9:15 a.m. Updates from the Interconnection Points PacBell NAP Warren Williams, PacBell Sprint NAP Bilal Chinoy, SDSC MAE-Houston, MAE East, Steve Feldman, MFS Datanet MAE West, MAE-LA MAE-Phoenix, Tucson NAP Dave Siegel, RTD Systems & Networking 10:15 a.m. Application of the BGP Enke Chen, internetMCI Community in Multi-home Routing 10:45 a.m. Break 11:00 a.m. Network Analysis and Hans-Werner Braun, SDSC Statistics Kim Claffy, SDSC 11:20 a.m. Information Caching Hans-Werner Braun, SDSC Peter Danzig, USC Donald Neal, Univ. of Waikato, New Zealand 12:00-1:00 Lunch 1:00 p.m. IPv6 Transition: Update Bob Gilligan, Sun for Operators & Providers 1:45 p.m. Auto-configuration in IPv6 Allison Mankin, ISI 2:45 p.m. Data Over Cable & the Paul Mockapetris, @home @home Network 3:15 p.m. Break 3:30 p.m. Internet Routing Study & Vern Paxson, TCP Dynamics Analysis Lawrence Livermore Labs 4:15 p.m. Coordination and Randy Bush, RGnet Authorization Issues in IP Address Allocation and Delegation Friday, February 16 9:00 a.m. RA Update Elise Gerich, Merit Ramesh Govindan, ISI Cengiz Alaettinoglu, ISI Satish Kumar, ISI 9:45 a.m. Framework for a Global Robert Voigt, Hierarchical Multicast Naval Postgraduate School 10:30 a.m. DVMRP/PIM Pilot Project Dave Meyer, Univ. of Oregon 10:55 a.m. DVMRP/PIM Updates to GateD Sue Hares, Merit 11:00 p.m. Break 11:15 a.m. Proposal for Route Yakov Rekhter, Cisco Advertisement Charging 12:00 p.m. Collaborations in Internet Phil Dykstra, Army Security: Federal Research Lab Initiatives 12:45 p.m. PIER IP Address Survey Bill Manning, ISI 12:55 p.m. Closing Remarks Bill Norton, Merit

1 0

Re: Policy Statement on Address Space Allocations
by Sean Doran 01 Feb '96

01 Feb '96

| 1) Provider X can announce the aggregate outside of the area & thus | give free transit to the whole area; or | | 2) Provider X can announce just provider X's customers outside of the | area, thus defeating the gain from aggregation; or | | 3) Provider X can be paid by everyone else in the area to provide | transit to the entire area to where ever else Provider X connects to. Just to be vicious, I think I should mention option #4: Provider X can announce the aggregate outside of the area and drop packets bound for people in the area who do not pay Provider X for transiting packets to them. I think you will find that if a system were set up such that there were many touchdowns of this nature (announcing a single prefix), people would be screaming that they were at the mercies of the decisions about to whom in each local aggregate each long-distance carrier would be willing to deliver traffic. One could also view this as a way to push the problems of CIDRization out to the edges -- it would then be the end sites which would have to learn and be able to route towards the exceptions in the local aggregates, rather than the long-haul carriers. Sean.

3 3

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 31 Jan '96

31 Jan '96

I love engineers playing economists and lawyers :) That reminds me of nuclear physicists who are pretty damn sure they can do anything better than anybody else, including writing programs. Sure, yeah. I would call to look for solutions in the domain we understand and can influence, namely the technological soultions, and let the sleeping legal hounds lie. It appears that the current economical model of Internet is sustainable for time sufficient for design and deployment of new technology. (I meant *new* technology, not IPv6 or creatures of Alcohol-Troubled Minds). Please do not take that personally, it is just a reality check. --vadim

2 1

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 31 Jan '96

31 Jan '96

From: Curtis Villamizar <curtis(a)ans.net> > We can also limit the amount of routing overhead by providing configured > AAB boundaries for a given multihomed site which enclose a path between > the primary and secondary providers. Since this will in some cases > require ... automated tools we don't have yet, don't hold you breath for > that one either. You may not have to wait as long as you think. ... The idea is to provide a means to specify the aggregation boundary within the IRR and provide the tools to transform that specification into router configurations. Oh, I should also mention that Tony Li did have an idea for how to do something like the above (providing a path between primary and secondary) automatically; it involves forwarding a more specific route toward the source of a more generic route. This is worth investigating, I think. One issue with that approach is how good the routes are to the destination if the link to the primary goes down. A lot of traffic might wind up taking two sides of a triangle, but maybe that's OK for a fallback. The configured AAB probably provides better routing after a failure has happened, at higher routing overhead of course. Also, another way to think of these things are as "partition repair" mechanisms. Some routing protocols which support areas also support automatic partition repair mechanisms; IS-IS does this with a tunnel. Maybe we should look into the work that has been done in that area, too. This code will enable ANS to do much better aggregation that we now do regardless as to whether other providers buy into the idea. To accomplish the type of multiprovider cooperation you refer to above, it is a matter of getting someone else doing the same thing, or something similar enough that we have someone to cooperate with. I think that eventually we're probably going to have to look into abstraction control mechanisms that operate on scales larger than a single provider; not clear how urgently that will happen. It's true that we are having to sit fairly hard on the 32-bit space to fit everyone into it, but now that multi-level CIDR is being deployed, that is not as big an issue. The big issues that I see coming up now are things like: - How do we set AAB's and similar configured items; the current hand configuration of things like this just won't keep working. - The need for continuing to add levels of abstraction (we're currently up to about 5 - carrier, ISP, customer, subnet, host) but need to keep going to keep the routing table growth supportable as the growth in net size continues to outpace technology growth. In other words, addresses will likely have to be more organized at higher and higher levels (since the lower ones are already pretty logically assigned), which is going to be very painful indeed. Noel

1 0