http://www.latimes.com/business/la-110705grokster_lat,0,4450717.story?
coll=la-home-headlines
Grokster Ltd. today shut down its online file sharing service to settle
an entertainment industry lawsuit aimed at stopping illegal downloads of
copyrighted music, movies and other programming.
Th
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
On Mon, Nov 07, 2005 at 09:33:30PM +0100, Henk Uijterwaal wrote:
> At 11:57 07/11/2005, [EMAIL PROTECTED] wrote:
> >> What about those that are assigned and used but not [currently] visible
> >> on the public Internet [i.e., are on other internets]?
> >
> >Indeed!
> >
> >On Henk's slide number 5 h
> 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
At 11:57 07/11/2005, [EMAIL PROTECTED] wrote:
> What about those that are assigned and used but not [currently] visible
> on the public Internet [i.e., are on other internets]?
Indeed!
On Henk's slide number 5 he states:
"Each AS wants to be able to send traffic to any other AS"
This is NOT
> 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
Thus spake <[EMAIL PROTECTED]>
One way to visualize this is to imagine the Internet
as a cloud. At the core of the cloud are the core
providers and at the edge of the cloud are the end
user organizations, many of which appear to be
singly homed. However, hidden behind this edge is
a thin layer w
http://www.tvtechnology.com/features/Masked-Engineer/f_mario_orazio-10.19.05.shtml
Katrina communications problems were caused by downed towers, power loss,
broken connections, drained batteries, missing generators, and equipment
underwater. Pick one or more. They were not caused by a lack of ac
NANOG 35
October 23-35, 2005
Los Angeles
Host: Equinix
--
Many thanks to Equinix, our new Steering/Program commit
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
Will someone from the Alltel NOC contact me off-list. Your NOC number
is not listed on puck, nor do your front end helpdesk-ites or main
switchboard folks know how to contact you.
Thanks,
-Bob
--
Bob Collie
Education Networks of America, Inc. (ENA)
p: +1 615 312-6004 or +1 317 612-2883 f: +1 6
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.
On 7-Nov-2005, at 05:57, [EMAIL PROTECTED] wrote:
On Henk's slide number 5 he states:
"Each AS wants to be able to send traffic to any other AS"
This is NOT true. Many ASes explicitly do *NOT*
want to send traffic to any other AS.
Wanting to do something and wanting to be able to do someth
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 Nov 7, 2005, at 8:32 AM, Howard C. Berkowitz wrote:
At 9:44 AM -1000 11/6/05, Randy Bush wrote:
> A peer should never announce a route it has already announced
unless
that route is withdrawn.
one of many counterexamples: change in igp will cause change in
med. any attribute changes
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
At 9:44 AM -1000 11/6/05, Randy Bush wrote:
> A peer should never announce a route it has already announced unless
that route is withdrawn.
one of many counterexamples: change in igp will cause change in
med. any attribute changes, and announcement is required.
e.g., an internal igp oscil
We have considered the options carefully and decided to announce a
covering /23 to get around the problem spotted by Randy and the folks in
Oregon. We considered the /24+/25 soloution but decided against that
because it makes little sense when we are considering to eventually
remove as much of th
< 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 s
> What about those that are assigned and used but not [currently] visible
> on the public Internet [i.e., are on other internets]?
Indeed!
On Henk's slide number 5 he states:
"Each AS wants to be able to send traffic to any other AS"
This is NOT true. Many ASes explicitly do *NOT*
want to send
38 matches
Mail list logo
