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.
a3854d83 changed cleanup order. But we should remove CHILD_SAs first, as routes
for CHILD_SAs might get deleted while removing virtual IPs, resulting in
an error when a CHILD_SA tries to uninstall its route.
When a CHILD_SA is closed in IKEv1, if it is not being rekeyed and
closeaction has been set, we can now perform a restart or hold as is
currently done for IKEv2.
Tobias Brunner