On 3-okt-2006, at 0:20, Fred Baker wrote:
This is also a good way forward, and it has the advantage that it's
more general than my suggestion which requires changes to the client
protocol.
I would suggest that a key in the list actually has two timestamps
(virtual or actual) associated with it - a point in time where the
sender should start using it, and a point in time at which the key
should be deleted from the list (eg neither send nor accept).
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.
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.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf