- Test - lists.nanog.org

Re: ISP Domain Auction
by Sean Doran 11 Feb '96

11 Feb '96

I'll pay $1 (Canadian) for businessfinancing.com. Sean.

1 0

Re: [NIC-960209.1757] Routing Problem (fwd)
by Robert Du Gaue 09 Feb '96

09 Feb '96

> Regional Internet registries have no control over the routing policies > of any ISP. The IANA has instructed the Internet registries not to > assign IP addresses based on any ISP's particular routing policy, rather > on specific criteria including utilization efficiency. An organization > will be assigned the number of IP addresses it can justify. If this > number is not fully routable, that is an issue that should be taken up > with the ISP(s) concerned. This is just one big cop-out from the organization that CONTROLS who gets IP blocks. How the hell can I be a successful ISP when first, I probably can not justify 64 blocks (and if I do Sprint may change it to 128 anyways!) and second if the blocks I get are not routed through one of the MAJOR backbone proivders then they are useless to me and my end users! You are basically allowing one company to dicate policy and growth of the Internet. It's totally unfair to smaller ISPs and sets an ugly presedence as to just how the 'net will grow if you allow each organization to define their own rules that affect the Internet in general. Using old policies to justify not doing something against what is obviously discrimination against smaller ISPs does nothing to solve the problem.

1 0

more on MCI and Microsoft
by alexy＠alpha.c2.org 09 Feb '96

09 Feb '96

URL with additional leads [including the microsoft press release] http://www.zdnet.com/pcweek/berst/alert.html Alex

1 0

What are the *current* limits?
by pj＠place.org 09 Feb '96

09 Feb '96

Excuse my newbiness, but with all the current talk of reducing route table size and such, I have a few questions: What is a current router table size? How is it measured? (in routes? or kilobytes? or megabytes?) How big a router is needed to handle it? By 'big' I mean how much RAM and/or cpu is needed to deal with just routing and route table updates and flap control? Sepearte, but related, is the issue of bit shoveling. Given the minimum router that will handle a full routing table, how much bandwidth can it shovel through its various ports? I'm assuming this is related more to CPU speed than to memory constraints. Given a full routing table, how much bandwidth can routers of various sizes handle? I guess what I'm looking for are the real 'just-this-side-of-breakage' limits. So we need to reduce route table size - okay, fine, but _how much_ do we need to reduce it? at what size does it become handlable? I hope these questions make sense, I'm fairly new at this. See you at NANOG! --Paul Jimenez Freeside Communications

2 1

CERT Advisory CA-96.01 - UDP Port Denial-of-Service Attack
by CERT Advisory 08 Feb '96

08 Feb '96

============================================================================= CERT(sm) Advisory CA-96.01 February 8, 1996 Topic: UDP Port Denial-of-Service Attack ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of programs that launch denial-of-service attacks by creating a "UDP packet storm" either on a system or between two systems. An attack on one host causes that host to perform poorly. An attack between two hosts can cause extreme network congestion in addition to adversely affecting host performance. The CERT staff recommends disabling unneeded UDP services on each host, in particular the chargen and echo services, and filtering these services at the firewall or Internet gateway. Because the UDP port denial-of-service attacks typically involve IP spoofing, we encourage you to follow the recommendations in advisory CA-95:01 and CA-95:01.README. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-96.01.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description When a connection is established between two UDP services, each of which produces output, these two services can produce a very high number of packets that can lead to a denial of service on the machine(s) where the services are offered. Anyone with network connectivity can launch an attack; no account access is needed. For example, by connecting a host's chargen service to the echo service on the same or another machine, all affected machines may be effectively taken out of service because of the excessively high number of packets produced. In addition, if two or more hosts are so connected, the intervening network may also become congested and deny service to all hosts whose traffic traverses that network. II. Impact Anyone with network connectivity can cause a denial of service. This attack does not enable them to gain additional access. III. Solution We recommend taking all the steps described below. 1. Disable and filter chargen and echo services. This attack is most readily exploited using the chargen or echo services, neither of which is generally needed as far as we are aware. We recommend that you disable both services on the host and filter them at the firewall or Internet gateway. To disable these services on a host, it is necessary to edit the inetd configuration file and cause inetd to begin using the new configuration. Exactly how to do this is system dependent so you should check your vendor's documentation for inetd(8); but on many UNIX systems the steps will be as follows: (1) Edit the inetd configuration file (e.g. /etc/inetd.conf). (2) Comment out the echo, chargen, and other UDP services not used. (3) Cause the inetd process to reread the configuration file (e.g., by sending it a HUP signal). 2. Disable and filter other unused UDP services. To protect against similar attacks against other services, we recommend - disabling all unused UDP services on hosts and - blocking at firewalls all UDP ports less than 900 with the exception of specific services you require, such as DNS (port 53). 3. If you must provide external access to some UDP services, consider using a proxy mechanism to protect that service from misuse. Techniques to do this are discussed in Chapter 8, "Configuring Internet Services," in _Building Internet Firewalls_ by Chapman and Zwicky (see Section IV below). 4. Monitor your network. If you do provide external UDP services, we recommend monitoring your network to learn which systems are using these services and to monitor for signs of misuse. Tools for doing so include Argus, tcpdump, and netlog. Argus is available from ftp://lancaster.andrew.cmu.edu/pub/argus-1.5/argus-1.5.tar.gz MD5 (argus-1.5.tar.gz) = 9c7052fb1742f9f6232a890267c03f3c Note that Argus requires the TCP wrappers to install: ftp://info.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.2.tar.Z MD5 (tcp_wrappers_7.2.tar.Z) = 883d00cbd2dedd9bfc783b7065740e74 tcpdump is available from ftp://ftp.ee.lbl.gov/tcpdump-3.0.2.tar.Z MD5 (tcpdump-3.0.2.tar.Z) = c757608d5823aa68e4061ebd4753e591 Note that tcpdump requires libpcap, available at ftp://ftp.ee.lbl.gov/libpcap-0.0.6.tar.Z MD5 (libpcap-0.0.6.tar.Z) = cda0980f786932a7e2eebfb2641aa7a0 netlog is available from ftp://net.tamu.edu/pub/security/TAMU/netlog-1.2.tar.gz MD5 (netlog-1.2.tar.gz) = 1dd62e7e96192456e8c75047c38e994b 5. Take steps against IP spoofing. Because IP spoofing is typically involved in UDP port denial-of-service attacks, we encourage you to follow the guidance in advisory CA-95:01 and CA-95:01.README, 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 IV. Sources of further information about packet filtering For a general packet-filtering recommendations, see ftp://info.cert.org/pub/tech_tips/packet_filtering For in-depth discussions of how to configure your firewall, see _Firewalls and Internet Security: Repelling the Wily Hacker_ William R. Cheswick and Steven M. Bellovin Addison-Wesley Publishing Company, 1994 ISBN 0-201-63357 _Building Internet Firewalls_ Brent Chapman and Elizabeth D. Zwicky O'Reilly & Associates, Inc., 1995 ISBN 1-56592-124-0 --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Peter D. Skopp of Columbia University for reporting the vulnerability and Steve Bellovin of AT&T Bell Labs for his support in responding to this problem. --------------------------------------------------------------------------- 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). We strongly urge you to encrypt any sensitive information you send by email. The CERT Coordination Center can support a shared DES key and 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 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request(a)cert.org 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 Copyright 1996 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

Welcome to nanog
by Majordomo＠merit.edu 08 Feb '96

08 Feb '96

-- Welcome to the nanog mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo" with the following command in the body of your email message: unsubscribe nanog gia(a)indosat.go.id nanog(a)merit.edu Here's the general information for the list you've subscribed to, in case you don't already have it: North American Network Operators Group

1 0

subscribe gia@indosat.go.id nanog@merit.edu
by Subagia 08 Feb '96

08 Feb '96

subscribe gia(a)indosat.go.id nanog(a)merit.edu

1 0

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

07 Feb '96

At 01:11 PM 2/5/96 -0600, Alan Hannan wrote: > > Learn how to renumber. It really is possible, you know. > > -alan > So, Alan, are you volunteering to help us out in PIER? ;-) - paul

1 0

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

07 Feb '96

Hocus Pocus. A NAT solves this problem. :-) - paul At 08:12 AM 2/5/96 -0700, Tan Chang Hu wrote: >> >> If you have a class B and use a firewall, then a /27 should be more >> than is needed on the global Internet and they should use an address >> from RFC1597 internally and return the /16. >> >> Hank >> >Hank, > Depending on the firewall design, hosts located behind firewalls >can conceivably access the Internet directly for certain services and in >this case unique addresses are required. Your assumption would be valid >when all traffic for that site is handled by proxy servers. > >-- >T. C. Hu | tchu(a)sandia.gov >Sandia National Laboratories | Tel: (505) 845-8936 >P.O.Box 5800 | FAX: (505) 844-2067 >Albuquerque, NM 87111-0807 | > > > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: Policy Statement on Address Space Allocations
by Vince Fuller 05 Feb '96

05 Feb '96

In message <199602021946.AA16364(a)mail.crl.com>, George Herbert writes: > > >> How do Pipex and Dante get global routes right now? > > > >Oh.. from a whole bunch of different places. > > > > ANS customer routes from ANS > > MCI customer routes from MCI > > SprintLink customer routes from Sprint > > Alternet customer routes from Alternet > > AUNET routes from EUNET > > ... > > > >You get the idea. > > How do they get to Barrnet? SURAnet? Etc? Suranet is at MeaEast. Barrnet is presently an MCI transit customer. Actually, the situation is a bit more complicated than this (in case anyone really wants to know). It is the case that each of the BBN Planet regions are MCI transit customers, but BBN Planet also has presence at MAE-East, FIX-East, MAE-West, and the Pennsauken NAP. We are in the process of finalizing the peering policy for BBN Planet as an integrated whole. In the near future, we will send a notice to the provider community that describes our policy and invites others to establish bi-lateral peering agreements with us. Vince Fuller, BBN Planet Network Engineering

1 0