Re: [tcpm] TCP-AO: Text for New_Key Process

[Brian Weis <[e-mail]>]

The message below summarizes the problem nicely.

On Jan 28, 2009, at 8:27 AM, Eric Rescorla wrote:

> At Tue, 27 Jan 2009 13:34:20 -0800,
> Joe Touch wrote:
>> I'll kick off discussion on this point on the list.
>>
>> IMO, this mechanism is not viable for TCP-AO; it requires generating
>> (and consuming) TCP segments that a native TCP would not generate.  
>> I was
>> under the assumption that our design space was as close to TCP MD5 as
>> possible, i.e., augment existing segments with a new option, but  
>> neither
>> generate nor consume new segments.
>
> I think it's important to separate two issues:
>
> 1. How can an implementation decide when it's safe to use a newly  
> installed
>    key?
> 2. How can an implementation help a peer implementation make that  
> decision.
>
> I think it's pretty clear that the most natural way to answer question
> (1) is "when you see a segment protected with that key".  
> Unfortunately,
> this creates a deadlock problem since both sides are waiting for the
> other side to use the key. Thus, we need a combination of two
> methods:
>
> 1. If a node has two keys, OLD and NEW, as soon as it sees a segment
>    from the peer protected with NEW, it starts sending with NEW.
> 2. If a node has two keys, OLD and NEW, and it's still using OLD
>    it occasionally experimentally sends a segment with NEW (probing).
>
> Taken together, these rules allow a clean transition, since both
> nodes are in probing state until one node receives a packet with
> NEW, at which point it switches over and the peer soon follows.
>
> The question then becomes how the probing mechanism works. At a
> high level, there are two options:
>
> 1. Probe with packets that the TCP stack would already send.
> 2. Generate new segments to use explicitly as probes.
>
> The advantage of (1) is obviously minimal impact on the stack,
> but may mean that segments are lost and could unless cere is taken,
> exert false congestion feedback. The advantage of (2) is that it
> is less likely to create false congestion feedback, but it requires
> more changes to the stack and of course creates additional traffic
> on the wire. Greg's mechanism is of course of type (2).
>
> -Ekr


Probing implies "using a key optimistically", whereby the sender is  
taking a substantial risk that the peer does not yet have knowledge  
of that key. I don't particularly like either option above since they  
are both highly likely to result in significant change to the  
operation of the TCP session.

Joe mentioned a third approach. Summarizing the discussion, rather  
than "probe" with segments that the TCP stack would already send, his  
approach would add a signal to TCP segments noting that a new master  
key was available. This helps a peer implementation make the decision  
to move to a new key (i.e., the problem we're trying to solve)  
without actually using the new key. This can break the deadlock  
without the actual use of the new key.

I favor this approach, but not the mechanism. Joe's idea consumes one  
extra KeyID value for each real KeyID. The example given was to  
allocate both KeyID 5 and KeyID 6 when using KeyID 5. Signaling the  
presence of a new key comes by moving to KeyID 6. But overloading  
KeyIDs is not ideal -- in particular, recall that KeyID values are  
chosen by some external entity (e.g., a human or some automated key  
management system). I'm really not confident that a human will always  
appreciate that they can only configure "odd" KeyID values, for  
example. Furthermore, in order to guarantee interoperability I  
believe that this would have to be described in TCP-AO. We would want  
to avoid different implementations have different conventions, and  
not be able to set the same KeyIDs! This could be a fair amount of  
addition to TCP-AO.

A better approach is to steal a bit from the KeyID field, and give it  
the meaning "I have a new KeyID". This is an explicit marking with a  
clear meaning. There's no reason the KeyID has to consume 8 bits --  
KeyIDs should be associated with a single peer, and even 7 bits worth  
of simultaneous KeyIDs should be more than enough. A system  
configured with a new KeyID for that peer sets the "new KeyID bit"; a  
system which also has a new KeyID begins use of it when it sees that  
bit set. As far as I can tell, stealing this bit has a negligible  
effect on the current definition of TCP-AO.

Some further comments addressing other discussion in this thread:

- No external entity has to be present in this approach.

- It's true that the two systems could have made an error in stalling  
a new set of policy, and automatically switching to a new KeyID could  
result in peers that cannot communicate. It is a plausible situation  
when the values are manually configured. I'm personally willing to  
make that tradeoff for a simpler TCP stack. This error should rarely  
occur in the presence of a future automated key management method.

One more thought ... it seems to me that with probe-based approaches  
a man-in-the-middle can prevent the session ever moving to the new  
key. This would be done by dropping frames containing a new KeyID,  
forcing the TCP session continue with an old key. Continued use of  
the old key indefinitely may not be detected by operations staff. On  
the other hand, the presences of a "new KeyID bit" would requires a  
man-in-the-middle to disrupt the TCP session entirely, which is not a  
new attack on TCP, and also immediately visible to operations staff.

Brian

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: [phone]
Email: [e-mail]

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm