[tcpm] AO-04: Text for Key Coordination

["Gregory M. Lebovitz" <[e-mail]>]

Hey all,
I sent this text to Joe for -04, but it didn't quite make it. This 
text may or may not need to be in the spec. Personally, I'd like to 
see it in an example, or in an appendix, because I think it really 
makes clear how the coordination occurs in tricky case. I do think 
the rules need to be included in the main body text.  Pls comment:

 > ============
 > For three keys K1, K# and Kx
 > When only K1 is entered into TCP, set
 >   KeyID = K1
 >   NextKeyID = KeyID
 >
 >  send K1,K1  (per KeyID, NextKeyID convention)
 >
 > When K# is entered, set
 >   KeyID = K1
 >   NextKeyID = K#
 >  send K1,K# and continue sending K1,K# until K*,K# is received (where
 > "*" is wildcard ANY)
 >
 > Once receive K*,K#
 >    K1 - start 2MSL timer
 >   set KeyID = K#
 > AND
 >   SEND K#, K#
 >  -thus, will no longer send with K1, even if receive a segment out of
 > order with K1,K1 because already know that other side has and can use
 > K#, and K# has higher preference over K1.
 >
 > When Kx is entered
 >   K1 - MSLtimer !=0
 >   KeyID = K#
 >   NextKeyID = Kx
 > AND
 >   SEND K#, Kx  until K*,Kx is received.
 >
 > Once receive K*,Kx
 >    K1 - MSLtimer !=0
 >  set
 >    K# - start 2MSLtimer
 >    KeyID = Kx
 > AND
 >    SEND Kx, Kx
 >
 > In the below case, we assume K1 was current, then K# and Kx respectively
 > where entered in quick succession.
 >
 >   KeyID = K1
 >   NextKeyID = K#
 >
 > if no segments are received from Alice with K# in NextKeyID, then K#
 > never gets set to KeyID, and as such no segement is ever sent MAC'd
 > using K#.
 >
 > Then Kx is entered into Bob's TCP. Now:
 >
 >   KeyID = K1
 >   K# - start 2MSL timer
 >   NextKeyID = Kx
 >
 > because
 >   (a) we never made the shift to sending protected with K#, and
 >   (b) K1 is the only known good key for both me and Alice, so far, and
 >   (c) there can only be one NextKeyID, and Kx was the last entered, so
 > it gets NextKeyID
 >
 > In JT's out of order arrival example...
 >
 > The following flag settings would exist on Bob:
 >   KeyID = K1
 >   K# - 2MSLtimer !=0
 >   NextKeyID = Kx
 >
 > For snd = what Alice sends, rcv = what Bob receives, rply = what Bob
 > sends next (and we drop the "Ks" for ease of notation)
 >
 > snd  rcv  rply
 > -----  ----   -------
 > 1,1  1,1   1,x
 > 1,#  1,x   x,x  Bob executes K1 start 2MSLtimer, AND KeyID = Kx,
 >                      AND NextKeyID=KeyID
 > 1,x  1,#   x,x
 > (at this point Alice would start sending x,x)
 > (even if she didn't for some reason, like she hadn't yet received back
 > an x,x from Bob due to drops or latency, it would look like:
 > 1,x  1,x   x,x
 > 1,x  1,x   x,x
 > 1,x  1,x   x,x
 > ...
 > (until Alice finally received an x,x from Bob, and thus started sending x,x)
 > x,x  x,x   x,x
 > x,x  x,x   x,x


 > The rules describing all this are:
 >
 > For local values of
 >    KeyID
 >    NextKeyID

 > SENDING:
 > IF NextKeyID = KeyID, send KeyID(KeyID), NextKeyID(KeyID)
 >   ELSE send KeyID(KeyID), NextKeyID(NextKeyID)

 > KEY MOVEMENT:
 >  when you receive a NextKeyID = Ky from peer:

 >   IF for local Ky 2MSLtime != 0, then do nothing
 >   IF local KeyID = Ky, do nothing
 >   IF local NextKeyID = Ky, and NextKeyID != KeyID
 >      THEN, given a current KeyID = Kx, start Kx 2MSLtimer
 >    AND set local KeyID = Ky
 >    AND set local NextKeyID = KeyID

 > ENTERING KEYS INTO TCP:
 >   When a new key Ky is entered into TCP, for an existing Kx:

 >   IF NextKeyID = KeyID, THEN set NextKeyID = Ky,
              now KextKeyID = Ky and KeyID = Kx
 >   IF local Kx = NextKeyID != KeyID, THEN set Kx 2MSLtimer,
 >        AND set NextKeyID = Ky
 >   IF Ky 2MSLtimer != 0, THEN set Ky 2MSLtimer = 0, AND NextKeyID = Ky
 >      (This one is for repeated keyID value usage, or correcting a config
 > mixup.)
 >     or we might want to say:
 >    IF Ky 2MSLtimer !=0, THEN throw error "Ky already in aging state,
 > cannot install"
 >

Thoughts?
Gregory.


+++++++++++++++++++++++
IETF-related email from
Gregory M. Lebovitz
Juniper Networks
g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m