#29 [*](2401bis) Rekeying (section 4.4.1)

#29 [*](2401bis) Rekeying (section 4.4.1)

	section 4.4.1:
	Please make sure this discussion is aligned with 2401bis.  I think it
	may change small details but they seem to have adopted much of the
	same strategy kink uses.  The area wher I believe they speak to this
	issue is when you should rekey (timers etc).  (Sam Hartman)

About issue #29, I could not completely understand what is an isssue in seciton
4.4.1.

However I guess there is an issue, which is a possibility of difference between
Treky and soft lifetime. Instead both Trekey and soft lifetime specify time of
starting rekey.

At "4.4.2.1 Data Items in the SAD" in rfc2401bis, there is a description about
lifetime

     (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
         warns the implementation to initiate action such as setting up
         a replacement SA; and a hard lifetime when the current SA ends
         and is destroyed.

If we will be able to replace Trekey by "soft lifetime", it will be editorial
issue. Unless, we need to understand the reason why KINK introduced Trekey.

How about this as the third paragraph?

Normally a KINK implementation which rekeys existing security associations will
start to rekey the security association at the soft lifetime. In order to avoid
synchronization with similar implementations, KINK initiators MUST randomly pick
a rekeying time between the soft lifetime and the hard lifetime minus the amount
of time it would take to go through a full retransmission time cycle, Tretrans.
The soft lifetime SHOULD be set at least twice Tretrans before the hard lifetime.

#The last sentence would not be needed.

BTW KINK specifies the initiator is responsible for rekeying but it introduces
randomizing rekey time to avoid synchronization. What is the synchronization?

--
Kazunori Miyazawa