On Wed, 4 Oct 2006 13:13:22 +0300 (EEST), Pekka Savola
<pekkas(_at_)netcore(_dot_)fi>
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf