The draft allows you to have a set of keys in your keychain and the implementation tries all of them before declaring the segment as invalid. No time synchronization required. No BGP message required. The added cost for CPU-bound systems is that they have to try (potentially) multiple keys before getting the **right** key but in real life this can be easily mitigated by having a rating system on the key based on the frequency of success. Regards Bora
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Iljitsch van Beijnum Sent: Monday, June 19, 2006 10:22 AM To: Randy Bush Cc: NANOG list Subject: Re: key change for TCP-MD5
On 19-jun-2006, at 19:10, Randy Bush wrote:
try reading more carefully
Didn't help...
how sad, as the whole document is about how to usefully be able to introduce and roll to new keys without agreeing on a narrow time.
Well, as you can tell from my message just now, I don't think going from agreeing on a narrow time to agreeing on a wider time is worth the trouble, especially since by adding a BGP message it would be possible to roll over if and as soon as both sides are ready, removing the "wait for some time and then see whether the other end really installed the new key" part from the proceedings.