Re: Last Call: 'Key Change Strategies for TCP-MD5' to Informational RFC (draft-bellovin-keyroll2385)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]