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 b
> 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 el
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> job. The required field-length checking for every multi-byte copy/move
RB> operation does have a significant negative impact on performance,
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
> 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
On Nov 7, 2005, at 11:15 AM, Tom Sands wrote:
We have that exact problem, if one considers it to be a problem.
We have only vendor X, and we've often wanted to try out others.
However, the management arguments and opinions are often difficult
to sway.
Something that often makes manag
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) "smash
> 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 d
> 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 v
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 an
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 I&D was developed [on the PDP-11
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
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 af
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
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 code
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. Supp
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.
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
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".
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 *PIM
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 benefit by having "genetic
diversity" in our rou
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
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 a
> 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
> 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
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
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 differe
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
>
> 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 networ
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 comple
30 matches
Mail list logo
