July 2001 - Test - lists.nanog.org

Re: product liability (was 'we should all be uncomfortable with the extent...
by herb＠tomobiki.urusei.net 25 Jul '01

25 Jul '01

LBolton(a)geiger.com wrote: > Your analogy is flawed. > > The question is, should Firestone be responsible for someone going around > slashing the tires? No they shouldn't. No, but they should be held accountable for not making a product that will last as long as expected (warrented) or that acts in a manner that causes harm to a user who is not abusing the product (constantly blowing out at speeds considered "normal" like 65). > Then why should Microsoft or any other software manufacturer be responsible > for the damage done by third parties? Why not? 3rd parties (script kiddies) are no different than rocks on the road: They are there; you can't get rid of them; they cause damage; and products should be made with them in mind... > You could make the argument that Microsoft should have designed more > security into their products to prevent security breaches of this nature, > but you could also argue that Firestone should make their tires out of > kevlar to prevent people from slashing them. Firestone (and most all other) tires *are* made with kevlar to give them puncture resistance... They and other manufactures want to make tires that will last x amount of miles or time on the road. They provide treadwear ratings so you can compair against other makes and models. And there are a jillion different tire makers out there that make products of compairable quality that all can work with each other as well so you don't have to buy 5 tires of the same make/model... And there is a standard system for fitting tires onto rims. > We shouldn't hold the software manufacturers responsible, unless they > willingly and knowingly left the security flaw in place. We should hold > the programmers that release malicious code responsible. If Microsoft (and other OS makers) had the same quality standards as tire makers, we would see up-times of 3 to 10 years. (Or however long it takes to use a computer to the equivilant amount of putting 100000 miles on a tire...) Oh, wait--VMS and UNIX boxes have already been known to stay up for that long... =) Should people sue all makers of screw, nails, and other puncturing devices for selling things that can screw up tires? /herb

1 0

RE: Peering, Large ISPs, and You
by Daniel Golding 25 Jul '01

25 Jul '01

See my comments below... > -----Original Message----- > From: David Barak [mailto:thegameiam@yahoo.com] > Sent: Wednesday, July 25, 2001 1:14 PM > To: nanog(a)merit.edu > Cc: dan(a)netrail.net; jeblinton(a)corp.earthlink.net; > peeringresistance(a)yahoo.com > Subject: Peering, Large ISPs, and You > > > I'll interleave my comments. > > Quoth Daniel Golding: > > >The large ISPs have finally started to work together, > >to potentially exclude > >smaller providers. That isn't good. > > are you arguing that the situation of the past several > years does NOT exclude smaller providers? Most of the > really big ISPs (you know who you are) rely primarily > on private peering already. How exactly does this > change matters? > Smaller providers have certainly felt the squeeze. This changes matters because previously the big players were working seperately, with distinct sets of rules. From my reading of these comments, it looks like they are starting to work together, and plan jointly. If this is true (and at least one non-anonymous poster has seemed to confirm it), than thats bad. > >Certain colo facilities are being choosen. Others are > >not. This has a major > >business impact on the ones who aren't choosen. > > s 'are being'/'had been' and you'll see that this is > not only nothing new, it's nothing which is > particularly undesireable. In fact, you can look at > this as colo-competition - those colo spaces which > provide services which the really big ISPs want will > get their business. > Yes. But previously, all these ISPs made independent decisions, which encouraged competition. If all of them jointly choose a single player in a certain market, thats bad for competition. That has NOT happened previously. > >Earthlink is a huge consumer of transit bandwidth, so > >it would seem to be in > >your shareholder's best interest to keep competition > >high, and thus keep > >prices low. > > True. So tell me this: how will providers reducing > their costs on settlement-free interconnections cause > overall costs to rise? If anything, this period of > severe cost-sensitivity should drive the really big > ISPs to pay very close attention to pricing, in an > attempt to maintain and maximize revenue. > There are numerous examples of this in real life. The best one if the airline industry. At any rate, once the pricing variability is taken out of the transit game, syncing of pricing will happen. There seems to be a hope that this will supress pricing. This may happen, although it is difficult to see how transit can be delivered, at a profit, for lower prices. But be careful to see the other side of the coin - it makes price increases much easier. > -David Barak > "Quis custodes ipsos custodiet?" - Juvenal > > __________________________________________________ > Do You Yahoo!? > Make international calls for as low as $.04/minute with Yahoo! Messenger > http://phonecard.yahoo.com/ > - Dan

3 2

RE: 'we should all be uncomfortable with the extent to which luck ..'
by Roeland Meyer 25 Jul '01

25 Jul '01

> From: David Shaw [mailto:dshaw@jabberwocky.com] > Sent: Wednesday, July 25, 2001 12:06 PM > This is the part I disagree with. Given my example (needing to > connect from a public machine while traveling), I cannot trust the > local terminal. <Boogle> You don't travel with a laptop?!?! ... wow.

2 1

Re: SONET UPSR questions
by Dave Israel 25 Jul '01

25 Jul '01

On 7/25/2001 at 11:25:55 -0700, Rishi Grover said: > > Hi, > > I don't know if this is the right forum No. It isn't. A simple google search would have turned up: http://www.g3m.com/applications/OpticalFiberNetworks.pdf A careful reading of the secion on UPSR would have answered most of your questions. A little thought on how telco circuits work would have answered the rest. -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

1 0

SONET UPSR questions
by Rishi Grover 25 Jul '01

25 Jul '01

Hi, I don't know if this is the right forum but if someone could shed some light on the following questions, I would really appreciate that. I have read the standards but did not get a clear understanding on the following: 1) Given a SONET ring with UPSR, is it required that all working paths be in one direction (clockwise or anticlockwise) and all protected paths be in the opposite direction? Can I provision some working paths to be clockwise and some to be counterclockwise? I couldn't find anything in the standards that says that this is not allowed. If this can be done, what are the merits/demerits of this approach? 2) In UPSR, when provisioning a working path, my understanding is that it is not "required" to provision the protected path as well. i.e. One can provision only unprotected paths in a UPSR configuration. Is this correct? 3) Given a deployment of 4 node UPSR configuration A, B, C, D. Say I provision a working path in clockwise direction from node A to D. Say I am using timeslot 'x' for this path. Is timeslot 'x' also reserved in the clockwise direction from D to A? What is the rational behind reserving this timeslot 'x' from D to A? Thanks, Rishi

1 0

'we should all be uncomfortable with the extent to which luck..'
by k claffy 25 Jul '01

25 Jul '01

david moore's analysis of code red: episode 0/1 is at http://www.caida.org/analysis/security/code-red/ [funded by DARPA's ITO office NGI/NMS programs, NSF ANIR, and CAIDA members, david a caida PI] definitely check out jeff brown's animation at bottom; watch carefully around 15:00 for pretty ominous elbow in infection rate (get an epidemiologist to look at it without telling them what it is...) 360,000 machines (well, IP addresses) infected in under 14 hours. from conclusion: // ..in the final analysis, we should all be uncomfortable with the extent to which luck, rather than proactive diligence, maintains the stability of the Internet infrastructure. // it goes without saying that many hosts are still vulnerable. and will likely remain so (to this or the next poison) until our luck runs out. do we expect the next version to have the two weaknesses christopher pointed out today? do we expect the next version won't clear every 3rd bit on the hard drive? almost makes me wonder if some white hat might (should?) have been behind CodeRed as some 'vaccination' attempt. "The bad news is, nobody will do anything about critical infrastructure protection until there's a global catastrophic failure," said Rasch. The good news is, there will be a global catastrophic failure." -- http://www.nando.net/technology/story/44887p-694372c.html the worse news is: protecting 'critical infrastructure' is far from enough. again from http://www.caida.org/analysis/security/code-red/ This assault also demonstrates that machines operated by home users or small businesses (hosts less likely to be maintained by a professional sysadmin) are integral to the robustness of the global Internet. As is the case with biologically active pathogens, vulnerable hosts can and do put everyone at risk, regardless of the significance of their role in the population. fwiw, caida trying to do gentle survey of patching speed, see http://worm-security-survey.caida.org/ k ps: john maddog hall (linux int'l) had a great slide a few months ago at UCSD talk; upshot something like INSTALLED BASE (EARTH) + 20 million linux systems + 450 million gates licenses ==> 4.4 - 6.6 % of the population total ... world population: ~6B ==> 5.4 billion people haven't selected an OS yet [k: maybe we can get them on OS-antioxidants before it's too late]

11 11

RE: product liability (was 'we should all be uncomfortable with t he extent to which luck..')
by Roeland Meyer 25 Jul '01

25 Jul '01

> -----Original Message----- > From: William Allen Simpson [mailto:wsimpson@greendragon.com] > Sent: Wednesday, July 25, 2001 7:04 AM > To: nanog(a)nanog.org > Subject: Re: product liability (was 'we should all be > uncomfortable with > the extent to which luck..') > > > > Roeland Meyer wrote: > > > > > From: William Allen Simpson [mailto:wsimpson@greendragon.com] > > > A check in the mail would be a better incentive to > > > administrators than "automatic" updates. > > > > Now *there's* a thought. However, all software companies > carry product > > liability insurance. It's sometimes called a shrink-wrap > license. You might > > actually try reading it the next time you purchase and > install software. > > I'm not a party to the EULA. > > For the sake of argument, ISPs are the party that the SUV hit when it > rolled over after the tires exploded.... > > (actually, because of our proactive action and filtering, we had > exactly zero customers that were still infected by Jul 20th. But we > had to spend the manpower and technical support -- that's worth > something!) > > Also, you may have noticed that shrink-wrap licenses are > valid in only > two places: Washington (state) and Virginia. This would be a Federal > class action. Please, do not confuse "governing law" and "jurisdiction" with applicability. With most commercial software, you don't own it. The actual owners retain full ownership rights. That makes a huge legal difference. BTW, MHSC shrink-wrap, and all other MHSC contracts, are under Delaware law, with alternative jurisdiction in Colorado, and neither of the other two jurisdictions that you mention. It has to do with where the corporate home is. Further, lawyers make big bucks arguing "comparative negligence". None of us gets paid well enough to do so here. FWIW, almost all commercial software developers carry "Errors and Omissions" coverage, as a second-level backup to the lawyers. That said and in most jurisdictions, the driver has primary responsibility. This is due to the fact that the driver has primary responsibility for maintenance and application. This is the primary reason for the "fitness of purpose" clause. > Joe Shaw wrote: > > > > And with this latest threat of code red, Microsoft would > have been covered > > anyway, because a patch for this exploit existed well > before CodeRed hit. > > They released a patch for the indexing server on June 18, > 2001, which as > Actually, although the patch was released, M$ lied, saying it > was only > needed by web servers. We have since learned that *ALL* W2K and XP > systems were vulnerable. Fraud and misrepresentation? Since ALL Win2K and XP packages contain IIS, where did they even mislead? > > human somewhere wrote some bad code. It happens, and > continues to happen > > on a daily basis. > > It's long past time that humans were held accountable. Now, there is something that I can agree with. Let's hunt down the script kiddie and their bunk-daddy (who wrote Code Red) and start hacking off appropriate appendages. I'll be glad to sharpen the knives. > Funny, the engine electronics in my car doesn't seem to be vulnerable > to these failures.... Maybe it's the extensive (years) of > testing and code review? > > Why should I have to pay for the desire of M$ to be "first to > market", or more usually, "last to market but cheaper". > > There is no other industry where such bad practices would be > acceptable. It shouldn't be in ours, either! Have you ever done a function-point analysis, or path permutations analysis on your average GUI program? The simplest GUI is vastly more complex than the engine monitoring computer in your car. Just chasing all first-order paths would take decades. Second-order paths number in the billions. We won't go to third-order. Exhaustive testing is not even dreamable. If you even have a QA department available, ask them. While you're at it, do you QA your web-site? > > Security requires vigilence, and there seems to be too > little of it out in > > the world. > > > Agreed. Yes.

2 1

RE: product liability (was 'we should all be uncomfortable with t he extent to which luck..')
by Roeland Meyer 25 Jul '01

25 Jul '01

> From: William Allen Simpson [mailto:wsimpson@greendragon.com] > Sent: Tuesday, July 24, 2001 11:43 PM > Perhaps a different approach is in order -- product liability. > Network operators have been injured by the distribution of > buggy software from M$. We need to be compensated for our > time and expenses. > > End users need to be compensated for their costs to upgrade. > > A check in the mail would be a better incentive to > administrators than "automatic" updates. Now *there's* a thought. However, all software companies carry product liability insurance. It's sometimes called a shrink-wrap license. You might actually try reading it the next time you purchase and install software.

5 6

RWHOISD help needed - please contct off-list
by Rich Sena 25 Jul '01

25 Jul '01

-- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

1 0

RE: 'we should all be uncomfortable with the extent to which luck ..'
by Roeland Meyer 25 Jul '01

25 Jul '01

> From: Mitch Halmu [mailto:mitch@netside.net] > Sent: Wednesday, July 25, 2001 8:30 AM > > On Tue, 24 Jul 2001, Roeland Meyer wrote: > > > How many of us here run anything less than SSH and even > allow telnetd to > > live on any of our hosts?> > > Those (few) providers offering shell accounts still do. Someone once proved to me, definitvely, how easy it is to crack root from a shell account. Especially one that is allowed to execute their own code. That night, I killed all shell accounts of users that I didn't personally know and trust. Those that were left were introduced to SSH. This was five-years ago.

1 0