ikev2: Schedule a timeout for the delete message following passive IKE rekeying
authorMartin Willi <martin@revosec.ch>
Tue, 25 Nov 2014 13:21:34 +0000 (14:21 +0100)
committerMartin Willi <martin@revosec.ch>
Tue, 3 Mar 2015 12:45:39 +0000 (13:45 +0100)
commit1cce0df4a66a8eb8823fb3b140ddba0acebe517b
treed3364c4d183cf03a79a517e199329fa8fef5c961
parent6b57790270fb07c579315c70ecce34f8ad9a4d63
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.
src/libcharon/sa/ikev2/tasks/ike_rekey.c