- NANOG - lists.nanog.org

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

Continued IP Spoofing Attacks (INFO#95.16723)
by CERT Coordination Center 21 Jul '95

21 Jul '95

-----BEGIN PGP SIGNED MESSAGE----- ============================================================================== CONTINUED IP SPOOFING ATTACKS CERT Coordination Center July 21, 1995 ============================================================================== **** This note is the same ``heads-up'' that was originally sent on June 29, **** 1995. It is being resent because some recipients were unable to read **** it. Because of the importance of the subject matter, we are resending **** with a PGP signature but without a MIME header. Over the past few weeks, we have received reports of 170 IP spoofing attacks against Internet sites internationally. We are sending you this "heads-up" because you, a network service provider, are a likely target. At least 80 of the targets we know of are name servers, routers, and other network operation systems. The attacks have been largely successful, we continue to receive reports, and we are concerned that more attacks are going undetected. We urge you to check your systems and routers for any signs of compromise and to use the information in CERT advisory CA-95:01, "IP Spoofing Attacks and Hijacked Terminal Connections," to help protect yourself, detect IP spoofing attacks, and recover from root compromises. The advisory is available by anonymous FTP from ftp://info.cert.org/pub/cert_advisories This "heads-up" contains additional information about what you can do, as well as issues to consider before taking action. Please feel free to forward this to other providers of Internet services. What is IP Spoofing? - -------------------- To gain access, intruders create packets with spoofed source IP addresses. This exploits applications that use authentication based on IP addresses and leads to unauthorized user and possibly root access on the targeted system. Examples are the rsh and rlogin services. It is possible to route packets through filtering-router firewalls if they are not configured to filter incoming packets whose source address is in the local domain. It is important to note that the described attack is possible even if no reply packets can reach the attacker. Examples of configurations that are potentially vulnerable include: - - routers to external networks that support multiple internal interfaces - - routers with two interfaces that support subnetting on the internal network - - proxy firewalls where the proxy applications use the source IP address for authentication Communicating with us - ---------------------- Warning: For sensitive information, use encrypted email. You will find the CERT public PGP key at the end of this document. We would appreciate it if you would let us know whether you are watching for IP spoofed packets on your networks (or plan to do so). If you see spoofed packets, we'd like to learn how many you see and from how many different sites; this will help us determine the scope and pattern of the attacks. We will keep all detailed information and the identity of organizations confidential. Because of our workload, we must ask you not to send log files of activity, but we would be happy to work with you as needed on how to interpret data that you may collect. If you see activity that indicates an attack is in progress, we encourage you to contact your customer, or other involved sites or their service provider. We have some general information on IP spoofing and on recovering from a compromise that we can make available to you for your customers' use. We would also be happy to provide guidance and advice, if needed, on how to handle incidents and work with law enforcement. ............................................................................. Some things you can do - ---------------------- It is possible to check network traffic for indications of the type of attack we are currently seeing. Before doing so, please look at the next section, "Issues to consider before taking action." There are several classes of packets that you could watch for. The most basic is any TCP packet where the network portion (Class A, B, or C or a prefix and length as specified by CIDR, the Classless Inter-Domain Routing specification) of the source and destination addresses are the same but neither are from your local network. These packets would not normally go outside the source network unless there is a routing problem, worthy of additional investigation, or the packets actually originated outside your network. The latter may occur with Mobile IP testing, but an attacker spoofing the source address is a more likely cause. For a NAP or NSP, the interface into which a packet arrived indicates the direction of the source of the attack. The packet's destination address indicates the "trusted" host involved in an attack. That information suggests which hosts may be under attack. There are public domain and vendor provided tools available for checking your networks for IP spoofed packets. Among them are Argus, tcpdump, and snoop. Argus 1.5 - --------- Argus is an IP network transaction-auditing tool developed at the Software Engineering Institute of Carnegie Mellon University. The Argus 1.5 distribution includes scripts that perform simple network administrative tasks, one of which is IP spoofing detection. The data that Argus generates makes it possible to analyze network activity and performance in ways that have not been possible before. For example, you can answer questions such as, "Were there any IP spoofing attempts into our firewall network over the past 8 hours?" The developers of Argus have made the tools available from ftp://ftp.sei.cmu.edu/pub/argus-1.5 If you have any questions, comments, or suggestions, please send mail to argus(a)sei.cmu.edu. Scripts - ------- At the end of this document ("Attachment A") are scripts you may want to use to check your network. We are aware that the Internet is now "classless," meaning that the old notion of class A, B, and C addresses is being replaced with a prefix and length notation, also known as CIDR. Even so, the scripts, which are based on classes, may be useful to some service providers. In all the IP spoofing incidents reported to us to date, we believe that the scripts would have shown the spoofed packets. (The problem here is that these scripts may either show other packets labeled as spoofed or not show true spoofed packets due to CIDR.) A standalone machine running tcpdump or equivalent should be able to run these scripts without affecting the performance of the local net. It may be possible to configure routers to do this check directly but we are not currently aware of any systems on which this is possible. .............................................................................. Issues to consider before taking action - --------------------------------------- Before writing this "heads-up," we consulted colleagues on other response teams, several network service providers, and other technical experts. They raised the following issues, and there surely are others you should consider before taking action. Technical and performance issues: - There may be too many "false positives." Two causes are mobile IP and misconfigurations; there may be other causes as well. - The feasibility of installing network monitors may depend on network topology. - It is not clear how many monitoring machines you would need to pinpoint the problem. - When the tcpdump and snoop scripts were tested on a dedicated Sun IPX connected to a T1, the impact on performance was only marginal. Long-haul tests with similar scripts do not have performance problems either. - Anything above a T1 is going to cause some performance problems (applications like tcpdump and snoop do not work very well at all on DS3 or FDDI interfaces). Legal issues: - - Some service providers believe that checking your network as we suggest is all right; others believe that there may be a problem. We urge you to check with your legal advisors about analyzing packet header information, analyzing traffic content to detect unauthorized activity, and analyzing internal traffic and customer-bound traffic. - - For US service providers, the Digital Telephony Bill of 1994 is relevant; in particular, check the amended provision found at 18 U.S.C. 2511(2) (a) (i), which permits an electronic communications service and its employees to ...intercept, disclose, or use that communication in the normal course of...employment while engaged in any activity which is a necessary incident to the rendition of...service or to the protection of the rights or property of the provider of that service.... .............................................................................. Attachment - Scripts for Checking Networks - -------------------------------------------- We have tested the following scripts on a recent version of tcpdump and snoop (192.9.200.0 would be replaced by the site's local net, of course): --- script for tcpdump --- #!/bin/sh tcpdump 'tcp and not dst net 192.9.200.0 and ( (ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]) )' (Note this only seems to work with tcpdump-3.0.2 and libpcap-0.0.6 currently.) --- script for snoop --- #!/bin/sh snoop 'tcp and not net 192.9.200.0 and ((ip[12]&0x80=0 and ip[12]=ip[16]) or (ip[12]&0xc0=0x80 and ip[12]=ip[16] and ip[13]=ip[17]) or (ip[12]&0xe0=0xc0 and ip[12]=ip[16] and ip[13]=ip[17] and ip[14]=ip[18]))' (Note that this does not appear to work with Solaris 2.3 machines.) To more accurately analyze network traffic, it is useful to first describe the network topology; for example: ---------------- | INTERNET | ---------------- | ---------- | | NETWORK | ---------------- | MONITOR | | ROUTER | ---------- ---------------- | | | | ----------------------------------------------------------------- |MAC-A |MAC-B |MAC-C --------- --------- --------- |ROUTER | |ROUTER | |ROUTER | --------- --------- --------- | | | | | | | | | | | | | | | | | | | | | | | | | | | Ca Cb Cc Cd Ce Cf Cg Ch Ci (MAC-A, MAC-B, and MAC-C refer to the ethernet addresses of the router interfaces attached to the same network as the network monitor machine.) In this case, the machine used to check network traffic could be any machine capable of running tcpdump, snoop, or any other packet capture and analysis software. This machine could be programmed so that any packets that match the following expression are displayed. tcp and ( not ether src MAC-A and ( src net Ca or src net Cb or src net Cc ) not ether src MAC-B and ( src net Cd or src net Ce or src net Cf ) not ether src MAC-C and ( src net Cg or src net Ch or src net Ci ) ) This expression looks at the source address of each packet and identifies those that did not originate from the correct interface. This example should be extensible to take CIDR into account. For example, if the CIDR specification of network Ca is 192.9.200/21, then the sub-expression: src net Ca should be replaced with: ip[12:4]&0xfffff800=192.9.200.0 .............................................................................. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMA/8F3VP+x0t4w7BAQGKfgQArR6jBz+HjRbPBRAjO88aNIaH/ZbBzt1K cPDE54nLWa0+CP4F4ZWhn+UH1SMdRrLFdYZdD1sn5j56zx+nXmzo2sL3eRvylpdp LigpavVWJoOoC8XY8AJqUCT+A4txd4QacawGZMMbedIi9IyzU/33ia7BIb4wW/k6 bidvD0ExGNQ= =nyX9 -----END PGP SIGNATURE-----

1 0

Internic procedure problems
by Michael Dillon 21 Jul '95

21 Jul '95

I've been thinking about this incident with the wrong address in the .net domain for ns2.bc.net and I have come to the conclusion that the Internic needs to review some of their procedures. First of all, I wonder why they don't run a sanity check on the top level zone files from time to time to make sure that the correct domain names and IP addresses are recorded. If this were done and a sanity check was also done at the time of any changes to the zone files, then this kind of problem would not occur. THis is not the first time I have encountered such a problem. A few weeks ago I helped a small college in California sort out a problem with their email which was the result of the incorrect nameserver being recorded in the .ca.us domain. Another thing that would be nice to see is some method for updating domain information similar to the way routing policy is updated. If I wish to change secondary nameservers, I should be able to directly update records for my domain rather than submit an email request and wait 3-4 weeks for an overworked human being to get around to it. This is especially irritating for us because when we switched providers and therefore needed to switch secondary nameservice, it only took a few days to get the in-addr domains changed but our .net domain is dragging on forever. 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

3 2