- Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by Sean Donelan 02 Feb '96

02 Feb '96

>If an organization registered an address they are responsible for >keeping the contact name up to date. If they don't announce the >route, they have not provided a valid contact, and there is no way to >contact them, including publishing a list on major mailing lists, then >it should be safe to recover the address since every reasonable effort >was made to contact them. If a route is not announced, this is a NOOP >anyway. Things get out of date very, very quickly on the net (and real-life). And even the best run organizations sometimes have lapses. How about an example a little closer to home. Although its an AS number rather than an IP network number, what happens when the net runs out of AS numbers. Should things like AS 690 'reclaimed' based on out-of-date information? Although Elise is kind enough to forward messages on to ANS now, what if she got tired of it, and just dumped the message in the bit bucket. And the following week the NIC issued AS 690 to some other network. $ whois as 690 Merit Computer Network (ASN-NSFNET-T3-RT) 1075 Beal Avenue Ann Arbor, MI 48109 Autonomous System Name: NSFNET-T3-RT-AS Autonomous System Number: 690 Coordinator: Gerich, Elise (EG14) epg(a)MERIT.EDU 313 764 9430 (FAX) (313) 747-3745 Record last updated on 13-Apr-94. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. >If the route is announced, go through the AS path and/or traceroute >asking the provider closest to the route for a contact name. Just >send a "Dear IP Provider" letter stating "This appears to be your >customer but we have no way to contact them. Can you help?". Most >providers have a way of contacting their customers. Sometimes not even the providers seems to know. I've dealt with several providers whose only contact information for a customer is a credit card number. They 'contact' the customer by disabling the connection, and what for the customer to call them. Not very friendly, and about as bad as hijacking the connection. Ok, maybe that's just the little guys. If you consider MFS as the 'provider' of MAE-East. You might expect MFS knew how to contact their mae-east customers. Sorry MFS, you're just a nice neutral example to show the half-life of contact information on the net is very, very short. I've been contacting other ISP's on mae-east off and on for several months. About 40% of MFS's mae-east customer contact information was outdated or non-existent. For example, the contact person doesn't work for the company any more. The company has changed names three or more times, moved twice, and no one knows the current company name, address or phone number. In a few cases, the phone number has been disconnected, with no forwarding number. Add the number of people who got the message, and didn't care to respond, I can easily understand a 60% non-response rate. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Policy Statement on Address Space Allocations
by Kent W. England 02 Feb '96

02 Feb '96

At 02:16 PM 2/2/96 +1100, Geoff Huston wrote: > >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. > >Geoff > > > I have a concern about tying any kind of fee to address allocations. If we do that, we are essentially leasing addresses and we have no way to deal with address speculation. There is no way we could prevent arbitrage, scalping, speculation and hoarding, no matter how high the fees are set. Better to stay away from fees and leave open options with respect to allocation. That's not to say that we could have charges for routing table entries, although no one has suggested a formula for how to do that or predict the total costs. --Kent

2 1

Re: Policy Statement on Address Space Allocations
by Paul Ferguson 02 Feb '96

02 Feb '96

At 02:16 PM 2/2/96 +1100, Geoff Huston wrote: >> >> > 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. > >Geoff > Would this process, perhaps, be associated with a route announcement charging scheme? - paul

2 1

Re: Policy Statement on Address Space Allocations
by Kent W. England 02 Feb '96

02 Feb '96

At 11:20 AM 2/2/96 +0000, Nick Hilliard wrote: > >There must be some mechanism implemented whereby address space will return >to the IANA after a specified period of time unless otherwise requested by >the prefix holder. Otherwise what will happen is that this 60% (or some >other large percentage when the figures finally settle) of the 192/8 address >space will effectively be lost from the internet with no real means of >retrieving it. A system like this without any garbage collection mechanism >is eventually going to fill up with defunct allocations and the cruft of >years past -- something which is not an option when dealing with limited >address space. > We have no lack of address space in the 32 bit IPv4 world. Half of the old A space is reserved and so is most of the old C space and above. We exhausted the old B space and created a limited address space crisis, but CIDR solved that. What we are constrained on is routing table space. So it's not whether IANA gets the addresses back, it's whether ISPs have to carry all the routes for all the cruft and leftovers or whether they can safely delist abandoned address blocks. Should be straightforward to do that based on traffic measurements. But don't assume that just because routes don't appear to have traffic that the address blocks aren't being used. They may have disappeared behind a firewall, where they are still being used. In which case they could safely be delisted from the routing table or safely aggregated. --Kent

1 0

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