Re: Rekey of IKE-SA

["David Faucher" <dfaucher@lucent.com>]

| > I think adding a 3rd IKE-SA into the management
| > of CHILD-SAs does add some complexity.
| > 
| > - the deletion of CHILD-SAs must be coordinated between two IKE-SAs.
| > - simultaneous DELETEs of a CHILD-SA on the two rekeyed IKE-SAs.
| > - creation of new CHILD-SAs on both rekeyed IKE-SAs which prevents
| > rekeying only one of them (at the next rekey period).
| > 
| > As for a simple proposal, The "original initiator's" request
| > for a rekey always wins.
| > 
| >     - if a collision is detected by the "original initiator", it MUST
| >     respond to the rekey request with a NOTIFY payload containing a
| >     error code of "REKEY-IN-PROGRESS".
| > 
| >     - if a collision is detected by the "original repsonder", it MUST
| >     respond to the rekey request as normal. (It's rekey request will
| >     fail due to receipt of error "REKEY-IN-PROGRESS).
| 
| If you want the NOTIFY message to be protected, then you'll have to wait
| for the IKE SA to finish phase 1.  I suppose in your proposal, then,
| that the "original initiator" would determine which IKE SA gets the
| REKEY-IN-PROGRESS error?
| 
| -g
| 

The proposal doesn't actually need the NOTIFY to work properly. It
was merely sent as a courtesy (MUST could be changed to SHOULD or MAY)
since the "original responder" would detect the collision as well
and thus could tear down its rekey request.


| > David
| > 
| > 
| > ----- Original Message -----
| > From: "Stephane Beaulieu" <stephane@cisco.com>
| > To: "David Faucher" <dfaucher@lucent.com>; <ipsec@lists.tislabs.com>
| > Sent: Monday, November 25, 2002 2:01 PM
| > Subject: RE: Rekey of IKE-SA
| > 
| > 
| > | I would think that in the event of a rekey collision that 
| > both IKE SAs
| > could
| > | be used.  It is a little bit wasteful of resources to have 
| > 2 where only 1
| > is
| > | needed, but there should be no functional difference.  
| > After all, you
| > still
| > | need to be able to handle the time in which there is an 
| > overlap between
| > the
| > | old SA and the new one.  So, if you have to handle that 
| > anyway, there is
| > | probably no point in adding any functionality to the 
| > protocol.  If that
| > | should occur, you just have to make sure you only rekey (on the next
| > rekey),
| > | one of those 2 IKE SAs.
| > |
| > | Adding a good jitter to your expiry should greatly reduce 
| > the number of
| > | collisions (except maybe in the lab with very small lifetimes).
| > |
| > | If you have a specific proposal that is VERY simple then I 
| > might change my
| > | mind Otherwise I'm inclined to say that it's really not 
| > complicated to
| > deal
| > | with in the event it does happen, and should be rare enough 
| > to forget
| > about
| > | the resource impact.
| > |
| > | Stephane.
| > |
| > | > -----Original Message-----
| > | > From: owner-ipsec@lists.tislabs.com
| > | > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Faucher
| > | > Sent: Monday, November 25, 2002 12:22 PM
| > | > To: ipsec@lists.tislabs.com
| > | > Subject: Rekey of IKE-SA
| > | >
| > | >
| > | >
| > | > I believe IMHO, that there needs to be a mechanism for
| > | > avoiding a collision on an IKE-SA rekey. In its absence
| > | > nodes may end up assigning ownership of the child-SAs to
| > | > different IKE-SAs.
| > | >
| > | > This subject has been brought up before (May 2002) but
| > | > without a firm resolution.
| > | >
| > | > David
| > |
| > 
| > 
|