[70000] in North American Network Operators' Group
Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5key for old session after key change)
daemon@ATHENA.MIT.EDU (sthaug@nethelp.no)
Sat Apr 24 16:48:11 2004
To: sean@donelan.com
Cc: nanog@merit.edu
From: sthaug@nethelp.no
In-Reply-To: Your message of "Sat, 24 Apr 2004 16:40:13 -0400 (EDT)"
Date: Sat, 24 Apr 2004 22:46:58 +0200
Errors-To: owner-nanog-outgoing@merit.edu
> > After a while I decided to change the MD5 key. The session with the new
> > key came up and looked fine, but the old session didn't close properly.
> > Notice the close is initiated from the Juniper side, and the first
> > packet from the Cisco side is now sent with an invalid MD5 digest - it
> > turns out that the packet is actually sent with an MD5 digest based on
> > the *new* key:
>
> This is a feature, and hopefully Juniper will also add the same feature
> soon. The feature allows you to change the MD5 key without flapping the
> BGP session which is very important on large peering sessions. There is
> no requirement that MD5 keys must remain constant throughout an entire TCP
> session, or to terminate a TCP session when the key changes. As long as
> both sides agree, the key can be changed at any time including in the
> middle of a TCP session. New packets after the key change are sent with
> message digests based on the new key.
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!
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
