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

On 28-sep-2006, at 22:54, The IESG 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 IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.

Since my earlier comments to the author were apparently ignored:

Implementation of this draft allows for misconfiguration and  
operational problems that can't happen without implementation of the  
draft. As such, it should be considered harmful and the draft  
shouldn't be published, regardless of its intended informational status.

When two routers run BGP with the TCP MD5 option, and one implements  
this draft, key rollover will indeed be easier, if the upgraded side  
is first configured with the new key (which it won't use at this  
point), then the non-upgraded side is configured with the new key and  
immediately starts using it, which is detected by the upgraded side.  
This completes the key change immediately after the non-upgraded side  
configures the new key.

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.

In this case, one side will start using its new key at some point in  
time. If the other side doesn't have the same key, it can't validate  
the TCP segment so the segment is dropped. In theory, it's possible  
to recover from this condition by adding logic that observes the TCP  
state, but I don't see how this can be made fully reliable,  
especially given the wide variety of TCP implementations and other  
environmental factors such as BGP (in)activity, packet loss and  
reduced response times because of high CPU loads.

So in a good number of cases, TCP segments remain unvalidated for too  
long and the BGP session breaks. The really bad part is that this  
happens at some unpredictable interval AFTER operator action, so  
operator error doesn't create any usable feedback. Today, feedback is  
immediate and conclusive. So the new situation is vastly inferior  
from an operational robustness perspective.

This problem can easily be fixed by adding a BGP capability code and  
a new BGP message. The capability code would indicate support for the  
new message, and the new message would be used by each BGP speaker to  
communicate the availability of a new key, along with a hash over the  
key so the BGP speakers know at which point the other side has the  
new key available, and that the new key is indeed the same as the  
locally configured one. These types of additions to the BGP protocol  
are well-understood and shouldn't lead to significant additional  
implementation difficulty.

(What follows isn't specific to the draft under consideration and  
shouldn't be taken as input on how to change this particular draft.)

As long as I'm taking up bandwidth, let me address a more fundamental  
problem with this draft and several others addressing the same or  
similar issues. (It would be nice by the way to have a single venue  
where all of this is discussed, in Montreal the discussion moved from  
working group to working group and was therefore extremely hard to  
follow for everyone who didn't make an express effort to do so.)

The real problem is agreeing to a key with people from another AS.  
It's not uncommon for network operations staff for two ASes to reside  
in different timezones, to speak different languages and to have  
wildly dissimilar operational mores. This makes seemingly trivial  
tasks such as finding a person who can agree to a key and finding a  
secure channel to communicate the key very hard. The particular issue  
that this draft addresses, which is agreeing on a time when the keys  
are changed, is indeed also an issue but in my experience, it's not  
the most problematic one in practice. The reason for this is that in  
practice, keys are rarely changed after they've been set up  
initially. I estimate that I've done some 200 inter-AS-session-years  
worth of BGP operational management, and I can't remember ever having  
been asked to change an existing BGP TCP MD5 password. The assumption  
that these keys are so sensitive that they must be changed regularly  
simply doesn't hold in practice.

But suppose that the keys must indeed be changed often. The problems  
unrelated to the actual time of the change remain unaddressed here.  
This is also true of the other proposals that I'm aware of, which  
address other problems such as the weakness of the MD5 hash and the  
way in which it's used here. In order for network operations to be  
able to change the actual session keys often, it's necessary to base  
the actual session keys (and preferably, the keying information  
configured on a router) without the need to agree to any specific  
keying information out-of-band. This probably involves some kind of  
public key encryption, where a session is not configured with an  
actual secret key, but with a fingerprint for a certificate held by  
the remote router, or, better yet, the remote AS.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf