Re: [tcpm] question about TCP-AO and rekeying

[Joe Touch <[e-mail]>]

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



Eric Rescorla wrote:
> At Wed, 17 Jun 2009 08:41:52 -0700,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Eric Rescorla wrote:
>>> At Tue, 16 Jun 2009 23:24:55 -0700,
>>> Joe Touch wrote:
>>>> Eric Rescorla wrote:
>>>> ...
>>>>>> However, the invariant is twofold:
>>>>>>
>>>>>> 	a) for a given packet, only one MKT applies
>>>>>>
>>>>>> 	b) for two endpoints with multiple MKTs,
>>>>>> 	the *same* MKT applies.
>>>>> I don't see that this is true. As I understand the current design
>>>>> there's no reason that both sides can't use different MKTs
>>>>> indefinitely.
>>>> Each side can use a different MKT to transmit. However, if side A uses
>>>> MKT X to transmit, then side B needs to know to use MKT X to receive. If
>>>> side A matches MKT X on transmit and side B matches MKT Y on receive,
>>>> then there's a problem for that connection.
>>>>
>>>> So let's rephrase, recognizing that there are two MKTs at any given time
>>>> (one for transmit on each side, and the same pair for receive on the
>>>> opposite side).
>>>>
>>>> b) for two endpoints, if a given packet matches MKT on one side during
>>>> transmit, it must match the corresponding MKT on the other side during
>>>> receive.
>>> Right, but this doesn't require ordering or non-overlapping, as far as
>>> I can tell.  It merely requires that at any time there only be one MKT
>>> corresponding to any given socketpair/key-id.
>> That is only possible with either non-overlapping or ordering to resolve
>> overlaps.
> 
> I don't see why this is true. Any time a new key is entered, you
> find all other keys that overlap with it and verify that they
> have distinct key-ids.

That is a very expensive operation that I am hoping we can avoid.

> If so, the entry fails. If that's what
> you mean by "prohibit overlaps", yes, I think we should
> prohibit overlaps. 
> 
> If what you mean is that two MKTs with different key-ids can't overlap
> the same socket pair space, I don't see a problem with that.

That is a problem for outgoing SYNs. For those, either the connection
has to know a-priori which ID to use, or we need to make sure MKTs can't
overlap at all (ignoring keyIDs).

The former (connection knows the ID requires apps be rewritten to select
the ID before the SYN is sent. I hope we don't expect apps to be
rewritten to use TCP-AO on their connections.

The latter (MKTs don't overlap socket pairs at all) defeats the use of
less specific MKTs as a catchall, and more specific MKTs within that.
This means more constraints than just "one packet -> one MKT", e.g., it
may require that MKTs overlap only as subsets (which is efficient to check).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko5F7cACgkQE5f5cImnZrt/TwCgn2HqoZXKaIDfx0rUfczW761f
0TcAn3zednN0N6haw6lCYvgTyQpL8uXe
=EI3H
-----END PGP SIGNATURE-----