[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rekey of IKE-SA



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

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
|