diff options
| author | Martin Willi <martin@revosec.ch> | 2014-04-10 11:25:32 +0200 |
|---|---|---|
| committer | Martin Willi <martin@revosec.ch> | 2014-04-17 09:59:06 +0200 |
| commit | f02cabbe358cc2f5636de0f7de7be114884302c3 (patch) | |
| tree | 4c494c15a71b193e436953f1b81b00c759c2175f /src | |
| parent | 094963d1b16024c56adc624cc97729ce424e2814 (diff) | |
| download | strongswan-f02cabbe358cc2f5636de0f7de7be114884302c3.tar.bz2 strongswan-f02cabbe358cc2f5636de0f7de7be114884302c3.tar.xz | |
ikev2: Reject CHILD_SA creation/rekeying while deleting an IKE_SA
If one peer starts reauthentication by deleting the IKE_SA, while the other
starts CHILD_SA rekeying, we run in a race condition. To avoid it, temporarily
reject the rekey attempt while we are in the IKE_SA deleting state.
RFC 4306/5996 is not exactly clear about this collision, but it should be safe
to reject CHILD_SA rekeying during this stage, as the reauth will re-trigger the
CHILD_SA. For non-rekeying CHILD_SA creations, it's up to the peer to retry
establishing the CHILD_SA on the reauthenticated IKE_SA.
Diffstat (limited to 'src')
| -rw-r--r-- | src/libcharon/sa/ikev2/tasks/child_create.c | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/src/libcharon/sa/ikev2/tasks/child_create.c b/src/libcharon/sa/ikev2/tasks/child_create.c index e0ade07b2..35b7e12c9 100644 --- a/src/libcharon/sa/ikev2/tasks/child_create.c +++ b/src/libcharon/sa/ikev2/tasks/child_create.c @@ -1192,6 +1192,12 @@ METHOD(task_t, build_r, status_t, message->add_notify(message, TRUE, NO_ADDITIONAL_SAS, chunk_empty); return SUCCESS; } + if (this->ike_sa->get_state(this->ike_sa) == IKE_DELETING) + { + DBG1(DBG_IKE, "unable to create CHILD_SA while deleting IKE_SA"); + message->add_notify(message, TRUE, NO_ADDITIONAL_SAS, chunk_empty); + return SUCCESS; + } if (this->config == NULL) { |