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