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.
When we have a trap installed, but a CHILD_SA gets established for the same
config from the peer, we should reuse the same reqid. Otherwise we would have
two identical policies using different reqids, what we can't handle in our
kernel backend.
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
RFC 5996 compatible implementations MAY send an INFORMATIONAL message
with an AUTHENTICATION_FAILED if the initiator failed to authenticate us.
Handle such a message like a DELETE for an IKE_SA.
According to RFC 5996, we MAY send an INFORMATIONAL message having an
AUTHENTICATION_FAILED. We don't do any retransmits, though, but just close
the IKE_SA after one message has been sent, avoiding the danger that an
unauthenticated IKE_SA stays alive.
While this was problematic in earlier releases, it seems that it works just
fine the way we handle compression now. So there is no need to disable it over
NATed connections or when using forceencaps.
The previous code did not properly check for the situation when the
DELETE for a redundant CHILD_SA created by a responder during a
CHILD_SA rekey collision arrives before the responder's answer to the
initiator's winning CREATE_CHILD_SA request.
If two peers rekey Quick Modes at the same time, the original Quick Mode is
in REKEYING state and hence the requid is not reused. This is required though,
as two identical policies won't work if they have different requids.
This XAuth backend does not do any authentication of client credentials
but simply sends a successful XAuth status to the client, thereby
concluding the XAuth exchange. This can be useful to fallback to basic
RSA authentication with clients that can not be configured without XAuth
authentication.
Tobias Brunner