July 2000 - Test - lists.nanog.org

Opinion on NSI's quasi-monopoly
by Steve Sobol 10 Jul '00

10 Jul '00

http://webdeveloper.com/refresh/refresh_070700.html -- North Shore Technologies, Cleveland, OH http://NorthShoreTechnologies.net Steve Sobol, BOFH - President, Chief Website Architect and Janitor Pictures of two of my 'children': http://www.WrinkleDogs.com About Spamfighters: "We're not net nazis. We're dot communists." - W. Arnold

1 0

routing troubles?
by Adam Korab 10 Jul '00

10 Jul '00

Does anybody know of anything going on in Kansas City? Both my UUnet and Sprint routes are simply dying there, and making parts of the network inaccessible to my customers. Thanks, --Adam -- Adam Korab System Administration Internet Nebraska (402) 434-8680 RFC 882 put the dot in .com, not Sun Microsystems

1 0

Re: ISP performance
by Sean Donelan 10 Jul '00

10 Jul '00

"Well-engineered" is a loaded term, and presumes unchanging routes are always the best way to engineer a network. With ATM, MPLS and other provider games the IP-level path may have very little to do with where your packets go. What you are looking for is the work done at MERIT and later the Skitter project at CAIDA. See www.caida.org for more infomation. On Mon, 10 July 2000, Rajesh Talpade wrote: > At the risk of making a possibly naive request, could > someone point me to data on ISP network performance > (routing stability, packet loss, latency) ? I am > primarily interested in the first metric, and am > trying to understand the relative stability of large, > _well-engineered_ ISP networks. In other words, with > what degree of confidence can I predict the IP-level > path between two PoPs of a large ISP. Please note > that I am not getting into the general Internet > performance here. > > Somehow I get this feeling that the answer would be > a fairly large...it depends ! It would be useful to > understand the influencing factors as well.

2 1

ISP performance
by Rajesh Talpade 10 Jul '00

10 Jul '00

Hi Folks At the risk of making a possibly naive request, could someone point me to data on ISP network performance (routing stability, packet loss, latency) ? I am primarily interested in the first metric, and am trying to understand the relative stability of large, _well-engineered_ ISP networks. In other words, with what degree of confidence can I predict the IP-level path between two PoPs of a large ISP. Please note that I am not getting into the general Internet performance here. Somehow I get this feeling that the answer would be a fairly large...it depends ! It would be useful to understand the influencing factors as well. Thanks. Rajesh. -- Rajesh R. Talpade rrt(a)research.telcordia.com 973 829-4261 Telcordia Technologies

1 0

CERT Advisory CA-2000-69
by jamie＠next.hway.net 10 Jul '00

10 Jul '00

CERT Advisory CA-2000-69 AIBO Authentication Algorithm Corruption Vulnerability Original Release Date: July 10, 2000 Last Revised: -- Source: CERT/CC A complete revision history is at the end of this file. Systems affected * AIBO ERS-110 Aperios OS * AIBO ERS-111 Aperios OS Overview A vulnerability involving the Visual authentication algorithm has recently been identified in the Sony, Inc. "AIBO" Entertainment Robot. Owners of AIBO Robots are encouraged to upgrade their Aperios DogOS soon as possible. The AttackBite() control has a serious vulnerability that allows remote intruders within earshot of AIBO to execute arbitrary code. Scripts are proliferating the Internet with new routines such as PeeOnRug(), ShoeChew(), KillTheCat() and AttackOwnersGenitals(). The latter, classified by CERT as a "Denial of Service" attack, is most vicious, and for this reason CERT encourages immediate patch implementation. Some common cicrumstances under which this vulnerability can be exploited are addressed by the Sony patch; others are not. I. Description There are at least three distinct vulnerabilities in the ERS-110 and ERS-111 implementation of the Aperios software. All of these vulnerabilities may be exploited to effect Quicker-Picker-Upper and Owner Discomfort attacks with varying degrees of severity. Owners are advised, until patch completion, to guard themselves, and to have extra paper towels on hand. - The AIBO Sound Controller, when configured to play Britney Spears' "Oops, I Did It Again," will cause AIBO to lift a hind leg and spontaneously leak battery juice on the floor, simulating a urination (female ERS-110 models "squat" during this exploit). - The buffer used to hold the variable MyOwner in the function process_face() can be overflowed, reverting AIBO into experimental AiboPitBull code. When combined with the Sound Controller's Performance Mode signal, unpatched AIBO units can receive arbitrary code, and multiple reports of owner emasculation have been reported. - (Unverified) Owners who accidentally have left their television on late at night have reported incidents of AIBO attacking their small children and pets within minutes of the airing of "Tom Vu's Real Estate Seminar," The Story of A Vietnamese Immigrant's rags-to-riches Infomercial. - Two reports have been submitted where a race condition involving Tom Vu's Real Estate Seminar and presence of Richard Simmons' "Farewell to Fat" have caused AIBO units to "die". We are still investigating this. II. Impact Depending on the version of AIBO, the environment in which it is running, and the particular vulnerability that is exploited, a remote attacker can cause one or more of the following: - The AIBO to attack its owner, - The AIBO to wake, walk off its base station and attack children/pets, - The AIBO to generate Cyber-Body-Fluid and/or Excretion, and/or - The AIBO to die. III. Solution Upgrade your version of AIBO Aperios DogOS If you are running vulnerable Aperios and cannot upgrade, you are strongly advised to remove the battery from AIBO's behind and contact Sony for more assistance. Appendix A. Vendor Information Sony, Inc. Please see http://www.world.sony.com/robot/aperios_vuln.htm Richard Simmons Please see http://www.richardsimmons.com/shop/info.idc?id=08-00164 _________________________________________________________________ The CERT Coordination Center thanks your Mom and Eva Peron for their help in developing this advisory. _________________________________________________________________ Author: Jamie Rishaw <jamie(a)arpa.com> _________________________________________________________________ This document is available from: http://arpa.com/advisories/CERT-2000-69.html _________________________________________________________________ (This is a spoof, if you haven't gotten it by now) _________________________________________________________________ CERT/CC Contact Information Email: cert(a)cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request(a)cert.org and include SUBSCRIBE your-email-address in the subject of your message. * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. * "CERT" and "CERT Coordination Center" had absolutely nothing to do with this advisory, and do not support it. It's a parody. NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _________________________________________________________________ Conditions for use, disclaimers, and sponsorship information Revision History July 10, 2000: Initial Release

1 0

Re: Lurking lawyers
by Robert Cannon 10 Jul '00

10 Jul '00

I lurk and occasionally participate.* *Disclaimer: Opinions expressed by said attorney do not reflect those of any rational person or his dog. This communication via the Internet does not constitute legal advice; no attorney client privilege has been established. Believe me, if this was legal advice, you would get a really really big bill. By reading this far you have consented to the proposition that said attorney's are in fact worth more than any one elses. Fromheretofore, you agree to pay said attorney $1 for each word read. Application of this provision is heretoandthereafter retroactive. Any technical flaws or misunderstandings in said attorneys opinions are the fault entirely of David Lesher. By "Internet," this disclaimer refers to 47 USC § 231(e)(3) and not 47 USC § 230(f)(1). Attorneys do not have "best friends" and none should be so misconstrued. -Robert Cannon Director Internet Telecom Project www.cybertelecom.org cannon(a)world.oberlin.edu Senior Counsel for Internet Issues FCC Office of Plans and Policy rcannon(a)fcc.gov PS: Do I have to say "It's a joke" PSS: If you are looking for listservs that discuss Internet legal issues I recommend cybertelecom-l (federal reg of the Internet with emphasis on the FCC) and cyberia-l (high volume on all Internet legal issues). Many here are there. ------Original Message------ From: Sean Donelan <sean(a)donelan.com> To: nanog(a)merit.edu Sent: July 9, 2000 1:20:55 AM GMT Subject: Re: Lurking lawyers On Sat, 08 July 2000, Steve Sobol wrote: > Ok. Would it be more accurate to say that no attorneys or judges > actively participate in this group? All of the people I see posting > are techies. Yes, there are people who are, or were, members of the bar actively participate on occasion. Some of my best friends are lawyers :-) But, unless you've paid for it, their opinions on this list aren't worth any more than anyone else's. ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

1 0

RE: RBL-type BGP service for known rogue networks?
by Karyn Ulriksen 10 Jul '00

10 Jul '00

Shawn, I noticed that in BIND8, DNS gets _VERY_ unhappy if you use a CNAME for the zone's MX. Maybe there's something else at work.... Karyn -----Original Message----- From: Shawn McMahon [mailto:smcmahon@eiv.com] Sent: Monday, July 10, 2000 8:38 AM To: nanog(a)merit.edu Subject: Re: RBL-type BGP service for known rogue networks? On Mon, Jul 10, 2000 at 11:10:35AM -0400, Greg A. Woods wrote: > > However I should have listed the other requirement that I thought was > self-obvious since we're talking about SMTP here. I.e. I don't ever > accept e-mail from anything less than the most strictly conforming SMTP > implementations. You're violating part one of RFC 1123 section #5.2.5. > The name given by your SMTP server in the HELO "MUST" be a canonical > hostname. It must not be a CNAME. Oh, you wanna go there? 5.2.5 HELO Command: RFC-821 Section 3.5 The sender-SMTP MUST ensure that the <domain> parameter in a HELO command is a valid principal host domain name for the client host. As a result, the receiver-SMTP will not have to perform MX resolution on this name in order to validate the HELO parameter. The HELO receiver MAY verify that the HELO parameter really corresponds to the IP address of the sender. However, the receiver MUST NOT refuse to accept a message, even if the sender's HELO command fails verification. Hmm. MUST NOT refuse. Who's violating the RFC here, again? *ANYBODY* using sendmail from a dynamic IP is either going to do this, or worse. RFC 1123 requires you to live with it. If you choose not to, don't wave the damn RFC around like a magic shield. CNAMEs are "valid principal host domain name[s]". Nothing in the RFC says it can't be a CNAME, but something in the RFC says you have to accept it even if it's flat-out wrong or a lie. Your thin ice just cracked, Greg. Admit you're wrong and get on with your life. You're not running an RFC 1123-compliant mail setup at present.

4 3

RE: "top secret" security does require blocking SSH
by rdobbins＠netmore.net 10 Jul '00

10 Jul '00

They're well aware of the excellent points you make, I assure you. -----Original Message----- From: Alexei Roudnev [mailto:alex@relcom.net] Sent: Monday, July 10, 2000 10:29 AM To: rdobbins(a)netmore.net; nanog(a)merit.edu; gwoods(a)acm.org Subject: Re: "top secret" security does require blocking SSH Btw, it's NOT ENOUGPH. I mean - if , for example, Dod have hight classifyed network, and they cut all connections to the Internet (that's obvious) - they are not yet SAFE. They should prevent access to their network from the computers used for the Internet network - too. It can be - notebooks which are used for the classified access, but sometimes are used to read a public mail; that should not be dialup access, etc etc. On the other hand, it's not difficult to allow mail exchange with Internet (of course, no any objects, word files, attachments; but text messages are non unsecure from the network (not content) piont of view. And talking about original message - it's not about 22'th port; the problem appear if you allow ANY kind of access not controlled by the network admin. In my practice, we restricted 22 port and allowed telnet port, because we have used one time passwords (but ssh with OTP is much more secure than telnet with OTP). And just again, this is only a small brick in the wall. ----- Original Message ----- From: <rdobbins(a)netmore.net> To: <nanog(a)merit.edu>; <gwoods(a)acm.org> Sent: Sunday, July 09, 2000 1:48 PM Subject: "top secret" security does require blocking SSH > > > You are correct, it cannot. > > I've spent a good portion of my career working on networks which are > CLASSIFIED or higher. There are very strong restrictions on > simultaneous interconnection between systems of varying > classifications. In most cases, complete -physical- isolation is > required, although waivers may be obtained on a case-by-case basis. The > enforcement of these policies of course varies between agencies, > bureaus, and departments. I remember just a year-and-a-half ago > installing fibre switchboxes on some USAF nodes which at various times > needed to have connectivity to networks of varying security levels. > This is slowly changing at the lower levels due to the advances in > proxying technology, etc., but when you reach TS/SCI or SAP/SAR it's a > different story, and understandably so. > > As a side note, the reason the first version of Microsoft Exchange, 4.0, > was so late was due in large part to the fact that Microsoft wanted to > bid on the Defense Messaging System, or DMS contract. DMS supports all > levels of classification and types from UNCLASSIFIED all the way through > FLASH, CRITIC, etc. The powers that be understand that an > application-level service like messaging has to be able to cross such > boundaries, but only with strong rules which prevent the dissemination > of information of higher sensitivity to those who aren't cleared for > same. > > To the best of my knowledge, there are no networks in DoD, the armed > forces, or various other arms of the U.S. government which are ranked as > SECRET or above which have any form of Internet connectivity at anything > less than two removes. One of the reasons that it's so hard for them to > come up with a coherent and workable overall information security policy > is because of the (very necessary, more so than the typical slashdotter > tends to believe) compartmentalization of information - and hence, IT > resources - within various organizations which deal with sensitive > information and issues. > > "Greg A. Woods" wrote: > > > > [ On Sunday, July 9, 2000 at 08:22:46 (-0700), Roeland M.J. Meyer wrote: ] > > > Subject: RE: RBL-type BGP service for known rogue networks? > > > > > > In many organizations, a system isn't considered secure unless > > > port 22 is blocked, at the firewall. It is, after all, the secure > > > port, that must mean that you have to block it to be secure, > > > right? > > > > Yes, that's exactly right, but not for the reasons you imply. > > > > If the primary concern of a security policy is that covert channels must > > be prevented then it is absolutely mandatory that port-22 be blocked > > since it is by definition a covert channel. > > > > However having any kind of Internet connection, proxied or not, into a > > site where sensitive information must not be allowed to be leaked is in > > effect a violation of the policy. > > > > Unfortunately we're rapidly approaching (if we're not already there) a > > state of affairs where it is impossible to technically prevent inbound > > and outbound covert channels wherever people are required to interact in > > a privileged way with security sensitive systems. A paper given at last > > year's ACM New Security Paradigms Workshop by Dean Povey ("Optomistic > > Security: A New Access Control Paradigm") suggests that it might be > > better to adopt the view that security officers should "Make the users > > ask forgivness not permission." Whether this paradigm can successfully > > be delployed in top secret (or higher) environments or not is yet to be > > discussed. I suspect it can but then I'm not an expert in traditional > > forms of high security. > > > > -- > > Greg A. Woods > > > > +1 416 218-0098 VE3TCP <gwoods(a)acm.org> <robohack!woods> > > Planix, Inc. <woods(a)planix.com>; Secrets of the Weird <woods(a)weird.com> > > -- > ----------------------------------------------------------- > Roland Dobbins <mordant(a)gothik.org> // 818.535.5024 voice > > One of the surest signs of the philistine is his reverence > for the superior tastes of those who put him down. > > -- Pauline Kael > >

1 0

Re: Open Question About AS Number assignments...
by Scott Marcus 10 Jul '00

10 Jul '00

At 02:54 07/10/2000 -0700, David R Huberman wrote: > ... >> 5) Is there a advantage to having a lower AS number? > >Some network operators measure the size of their, um, "networks", by >the lowness of their primary AS (Scott Marcus-envy). :> ... Ummm, thanks, I think. :-) Yes, the lower numbers have sort of a nice cachet to them, and we're certainly happy with ours; however, I would think of it as being more like having a low employee number on your company ID badge. It says more about your longevity and seniority than it does about your rank (or in this case, network size). - Scott Marcus (CTO, Genuity [AS 1])

3 2

A Conversation With Stratton Sclavos (WashPost)
by David Lesher 10 Jul '00

10 Jul '00

http://www.washingtonpost.com/cgi-bin/gx.cgi/AppLogic+FTContentServer?pagen… By Leslie Walker Monday , July 10, 2000 ; F05 The $15.3 billion merger of electronic security firm VeriSign Inc. and domain name king Network Solutions Inc. was the largest deal in Internet history. Analysts say the combined company likely will be one the Internet's most powerful players because it will maintain the Web address infrastructure and be well positioned to to offer e-commerce services to companies registering Internet domains. ............ He outlined many other projects underway: Network Solutions is taking over from volunteer groups the big computers that have run much of the dot-com address system for years....... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0