- Test - lists.nanog.org

Re: Peering problem with NSP
by William Allen Simpson 02 Nov '95

02 Nov '95

> From: Michael Dillon <michael(a)memra.com> > Sure it has. But a lot of professionals have the attitude that details > need to be hashed out discreetly in private so that a polished, > professional front can be shown in public. Naw, that's called "going behind your back", "back-stabbing", "beating around the bush", "behind closed doors", "smoke-filled rooms", and other derogatory statements. That's for politicians and management. Not professionals. polished != professional > I'm not saying that the > desires of the public have changed, but that the attitudes of > professionals have changed and are continuing to change. > Actually, I just think that more politicians and white-collar workers are calling themselves "professionals", which used to be reserved for doctors, engineers, professors (note the root), scientists, etc. Now, we have "sanitary waste-management engineers" (which has no educational requirement).... If the distinction escapes you, remember that traditionally a lawyer is an apprenticed tradesman, a judge is a professional. Every time I see some dingbat lawyer that adds "Esquire" after their name, I ask "Who is your knight? What liege have you sworn fealty?" Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 3

Re: cisco BGP aggregation bug
by levinn＠noc.psi.net 02 Nov '95

02 Nov '95

Hi there, >Why not just generate an atomic aggregate for 38/8 by >setting up a static route to the /8 pointing at null0? We have that. And we had lots of other variations... The bottom line is that there is no reason for the route to have ever flapped. It is simply a bug. -Mitch

1 0

Re: cisco BGP aggregation bug (fwd)
by bmanning＠ISI.EDU 02 Nov '95

02 Nov '95

> > Our current config, which seems to be working fine, forces us to allow > > auto summary, resulting in us withdrawing from the net39 experiment > > until a real bug fix is generated by cisco. ........ > > At any rate, we believe the current situation is stable as > > far as our announcements go. We hope to be able to rejoin the net39 > > effort again soon... > > > > > > -Mitch Better Hurry. RFC 1797 specifies a 01 Dec 1995 deadline for the net39 activities. --bill

1 0

Re: cisco BGP aggregation bug
by Sean Doran 02 Nov '95

02 Nov '95

Why not just generate an atomic aggregate for 38/8 by setting up a static route to the /8 pointing at null0? Sean.

1 0

CERT Advisory CA-95:14 - Telnetd Environment Vulnerability
by CERT Advisory 01 Nov '95

01 Nov '95

============================================================================= CA-95:14 CERT Advisory November 1, 1995 Telnetd Environment Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has been made aware of a vulnerability with some telnet daemons. The daemons affected are those that support RFC 1408 or RFC 1572, both titled "Telnet Environment Option," running on systems that also support shared object libraries. To determine if your system is potentially vulnerable, refer to the information we have received from vendors which is summarized in Section III below; details are in Appendix A and reproduced in the CA-95:14.README file. Note that if you installed a version of David Borman's telnet package that is older than October 23, 1995, your system may be vulnerable even though it was not vulnerable as distributed by the vendor. If your vendor is not listed, you will need to determine if your system may be vulnerable. First, determine if your telnet daemon is RFC 1408/1572 compliant. One indication that it is compliant is if your telnet(1) program supports the "environ" command or your telnetd(8) program supports the ENVIRON or NEW-ENVIRON options. Unless you are certain that your telnet daemon is not RFC 1408/1572 compliant, you may wish to assume it is to be safe. Second, determine if your system supports shared libraries. To do this, consult the ld(1) manual page. If it describes dynamic or shared objects, your system probably supports shared object libraries. A system is potentially vulnerable if the telnet daemon supports RFC 1408/RFC 1572 and the system supports shared object libraries. We recommend that you follow your vendor's directions for addressing this vulnerability. Until you can install a patch, we recommend using the workaround in Appendix B below. If you have previously installed David Borman's telnet package on your system, we recommend that you obtain the current version of telnet (see Section III.C). As we receive additional information relating to this advisory, we will place it in: ftp://info.cert.org/pub/cert_advisories/CA-95:14.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description Some telnet daemons support RFC 1408 or RFC 1572, both titled "Telnet Environment Option." This extension to telnet provides the ability to transfer environment variables from one system to another. If the remote or targeted system, the one to which the telnet is connecting, is running an RFC 1408/RFC 1572-compliant telnet daemon *and* the targeted system also supports shared object libraries, then it may be possible to transfer environment variables that influence the login program called by the telnet daemon. By influencing that targeted system, a user may be able to bypass the normal login and authentication scheme and may become root on that system. Users with accounts on the targeted system can exploit this vulnerability. Users without accounts on that system can also exploit this vulnerability if they are first able to deposit an altered shared object library onto the targeted system. Therefore, a system may be vulnerable to users with and without local accounts. Not all systems that run an RFC 1408/RFC 1572-compliant telnet daemon and support shared object libraries are vulnerable. Some vendors have changed the trust model such that environment variables provided by the telnet daemon are not trusted and therefore are not used by the login program. Section III contains a summary of information vendors have reported as of the date of this advisory. II. Impact Local and remote users can become root on the targeted system. III. Solution The general solution to this problem is to replace the telnet daemon with one that changes the environment given to the login program. We recommend that you install a patch from your vendor if possible. If this is not possible, we recommend using the workaround in Appendix B until you can install a patch. Finally, if you have previously installed Mr. Borman's telnet package, see Section C for how to get a new version that fixes the vulnerability. A. Vendor Patches Below is a summary of the vendors listed in the current version of the CA-95:14.README file, and the status they have provided. More complete information, including how to obtain patches, is provided in Appendix A of this advisory and reproduced in the README file. We will update the README file as we receive more information from vendors. If your vendor's name is not on this list, please contact the vendor directly. REMINDER: If you installed a version of David Borman's telnet package that is older than October 23, 1995, your system may be vulnerable even though it was not vulnerable as distributed by the vendor. Vendor or Source Status ---------------- ------------ Apple Computer not vulnerable Berkeley Software Design not vulnerable Cray Research not vulnerable CYGNUS cns-95q1 - vulnerable cns-95q4 - not vulnerable Data General not vulnerable Digital Equipment Ultrix - not vulnerable OSF/1 - vulnerable FreeBSD vulnerable Harris not vulnerable Hewlett-Packard not vulnerable Linux Debian - vulnerable Red Hat - vulnerable Slackware - appears vulnerable MIT-distributed for Athena vulnerable NetBSD 1.0 - vulnerable current - not vulnerable NEC vulnerable Open Software Foundation OSF/1 version 1.3 not vulnerable OpenVision OpenV*Secure 1.2 - vulnerable SCO not vulnerable SGI 5.2, 5.3, 6.0.1, 6.1 - vulnerable Sony Corp. NEWS-OS 6.x - not vulnerable B. Workaround Until you can install a patch from your vendor, you can use the workaround provided in Appendix B. C. If you have installed a previous version of Mr. Borman's telnet package, note that he has fixed this problem in the version available at the following location: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z MD5 checksum 2e14879a5b0aa6dd855a17fa8a3086cf --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Eric Halil of AUSCERT, Wolfgang Ley of DFNCERT, and Sam Hartman of the MIT Kerberos Development team for their 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). 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 November 1, 1995 See CA-95.14.README for updated information Below is information we have received from vendors. If you do not see your vendor's name below, contact the vendor directly for information. Apple Computer, Inc. -------------------- Apple's A/UX is not vulnerable. Berkeley Software Design, Inc. ----------------------------- BSDI's BSD/OS is not vulnerable. Cray Research, Inc. ------------------- Cray's UNICOS is not vulnerable. CYGNUS Network Security V4 Free Network Release ---------------------------------------------------- cns-95q1 is vulnerable. cns-95q4 is not vulnerable. Customers can use the following URL to obtain the patch: http://www.cygnus.com/data/cns/telnetdpatch.html If customers are unable to obtain the patch in this manner or have any questions, send e-mail to kerbask(a)cygnus.com/ Note that while the URL and patch are already available, there is no link to the page yet. We will add a link once the announcement has been made. Data General Corporation ------------------------ Data General believes the DG/UX operating system to be NOT vulnerable to this problem. This includes all supported releases, DG/UX 5.4 Release 3.00, DG/UX 5.4 Release 3.10, DG/UX Release 4.10 and all related Trusted DG/UX releases. Specifically, telnetd shipped in DG/UX does not support environment options and does not support RFC 1572. Digital Equipment Corporation ----------------------------- Digital's OSF/1: vulnerable Digital's ULTRIX: not vulnerable Digital has corrected this potential vulnerability. Patches containing new images for Digital's OSF/1 platforms are being provided to your normal Digital Support channels beginning October 31 (U.S. time). The kits may be identified as ECO SSRT0367 (telnetd) for DEC OSF/1 V2.0 thru V3.2c This potential vulnerability is not present on Digital's ULTRIX systems. Digital distribution of this announcement will be via AES services (DIA, DSNlink FLASH etc.). Digital Equipment Corporation strongly urges Customers to upgrade to a minimum of DEC OSF/1 V3.0, then apply this patch. FreeBSD ------- Vulnerable. A patch has been applied to the current development FreeBSD source tree which is not yet released. This patch is slightly modified compared to posted one, i.e. only variables which affects FreeBSD are disabled. It is telnetd patch, not a login wrapper. For the official patch, location please contact: Jordan Hubbard <jkh(a)FreeBSD.org> Harris ------ Harris Computer Systems Corporation's Night Hawk is not vulnerable. Hewlett-Packard Company ----------------------- HP/UX is not vulnerable. Linux (freely available software; not a vendor) ----- Debian GNU/Linux (From "Peter Tobias" <tobias(a)et-inf.fho-emden.de>): The current version of the Debian GNU/Linux distribution (released 10/27/95) is not vulnerable anymore. All Debian Installations that use a netstd package version prior to v1.21-1 are vulnerable (telnetd is part of the netstd package). netstd-1.21-1 and above are ok. Patches are available. Peter fixed the bug last week and uploaded the fixed version to our ftp site (ftp.debian.org) Binaries, sources and the diffs against the bsd telnetd can be found there. The URL for the new binary package is: ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb and the sources and the diff against the bsd telnetd can be found at: ftp://ftp.debian.org/debian/debian-0.93/source/net/netstd-1.21-1/telnetd.ta… ftp://ftp.debian.org/debian/debian-0.93/source/net/netstd-1.21-1/telnetd.di… Red Hat Linux (From Erik Troan <ewt(a)redhat.com>): Vulnerable. A fix is now available at: ftp://ftp.redhat.com/pub/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/NetKit-B-0.06-4.i386.… It will also be fixed in the upcoming Red Hat 2.1 release. Slackware Linux (Alan Cox <alan(a)cymru.net>): The telnetd distributed with Slackware Linux appears to be vulnerable, although it has not been verified. MIT-distributed Athena telnet/telnet95 -------------------------------------- Vulnerable. Patches available in: ftp://aeneas.mit.edu/pub/kerberos/telnet-patch/ beta4-3.patch is the patch versus the Beta 4 patchlevel 3 distribution of Kerberos v5. beta5.patch is the patch versus the Beta 5 distribution of Kerberos V5. Both patches have been PGP signed by Ted Ts'o <tytso(a)MIT.EDU> using detached signatures (beta4-3.patch.sig and beta5.patch.sig). NetBSD ------ NetBSD 1.0 (the last official release) is vulnerable; NetBSD 1.1 (due out in mid-November) will not be. NetBSD-current is not vulnerable, as of a week or so ago. Patches: A source form patch has been developed. A core team member will have to make source and binary patches available and provide a location for it. The login-wrapper given in the advisory can be compiled with NetBSD with: cc -o login-wrapper login-wrapper.c NEC Corporation --------------- Some NEC systems are vulnerable. Here is their vulnerability matrix: OS Version Status ------------------ ------------ ------------------------------------- EWS-UX/V(Rel4.0) R1.x - R6.x not vulnerable EWS-UX/V(Rel4.2) R7.x - R10.x not vulnerable EWS-UX/V(Rel4.2MP) R10.x vulnerable patch available by the end of Nov, 1995 UP-UX/V R2.x - R4.x not vulnerable UP-UX/V(Rel4.2MP) R5.x - R7.x vulnerable patch available by the end of Nov, 1995 UX/4800 R11.x vulnerable patch available by the end of Nov, 1995 -------------------------------------------------------------------------- Contacts for further information: E-mail:UX48-security-support@nec.co.jp Open Software Foundation ------------------------ OSF/1 version 1.3 is not vulnerable. OpenVision ---------- This is from: Barry Jaspan <bjaspan(a)cam.ov.com>: OpenVision has a patch for the telnetd in OpenV*Secure 1.2 and will contact its customers directly. SCO --- Not believed to be vulnerable. Silicon Graphics ---------------- IRIX 5.2, 5.3, 6.0.1, and 6.1 are vulnerable. SGI acknowledges the telnetd vulnerability reported by MIT and is currently investigating. No further information is available at this time. As further information becomes available, additional advisories will be issued. SGI Security Information/Contacts: For obtaining security information, patches or assistance, please contact your SGI support provider. If there are questions about this document, email can be sent to cse-security-alert(a)csd.sgi.com . For reporting *NEW* SGI security issues, email can be sent to security-alert(a)sgi.com. Sony Corporation ---------------- Sony's NEWS-OS 6.x is not vulnerable. .............................................................................. Appendix B: login-wrapper Workaround The login-wrapper program shown below is meant to be executed just before the distributed login program. The wrapper cleans specific variables from the environment before invoking the distributed login program. ------------------------cut here--8<------------------------ /* * This is a login wrapper that removes all instances of * various variables from the environment. * * Note: this program must be compiled statically to be * effective against exploitation. * * Author: Lawrence R. Rogers * * 10/25/95 version 1.1 Original version * 10/26/95 version 1.2 ELF_ variables removed (Linux) * 10/27/95 version 1.3 ELF_ changed to ELF_LD_ * Added AOUT_LD_ (Linux) * */ #include <stdio.h> #if !defined(_PATH_LOGIN) # define _PATH_LOGIN "/bin/login.real" #endif main (argc, argv, envp) int argc; char **argv, **envp; { register char **p1, **p2; for (p1 = p2 = envp; *p1; p1++) { if (strncmp(*p1, "LD_", 3) != 0 && strncmp(*p1, "_RLD", 4) != 0 && strncmp(*p1, "LIBPATH=", 8) != 0 && strncmp(*p1, "ELF_LD_", 7) != 0 && strncmp(*p1, "AOUT_LD_", 8) != 0 && strncmp(*p1, "IFS=", 4) != 0 ) { *p2++ = *p1; } } *p2 = 0; execve(_PATH_LOGIN, argv, envp); perror(_PATH_LOGIN); exit(1); } ------------------------cut here--8<------------------------ The following two examples show how to compile the login-wrapper for SGI's IRIX 5.3 and FreeBSD 2.x systems. The examples move the distributed login program to a new location and install the wrapper in the standard location. When executed, the wrapper first cleanses the environment and then calls the relocated, distributed login program. Note 1: The wrapper must be compiled statically. On SGI's IRIX system, compiling statically requires that the non-shared versions of libraries be installed. Consult your system documentation to determine how to do this. Note 2: You may need to change the _PATH_LOGIN variable to define where the real login program resides on your system. On some systems, login resides in /usr/bin/login. Compiling for IRIX 5.3 ---------------------- # uname -a IRIX test 5.3 11091812 IP22 mips # /bin/ls -lL /bin/login -rwsr-xr-x 1 root sys 65832 Sep 9 14:24 /bin/login # /bin/cc -non_shared -O login-wrapper.c -o login-wrapper # /bin/mv /bin/login /bin/login.real # /bin/chmod 755 /bin/login.real # /bin/mv login-wrapper /bin/login # /bin/chmod 4755 /bin/login # /bin/chown root /bin/login # /bin/chgrp sys /bin/login # /bin/ls -lL /bin/login /bin/login.real -rwxr-xr-x 1 root sys 65832 Sep 9 14:24 /bin/login.real -rwsr-xr-x 1 root sys 213568 Oct 30 08:42 /bin/login Compiling for FreeBSD 2.x ------------------------- # /bin/ls -lg /usr/bin/login -r-sr-xr-x 1 root bin 20480 Jun 10 20:00 /usr/bin/login # /usr/bin/cc -D_PATH_LOGIN=\"/usr/bin/login.real\" -static \ -O login-wrapper.c -o login-wrapper # /bin/mv /usr/bin/login /usr/bin/login.real # /bin/chmod 555 /usr/bin/login.real # /bin/mv login-wrapper /usr/bin/login # /bin/chmod 4555 /usr/bin/login # /usr/sbin/chown root.bin /usr/bin/login # /bin/ls -lg /usr/bin/login /usr/bin/login.real -r-sr-xr-x 1 root bin 24885 Oct 25 22:14 /usr/bin/login -r-xr-xr-x 1 root bin 20480 Jun 10 20:00 /usr/bin/login.real

1 0

Re: Peering problem with NSP
by Michael Dillon 01 Nov '95

01 Nov '95

On Tue, 31 Oct 1995, Patrick Horgan wrote: > Michael Dillon sez: > > > > The world is changing, Sean. And one of the things that is changing is > > the definition of "professionalism". Dragging things out into the open, > > hashing them out, and resolving issues based on facts is increasingly > > being seen as the professional way to do things. > > Being open, honest, and ethical...a new feature? It's always been what > customers wanted. Sure it has. But a lot of professionals have the attitude that details need to be hashed out discreetly in private so that a polished, professional front can be shown in public. I'm not saying that the desires of the public have changed, but that the attitudes of professionals have changed and are continuing to change. 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

1 0

Re: Peering problem with NSP
by patrick＠Verity.COM 31 Oct '95

31 Oct '95

> From: briand(a)fonorola.net (Brian Dickson) > > > > >Now, here is exactly what you ought to desire -- an informed customer. > >Yet, you publically castigate him for asking a mailing list which deals > >with _exactly_ these technical issues. > > My point was, he asked for no detailed technical information from us before > his mail to the nanog list. By being more informed to start with, he will > be better able to ask questions that will get him somewhere. This list Actually he reported that he did ask you for information and his take on the information was that it made no sense, hence he asked us...IMHO that's a reasonable thing to do. To me it looks like your trying to spin the event now, this post has a quite different tone and information than the first you made here. It makes it hard to take you seriously...but it was hard to take the whole thing seriously from the first post...it still makes no sense that you won't guarantee routing for him unless he makes you his primary provider. It sounds like you're just trying to tie him up. > > Absolutely. We are multiply homed, and would recommend it to any large > service provider. Please do not confuse our lack of guarantee for a > discouragement. I don't think that you are effectively...one couldn't count on you unless you were the primary provider. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

2 1

Re: Peering problem with NSP
by Sean Doran 31 Oct '95

31 Oct '95

Well, when dealing with this off-line, kindly include engineer(a)sprint.net, because quite frankly, *I* have no idea what you're talking about either. Perhaps it's too subtle for me. That kind of information is worth sharing so that both parties' shared customer is satisfied. (And perhaps this will be useful enough for people planning on multihoming between you and other providers than SprtintLink that it should be talked about in a more public forum with a view to helping people understand all the complicated issues involved in multihoming among several transit providing backbones.) Say, I wonder if this'll get me accused of unprofessionalism or disreputableness too? It's been a quiet week; nobody has ranted about me in far too long. Sean. - -- >From list-admin(a)merit.edu Mon Oct 30 20:26:13 1995 X-Sender: briand(a)mail.fonorola.net Mime-Version: 1.0 To: nanog(a)merit.edu From: briand(a)fonorola.net (Brian Dickson) Subject: Re: Peering problem with NSP Cc: Matt Harrop <mharrop(a)interlog.com>, Nathan Stratton <nathan(a)netrail.net>, ericc(a)nds.istar.ca > On Mon, 30 Oct 1995, Matt Harrop wrote: > > > In a few months, the network I operate is going to become > > multi-homed. I've just ordered the T1 from SprintLink and I know that > > they'll have no problem with BGP4 peering, or with the fact that I'll be > > multi-homed. My problem is with my existing NSP; fONOROLA. When I > > informed that that I would be going multi-homed, and asked them about > > peering this was their answer: > > > > > Due to our high level of interconnectivity, we carry over 6k routes >on our > > > backbone. Not all will be available to you. We can only assure you >that direc > > t > > > connect routes will be offered, namely AS2493 & AS812. Transit ASes >cannot be > > > provided to you at this time on a guarenteed basis. If you use us as > > > default, this is not a problem, but I suspect you will not. We have >direct > > > connectivity to CA*net, Rogers, UUNET, WorldLinx, MCI, ANS, and > > > cannot, at this time, ensure that all routes land on you. This kind of > > > routing transit service is not really intended as our usual service > > > offering, and it has a strong impact on our backbone design. > > > > Is this in any way reasonable? fONOROLA's primary connections to the rest > > of the world are MCI and ANS. If they can't provide transit to MCI and > > ANS, they are essentialy useless to me. Of perticular interest to me is > > their last statement. Would this actualy have a "strong impact" on their > > backbone? Matt, I do wish you'd feel free to ask us these sorts of questions directly. We're more than happy to provide you with an explanation, and an honest answer based on the facts will go a lot farther towards providing you with a solution, than open speculation on a mailing list. But feel free to solicit opinions. Language used in networking can be a bit confusing, since some of the aspects of networking are somewhat subtle. I will send you a more detailed explanation, but I wanted to set the record straight in this public forum. The reason we cannot guarantee transit AS connectivity is a direct result of not being your default connection. If you select us as default, we can guarantee transit access. The particulars behind that are technical; I will fill you in off-line, since that information is proprietary. And yes, it really does have a strong impact on our backbone *design*. [ BTW, Matt, we are iSTAR internet, inc. (formerly fONOROLA i*internet). Please use our new name when referring to us, to avoid any confusion. ] > Ya, drop them, they just don't want to do it. > > Nathan Stratton CEO, NetRail, Inc. Your Gateway to >the World! [ Editorial mode on ] Frankly, it is this sort of unenlightened, baseless opinion that gives Usenet its deserved reputation. It certainly doesn't reflect the level of professionalism that a reputable NSP should display, on this list in particular. [ End of editorial mode ] ----------------------------------------------------------------------------- Brian Dickson, Email: briand(a)istar.ca iSTAR internet, inc., Tel : (613) 780-2200 Suite 202, 250 Albert Street, Fax : (613) 780-6666 Ottawa, Ontario, Canada, K1P 6M1 http://www.istar.ca -----------------------------------------------------------------------------

4 3

Re: Peering problem with NSP
by briand＠fonorola.net 31 Oct '95

31 Oct '95

At 10:06 PM 10/30/95, William Allen Simpson wrote: >> From: briand(a)fonorola.net (Brian Dickson) >> I do wish you'd feel free to ask us these sorts of questions directly. >You cut off his excellent rationale, which was (Quoting Matt Harrop): > ># before I start butting heads with their ># management, I want to be sure of the technical issues. > >Now, here is exactly what you ought to desire -- an informed customer. >Yet, you publically castigate him for asking a mailing list which deals >with _exactly_ these technical issues. My point was, he asked for no detailed technical information from us before his mail to the nanog list. By being more informed to start with, he will be better able to ask questions that will get him somewhere. This list is an excellent place to get a second opinion; but for a first opinion it would be best to talk to one's provider(s), due to their intimate knowledge of the particulars. >> Frankly, it is this sort of unenlightened, baseless opinion that gives >> Usenet its deserved reputation. It certainly doesn't reflect the level of >> professionalism that a reputable NSP should display, on this list >> in particular. > >This rather surprises me, since I don't believe that this is a Usenet >distributed list. Actually, that was my point: the comment to which I replied was typical of the news swamp, not of this list. Sorry I wasn't more clear on that. >To conclude, this person states that he is a "service provider". >Providers _should_ be multiply homed. This is encouraged! Absolutely. We are multiply homed, and would recommend it to any large service provider. Please do not confuse our lack of guarantee for a discouragement. ----------------------------------------------------------------------------- Brian Dickson, Email: briand(a)istar.ca iSTAR internet, inc., Tel : (613) 780-2200 Suite 202, 250 Albert Street, Fax : (613) 780-6666 Ottawa, Ontario, Canada, K1P 6M1 http://www.istar.ca -----------------------------------------------------------------------------

1 0

Re: Peering problem with NSP
by William Allen Simpson 31 Oct '95

31 Oct '95

> From: briand(a)fonorola.net (Brian Dickson) > I do wish you'd feel free to ask us these sorts of questions directly. > We're more > than happy to provide you with an explanation, and an honest answer based > on the facts > will go a lot farther towards providing you with a solution, than open > speculation on a > mailing list. You cut off his excellent rationale, which was (Quoting Matt Harrop): # before I start butting heads with their # management, I want to be sure of the technical issues. Now, here is exactly what you ought to desire -- an informed customer. Yet, you publically castigate him for asking a mailing list which deals with _exactly_ these technical issues. > Frankly, it is this sort of unenlightened, baseless opinion that gives > Usenet its deserved reputation. It certainly doesn't reflect the level of > professionalism that a reputable NSP should display, on this list > in particular. This rather surprises me, since I don't believe that this is a Usenet distributed list. My personal reaction was also, "they want you as a captive customer". You say: > ... Transit ASes > cannot be > provided to you at this time on a guarenteed basis. If you use us as > default, this is not a problem.... And: > The reason we cannot > guarantee transit AS connectivity is a direct result of not being your default > connection. If you select us as default, we can guarantee transit access. The > particulars behind that are technical; I surely don't understand what default routing (which would only be outgoing) has to do with your advertisements to other ASs (which would provide him incoming reachability). So, perhaps you can enlighten this technical mailing list? To conclude, this person states that he is a "service provider". Providers _should_ be multiply homed. This is encouraged! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0