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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI - there's an important reason not to use a separate flag bit. Doing
so requires parsing the bits of the incoming packet, i.e., this adds
extra processing. It also indicates to everyone on the wire that a key
change is pending; when using only the KeyID, no extra parsing is needed
and the meaning of a changing key is opaque to those on the wire.

Using a key flag means that one side can only ever tell the other end
"ready to use the new key", not which key (if there could be more than
one). That means that if you try it once and it fails and you want to
try it again, you might have to wait MSL (a few minutes) to try it
again, otherwise an old packet might indicate 'ready to receive the new
key" for the wrong key.

Overall, using just the keyID value as the indicator seems much more
flexible to and simple to me.

Joe

Brian Weis wrote:
> 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmGGNAACgkQE5f5cImnZrsbbQCfTVkugXLOyh4n0BPEpPBwiHgT
NRsAoMmHYFOT7gt0FukxM45NnNsfk4jb
=99A4
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm