RE: Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5key for old session after key change)

["Malayter, Christopher" <Christopher.Malayter () tdstelecom com>]

I agree here.  If we can roll new md5 keys without session resets I am all
for it.  I believe Juniper needs to fix their implementation.  Especially
with md5 rolling out network wide for quite a few networks.  If an employee
leaves and we have to reset the md5 passwords for the entire network with a
hybrid of Juniper and Ciscos, I would love to not have to bounce all of my
sessions.  I think your best bet is to call JTAC and ask for a feature
request.

-Chris



-----Original Message-----
From: Sean Donelan [mailto:sean () donelan com]
Sent: Saturday, April 24, 2004 4:32 PM
To: sthaug () nethelp no
Cc: nanog () merit edu
Subject: Re: Juniper failes to change keys (More MD5 fun: Cisco uses
wrong MD5key for old session after key change)



On Sat, 24 Apr 2004 sthaug () nethelp no wrote:
> But as long as the session *is* reset anyway, the current situation is
> extremely confusing - the log messages (on both Cisco and Juniper) give
> no indication that the invalid key in question is for an *old* BGP
> session, no longer active!

That's why I hope Juniper will fix their implementation not to reset
the session and to stop using an old key.  Once the key is changed, all
new packets (including new packets for old sessions) should use the new
key, not the old key.

You think the bug is on Cisco's side, I think the bug is on Juniper's
side.  Hence interoperability.