Previously, the logger installed by the controller always announced
LEVEL_PRIVATE(4), which produced completely useless logging calls with
the common clients (vici/stroke) whose default log level is LEVEL_CTRL(1).
This can produce quite some overhead if there are e.g. a lot of concurrent
initiate() calls.
While combining the actions could cause duplicates (while the SA is
initiated, traffic might trigger the trap and the initiation of another
CHILD_SA), the previous commit should avoid most duplicates. If reuse_ikesa
is disabled, duplicates can't be prevented, though.
This should make the DoS limits (cookie_threshold[_ip] and block_threshold)
more accurate so that it won't be possible to create lots of jobs from
spoofed IP addresses before half-open IKE_SAs are actually created from
these jobs to enforce those limits.
Note that retransmits are tracked as half-open SAs until they are
processed/dismissed as the check only happens in checkout_by_message().
Increasing the count in process_message_job_create() avoids issues with
missing calls to track_init() before calling checkout_by_message() (e.g.
when processing fragmented IKEv1 messages, which are reinjected via a
process message job).
This allows more fine grained control over what's updated and does not
require multiple calls of the method. Plus we'll be able to use it in
the ike-mobike task.
Reqids for the same traffic selectors are now stable so we don't have to
pass reqids of previously installed CHILD_SAs. Likewise, we don't need
to know the reqid of the newly installed trap policy as we now uninstall
by name.
This allows us to use it without having to initialize libcharon, which
was required for the logging (we probably could have included debug.h
instead of daemon.h to workaround that but this seems more correct).
This way updates to the mediation config are respected and the order in
which configs are configured/loaded does not matter.
The SQL plugin currently maintains the strong relationship between
mediated and mediation connection (we could theoretically change that to a
string too).
If the job gets queued for a newly created IKE_SA it might not yet be
checked in when the job is running, reschedule the job in that case.
This should fix the two p2pnat test scenarios, which occasionally
failed because one of the peers did not initiate the connection to
the mediation server.
Instead of just implicitly destroying the old SA we properly delete it to
notify the other peer (if the other peer keeps the SA up after the
reauthentication and sends DPDs it might consider us dead even though the
new SA is up, that seems to be the case with racoon). We delay the DELETE
a bit to give the other peer time to get the new SA fully established.
Since DELETE messages are not retransmitted it is still possible that
the other peer misses that we deleted the SA.
This is needed to handle DELETEs properly, which was previously done via
CHILD_REKEYING, which we don't use anymore since 5c6a62ceb6 as it prevents
reauthentication.
Some clients like iOS/Mac OS X don't do a mode config exchange on the
new SA during re-authentication. If we don't adopt the previous virtual
IP Quick Mode rekeying will later fail.
If a client does do Mode Config we directly reassign the VIPs we migrated
from the old SA, without querying the attributes framework.
Fixes#807, #810.
If additional tasks get queued before/while rekeying an IKE_SA, these get
migrated to the new IKE_SA. We previously did not trigger initiation of these
tasks, though, leaving the task unexecuted until a new task gets queued.
While a passively installed IKE_SA does not queue a DPD timeout job, one that
switches from active to passive might execute it. Ignore such a queued job if
the IKE_SA is in passive state.
When doing a rekey for a CHILD_SA, the use counters get reset. An inactivity
job is queued for a time unrelated to the rekey time, so it might happen
that the inactivity job gets executed just after rekeying. If this happens,
inactivity is detected even if we had traffic on the rekeyed CHILD_SA just
before rekeying.
This change implies that inactivity checks can't handle inactivity timeouts
for rekeyed CHILD_SAs, and therefore requires that inactivity timeout is shorter
than the rekey time to have any effect.
Tobias Brunner