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

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Sep 2006 22:47:03 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 30 Sep 2006 17:28:53 -0400

> Since my earlier comments to the author were apparently ignored:

"Ignored" is not the right word; I just don't happen to agree with you...
I replied to you, both privately and on the NANOG list.  I said:

	There are lots of good solutions if you're willing to change or
	introduce protocols.  That takes a lot longer, both procedurally
	and technically. This scheme is simple and single-ended, and can be
	implemented without co-ordination.

	We should indeed try for a better solution.  Until then, I'm
	suggesting this -- I'm aiming at Informational -- to tide us
	over.  The need for some such solution was quite clear during
	Bonica's talk in San Jose.

>...

> reduced response times because of high CPU loads.

There is explicit text in 2.2 discussing the need for integration with the
TCP timeout mechanism.
> from an operational robustness perspective.

Text I added after our exchange of messages in June discusses the need for
a MIB entry, precisely to address this issue.

> implementation difficulty.

Again, for that to have any utility it requires double-ended changes.
> the remote router, or, better yet, the remote AS.
I'm afraid I do believe you about the rarity of password changes -- that's
precisely what I'm trying to fix!  The need for such changes is discussed
in RFC 3562.

I agree with you completely about the need for better key management.  At
the request of one of the Security ADs, I added Section 4 to this
document, stating this explicitly and giving some guidance on how to
proceed.  I'm also working with people from the Transport Area on this
precise question.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Sep 2006 23:49:32 +0200

> I replied to you, both privately and on the NANOG list.

Sure. But my issues haven't been resolved.

> There is explicit text in 2.2 discussing the need for integration  

I don't think this can be robust enough, especially considering the  
possible alternatives.

> a MIB entry, precisely to address this issue.

How does that help?

>> These types of additions to the BGP protocol

> Again, for that to have any utility it requires double-ended changes.

I don't have a problem with how the suggested mechanism works if only  
one end is changed; the problem is exactly with the case where both  
are changed, so this requirement isn't problematic here.

> precisely what I'm trying to fix!  The need for such changes is  

Hm, that RFC assumes that an attacker can get hold of a packet  
belonging to a password-protected BGP session in order to do a brute  
force search for the key. That doesn't make sense because:

1. There is no obvious way in which an attacker can obtain such packets
2. Expending so much computing resources to execute an attack that  
only causes some temporary rerouting doesn't seem worth the effort

> I agree with you completely about the need for better key management.

The main question I posed in Montreal still remains unanswered:  
wouldn't it be easier to just run BGP over IPsec if better security  
is required?