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

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

Hi, Eric (et al.),

To others - it might be useful to weigh in on this discussion...

Eric Rescorla wrote:
> At Thu, 29 Jan 2009 07:15:15 -0800,
...
>> We can bury the mechanism I suggest inside TCP-AO if desired, but I
>> think that just ends up making it even more heavyweight. Automated key
>> management is a mechanism that does not need to be inside TCP-AO - we
>> were given that direction by the ADs from the start.
> 
> I don't consider this to be automated key management, and I don't
> think it's very productive to argue about the direction from the ADs
> gave us. My understanding from the discussion in MSP was that there
> was general WG consensus that the protocol ought to include some
> mechanism for automatic switchover of manually configured keys
> without real-time coordination. The minutes aren't as explicit
> as one might like but sort of reflect this when they say: 
> 
> "***ACTION*** GL will write the text up explaining all of this"

Greg was a proponent of it, and we were all interested in hearing what
he was thinking; I don't recall anything beyond interest in seeing the
details. Upon examining it in detail, it involves coupling directly with
TCP exchanges in a way I think is out of scope based on what I recall
the ADs saying - they can certainly remind us of what they're thinking
now...

> That isn't to say you need to love Greg's mechanism, but if you
> think the WG shouldn't do this sort of thing at all, I think we
> need a more meta discussion, perhaps requiring more time 
> in SFO.

My view is that TCP-AO MUST support a mechanism for key coordination -
which I believe was consensus in the design team at least.

I prefer TCP-AO not to include that mechanism internally, to keep things
simple. That's just a preference, though.

I do think that mechanisms that couple tightly to a particular segment
exchange should be out of scope, however.

...
>>> In your system, the 5-6 transition is used to signal the
>>> availability of 7, but if that transition fails the connection just
>>> falls over.
>> It's trivial to handle misconfigured keys in a similar fashion in the
>> mechanism I proposed - when you get keyID6, you switch to using keyID7;
>> if you don't get ACKs after some timeout, you revert back. Again, this
>> can be done without burying the mechanism inside TCP (you can do it by
>> sampling the keyIDs received).
> 
> Well, you've now sort of reinvented the mechanism I originally
> suggested and which is in Greg's message,

Not really; the difference is that in my example side A can tell side B
it's ready to switch keys without ANY impact to side B; side B can
switchover when its ready. Further, my mechanism does not require tight
coupling with TCP segments being exchanged - it can be done through the
API, with zero impact to the TCP implementation.

> but this is worse IMO because
> substantial numbers of packets may be lost at one time before you can
> switch over. 

Yes, packets are lost when you switchover and the key is wrong in my
mechanism. However, NO packets are lost when the key is right, vs.
Greg's mechanism which loses all probe packets until the other side is
ready. The impact of the lost probes depends on the variant used; if no
new TCP segments are generated, then the lost probes impact TCP's
congestion control. If new TCP segments are generated, the
implementation needs to be tightly coupled with TCP (which, again, I was
expecting we were trying to avoid).

> Granted, this only happens with misconfiguration but it
> makes misconfiguration quite bad. And the logic around failure also
> becomes quite complicated. How long do I wait before I decide the
> other side has screwed up? 

IMO, that's the benefit - it's up to the user, not the TCP-AO
implementation to decide that.

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

iEYEARECAAYFAkmB5HQACgkQE5f5cImnZrtNvQCgnfJB1dfoGZErisfkDYxOASRu
UiYAoPhhqqLDlBrSde0y7uSbBzrMhHCl
=RxsO
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm