On 1/31/12, Nick Hilliard wrote:
> On 31/01/2012 16:40, David Barak wrote:
>> Because downtime is a security issue too, and MD5 is more likely to
>> contribute to downtime (either via lost password, crypto load on CPU, or
>> other) than the problem it purports to fix. The goal of a network
>> eng
Sounds like we want a well thought out plan in place in case there is a
screw up
with an org's lack of planning and management capabilities..
Mike
On Tue, Jan 31, 2012 at 12:56 PM, Nick Hilliard wrote:
> On 31/01/2012 16:40, David Barak wrote:
> > Because downtime is a security issue t
On 31/01/2012 16:40, David Barak wrote:
> Because downtime is a security issue too, and MD5 is more likely to
> contribute to downtime (either via lost password, crypto load on CPU, or
> other) than the problem it purports to fix. The goal of a network
> engineer is to move packets from A -> B. T
From: harbor235
> Also, It does not matter how many attempts compromising a BGP session
> occurs, it only takes one, so why not nail it down.
Because downtime is a security issue too, and MD5 is more likely to contribute
to downtime (either via lost password, crypto load on CPU, or other) than
My thoughts are that you should filter traffic routed directly to your BGP
speaking devices, traffic routing through a edge device and to an edge
device are treated differently. BGP session protection using a MD5 password
by itself is not securing the control plane, but it is a component of an
over
I suppose so but BFD certainly has alot more moving parts then adding
MDF checksums to an existing control packet. I'm not saying everyone
should turn it on or off for that matter. I just don't see what the
big deal is. Most of the shops I've seen have it on because of some
long forgotten engine
On Fri, 27 Jan 2012 15:52:41 -0500
"Patrick W. Gilmore" wrote:
> Unfortunately, Network Engineers are lazy, impatient, and frequently
> clueless as well.
While the quantity of peering sessions I've had is far less than
yours, once upon a time when I had tried to get MD5 on dozens of peering
sess
On Jan 27, 2012, at 6:20 PM, Jared Mauch wrote:
> On Jan 27, 2012, at 3:52 PM, Patrick W. Gilmore wrote:
>
>> Your network, your decision. On my network, we do not do MD5. We do more
>> traffic than anyone and have to be in the top 10 of total eBGP peering
>> sessions on the planet. Guess ho
I am in the camp of no MD5 in general and more specifically IX. It is a
real pain to manage MD5 and no network in my experience has ever
implemented a sustainable solution. There is no BCP that folks follow so
generally its a verbal agreement that someone in either party will
maintain the record. T
2012/1/27 Jeff Wheeler :
> On Fri, Jan 27, 2012 at 6:35 PM, Keegan Holley
> wrote:
>> realizes that it's ok to let gig-e auto-negotiate. I've never really
>> seen MD5 cause issues.
>
> I have run into plenty of problems caused by MD5-related bugs.
>
> 6500/7600 can still figure the MSS incorrectl
On Fri, Jan 27, 2012 at 6:35 PM, Keegan Holley
wrote:
> realizes that it's ok to let gig-e auto-negotiate. I've never really
> seen MD5 cause issues.
I have run into plenty of problems caused by MD5-related bugs.
6500/7600 can still figure the MSS incorrectly when using it. It used
to be possi
2012/1/27 Jared Mauch :
>
> On Jan 27, 2012, at 3:52 PM, Patrick W. Gilmore wrote:
>
>> Your network, your decision. On my network, we do not do MD5. We do more
>> traffic than anyone and have to be in the top 10 of total eBGP peering
>> sessions on the planet. Guess how many times we've seen
On Jan 27, 2012, at 3:52 PM, Patrick W. Gilmore wrote:
> Your network, your decision. On my network, we do not do MD5. We do more
> traffic than anyone and have to be in the top 10 of total eBGP peering
> sessions on the planet. Guess how many times we've seen anyone even attempt
> this att
On 27-01-12 21:52, Patrick W. Gilmore wrote:
> Who would want to reset a BGP that will come back up in 30-90 seconds when
> you can packet an entire router off the 'Net easier, more quickly, and for
> longer a period?
+1
Actually, when you have lot of MD5 BGP session coming up at the same
time
On Fri, Jan 27, 2012 at 3:52 PM, Patrick W. Gilmore wrote:
> MD5 on BGP sessions is the canonical example of a cure worse than the
> disease. There has been /infinitely/ more downtime caused by MD5 than the
> mythical attack it protects again. (This is true because anything times zero
> is st
MD5 on BGP sessions is the canonical example of a cure worse than the disease.
There has been /infinitely/ more downtime caused by MD5 than the mythical
attack it protects again. (This is true because anything times zero is still
zero.)
It is far easier to take a router out than try to calcul
16 matches
Mail list logo
