| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
For instance, if a DPD exchange is initiated by the gateway when a
mobile client is roaming and it then gets a new IP address and sends
an address update via MOBIKE, the DPD retransmits would still be sent
to the old address and the SA would eventually get closed.
|
|
|
|
|
| |
If a fragmented message is retransmitted only the first packet is passed
to the alert() hook.
|
| |
|
|
|
|
| |
We now prefer MOBIKE tasks over delete tasks then the rest.
|
|
|
|
|
|
|
|
| |
This reverts commit 3293d146289d7c05e6c6089ae1f7cdbcea378e63.
The position of tasks in the queue does not actually determine the order
in which they are activated. Instead this is determined by the
statements in task_manager_v2_t.initiate().
|
|
|
|
|
| |
The MOBIKE task is active during the initial exchanges but we don't want
to treat them as actual MOBIKE exchanges (i.e. there is no path probing).
|
| |
|
| |
|
|
|
|
| |
Path probing is enabled if the current path is not available anymore.
|
|
|
|
|
| |
We do the same before initiating the task, so we should probably do it
too when we already initiated it, not just time out and destroy the SA.
|
| |
|
|
|
|
|
|
|
| |
This might not be the case if e.g. an address appeared but the old one
is still available but not actually usable. Without this the MOBIKE
task would eventually time out even though we might be able to switch
to a working address.
|
| |
|
| |
|
|
|
|
|
| |
In case we have no usable path to the other peer there is no point in
initiating any other tasks (like rekeying).
|
|
|
|
|
| |
This will probably never be more than 1 since we only have one task queued
at a time and we don't migrate running tasks.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The old identifiers did not use a proper namespace and often clashed with
other defines.
|
|
|
|
|
|
|
|
|
|
|
| |
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 c949a4d5016e33c5 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.
|
|
|
|
|
| |
Works around issues related to system time changes and kernel backends using
that system time, such as Linux XFRM.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Courtesy of C.J. Adams-Collier, ZeroLag Communications, Inc.
|
|
|
|
| |
Courtesy of C.J. Adams-Collier, ZeroLag Communications, Inc.
|
|
|
|
| |
Courtesy of C.J. Adams-Collier, ZeroLag Communications, Inc.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 <thomas.egerer@secunet.com>
|
| |
|
|
|
|
| |
Fixes #437.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
closeaction=restart|hold
This regression was introduced with c949a4d5.
|
|
|
|
|
|
|
| |
handling IKE_SA_INIT
We want to avoid this allocation if the initial message is invalid (e.g.
if the message ID is != 0).
|
|
|
|
| |
Partially based on an old patch by Adrian-Ken Rueegsegger.
|
| |
|
|
|
|
|
| |
Not directly returning a linked list allows us to change the internals of
the CHILD_SA transparently.
|
|
|
|
| |
Eliminates another three lists, 0.5KB per IKE_SA.
|
| |
|
| |
|
|
|
|
|
| |
If the responder not correctly send the correct protocol or SPI in the delete
response, we should remove the CHILD_SA regardless.
|