The kernel will apply the mask to the mark on the packet and then
compare it to the configured mark. So to match only unmarked packets we
have to be able to set 0/0xffffffff.
If the number of flows over a gateway exceeds the flow cache size of the Linux
kernel, policy lookup gets very expensive. Policies covering more than a single
address don't get hash-indexed by default, which results in wasting most of
the cycles in xfrm_policy_lookup_bytype() and its xfrm_policy_match() use.
Starting with several hundred policies the overhead gets inacceptable.
Starting with Linux 3.18, Linux can hash the first n-bit of a policy subnet
to perform indexed lookup. With correctly chosen netbits, this can completely
eliminate the performance impact of policy lookups, freeing the resources
for ESP crypto.
WARNING: Due to a bug in kernels 3.19 through 4.7, the kernel crashes with a
NULL pointer dereference if a socket policy is installed while hash thresholds
are changed. And because the hashtable rebuild triggered by the threshold
change that causes this is scheduled it might also happen if the socket
policies are seemingly installed after setting the thresholds.
The fix for this bug - 6916fb3b10b3 ("xfrm: Ignore socket policies when
rebuilding hash tables") - is included since 4.8 (and might get backported).
As a workaround `charon.plugins.kernel-netlink.port_bypass` may be enabled
to replace the socket policies that allow IKE traffic with port specific
bypass policies.
They are only required if drop policies would otherwise prevent
forwarding traffic. This reduces the number of policies and avoids
conflicts e.g. with SPD hash thresholds.
When fresh CRLs are released with a high update frequency (e.g.
every 24 hours) or OCSP is used then the certificate cache gets
quickly filled with stale CRLs or OCSP responses. The new VICI
flush-certs command allows to flush e.g. cached CRLs or OCSP
responses only. Without the type argument all kind of certificates
(e.g. also received end entity and intermediate CA certificates)
are purged.
Some tasks might get removed immediately once the IKE_SA_INIT response has
been handled even if there were notifies that require a restart of the
IKE_SA (e.g. COOKIE or INVALID_KE_PAYLOAD). Such a task is ike_vendor,
which caused vendor IDs not to get sent in a retry. This change ensures
all required tasks are queued after the reset, which some callers did
already anyway.
These seem to indicate the major and minor version of the protocol, like
e.g. for the DPD vendor ID. Some implementations seem to send versions
other than 1.0 so we just ignore these for now when checking for known
vendor IDs.
Fixes#2088.
By aborting the active task we don't have to wait for potential
retransmits if the other peer does not respond to the current task.
Since IKEv1 has no sequential message IDs and INFORMATIONALs are no real
exchanges this should not be a problem.
Fixes#1537
References #429, #1410Closesstrongswan/strongswan#48
Depending on the lifetimes a CHILD_SA we rekeyed as responder might
expire shortly afterwards. We don't want to rekey it again.
When retrying due to an INVALID_KE_PAYLOAD notify the expected state
is CHILD_REKEYING if it is anything else (e.g. due to a collision) we
ignore it.
We also abort the exchange properly if we don't find the CHILD_SA, no
need for an empty INFORMATIONAL exchange anymore.
If a passive rekeying fails due to an INVALID_KE_PAYLOAD we don't want
to consider this task later when resolving collisions. This previously
might have caused the wrong SA to get deleted/installed based on the nonces
in the unsuccessful exchange.
Such a task is not initiated unless a certain time has passed. This
allows delaying certain tasks but avoids problems if we'd do this
via a scheduled job (e.g. if the IKE_SA is rekeyed in the meantime).
If the IKE_SA is rekeyed the delay of such tasks is reset when the
tasks are adopted i.e. they get executed immediately on the new IKE_SA.
This hasn't been implemented for IKEv1 yet.
If the peer does not detect the rekey collision and deletes the old
IKE_SA and then receives the colliding rekey request it will respond with
TEMPORARY_FAILURE. That notify may arrive before the DELETE does, in
which case we may just conclude the rekeying initiated by the peer.
Also, since the IKE_SA is destroyed in any case when we receive a delete
there is no point in storing the delete task in collide() as process_i()
in the ike-rekey task will never be called.
We conclude the rekeying before deleting the IKE_SA. Waiting for the
potential TEMPORARY_FAILURE notify is no good because if that response
does not reach us the peer will not retransmit it upon our retransmits
of the rekey request if it already deleted the IKE_SA after receiving
our response to the delete.
Tobias Brunner