| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under some conditions it can happen that the CREATE_CHILD_SA exchange for
rekeying the IKE_SA initiated by the peer is successful, but the delete message
does not follow. For example if processing takes just too long locally, the
peer might consider us dead, but we won't notice that.
As this leaves the old IKE_SA in IKE_REKEYING state, we currently avoid actively
initiating any tasks, such as rekeying or scheduled DPD. This leaves the IKE_SA
in a dead and unusable state. To avoid that situation, we schedule a timeout
to wait for the DELETE message to follow the CREATE_CHILD_SA, before we
actively start to delete the IKE_SA.
Alternatively we could start a liveness check on the SA after a timeout to see
if the peer still has that state and we can expect the delete to follow. But
it is unclear if all peers can handle such messages in this very special state,
so we currently don't go for that approach.
While we could calculate the timeout based on the local retransmission timeout,
the peer might use a different scheme, so a fixed timeout works as well.
Fixes #742.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As we now use the same reqid for multiple CHILD_SAs with the same selectors,
having marks based on the reqid makes not that much sense anymore. Instead we
use unique marks that use a custom identifier. This identifier is reused during
rekeying, keeping the marks constant for any rule relying on it (for example
installed by updown).
This also simplifies handling of reqid allocation, as we do not have to query
the marks that is not yet assigned for an unknown reqid.
|
| |
|
| |
|
| |
|
|
|
|
| |
pki tool
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|