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

["Eddy, Wesley M. (GRC-RCN0)[VZ]" <[e-mail]>]

I mostly agree with Joe, and have some brief comments below:

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of Joe Touch
>Sent: Thursday, January 29, 2009 12:17 PM
>
>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.
>


The direction that we were always heading in was that TCPM will make
sure the spec for AO permits automated changes of keys and won't be
breaking other parts of TCP in the meantime.  We understood that
"permiting" or "supporting" the changeover in AO didn't mean actually
being responsible for doing it all inside the TCP connection, and that
the SECDIR would define a separate mechanism (not inside TCP) for this.
To be done timely and without bugs, AO has to stay as simple as the
needed security properties permit, so I have to agree with Joe.


>> 
>> 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.


This is a very important property given the level of complexity that
we already have in TCP implementations to be robust under all sorts
of circumstances and with various combinations of options in play.


>> 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).


I agree, this should definitely be avoided.  It's easy to specify wrong,
and even easier to implement wrong.


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