On Wed, 4 Oct 2006 13:13:22 +0300 (EEST), Pekka Savola <pekkas@xxxxxxxxxx> wrote: > On Sat, 30 Sep 2006, Iljitsch van Beijnum wrote: > >> The IESG has received a request from an individual submitter to consider > >> the following document: > > > >> - 'Key Change Strategies for TCP-MD5 ' > >> <draft-bellovin-keyroll2385-03.txt> as an Informational RFC > ... > > The problems start when BOTH sides implement the new mechanism. In that case, > > new keys will remain unused for some time, and then become active at some > > hard-to-determine time in the future. (Neither side knows for sure when the > > other side will switch to the new key.) This means that there will be a > > problem in the case where the new key isn't present on both sides, for > > instance because one side wasn't configured with the new key in a timely > > fashion, despite out-of-band agreement to do so, the keys configured on both > > sides don't match. > > Having read the draft, I do have similar concerns with "double-ended" > operations. The draft mentions that the new key should only be used > when it's "at a point where it is reasonably certain that the other > side would have it installed, too". This is not very exact language, > and I wonder how implementations would handle this. My intention, actually, was that operators would do that. "Attention customers: we will be installing the 2007 BGP key on January 15. Please install the new key on your end before then." -- and then you actually do your end on Jan 20 or thereabouts. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf