RE: Rekey of IKE-SA

["Geoffrey Huang" <ghuang@cisco.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

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