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

[Eric Rescorla <[e-mail]>]

At Wed, 28 Jan 2009 08:57:56 -0800,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> > At Tue, 27 Jan 2009 13:34:20 -0800,
> > Joe Touch wrote:
> >> I'll kick off discussion on this point on the list.
> >>
> >> IMO, this mechanism is not viable for TCP-AO; it requires generating
> >> (and consuming) TCP segments that a native TCP would not generate. I was
> >> under the assumption that our design space was as close to TCP MD5 as
> >> possible, i.e., augment existing segments with a new option, but neither
> >> generate nor consume new segments.
> > 
> > I think it's important to separate two issues:
> > 
> > 1. How can an implementation decide when it's safe to use a newly installed
> >    key?
> > 2. How can an implementation help a peer implementation make that decision.
> > 
> > I think it's pretty clear that the most natural way to answer question
> > (1) is "when you see a segment protected with that key". Unfortunately,
> > this creates a deadlock problem since both sides are waiting for the
> > other side to use the key. Thus, we need a combination of two 
> > methods:
> > 
> > 1. If a node has two keys, OLD and NEW, as soon as it sees a segment
> >    from the peer protected with NEW, it starts sending with NEW.
> > 2. If a node has two keys, OLD and NEW, and it's still using OLD
> >    it occasionally experimentally sends a segment with NEW (probing).
> 
> 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. In other words,
if you get a packet with key-id 6 and you only have key-id 5, you should
reject it, not try the key corresponding to key-id 5, so we've reduced
this to a previously unsolved problem.

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. There's no natural
connection between the switch from 5-6 and the switch from 5-7. So, 
no, I don't favor that approach.

-Ekr








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