- Test - lists.nanog.org

Re: chicago nap questions
by reb＠aads.net 13 Dec '95

13 Dec '95

> At 8:16 PM 12/7/95, Gordon Cook wrote: > > went looking for aadsnet on ameritechs chicago nap web page > > couldn't find them. But shouldn't they be there to get the rest of their > customers to the rest of the internet? AADSNet does not use the NAP for connectivity to the Internet for it's Chicago LATA customers. eric ---- R. Eric Bennett <reb(a)aads.net> | 339 E. Liberty, Suite 310 Internet Engineering | Ann Arbor, MI 48014 Ameritech Advanced Data Services | (313) 913-0802 "We're from the phone company, we're here to help."

1 0

Bogon /8 announcment from PSI
by asp＠uunet.uu.net 13 Dec '95

13 Dec '95

Network Next Hop Metric LocPrf Weight Path *>i5.0.0.0 192.41.177.235 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i *>i102.0.0.0 192.41.177.235 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i * i 149.20.64.33 10 100 0 174 i 64/8 to 126/8 are reserved. So is 5/8. --asp(a)uunet.uu.net (Andrew Partan)

2 2

Re: Sprint BGP filters in 207.x.x.x?
by sob＠academ.com 13 Dec '95

13 Dec '95

Gordon, There are lots of reasons a provider might aggregate networks for their customers. One is that many customers are not able to run routing protocols that do aggregation (customers that are not running routing protocols and use a static default is one example). In fact, in this case Sprint ought be doing aggregation for such customers (and I am sure they are). In any case, MCI's policy is not unique. Many providers do this. -- 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: Sprint BGP filters in 207.x.x.x?
by SURAnet NACR Account 13 Dec '95

13 Dec '95

> Aside from what Daniel says about Sprint and MCI's routing policy > mismatch, this statement is interesting on another level. For Dan says: > MCI aggregates all its customer's routes into /19's. This is new is it > not? Also it says *MCI* does the aggregating and not the customer. > Would someone please explain how this differs from what I understand to > be Sprints policy which says (i believe) that it is the CUSTOMER's > responsibility to aggregate the routes they present to sprint??? The difference is that MCI refers to addresses assigned out of their CIDR block. They are saying that they are aggregating nets on a /19 basis- one might assume on a per pop basis, or something similar. > Why would MCI do the aggregating? Is such mci policy good for mci or > good for the customer or equally good for both? They are not referring to proxy aggregation of PI address space. That is another religious war altogether. This is good policy, in that they are aggregating. They are most likely prevented from aggregating their announcements further to their peers in the interests of maintaining better routing policy to the individual nets- for example, say part of the space was in new york, and another was in dallas. If they only announced the aggregated /16 to their peers, their peers would pass off traffic to the closest announcement of the aggregate, as opposed to passing the net off to the closest place to the destination. 'Course, I remember that some poeple are shortest exit to MCI anyway- but that may have changed. _k

1 0

Sprint's filter
by Dorian Kim 12 Dec '95

12 Dec '95

For those who didn't save this the first time. -dorian ---------- Forwarded message ---------- Date: Sat, 23 Sep 1995 18:46:01 -0400 From: Sean Doran <smd(a)sprint.net> To: nanog(a)MERIT.EDU Subject: access-list 112 This is probably ugly and difficult to read. It also can be trimmed, but has been left overly-long and overly-paranoid for readability when using "show access-list 112" and because the IOS 10.3 distribute-list caching doesn't seem to mind the extra deny clauses all that much. Sean. - -- ! list 112 - deny more specifics of some prefixes ! ! IMPORTANT-TO-REMEMBER SYNTAX FOR BGP distribute-list! ! access-list <#> <permit|deny> ip <prefix> <don't care bits> <mask> <don't care bits> ! ! clear old list ! no access-list 112 ! ! this was originally ordered A, B, C and side-effects, but ! what we really want to do is put the permit clauses up front ! starting with the swamp, as this will match the most prefixes ! !!!!! START ! !!!! PERMITs ! !!! C space !! permit /24s in 192/8-205/8. ! (192==1100 0000, 205==1100 1101) ! ! allow M =< /24 in 1100 xx0x * ! (allow mask bits in first three octets) ! 1100xx0x == {192,193,196,197,200,201,204,205} ! access-list 112 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 ! ! ! allow M =< /24 in 1100 {0010,0011,0110,0111,1010,1011} ! (which really means 1100 {001x,011x,101x}, ! which in turn is really 1110 {x01x,011x}} ! 1100x01x == {194,195,202,203} ! 1100011x == {198,199} ! access-list 112 permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 access-list 112 permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 ! ! !! hack - allow M =< /19 in 206/8 ! access-list 112 permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 ! ! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 ! ! !!! B space !! permit /16s in old B-space ! 10xx xxxx * ! (we don't care what bits are in the first two octets ! of the mask; the second two octets must be 0) ! access-list 112 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 ! ! !!! A space !! permit /8s and shorter prefixes in old A-space ! 0xxx xxxx * would be simple but unsafe from 0/8 POV, so ! we make sure that there is at least one 1 bit in the first ! octet's last seven bits, and that the first bit is 0; ! we don't care what bits are set in the mask, because ! we assume IOS won't present us with a prefix with ! bits set in the prefix's first octet but not in the mask, ! unless it's a long mask... ! ! 126=01111110 (IOW, CddddddC C==CARE, d=don't care) ! 125=01111101 ! ... ! 95=01011111 ! 63=00111111 ! access-list 112 permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 ! ! !! permit 9.20.0.0/18 and 9.2/16 by exact match ! (both IBM early birds wrt subnets of As) ! access-list 112 permit ip 9.2.0.0 0.0.255.255 255.255.0.0 0.0.0.0 access-list 112 permit ip 9.20.0.0 0.0.255.255 255.255.192.0 0.0.0.0 ! !! permit exp39 /24s and shorter prefixes only ! (no ones set in the fourth octet) ! access-list 112 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 ! ! !!!! DENYs ! ! This is super paranoia. At this point we have permitted ! all valid unicast prefixes and masks. ! In theory, we could end right here with a ! ! access-list 112 deny ip any any ! ! but this section below offers some degree of clarity ! policy-wise... (at least to me, but I'm weird -- smd) ! ! we also could have done a quick deny after each permit ! to catch any prefixes which didn't pass the permit filters, ! however, as noted below, I am superparanoid about ! funny, noncontiguous masks and other weirdnesses, and ! would like to be able to see them being caught, if ! they ever get as far as the access-list. ! !!! A space !! deny 0/(9-15) - 127/(9-15) ! deny subnets in old-style class A space, first octet ! (if any bit set in bit 8-15 (second octet), deny) ! ! this is a paranoid way of writing this out; ! less paranoia would let us write: ! ! ... deny ip 0.0.0.0 127.0.0.0 0.0.0.0 255.128.0.0 ! ! because we believe in contiguous netmasks; so we would ! never have a /18 if we block /17. ! ! However, better safe than sorry... ? ! ! 0xxx xxxx * ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 ! !!! B space !! deny 0-127/16, 0-(17-23) - 191/(17-23) ! deny subnets in old-style class-B space ! and second octet of class A space. ! (first two bits will be 00 or 10; so x0xx xxxx; 191==10111111) ! (if any bit set in 16-23, deny) ! we also need to zap 0xxx xxxx * /16 ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 ! ! !!! C space !! deny 206/(19-23) - 239/(19-23) ! block prefixes longer than /18 in 207/8-239/8 ! no < /18 in 1100 1110 *, 1100 1111 *, 1110 xxxx * ! ! we block all M => /24 below and we did /17-/23 for 0/8-191/8 above, ! so we only need to worry about 19-23 for 207/8-239/8 ! ! first, in 1100 111x (206/8, 207/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 ! ! next in 1101 xxxx (208/8-239/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 ! !!! all UNICAST space !! deny ANY/24, ANY/(25-32) ! now we block the final octet for 0/8-239/8 ! (because we specifically allowed /24s in 192/8-205/8, we can ! just block everything in xxxx xxxx * that has any 1 bits in 4th octet) ! access-list 112 deny ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.0 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.128 255.255.255.127 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.64 255.255.255.191 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.32 255.255.255.223 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.16 255.255.255.239 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.8 255.255.255.247 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.4 255.255.255.251 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.2 255.255.255.253 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.1 255.255.255.252 ! !!! all IP space !! deny 240/(4-32), 0/(8-32) ! finally, we get rid of any announcements that are bogons ! 240/8-255/8 and 0/8 ! 1111 xxxx * and 0000 0000 * (any mask) ! we can leave this last as it's likely almost never to happen ! access-list 112 deny ip 255.0.0.0 15.255.255.255 0.0.0.0 255.255.255.255 access-list 112 deny ip 0.0.0.0 0.255.255.255 0.0.0.0 255.255.255.255 ! !!!!! END end

1 0

CERT Advisory CA-95:17 - rpc.ypupdated vulnerability
by CERT Advisory 12 Dec '95

12 Dec '95

============================================================================= CA-95:17 CERT Advisory December 12, 1995 rpc.ypupdated Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a vulnerability in the rpc.ypupdated program. An exploitation program has also been posted to several newsgroups. This vulnerability allows remote users to execute arbitrary programs on machines that provide Network Information Service (NIS) master and slave services. Client machines of an NIS master or slave server are not affected. See Section III for a test to help you determine if you are vulnerable, along with a workaround. In addition, Appendix A contains a list of vendors who have reported their status regarding this vulnerability. As we receive additional information relating to this advisory, we will place it in: ftp://info.cert.org/pub/cert_advisories/CA-95:17.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description The rpc.ypupdated program is a server used to change NIS information from a network-based client using various methods of authentication. Note: The Network Information Service (NIS) was formerly known as Sun Yellow Pages (YP). The functionality of the two remains the same; only the name has changed. The name Yellow Pages is a registered trademark in the United Kingdom of British Telecommunications plc, and may not be used without permission. Clients connect to rpc.ypupdated and provide authentication information and proposed changes to an NIS database. If authenticated, the information provided is used to update the selected NIS database. The protocol used when clients communicate with a server only checks to see if the connection is authentic using secure RPC. The protocol does not check to see if the client is authorized to modify the NIS data or if the given NIS map exists. Even after an unsuccessful attempt to update the NIS information, the rpc.ypupdated server invokes the make(1) program to propagate possible changes. The invocation of make is implemented in an insecure fashion which allows the requesting client to pass malicious arguments to the call resulting in the execution of arbitrary commands on NIS master and slave servers. II. Impact Remote users can execute commands on vulnerable NIS master and slave machines. III. Solution First determine if you are vulnerable (see Sec. A below). If you are vulnerable, either follow the instructions vendors have provided in Appendix A or apply the workaround in Sec. B below. A. Consult the vendor information in Appendix A. If your vendor is not listed, then check to see if your system has an rpc.ypupdated server. To do this check, consult your system documentation or look in your system initialization files (e.g., /etc/rc*, /etc/init.d/*, and inetd.conf) for rpc.ypupdated or ypupdated. If you find a reference to this program on your system, then it is likely that you are vulnerable. B. Until patches are available for vulnerable systems, we recommend that you disable rpc.ypupdated as soon as possible. Below are some examples given for reference only. Consult your system documentation for the exact details. In these examples, the rpc.ypupdated program is killed if it is running, and the system is reconfigured so that the daemon does not automatically start again when the system is rebooted. Example 1 - SunOS 4.1.X For SunOS 4.1.X master and slave NIS servers, the rpc.ypupdated program is started by the /etc/rc.local script. First, determine if the server is running, and kill it if it is. Then, rename rpc.ypupdated so that the /etc/rc.local script will not find and therefore start it when the system reboots. # /bin/uname -a SunOS test-sun 4.1.4 1 sun4m # /bin/ps axc | /bin/grep rpc.ypupdated 108 ? IW 0:00 rpc.ypupdated # /bin/kill 108 # /bin/ps axc | /bin/grep rpc.ypupdated # /bin/grep ypupdated /etc/rc /etc/rc.local /etc/rc.local: if [ -f /usr/etc/rpc.ypupdated -a -d /var/yp/$dname ]; then /etc/rc.local: rpc.ypupdated; echo -n ' ypupdated' # /bin/mv /usr/etc/rpc.ypupdated /usr/etc/rpc.ypupdated.CA-95:17 # /bin/chmod 0 /usr/etc/rpc.ypupdated.CA-95:17 Example 2 - IRIX On IRIX systems, ypupdated is started by the inetd daemon. For versions 3.X, 4.X, 5.0.X, 5.1.X, and 5.2, the ypupdated is enabled; but for versions 5.3, 6.0.X, and 6.1, it is disabled. Note that the byte counts given for /bin/ed may vary from system to system. Note also that the inetd.conf file is found in different locations for different releases of IRIX. For 3.X and 4.X, it is located in /usr/etc/inetd.conf. For all other releases (5.0.X, 5.1.X, 5.2, 5.3, 6.0.X, and 6.1) it is in /etc/inetd.conf. # /bin/uname -a IRIX test-iris 5.2 02282015 IP20 mips # /bin/grep ypupdated /etc/inetd.conf ypupdated/1 stream rpc/tcp wait root /usr/etc/rpc.ypupdated ypupdated # /bin/ps -eaf | /bin/grep rpc.ypupdated root 184 1 0 Nov 20 ? 0:00 /usr/etc/rpc.ypupdated root 14694 14610 2 11:30:07 pts/3 0:00 grep -i rpc.ypupdated # /bin/kill 184 # /bin/ed /etc/inetd.conf 3344 /^ypupdated/s/^/#DISABLED# /p #DISABLED# ypupdated/1 stream rpc/tcp wait root /usr/etc/rpc.ypupdated ypupdated w 3355 q # /bin/ps -eac | /bin/grep inetd 193 TS 26 ? 0:04 inetd # /bin/kill -HUP 193 --------------------------------------------------------------------------- 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 email 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 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 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. Past CERT publications, information about FIRST representatives, and other information related to computer security are available for 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 non-commercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. .............................................................................. Appendix A: Vendor Information Current as of December 12, 1995 See CA-95.17.README for updated information Below is information we have received from vendors. If you do not see your vendor's name below, please contact the vendor directly for information. Apple Computer, Inc. ------------------- A/UX does not include this functionality and is therefore not vulnerable. Berkeley Software Design, Inc. (BSDI) ------------------------------------- BSD/OS by Berkeley Software Design, Inc. (BSDI) is not vulnerable. Data General Corporation ------------------------ Data General believes the DG/UX operating system to be NOT vulnerable. This includes all supported release, DG/UX 5.4 Release 3.10, DG/UX Release 4.10 and all related Trusted DG/UX releases. Digital Equipment Corporation ----------------------------- OSF/1 on all Digital platforms is not vulnerable. Analysis of ULTRIX is under way, and information will be available soon. Hewlett-Packard Company ----------------------- HP-UX versions 1.01, 10.10, and 10.20 are vulnerable. Solution: Do not run rpc.ypupdated. rpc.ypupdated is used when adding or modifying the public:private key pair in the NIS map public key.byname via the chkey command interface. rpc.ypupdated should ONLY be run while changes are being made, then terminated when the changes are complete. Make sure you re-kill rpc.ypupdated after each reboot. NEC Corporation --------------- OS Version Status ------------------ ------------ -------------------------- EWS-UX/V(Rel4.0) R1.x - R2.x not vulnerable R3.x - R6.x vulnerable EWS-UX/V(Rel4.2) R7.x - R10.x vulnerable EWS-UX/V(Rel4.2MP) R10.x vulnerable UP-UX/V R2.x not vulnerable R3.x - R4.x vulnerable UP-UX/V(Rel4.2MP) R5.x - R7.x vulnerable UX/4800 R11.x vulnerable --------------------------------------------------------------- The following is a workaround for 48 series. ypupdated program is started by the /etc/rc2.d/S75rpc script. First, determine if the server is running, killing it if it is. Then, rename ypupdated so that the /etc/rc2.d/S75rpc script will not find and therefore start it when the system reboots. # uname -a UNIX_System_V testux 4.2 1 R4000 r4000 # /sbin/ps -ef | /usr/bin/grep ypupdated root 359 1 0 08:20:05 ? 0:00 /usr/lib/netsvc/yp/ypupdated root 19938 836 0 23:13:20 pts/1 0:00 /usr/bin/grep ypupdated # /usr/bin/kill 359 # /sbin/mv /usr/lib/netsvc/yp/ypupdated /usr/lib/netsvc/yp/ypupdated.CA-95:17 # /usr/bin/chmod 0 /usr/lib/netsvc/yp/ypupdated.CA-95:17 -------------------------- Contacts for further information: E-mail:UX48-security-support@nec.co.jp Open Software Foundation ------------------------ YP/NIS is not part of the OSF/1 Version 1.3 offering. Hence, OSF/1 Version 1.3 is not vulnerable. Sequent Computer Systems ------------------------ Sequent does not support the product referred to in this advisory, and as such is not vulnerable. Silicon Graphics Inc. (SGI) --------------------------- IRIX 3.x, 4.x, 5.0.x, 5.1.x, 5.2: vulnerable. Turn off rpc.ypudated in inetd.conf; it is shipped with this turned on. IRIX 5.3, 6.0, 6.0.1: rpc.ypupdated was off as distributed. Turn off if you have turned it on. Solbourne --------- Not vulnerable. Sun Microsystems, Inc. ---------------------- SunOS 4.1.X is vulnerable. [Note from CERT Coordination Center: We have examined Solaris and found that Solaris 2.x is not shipped with NIS support and the vulnerability is not present. There is an extra software package named the "Solaris Name Service Transition Kit" which in version 1.2, the current version, does not contain the rpc.ypupdated program and is therefore not vulnerable. However, version 1.0 of the Solaris Name Service Transition Kit does contain rpc.ypupdated and is therefore presumed to be vulnerable.]

1 0

chicago nap questions
by Gordon Cook 08 Dec '95

08 Dec '95

went looking for aadsnet on ameritechs chicago nap web page couldn't find them. But shouldn't they be there to get the rest of their customers to the rest of the internet? can anyone tell me what the following is all about? 198.32.130.228 aads-F.sprint.net any help appreciated. ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook(a)cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************

2 1

Re: chicago nap questions
by Jonathan Heiliger 08 Dec '95

08 Dec '95

On Dec 7, 8:16pm, Gordon Cook wrote: > went looking for aadsnet on ameritechs chicago nap web page > > couldn't find them. But shouldn't they be there to get the rest of their > customers to the rest of the internet? Try http://www.aads.net/products/data/nap/, it even has the listing of who's connected. -- \|/ _____ \|/ Jonathan Heiliger @~/ . . \~@ MFS Global Network Services, Inc. ________________________/_( \___/ )_\______________________________________ \__U__/ E-Mail: loco(a)mfst.com Data Services Network Engineering

1 0

subscribe (fwd)
by sharono＠ukefl.demon.co.uk 07 Dec '95

07 Dec '95

unsubscribe nsfnet-cert(a)merit.edu -- Sharon Okoli

1 0

Re: outages, quality monitoring, trouble tickets, etc
by ulmo＠Q.Net 07 Dec '95

07 Dec '95

> Since error reporting sucks in most network applications, it becomes > the fault of whatever help desk happens to take the customers phone call. Bingo! Ever since ten years ago, I've wanted *all* my programs to automatically detect larger-than-usual delays (more than 5ms?) and start giving *exact* status reports, such as "your host is doing DNS query", getting more detailed as the delay gets worse, getting the status and error information dynamically from the intermediaries "host x.y.z is doing a query of nameservers of the BAZ.COM domain in your host flappy.c.e.baz.com, and out of seven route servers 4 have failed, currently trying ... a.root-servers.net ... ICMP unreachable by router X-Y-Z based on data obtained from ..." and on and on until either utter failure or success; the greater the delays from what's reasonable, the more status information gets queried and automatically offered; if any point freezes, you'd know who is responsible. Programs should use a common library of routines which would pop up a window of the responsible organization for the error at hand, and the proper email address to send complaints to; an automated, standard computer-interpretable complaint should be registered automatically similar to syslog but internetted, and a button the user can press to add comments, opinions, etc. or even send further emails (and attaching CC's, making local copies, etc.). I'm amazed it even works 50% of the time, too. I understand why it doesn't work more often; a zillion pieces. We could use the tools (I mean computers) at hand better to inform us of these problems. Yes, I want it to be like my Volvo -- a light lights up whenever a bulb stops working, but better yet the computer can tell me which light is out, and can automatically order the spare part from the right factory. When I'm in Mosaic or Netscape, there's no reason it shouldn't tell me that a diode in a CSU/DSU just blew out in Wyoming, owned by Joe Bizzlededof, and that his staff has an average response time of six hours to fix such a problem, and that his functionaries have been notified, and whether or not I should expect workarounds and what actions I would have to take in order to use them (mostly, this is none -- wait n minutes for routers to find another route and the route will work again?) And, the same thing with a route missing from a router table. Is this crazy? I don't think so! Everything is getting so complex, we need: 1) to know when users can't use the network; thus the automatic feedback mechanisms from end-to-end 2) to know what things to fix to minimize #1 (we're not all trillionares and get to buy redundant everythings; we have to know which items manufactured by who and which programs maintained by who are bound to be more reliable than which others, so we can choose good items or know which ones need redundancy or other protective measures). 3) users to know exactly who to blame, so that help desks get *appropriate* calls rather than *inappropriate* ones. (the get-calls metephore is starting to get old; get-email will be more and more appropriate), and so that users know which organizations not to spend money on. In many cases, users are help desks fixing other peoples' problems. It's all hierarchical, everyone's the top and everyone's the bottom. I believe programmers should experiment with these things, and standards should be drafted, specifically for feedback-to-user-of-actual-problem and end-to-end automatic error reporting in *both* directions (so that each side of the connection and each end of the stack of layers knows what to fix), and responsible party lookup automation (who to *really* bother when there's just no other way (right now, 95% of the time)). Bradley Allen <Ulmo(a)Q.Net>

1 0