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

At Wed, 28 Jan 2009 09:58:20 -0800,
Joe Touch wrote:
> Eric Rescorla wrote:
> >> 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.

As I've indicated before, I think this whole external process thing
is overcomplicating matters. Key management daemons are a bug,
not a feature, and it would be much better if things could
be constructed so the TCP-AO module would do everything. 

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

Yes, by laying the burden on some as yet nonexistent key management
mechanism.

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

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

-Ekr

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm