This patch exports the task manager's flush to allow flushing of all
queues with one function call from ike_sa->destroy. It allows the
access of intact children during task destructoin (see git-commit
e44ebdcf) and allows the access of the task manager in
child_state_change hook.
Signed-off-by: Thomas Egerer <[email protected]>
Because the write lock was held while calling add_policies() on
child_sa_t, which finishes with a call to child_state_change() on bus_t,
a deadlock would ensue if CHILD_SAs are concurrently being established,
which also causes a call to child_state_change() that will require
the read lock in trap_manager_t.
No locks are now being held while creating the CHILD_SA and installing the
trap policies.
Some peers seem to defer DELETEs a few seconds after rekeying the IKE_SA, which
is perfectly valid. For short(er) DPD delays, this leads to the situation where
we send a DPD request during set_state(), but the IKE_SA has no hosts set yet.
Avoid that DPD by resetting the INBOUND timestamp during set_state().
When we have a "keep" unique policy in place, we have to be less strict in
rejecting Main/Aggressive Modes to enforce it. If the host/port equals to
that of an existing ISAKMP SA, we assume it is a reauthentication attempt
and accept the new SA (to replace the old).
Sending a DELETE for the replaced SA immediately is problematic during
reauthentication, as the peer might have associated the Quick Modes to the
old SA, and also delete them.
With this change the delete for the old ISAKMP SA is usually omitted, as it
is gets implicitly deleted by the reauth.
This is especially useful on Android where we are able to send messages
even if we don't know the correct local address (this is possible
because we don't set source addresses in outbound messages). This way
we may learn the correct local address if it e.g. changed right before
reestablishing an SA.
Updating the local address later is tricky without MOBIKE as the
responder might not update the associated IPsec SAs properly.
If PFS is configured for a CHILD_SA first try to create a list of
proposals with using DH group negotiated during phase 1. If the
resulting list is empty (i.e. the DH group(s) configured for PFS differ
from the one(s) configured for the IKE_SA), fall back to the first
configured DH group from the CHILD_SA.
This modificiation is due to the fact that it is likely that the peer
supports the same DH group for PFS it did already for the IKE_SA.
The configuration string is appended to the XAuth backend name, separated by
a colon. The configuration string is passed untouched to the backend, where
it can change the behavior of the XAuth module.
Martin Willi