July 1995 - Test - lists.nanog.org

Re: US Domain -- County Delegations
by nordlund＠databank.com 27 Jul '95

27 Jul '95

>On Wed, 26 Jul 1995, Paul A Vixie wrote: > >> >Or, even better, for major metropolitan areas like SF, LA, NYC, >> >CHI etc the name central city can be used instead of state. >> >> I like this idea. (Note that VIXIE.SF.CA.US has moved many times since its >> creation, and though I've always been in the Bay Area I've not lived in San >> Francisco since 1988.) > >This would seem to indicate that geographical domains are a bad idea and >that domain names should be based on some characteristic that is less >likely to change over time. > >VIXIE.BIND.HACKER ? > >Michael Dillon Voice: +1-604-546-8022 >Memra Software Inc. Fax: +1-604-542-4130 >http://www.memra.com E-mail: michael(a)memra.com > How much do we want to use the .US domain? For heavy use, we need a style for organizations that are beyond cities, countys or even states. I support a style that will be organization.US or maybe organization.COM.US (of all things). Dave Nordlund Dir of Technical Svcs Databank, Inc 913/842-6699 1473 Hwy 40 nordlund(a)databank.com Lawrence, KS 66044 "Your Key to the Internet"

1 0

Re: US Domain -- County Delegations
by Barney Wolff 27 Jul '95

27 Jul '95

>Date: Thu, 27 Jul 1995 07:48:42 -0700 >From: Paul A Vixie <paul(a)vix.com> > >> The whole point of a name space is to make things easier to remember. > >This is the old invariant. It's varied. I'm still waiting for a proposal >for a hierarchy which will hold 25,000,000 names and still have them all >easy to remember, or easy to guess from external knowledge. > >The new "whole point of" the DNS name space is to provide names which change >less often than IP addresses change. If we could do just that we'd be winning. I'd like to question that 25e6 figure. It's one "mid-to-large" (to quote you) company in the US for every 10 inhabitants. Really? Is it perhaps a world figure instead? If we want a hash that's easy to compute from the company name, use the first three characters of the name, not something which requires external knowledge. It certainly does not solve the name-conflict problem, but it does provide sufficient division of the namespace to make the load on any one branch bearable, both for name service and for registration. Barney Wolff <barney(a)databus.com>

1 0

Re: US Domain -- County Delegations
by Hans-Werner Braun 27 Jul '95

27 Jul '95

It appears to me that we are making some rather weird assumptions here, based on history in other environments (like current domain names, phone numbers, USMail addresses, and so). It is not so clear to me that there will always be a one-to-one mapping between the destination one wants to reach, and some name like vixie.sf.ca.us. Eventually such strict bindings will hurt us even more than they do today. What do you really want? Well, I want to email Joe Smith? No way, there are too many of those, give me more information? So, eventually may be we have to deal with more levels of indirection and some data base support that allows us to zoom in, and, like it or not, perhaps introduce some margin of error ("sorry, wrong number, find another Vixie"). I think in our discussions we have ways too much a historical Internet perspective with strict bindings in mind, and names and addresses that are supposed to last for lfetimes. This will not work. Ther are too many people, too many companies, too many mapping strategies out there. Whether I email to "Vixie, the bind dude," or "Vixie, the networking person living in Northern California," may be there should be algorithms and facilities in place that map those to the same person. Perhaps even in ways the information (such as email) follows him, rather than him having to chase after his email (e.g., remap his "current" location when/after he moves). What names or addresses things eventually map to should be fairly irrelevant in terms of perceived complexity, as you'd alias Joe Smith@whereever to some short version in your personal alias/nickname file anyway. Or is that just mapping information for a data base supported translation server?

3 2

Re: US Domain -- County Delegations
by postel＠ISI.EDU 27 Jul '95

27 Jul '95

Hi. For every idea you have for structured names in the US domain, please consider how many names there will be in each component of the structure, and then consider how your would maintain a zone file of that size. Be realistic about how many companies, organizations, and individuals there are in the US. Assume they will all want domain names. --jon.

1 0

Re: US Domain -- County Delegations
by Scott Bradner 26 Jul '95

26 Jul '95

> Each state Department of Motor Vehicles maintains a two or three character representation of the county names for display on driver's licenses. there is also a 5 digit FIPS code for each county and I am working with a group that may want to support servers for it. Scott

1 0

Call for Advice
by Laurent Joncheray 26 Jul '95

26 Jul '95

As part as the RA contribution to the Community, we plan to develop a tool to convert Cisco Configuration files into RIPE-181 syntax objects. In order to make this tool the more generic as possible we need samples of real Cisco config files. If you are interested in this tool, and like to help in the development, you can send me (lpj(a)merit.edu) your favorite Cisco Configurations so i can gather some good examples of what people write in they config. Of course those files will be kept confidencial and won't be given to anybody. Thanks for your help, Laurent PS: Don't forget to remove the passwords from the files :-) PS/2: My PGP public key is on finger lpj(a)home.merit.edu if yo want to encrypt files. -- Laurent Joncheray, E-Mail: lpj(a)merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM

1 0

CERT Summary CS-95:01
by CERT Advisory 26 Jul '95

26 Jul '95

--------------------------------------------------------------------------- CERT Summary CS-95:01 July 26, 1995 As part of our ongoing efforts to disseminate timely information about Internet security issues, the CERT Coordination Center is pleased to announce the CERT Summary. CERT Summary will be distributed periodically to call attention to the types of attacks currently being reported to the CERT Coordination Center. The summary will include pointers to sources of information for dealing with the problems. --------------------------------------------------------------------------- Recent Activity The majority of incidents reported to the CERT Coordination Center in recent weeks fall into three categories: 1. IP Spoofing: We have seen a surge in IP spoofing. In recent weeks, we have received more than 170 reports of IP spoofing attacks or probes, many of them resulting in a successful break in. Several sites believed incorrectly that they were blocking such packets. Others planned to block them but hadn't yet done so. We urge you to take the time to review CERT Advisory CA-95:01, "IP Spoofing Attacks and Hijacked Terminal Connections," which has details on this type of attack and how to prevent it. Vulnerability to IP spoofing attacks is NOT limited to any specific router or OS vendor. This advisory is available from ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing ftp://info.cert.org/pub/cert_advisories/CA-95:01.README 2. Packet Sniffers: We receive new reports daily that describe sniffers installed on compromised hosts. These sniffers, which are used to collect account names and passwords, are frequently installed using a kit. Further information on packet sniffers is available from ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README Once root is compromised on a system, the sniffer kit can be activated to collect account names and passwords. Note that even if sniffing capabilities are disabled by recompiling and rebooting the kernel, we have received reports of intruders re-enabling these capabilities by recompiling and rebooting systems. Pay particular attention to every system reboot. In the attacks that we have seen, intruders frequently install (as root) Trojan horse system software that is available with the sniffer kit. Further information on the Trojan horses that we have seen is available from ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums ftp://info.cert.org/pub/cert_advisories/CA-94:05.README 3. NFS Attacks: We have seen a large increase in the number of attacks and probes against weaknesses within NFS. Again, many of these are successful. Programs to automate such attacks have become widespread. Please review CERT Advisory CA-94:15, "NFS Vulnerabilities," and its associated README file. They are available from ftp://info.cert.org/pub/cert_advisories/CA-94:15.NFS.Vulnerabilities ftp://info.cert.org/pub/cert_advisories/CA-94:15.README A successful attack usually results in the intruders gaining root access. Intruders have been targeting machines with vendor-licensed source code. They appear to be in search of the code for system software with the view to creating and installing copies containing Trojan horses on compromised systems. If you manage systems that contain vendor-licensed source code, pay particular attention to the "Security Measures" section of the advisory. ------------------------- New Trojan Horse Programs Once root has been compromised on a system, we are finding new Trojan horses installed in the inetd and in.rexecd daemons. These Trojan horses allow an intruder to gain access at a later time, bypassing most firewall and TCP wrapper configurations. Do not rely on checksums determined by the sum(1) program because intruders are creating files whose checksums match those of the vendor-distributed versions. Do not rely on time stamps of these files either because intruders are setting these to previous values as well. We recommend that you use a known clean version of cmp(1) to make a direct comparison of the binaries and the appropriate distribution media. Alternatively, you can check the MD5 results on suspect binaries against a list of MD5 checksums from known good binaries. Ask your vendor to make MD5 checksums available for their distribution binaries. You can also consult the following for some additional information on MD5: ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums ftp://info.cert.org/pub/cert_advisories/CA-94:05.README In addition, tools such as Tripwire can archive MD5 checksums of known good binaries when used immediately after a system installation. If you use Tripwire, you should regularly maintain the checksums on removable or read-only media. For more details on Tripwire and MD5, see the CERT security checklist: ftp://info.cert.org/pub/tech_tips/security_info We are also seeing Trojan horses introduced into shared object libraries. Examples are /usr/lib/libc.so.* and /usr/kvm/libkvm.so.* on SunOS-based machines. Although we have only received reports of SunOS-based machines being altered, the techniques used by intruders are applicable to other systems that use shared object libraries. These libraries are being modified so that the presence of certain directories and processes cannot be detected with vendor-provided programs or public domain programs built to use shared object libraries. This means that ANY program using these shared libraries will act in the manner described by the intruder without the intruder necessarily having to modify the program itself. The Trojan horse daemons previously described typically become "invisible" to programs such as ps once the kvm shared object library has been modified. Similarly, the directories used by intruders for building these daemons are "invisible" once the libc shared object library has been modified. Again, do not rely on checksums using sum(1) or time stamps to detect altered files. Use a known clean version of cmp(1) or a strong checksum technique such as MD5 to verify your files against the appropriate distribution. --------------------------------------------------------------------------- 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 e-mail 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 e-mail: 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 news group 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 by anonymous FTP from info.cert.org. --------------------------------------------------------------------------- Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University.

1 0

US Domain -- County Delegations
by US Domain Registration 26 Jul '95

26 Jul '95

Hello. We are planning to delegate every county name as a locality name in each State. For example, "Ventura.CA.US", "Dade.FL.US", "Riverside.CA.US". We are looking for volunteers to support the domain name registration and provision of name servers for these county domains. If you are interested in providing this service please return the template below. For further information about the US Domain please see RFC 1480. In the case where only one party requests a county delegation, they will be given that delegation. To be fair, where several requests are made for the same county(ies) those requests will be put in a hat and selected by lottery. If a locality name has already been delegated or it is both a city and county name we will not re-delegate it as a county. Only full names for counties, spelled out, with hyphens replacing spaces (e.g., Santa-Monica, or Fort-Collins"), will be considered. We must have a separate template for each county requested. It is important that you accurately fill in all the information requested on the template. If you alter it in any way, other than what is specified, it might not be considered. The data you supply will also be used to create your WHOIS entry. Be sure to accurately describe your domain name on the corresponding description question. Locality names should be in the following form: 2. Fully Qualified Domain Name 4. Description of Org/Domain ============================== ============================ VENTURA.CA.US Ventura, California DADE.FL.US Dade, Florida RIVERSIDE.CA.US Riverside, California We no longer use Internic NIChandles (Idents). We are creating our own US Domain Handles. It is important that you complete the Administrative and Technical contact information in full. We added an optional question "7j" for a Registration Request mailbox (i.e, hostmaster, support, dns-admin). We will accept all requests up to August 31, 1995. The current list of locality delegations can be found in the "us-domain-delegated.txt" file. For a list of counties in your state an atlas is a good place to look. RETRIEVAL OF DELEGATED SUBDOMAINS and CONTACTS URL: ftp://ftp.isi.edu/in-notes/us-domain-delegated.txt E-MAIL: To: RFC-INFO(a)ISI.EDU (include in message body) Help: us_domain_delegated_domains Ann Cooper US Domain Registry US DOMAIN TEMPLATE [7/95] PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY. Fields marked with an asterisk (*) may be duplicated. ************************************************************************** 1. REGISTRATION TYPE (N)ew (M)odify (D)elete..: 2.* FULLY-QUALIFIED DOMAIN NAME: 3. ORGANIZATION INFORMATION 3a. Organization Name.....: 3b. Address Line 1........: 3b. Address Line 2........: 3c. City..................: 3d. State.................: 3e. Zip/Code..............: 4. DESCRIPTION OF ORG/DOMAIN: 5. Date Operational......: 6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN 6b. Whole Name............: 6c. Organization Name.....: 6d. Address Line 1........: 6d. Address Line 2........: 6e. City..................: 6f. State.................: 6g. Zip/Code..............: 6h.* Voice Phone...........: 6i.* Electronic Mailbox....: 6j. FAX Number............: 7. TECHNICAL AND ZONE CONTACT 7b. Whole Name............: 7c. Organization Name.....: 7d. Address Line 1........: 7d. Address Line 2........: 7e. City..................: 7f. State.................: 7g. Zip/Code..............: 7h.* Voice Phone...........: 7i.* Electronic Mailbox....: 7j.* Registration Mailbox..: 7j. FAX Number............: 8. PRIMARY SERVER: HOSTNAME, NETADDRESS 8j. Hostname..............: 8k.* IP Address ...........: 9. * SECONDARY SERVER: HOSTNAME, NETADDRESS 9a.* Hostname..............: 9b.* IP Address............: ^L ************************************************************************** DISCLAIMER By the registration of your name on the Internet, the IANA, the InterNIC, Network Solutions Inc., the University of Southern California, and the National Science Foundation are accepting in good faith that you have the right to the use the name. The IANA and InterNIC/Network Solutions' function in registering names on the Internet is to assure that the name does not conflict with any other name in the name space requested. The user by its registration and use of the name and/or their continued use of an existing name, agrees, as part of their request for name registration, to indemnify and hold harmless from any and all costs, fees, expenses arising from litigation involving trademark, trade name, service mark, and any other name infringements, or other reasons, the IANA, the InterNIC, Network Solutions Inc., the University of Southern California, and the National Science Foundation. The party requesting registration of this name certifies that to her/his knowledge, the use of this name does not violate trademark or other statutes. Registering a domain name does not confer any legal rights to that name and any disputes between parties over the rights to use a particular name are to be settled between the contending parties using normal legal methods (See RFC 1591). **************************************************************************

2 1

Subscribe
by ser＠exodus.net 25 Jul '95

25 Jul '95

Who do I email to get on the NANOG list? -- Steven Eric Rubin - Senior Network Administrator Exodus Communications, Inc. 948 Benecia Ave, Sunnyvale, CA 94086 Email: ser(a)exodus.net - Phone: (408) 522-8473

1 0

CERT Vendor-Initiated Bulletin VB-95:05 - OSF
by CERT Bulletin 21 Jul '95

21 Jul '95

CERT Vendor-Initiated Bulletin VB-95:05 July 21, 1995 Topic: OSF/DCE Security Hole Source: Open Software Foundation (OSF) To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from the Open Software Foundation. OSF urges you to act on this information as soon as possible. OSF 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============================ Advisory on OSF/DCE Security Hole July 19, 1995 It has been discovered that OSF/DCE security has a flawed aliasing mechanism in its registry that can potentially yield a less secure DCE cell. PROBLEM: Multiple administrators in a DCE cell (i.e., principals with the privileges required to create principals and accounts within the DCE registry), some of which are intended to be less trusted than the cell administrator (e.g., principals intended to be restricted to create principals and accounts only within a subset of DCE registry name space), cannot be prevented from acquiring full privileges of the cell administrator. Due to a flaw in the DCE security registry such less privileged administrators are able to gain full privileges by creating an alias to the cell administrator. The security server grants an alias principal full rights of the principal it is aliased to. DCE security registry principals are generally not allowed to create accounts. Only an account designated as some type of administrator, by explicitly creating ACL entries for that principal, allows it to do things to the registry that normal users are not allowed to do, that is, create principals and accounts in a certain part of the security name space. In OSF/DCE as it ships, only cell_admin is given such privileges. To that effect, the DCE cell administrator can prevent any loss of security by following the guidelines described below. HOW TO AVOID: This security hole has existed in all releases of OSF/DCE todate. To avoid the problem in releases prior to OSF/DCE 1.1, the DCE cell administrators should not explicitly give registry administration rights to principals that would not otherwise have access to the cell administrator account itself. As distributed by OSF, only cell_admin is given such rights. OSF is in the process of providing a fix for this defect to DCE 1.1 support licensees for them to apply to their DCE 1.1 based products. The end-users may ask their DCE vendors for such a fix. All future releases of OSF/DCE will have this fix incorporated. ********************************************************************** OSF Systems Engineering Open Software Foundation 11 Cambridge Center, Cambridge, MA 02142 Telephone: +1 617 621 8990 E-mail: dce-support-admin(a)osf.org =========================FORWARDED TEXT ENDS HERE============================= CERT bulletins, CERT advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also 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. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail 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 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