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

[Joe Touch <[e-mail]>]

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

Eric (et al.),

Eric Rescorla wrote:
> At Wed, 28 Jan 2009 08:57:56 -0800,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> 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).
>> I've already shown a way to achieve this without requiring the use of
>> the NEW key, i.e., that used two KeyIDs with the OLD key, using the
>> change in the KeyID to inform the endpoints. I've also described in that
>> email a way to achieve this using the current API, without asking TCP-AO
>> to generate new packets or to do anything conditional _inside_ TCP-AO;
>> this can (and, IMO, should) all be accomplished with an external
>> mechanism, with __no__ impact on the stack.
> 
> I read your mechanism, but I'm not sure it works.
> 
> The basic unit of operation here isn't keys but key-ids. It's true that
> in your example key-id 6 refers to the same key as key-id 5, but that's
> not something that the stack should be observing.

The stack doesn't observe it; the stack reports it if asked to an
external process.

> In other words,
> if you get a packet with key-id 6 and you only have key-id 5, you should
> reject it, not try the key corresponding to key-id 5, so we've reduced
> this to a previously unsolved problem.

I've reduced the problem to a configuration solution, not a TCP-level
protocol mechanism. If you remove aspects of the solution (i.e., if you
don't install a key with two keyIDs), then the solution obviously won't
work. That doesn't reintroduce the unsolved problem; it reverts to the
unsolved problem when not solved (which is a tautology).

> If your point is that at the time I install key-id 5 I also install a
> dummy key-id 6, and use that purely for signalling, I agree that that
> would work, but it strikes me as extremely kludgy. 

It allows side A to tell side B when side A has a new key installed,
without causing any packets to fall on the floor on side B (note that
retransmissions, if received, could open the congestion window
inappropriately).

The mechanism I proposed achieved with no modifications to the TCP stack.

The other mechanisms suggested all have the property of also using the
KeyID value as a signal. The only downside of the mechanism I proposed
is that is inefficient in the use of the KeyID space - however, the
space is large enough that this isn't an issue.

> There's no natural
> connection between the switch from 5-6 and the switch from 5-7.

Why should there be? IMO, it's up to the endpoints to decide how and
when to switch keys; key change coordination needs to be _enabled_ by
TCP-AO, but not provided by it. IMO, that's a KMS issue - whether
automated at the endpoints, or via a protocol.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmAnLwACgkQE5f5cImnZrsDggCeLX8Sy6YORgG4D0kz+usylDep
zDYAnR8EMoBNAtrXx90OJW1Z1O0lMljF
=Kqm5
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm