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

[Eric Rescorla <[e-mail]>]

At Thu, 29 Jan 2009 07:15:15 -0800,
Joe Touch wrote:
> Eric Rescorla wrote:
> > At Wed, 28 Jan 2009 09:58:20 -0800,
> >> 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.
> > 
> > Yes, by laying the burden on some as yet nonexistent key management
> > mechanism.
> 
> 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"

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.



> >> 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.
> > 
> > That's far from the only downside.
> > 
> > For one, consider what happens if key 7 is misconfigured. In Greg's
> > system, everything works fine, because packets with MAC failures are
> > dropped.
> 
> I cannot believe TCP-AO needs to handle misconfigured keys. This is
> supposed to be a lightweight mechanism.

I agree it should be a lightweight mechanism, but as I took it your
argument is that we don't need an in protocol switchover mechanism
because it could be done with the external mechanism you propose.
My point is that your external mechanism is inferior in this 
respect, which motivates an internal mechanism.

This isn't the only downside, however. Your mechanism also entails
significantly more user intervention in the switchover process
to install these dummy keys. I don't consider that a feature.
  

> > 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, but this is worse IMO because
substantial numbers of packets may be lost at one time before you can
switch over. 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? 


> >>> 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.
> > 
> > Again, I don't agree. TCP-AO should work fine without some additional
> > KMS, and that includes having unsynchronized key changes work correctly.
> 
> TCP-AO *supports* key management; it doesn't include it. Synchronizing
> key changes is key management.

This seems like a definitional argument. As I said at the beginning, 
it was my read of the discussion in MSP that the WG agreed there
should be such a mechanism. I think that having one would be a good
thing. If that's key management, then make the most of it.

-Ekr



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