- Test - lists.nanog.org

Urp... Announcement of 208.x.x.x
by Avi Freedman 29 Nov '95

29 Nov '95

I just noticed that AS 3847 was announcing 208.0.1.0/24, 208.0.4.0/24, 208.0.5.0/24, and 208.0.9.0/24. Now, besides the fact that they could announce 208.0.4.0/23 ( :) ), those addresses aren't quite kosher-ly allocated, are they? Is there a spot where the Internic communicates what address space has been allocated? ("We are now allocating out of 207.x.x.x") Avi

2 2

Re: outages, quality monitoring, trouble tickets, etc
by Jeff.Ogden＠um.cc.umich.edu 29 Nov '95

29 Nov '95

OK. I am a small network service provider and I have two customers. One has service that is available 100% of the time. The other has service that due to various problems is available only 50% of the time (not sure why they stay with me, but I am happy to take their money). So what is the availability that I should report to potential new customers? 100% 50% or 75% Does it matter that the reason the one customer has only 50% availability is that the room where the router at that customer's site is underwater every other day due to no fault of my own? It is because of these sorts of questions that I never know what it means when someone says that their network is available 99.9% of the time. Hell at least part of MichNet is available 100% of the time, but that never seems to cut it with the folks who don't have service right now. -Jeff Ogden Merit/MichNet

5 6

URL mixup
by Susan R. Harris 29 Nov '95

29 Nov '95

My apologies for mixing up the URLs in this afternoon's "new RA tools" message. The tools for generating NAP routing table and route flap reports are both available at: http://www.ra.net/~ra/statistics/ --Susan Harris

1 0

Re: outages, quality monitoring, trouble tickets, etc
by Sean Donelan 28 Nov '95

28 Nov '95

>From: kwe(a)6SigmaNets.COM (Kent W. England) >I'm skeptical of any end-to-end availability figures over 97%. I don't >think they reflect the reality of leased line circuits today, or else they >don't include the leaf node circuits and only report backbone availability. >For a highly redundant backbone, almost any definition of availability >should result in a number like 99.mumble%. Remember 99.9% availability >means less than 9 hours outage per year. Routing hiccups take that much. >One or two leased lines outages is all you get for 9 hours. The real world >is a lot less available than that. Thank you! I thought I was living in a twilight zone with people reporting 99.9% network availability. This is the rathole end-to-end network useablity. The customer is interested in end-to-end useability. While the network operator can only easily measure intra-network modules. I can't tell you the answer, but there is definitely something happening with customer perceptions of Internet useability. Looking at the numbers I would agree a single leased circuit should be less reliable (single point of failure) than a highly redundant backbone. But by our customer perceptions, that isn't the case. Either we have better than "normal" leased circuits, or the highly redundant backbones aren't, or our customers needs are based something we aren't directly measuring. Highly redundant backbones remain extremely vunerable to the "glitch." Human glitches, software glitches, "impossible" data glitches. Redundant backbones do protect against the backhoe "glitch." >But since half the web servers I try to talk to refuse me half the time, >I'm not sure that network availability per se (HWB's complaints duly >acknowledged) is the tallest pole in the tent. Part of this problem is the growing number of interdepencies (complexity, chaos?). Even if each individual module is working 99.9% of the time, the probabilities start looking pretty bad when all need to be working at the same time. To make a web connection, you have a string of name servers, a string of networks to the name servers, a string of routers on those networks, another string of networks to the web server, another string of routers, more strings of networks and routers and servers on the return path. I'm amazed it even works 50% of the time. Unfortunately our customers aren't always as understanding. Since error reporting sucks in most network applications, it becomes the fault of whatever help desk happens to take the customers phone call. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: CIDR FAQ
by Steven J. Richardson 28 Nov '95

28 Nov '95

Hank: I'd really appreciate just getting this much message. Thanks, Steve R./Merit > Date: Tue, 28 Nov 95 13:11:21 IST > From: Hank Nussbacher <HANK(a)taunivm.tau.ac.il> > To: cidrd(a)IEPG.ORG, nanog(a)merit.edu, inet-access(a)earth.com, iap(a)vma.cc.nd.edu, local-ir(a)vma.cc.nd.edu, local-ir(a)apnic.net > > ------------------------------------------------------------------------ > The CIDR FAQ > Version 5 > 15 November 1995 > ------------------------------------------------------------------------ > The following document is a collection of Frequently Asked Questions > about CIDR. This document is not meant to be a networking/routing > guide and tutorial. Where appropriate pointers to other documents > of a more general nature have been mentioned. > > Updates from a previous version are marked with a '|' in column 1. > > If you have any questions you would like added, please send them to > the editor mentioned below: > > Hank Nussbacher (Tel Aviv University and IBM Israel) > hank(a)vm.tau.ac.il or hank(a)ibm.net.il > > If you would like to "discuss" items from this FAQ please send > your mail to cidrd(a)iepg.org > > This FAQ is being distributed to the following groups and lists: > alt.internet.services > alt.internet.access.wanted > nanog(a)merit.edu > inet-access(a)earth.com > iap(a)vma.cc.nd.edu > local-ir(a)ripe.net > cidrd(a)iepg.org > |local-ir(a)apnic.net > > To retrieve the most up-to-date version of this document: > |- ftp://ftp.ibm.net.il/pub/docs/cidr.faq > |- http://www.rain.net/faq/cidr.faq.html > ------------------------------------------------------------------------

1 0

Re: outages, quality monitoring, trouble tickets, etc
by Jonathan Heiliger 28 Nov '95

28 Nov '95

On Nov 27, 9:17am, Sean Doran wrote: > Jonathan> Everyone likes to portray > Jonathan> the image of having a 99.98% uptime whenever > Jonathan> possible, even though most folks realize > Jonathan> that it just plain isn't possible > > Well, more importantly, what on earth does a number like > that mean? Sorry, bad choice of words. Rather than uptime, availability would be the proper word. Availability tends to be the amount of time the network is "available" for the customer to receive their expected service (whether guaranteed in writing or not), and for the customers expectation of how the service will perform when it is considered "in-service" is met. -jh-

4 3

New tools from the RA project (fwd)
by Elise Gerich 28 Nov '95

28 Nov '95

FYI....just in case you all aren't on these other lists. --Elise >Susan R. Harris writes: > From owner-cidrd(a)aarnet.edu.au Tue Nov 28 17:01:20 1995 > Date: Tue, 28 Nov 1995 16:47:35 -0500 (EST) > From: "Susan R. Harris" <srh(a)merit.edu> > To: cidrd(a)iepg.org, bgp(a)ans.net > Subject: New tools from the RA project > Message-ID: <Pine.SUN.3.91.951128164516.1874K-100000(a)home.merit.edu> > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Greetings - Just a quick note to let you know about some new tools > available from the Routing Arbiter project. Comments and bug reports > welcome; please send 'em to ra-team(a)ra.net. > > > A new RADB tool tells you which RADB routes in an AS are duplicated or > covered by less specific routes in the IRR: > > http://www.ra.net/~ra/RADB.tools.docs/.reports.html > > > A new tool to generate Internet routing table reports for each NAP > tells you (1) the maximum number of announced routes in the Route > Server's routing tables, (2) the complete Internet routing table, > listed by prefix and associated AS path, as seen by the NAP's Route > Servers, or (3) the number of routes seen by each Route Server, listed > by RS peer and origin AS. > > The reports in (2) from the Washington, D.C. NAP (MAE-East) have shown > some interesting numbers, like 32-bit host announcements and prefixes > reserved by RFC 1597 (private internet address allocation). > > > You can now generate NAP route flap reports by RS peer as well as by > AS origin, prefix, and specific AS: > > http://www.ra.net/~ra/statistics/.routes.html > ------------------------------------------------------------------------ > Susan R. Harris, Ph.D. Merit Network, Inc. srh(a)merit.edu > Phone: (313) 936-2100 Fax: (313) 747-3185 > ------------------------------------------------------------------------ > > > >

1 0

New tools from the RA project
by Susan R. Harris 28 Nov '95

28 Nov '95

Greetings - Just a quick note to let you know about some new tools available from the Routing Arbiter project. Comments and bug reports welcome; please send 'em to ra-team(a)ra.net. > A new RADB tool tells you which RADB routes in an AS are duplicated or covered by less specific routes in the IRR: http://www.ra.net/~ra/RADB.tools.docs/.reports.html > A new tool to generate Internet routing table reports for each NAP tells you (1) the maximum number of announced routes in the Route Server's routing tables, (2) the complete Internet routing table, listed by prefix and associated AS path, as seen by the NAP's Route Servers, or (3) the number of routes seen by each Route Server, listed by RS peer and origin AS. The reports in (2) from the Washington, D.C. NAP (MAE-East) have shown some interesting numbers, like 32-bit host announcements and prefixes reserved by RFC 1597 (private internet address allocation). > You can now generate NAP route flap reports by RS peer as well as by AS origin, prefix, and specific AS: http://www.ra.net/~ra/statistics/.routes.html ------------------------------------------------------------------------ Susan R. Harris, Ph.D. Merit Network, Inc. srh(a)merit.edu Phone: (313) 936-2100 Fax: (313) 747-3185 ------------------------------------------------------------------------

1 0

Re: outages, quality monitoring, trouble tickets, etc
by Sean Doran 28 Nov '95

28 Nov '95

>"it's AOL's fault" because the provider themselves didn't properly >set up an RADB entry so the ANS network ... I find it amusing that the only utility ascribed to the RADB by network operators almost always has to do with being reachable from ANS. It's also tragic, actually. I'm glad that my taxes go up to the receiver-general for Canada sometimes rather than going to a project which frequently appears to benefit one and only one U.S.-based network service provider. Anyway, typically the only time we hear problems with respect to the RADB is when someone wants to talk to AOL and cannot, or when some ANS customer can't get to anything behind us or somewhere downstream from us. It'd be very interesting to see what happens to the RADB the second AOL has Internet connectivity through another provider... It'd certainly reduce the incidence of people updating the RADB to fix disconnectivities. Sean.

1 0

CERT Summary CS-95:03
by CERT Advisory 28 Nov '95

28 Nov '95

--------------------------------------------------------------------------- CERT Summary CS-95:03 November 28, 1995 The CERT Coordination Center periodically issues the CERT Summary to draw attention to the types of attacks currently being reported to our incident response staff. The summary includes pointers to sources of information for dealing with the problems. We also list new or updated files that are available for anonymous FTP from ftp://info.cert.org Past CERT Summaries are available from ftp://info.cert.org/pub/cert_summaries --------------------------------------------------------------------------- Recent Activity --------------- Since the September CERT Summary, we have seen these continuing trends in incidents reported to us. The majority of reported incidents fit into four categories: 1. Packet Sniffers We continue to see daily incident reports about intruders who have installed sniffers on compromised systems. These sniffers, used to collect account names and passwords, are frequently installed with a kit that includes Trojan horse binaries. The Trojan horse binaries hide the sniffer activity on the systems on which they are installed. For further information and methods for detecting packet sniffers and Trojan horses, see the following files: ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://info.cert.org/pub/cert_advisories/CA-94:01.README ftp://info.cert.org/pub/cert_advisories/CA-94:05.MD5.checksum ftp://info.cert.org/pub/cert_advisories/CA-94:05.README 2. Exploitation of SGI lp Vulnerability The vulnerability described in CERT advisory, CA:95:15 "SGI lp Vulnerability" continues to be exploited, though we have seen a decline in the number of reports since the advisory was released on November 8. Intruders gain unauthorized access to Silicon Graphics, Inc. (SGI) IRIX systems through a passwordless lp account; they use this initial access to leverage additional privileges on the compromised system. As distributed by SGI, the lp account (as well as other accounts), has no password on a newly installed system. This fact is addressed in the documentation that SGI distributes with their systems: "IRIX Advanced Site and Server Administrative Guide" (see the chapter on System Security). More information on this vulnerability and how it can be addressed can be obtained from ftp://info.cert.org/pub/cert_advisories/CA-95:15.SGI.lp.vul 3. Network Scanning We continue to receive several reports each week of intruders using the Internet Security Scanner (ISS) to scan both individual hosts and large IP address ranges. The ISS tool, which is described in CERT advisory CA-93:14 "Internet Security Scanner", interrogates all computers within a specified IP address range, determining the security posture of each with respect to several common system vulnerabilities. Intruders use the information gathered from such scans to gain unauthorized access to the scanned sites. As part of a defensive strategy, you may want to consider running ISS against your own site (in accordance with your organization's policies and procedures) to identify any possible system weaknesses or vulnerabilities, taking steps to implement security fixes that may be necessary. ISS is available from ftp://info.cert.org/pub/tools/iss/iss13.tar More information about the ISS tool and steps for protecting your site are outlined in the following documents: ftp://info.cert.org/pub/cert_advisories/CA-93:14.Internet.Security.Scanner ftp://info.cert.org/pub/cert_advisories/CA-93:14.README ftp://info.cert.org/pub/tech_tips/security_info ftp://info.cert.org/pub/tech_tips/packet_filtering 4. Sendmail Attacks New reports of intruders attacking sites through sendmail vulnerabilities are continuing to arrive daily, although most reports indicate the attacks have failed. The types of attacks are varied, but most are aimed at gaining privileged access to the victim machine. We encourage sites to combat these threats by taking the appropriate steps, described in the following documents: ftp://info.cert.org/pub/cert_advisories/CA-95:05.sendmail.vulnerabilities ftp://info.cert.org/pub/cert_advisories/CA-95:05.README ftp://info.cert.org/pub/cert_advisories/CA-95:08.sendmail.v.5.vulnerability ftp://info.cert.org/pub/cert_advisories/CA-95:08.README ftp://info.cert.org/pub/cert_advisories/CA-95:11.sun.sendmail-oR.vul ftp://info.cert.org/pub/cert_advisories/CA-95:11.README What's New in the CERT FTP Archive ---------------------------------- We have made the following changes since the last CERT Summary (September 26, 1995). * New Additions ftp://info.cert.org/pub/cert_advisories/ CA-95:12.sun.loadmodule.vul CA-95:13.syslog.vul CA-95:14.Telnetd_Environment_Vulnerability CA-95:15.SGI.lp.vul ftp://info.cert.org/pub/cert_bulletins/ VB-95:07.abell (lsof) VB-95-08.X_Authentication_Vul ftp://info.cert.org/pub/tools/sendmail sendmail/sendmail.8.7.1.tar sendmail/sendmail.8.7.1.tar.Z * Updated Files ftp://info.cert.org/pub/cert_advisories/ CA-93:16a.README (sendmail - note to use smrsh with all versions) CA-95:05.README (sendmail - date of Digital Equipment's patch) CA-95:08.README (sendmail - note to use smrsh with all versions) CA-95:10.README (ghostscript - patches and explanations) CA-95:13.README (syslog - information from vendors) CA-95:14.README (telnetd - information from vendors; correction to compilation example) ftp://info.cert.org/pub/tools/cops README (more recent email address for COPS author Dan Farmer) --------------------------------------------------------------------------- How to Contact the CERT Coordination Center 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 To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request(a)cert.org CERT advisories and bulletins are posted on the USENET news group comp.security.announce If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. We can support a shared DES key, PGP, or PEM (contact CERT staff for details). Location of CERT PGP key ftp://info.cert.org/pub/CERT.PGP_key --------------------------------------------------------------------------- Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and credit is given to the CERT Coordination Center. CERT is a service mark of Carnegie Mellon University.

1 0