On Oct 3, 2006, at 3:36 AM, Iljitsch van Beijnum wrote:
I don't quite see what happens when the new key isn't present on
both systems and timestamps start to expire, but that should be
solvable in one way or another.
The purposes of the TCP-MD5 protocol is to ensure that two TCPs that
don't have the same keys can't communicate. I think it accomplishes
that, sooner or later.
Your concern is that it might be too frisky getting there. I'm
proposing that you be in control of how quickly you get there by how
you set the "delete" timer.
Suggestion: don't start sending ALL traffic with all keys, just
throw in a copy of a packet signed with the new key once in a while
and keep using just the old key for most traffic until a packet
with the new key is received from the other side.
Well, one approach to my "optimization" would be start sending all
new traffic with the new key, but retransmit with the old key. That
*does* require at least an operational change to the protocol
implementation, although not a change to the protocol itself. It also
means that during the period that only Alice thinks there are two
active keys, we can't move very quickly.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf