On Wed, 4 Oct 2006 13:13:22 +0300 (EEST), Pekka Savola <[EMAIL PROTECTED]>
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 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
