ikev2: Schedule a timeout for the delete message following passive IKE rekeying

Under some conditions it can happen that the CREATE_CHILD_SA exchange for
rekeying the IKE_SA initiated by the peer is successful, but the delete message
does not follow. For example if processing takes just too long locally, the
peer might consider us dead, but we won't notice that.

As this leaves the old IKE_SA in IKE_REKEYING state, we currently avoid actively
initiating any tasks, such as rekeying or scheduled DPD. This leaves the IKE_SA
in a dead and unusable state. To avoid that situation, we schedule a timeout
to wait for the DELETE message to follow the CREATE_CHILD_SA, before we
actively start to delete the IKE_SA.

Alternatively we could start a liveness check on the SA after a timeout to see
if the peer still has that state and we can expect the delete to follow. But
it is unclear if all peers can handle such messages in this very special state,
so we currently don't go for that approach.

While we could calculate the timeout based on the local retransmission timeout,
the peer might use a different scheme, so a fixed timeout works as well.

Fixes #742.
This commit is contained in:
Martin Willi 2014-11-25 14:21:34 +01:00
parent 6b57790270
commit 1cce0df4a6
1 changed files with 6 additions and 0 deletions

View File

@ -210,6 +210,12 @@ METHOD(task_t, build_r, status_t,
this->public.task.build = _build_r_delete;
this->public.task.process = _process_r_delete;
/* the peer does have to delete the IKE_SA. If it does not, we get a
* unusable IKE_SA in REKEYING state without a replacement. We consider
* this a timeout condition by the peer, and trigger a delete actively. */
lib->scheduler->schedule_job(lib->scheduler, (job_t*)
delete_ike_sa_job_create(this->ike_sa->get_id(this->ike_sa), TRUE), 90);
return NEED_MORE;
}