Re: Networking Pearl Harbor in the Making

2005-11-13 Thread Edward B. Dreger
RB Date: Fri, 11 Nov 2005 11:03:44 -0600 (CST) RB From: Robert Bonomi RB Upgrades or 'fixes' that cause a machine to run noticably _slower_ than RB the 'down-rev' machine are a really good way to alienate customers. Especially RB thosw whose machines are running at nearly 100% capacity before

Re: Networking Pearl Harbor in the Making

2005-11-11 Thread Robert Bonomi
Date: Fri, 11 Nov 2005 14:15:40 + (GMT) From: Edward B. Dreger [EMAIL PROTECTED] Subject: Re: Networking Pearl Harbor in the Making RB Date: Mon, 7 Nov 2005 14:43:54 -0600 (CST) RB From: Robert Bonomi RB Re-coding to eliminate all 'possible' buffer overflow situations is a *big* RB

Re: Networking Pearl Harbor in the Making

2005-11-08 Thread Michael . Dillon
How do the operators/engineers explain to 'management', or whomever asks, the 'training issues' that always crop up when more than one vendor are proposed? Has anyone had good luck with this arguement? (my answer is sort of along the lines of: Its just a router, no matter the vendor and

Re: Networking Pearl Harbor in the Making

2005-11-08 Thread Roy S. Rapoport
On Mon, Nov 07, 2005 at 05:03:32PM +, Christopher L. Morrow wrote: How do the operators/engineers explain to 'management', or whomever asks, the 'training issues' that always crop up when more than one vendor are proposed? Has anyone had good luck with this arguement? (my answer is sort

Networking Pearl Harbor in the Making

2005-11-07 Thread J. Oquendo
CRAPAGANDA Which operating system, embedded in more than 80% of enterprise IT environments, represents one of the fastest-growing hacker targets and potentially the most-devastating information-security vulnerability? Hint: It ain't Windows. Cisco Systems' Internetwork Operating System now

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Jared Mauch
On Mon, Nov 07, 2005 at 06:43:35AM -0500, J. Oquendo wrote: the center of the information security vortex. Because IOS controls the routers that underpin most business networks as well as the Internet, I think in general this is an argument against converged networks, the added

RE: Networking Pearl Harbor in the Making

2005-11-07 Thread Hannigan, Martin
On Mon, Nov 07, 2005 at 06:43:35AM -0500, J. Oquendo wrote: the center of the information security vortex. Because IOS controls the routers that underpin most business networks as well as the Internet, I think in general this is an argument against converged networks, the

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Simon Waters
On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote: It's an argument for vendor diversity. No it is an argument for code base diversity (or better software engineering). Vendor diversity doesn't necessarily give you this, and you can get this with one vendor. Vendor diversity might be a

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Christian Kuhtz
Seems everyone considering the options would be well advised to consider how availability/reliability is actually calculated and based on that exercise make a more educated decision as to whether this does yield improvements at a cost that can be absorbed. Just because you have n

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Robert Boyle
At 08:52 AM 11/7/2005, you wrote: On Mon, Nov 07, 2005 at 06:43:35AM -0500, J. Oquendo wrote: the center of the information security vortex. Because IOS controls the routers that underpin most business networks as well as the Internet, I think in general this is an argument against

RE: Networking Pearl Harbor in the Making

2005-11-07 Thread Hannigan, Martin
On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote: It's an argument for vendor diversity. No it is an argument for code base diversity (or better software engineering). Vendor diversity doesn't necessarily give you this, and you can get this with one vendor. How so?

RE: Networking Pearl Harbor in the Making

2005-11-07 Thread Michael . Dillon
Convergence isn't going away because Networld Week thinks routers are insecure (no, really?). It's an argument for vendor diversity. There are two ways to interpret that last statement. 1. Network operators should build their converged networks using equipment from multiple vendors, i.e.

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Eric Gauthier
Robert, All of our network is now patched for the latest Cisco advisory. We were already running fixed code on a few routers when the advisory came out so we knew the code was stable and moved to it on all other boxes. I'm not exactly in the know on this one, but the heap-overflow

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Christian Kuhtz
On Nov 7, 2005, at 11:11 AM, Hannigan, Martin wrote: On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote: It's an argument for vendor diversity. No it is an argument for code base diversity (or better software engineering). Vendor diversity doesn't necessarily give you this, and you

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread J. Oquendo
On Mon, 7 Nov 2005, Blaine Christian wrote: Don't use proprietary protocols and insist on interoperability. Then make them play nice together! Good luck getting vendors to do something a-la Open Standards and withdrawing from labeling their product better because of new and improved *PIMP*

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Christopher L. Morrow
On Mon, 7 Nov 2005, Blaine Christian wrote: On Nov 7, 2005, at 11:26 AM, Eric Germann wrote: Looks like vendor J is going to benefit from the issues laid out for Vendor C. http://www.networkworld.com/news/2005/110405-juniper-cisco-hacker.html Cisco, Juniper, or vendor X. We all

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Eric Germann
Looks like vendor J is going to benefit from the issues laid out for Vendor C. http://www.networkworld.com/news/2005/110405-juniper-cisco-hacker.html At 08:52 AM 11/7/2005, you wrote: On Mon, Nov 07, 2005 at 06:43:35AM -0500, J. Oquendo wrote: the center of the information security

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Todd Vierling
On Mon, 7 Nov 2005, Christian Kuhtz wrote: How so? Haven't we recently seen an across the board bug in multiple version of $vendor code? And that's evidence of what other than nobody is willing to pay for what it takes to get better code out of $vendor? Code can be built better. It

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Blaine Christian
http://www.networkworld.com/news/2005/110405-juniper-cisco- hacker.html Cisco, Juniper, or vendor X. We all benefit by having genetic diversity in our routing/switching systems. I have been bit hard, as many of us on this thread have been bit, by bugs in vendor software/hardware. Support

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Christian Kuhtz
On Nov 7, 2005, at 12:16 PM, Todd Vierling wrote: On Mon, 7 Nov 2005, Christian Kuhtz wrote: How so? Haven't we recently seen an across the board bug in multiple version of $vendor code? And that's evidence of what other than nobody is willing to pay for what it takes to get better

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread James Baldwin
On Nov 7, 2005, at 10:21 AM, Eric Gauthier wrote: This latter case is what worries me since it implies that there is a fundamental problem in IOS, the problem still exists even after patching, and that Cisco can't readily repair it. I would postulate that this is a fundamental problem in

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Sam Crooks
I agree... Harvard architecture anyone? On Mon, 2005-11-07 at 11:39 -0600, James Baldwin wrote: On Nov 7, 2005, at 10:21 AM, Eric Gauthier wrote: This latter case is what worries me since it implies that there is a fundamental problem in IOS, the problem still exists even after

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Chris Woodfield
The problem is that generally, things have to get *really* bad before people will switch to a more secure infrastructure...it's all about costs, and the cost of staying with a less secure platform must substantially exceed the cost of switching before it's considered a reasonable response. It

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Joseph S D Yao
On Mon, Nov 07, 2005 at 11:01:23AM -0700, Sam Crooks wrote: I agree... Harvard architecture anyone? Ah, yes ... split I D [instruction data] space ... in its purest form, COMPLETELY split. Apparently named for the Aiken Mark I, but also where Unix V6 split ID was developed [on the PDP-11/45

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Tom Sands
How do the operators/engineers explain to 'management', or whomever asks, the 'training issues' that always crop up when more than one vendor are proposed? Has anyone had good luck with this arguement? (my answer is sort of along the lines of: Its just a router, no matter the vendor

RE: Networking Pearl Harbor in the Making

2005-11-07 Thread Robert Bonomi
Subject: RE: Networking Pearl Harbor in the Making Date: Mon, 7 Nov 2005 11:11:52 -0500 From: Hannigan, Martin [EMAIL PROTECTED] On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote: It's an argument for vendor diversity. No it is an argument for code base diversity (or better

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Robert Bonomi
Date: Mon, 7 Nov 2005 11:21:20 -0500 From: Eric Gauthier [EMAIL PROTECTED] Cc: nanog@merit.edu I'm not exactly in the know on this one, but the heap-overflow advisory that we've seen indicates that the IOS updates Cisco put out are not patches for this problem: Cisco has devised

Re: Networking Pearl Harbor in the Making

2005-11-07 Thread Joseph S D Yao
On Mon, Nov 07, 2005 at 02:43:54PM -0600, Robert Bonomi wrote: ... Most exploits (be it IOS or some other target) require multiple things to occur before the desired effect is achieved. buffer overflow exploits. in general. involve a minimum of two things: 1) smashing memory