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. Some other parts
of the document also include suggestions which may make it harder to
test the interoperability of various different mixes of
implementations.
One possibility could be that an implementation once it's configured
with a new key MUST always immediately send a TCP probe to figure out
whether the other end supports the configuration key. This ensures
that at least one operator is still on-line when a key change occurs.
If not, go to dormant mode, waiting for the other end to probe.
A TCP probe should be something that will be acknowledged without
extra code if received with a working key, but which does not need to
be retransmitted with a different key if it fails. An example of this
would be an additional KEEPALIVE BGP message (which would be
application-specific), a TCP SYN to the application port (where you
terminate the probed connection after it was established) or something
similar.
I'm also not sure if the time interval to change the key would be
needed. The only benefit is failure to change the session to a new
key within that period would trigger some kind of alert. But if the
implementation already reports which keys are used and when, the
operators could just monitor whether a change took place or not. In
any case, a working BGP session with the old key is always better than
a failed BGP session with a new key.
FWIW, we haven't seen the need to ever change TCP-MD5 keys either.
This feature has likely been requested by networks which fail to
fulfill the assumptions of [1], i.e., they do not have filtering [or
GTSM] capabilities at edges and hence the attack vector to send
TCP-RST to the network's BGP sessions is basically the whole world.
[1] draft-savola-rtgwg-backbone-attacks-02.txt
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf