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

[Sean Donelan <sean () donelan com>]

On Sat, 24 Apr 2004 sthaug () nethelp no wrote:
> 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.

Key management is still an issue.  It would be nice to be able to "roll"
the MD5 key change similar to more recent protocols.  If you had a list
of valid keys, we wouldn't need to perfectly synchronize key changes.
But this would increase CPU utilization for failed packets, i.e. check
key, key + 1, key - 1, increasing the DOS risk.