Because we only queue one MOBIKE task at a time, but destroy superfluous
ones only after we already increased the counter for pending MOBIKE updates,
we have to reduce the counter when such tasks are destroyed. Otherwise, the
queued task would assume another task is queued when it is running and
ignore any successful response.
Similar to assign_vips() used by a peer assigning virtual IPs to the other peer,
the handle_vips() hook gets invoked on a peers after receiving attributes. On
release of the same attributes the hook gets invoked again.
This is useful to inspect handled attributes, as the ike_updown() hook is
invoked after authentication, when attributes have not been handled yet.
If one peer starts reauthentication by deleting the IKE_SA, while the other
starts CHILD_SA rekeying, we run in a race condition. To avoid it, temporarily
reject the rekey attempt while we are in the IKE_SA deleting state.
RFC 4306/5996 is not exactly clear about this collision, but it should be safe
to reject CHILD_SA rekeying during this stage, as the reauth will re-trigger the
CHILD_SA. For non-rekeying CHILD_SA creations, it's up to the peer to retry
establishing the CHILD_SA on the reauthenticated IKE_SA.
Before this change a reqid set on the create_child_t task was used as
indicator of the CHILD_SA being rekeyed. Only if that was not the case
would the local traffic selector be changed to 0.0.0.0/0|::/0 (as we
don't know which virtual IP the gateway will eventually assign).
On the other hand, in case of a rekeying the VIP is expected to remain
the same, so the local TS would simply equal the VIP.
Since c949a4d501 reauthenticated CHILD_SAs also have the reqid
set. Which meant that the local TS would contain the previously
assigned VIP, basically rendering the gateway unable to assign a
different VIP to the client as the resulting TS would not match
the client's proposal anymore.
Fixes#553.
Prevents a responder peer to trick us into established state by starting
IKE_SA rekeying before the IKE_SA has been authenticated during IKE_AUTH.
Fixes CVE-2014-2338.
The salt, or often called implicit nonce, varies between AEAD algorithms and
their use in protocols. For IKE and ESP, GCM uses 4 bytes, while CCM uses
3 bytes. With TLS, however, AEAD mode uses 4 bytes for both GCM and CCM.
Our GCM backends currently support 4 bytes and CCM 3 bytes only. This is fine
until we go for CCM mode support in TLS, which requires 4 byte nonces.
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]>
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.
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.
Tobias Brunner