To quickly check out IKE_SAs and find associated CHILD_SAs, the
child_sa_manager stores relations between CHILD_SAs and IKE_SAs. It provides
CHILD_SA specific IKE_SA checkout functions wrapping the ike_sa_manager.
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.
The kernel backend uses an inbound parameter these days, where it makes
no sense to pass the update flag. The kernel backend decides itself how
it handles SA installation based on the inbound flag.
While we can handle the first selector only in BEET mode in kernel-netlink,
passing the full list gives the backend more flexibility how to handle this
information.
The reqid is not strictly required, as we set the reqid with the update
call when installing the negotiated SA.
If we don't need a reqid at this stage, we can later allocate the reqid in
the kernel backend once the SA parameters have been fully negotaited. This
allows us to assign the same reqid for the same selectors to avoid conflicts
on backends this is necessary.
When rekey_child_sa is called while enumerating the children of an IKE_SA, and
the child to be rekeyed is redundant a QUICK_DELETE task is queued instead of a
QUICK_MODE task. This alters the IKE_SA's list of children (ike_sa_t::child_sas)
invalidating the current element of the child_sa_enumerator. The enumerate
function of linked_list_t will then advance to an element with unpredictable
contents most likely resulting in an segmentation violation. A similar behavior
should be observed when delete_child_sa is called.
This patch creates a list of protocol/spi values while holding the
child_sa_enumerator and performs the rekeying (deletion of redundant) chlidren
after releasing the enumerator.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
While they usually are not included in a normal strongSwan build, the XPC
header indirectly defines these Mach types. To build charon-xpc, which uses
both XPC and strongSwan includes, we have to redefine these types.
Since 42e0a317c6 ("ike: Only parse payloads valid for the current IKE
version") payload types are checked before creating objects. This check
failed for internally used payload types (e.g. proposal substructures),
which have a type >= 256, i.e. outside the IKE payload type range.
The transform identifier used in AH transforms is not the same as the
authentication algorithm identifier used in the transform attributes in
AH (and ESP) transforms.
iOS and Mac OS X clients establish individual IPsec SAs for the traffic
selectors received in Split-Include attributes (might have been different
in earlier releases). If we return 0.0.0.0/0 as TSr that either results
in a bunch of Quick Mode exchanges (for each TS), or with the latest
client releases an error notify (ATTRIBUTES_NOT_SUPPORTED).
We also can't install the IPsec SA with all configured subnets as that
would cause conflicts if the client later negotiates SAs for other subnets,
which iOS 8 does based on traffic to such subnets.
For Shrew and the Cisco client, which propose 0.0.0.0/0, we still need to
override the narrowed TS with 0.0.0.0/0, as they otherwise won't accept
the Quick Mode response. Likewise, we also have to narrow the TS before
installing the IPsec SAs and policies.
So we basically have to follow the client's proposal and only modify TSr
if we received 0.0.0.0/0. Since we don't get the original TS in the
narrow hook we handle the inbound QM messages and make note of IKE_SAs on
which we received a TSr of 0.0.0.0/0.
Fixes#737.
Similar to the inbound rules, the ALE filter processes IP-in-IP packets for
outbound tunnel mode traffic. When using an outbound default-drop policy,
Windows does not allow connection initiation without these explicit rules.
When processing inbound tunnel mode packets, Windows decrypts packets and
filters them as IP-in-IP packets. We therefore require an ALE filter that
calls the FWPM_CALLOUT_IPSEC_INBOUND_TUNNEL_ALE_ACCEPT callout to allow them
when using a default-drop policy.
Without these rules, any outbound packet created an ALE state that allows
inbound packets as well. Processing inbound packets without any outbound
traffic fails without these rules.
As the underlying C functions, send/recv on ruby sockets are not guaranteed
to send/recv all requested bytes. Use wrapper functions to make sure we get
all bytes needed.
If multiple sockets are ready, we previously preferred the IPv4 non-NAT socket
over others. To handle all with equal priority, use a round-robin selection.
We currently send the notify in Main Mode only, as it is explicitly not allowed
by RFC 2407 to send (unprotected) notifications in Aggressive Mode. To make
that work, we'd need to handle that notify in Aggressive Mode, which could
allow a MitM to inject such notifies and do some harm.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Otherwise fragmented CREATE_CHILD_SA exchanges won't get accepted
because they don't contain an SA payload.
It also prevents a warning when ordering payloads.
Fixes#752.
When invoking /bin/sh, its default PATH is used. On some systems, that does
not include the PATH where the ipsec script is installed, as charon is invoked
with a custom PATH. Explicitly setting the PATH of charon should fix this
case, properly invoking the (default) updown script.
Fixes#745.
We assume that a responder is behind a static NAT (e.g. port forwarding)
and allow remote address updates in such situations.
The problem described in RFC 5996 is only an issue if the NAT mapping
can expire.
As we want to avoid the libstrongswan include dependencies for libvici, avoid
the use of the bool type. Unfortunately this change may break the ABI for
vici_dump(). As this function is mostly for debugging purposes, we do it
nonetheless; my apologies if somebody already relies on the ABI stability of
that function.
I still think ipsec/l2tp with fragmentation support is a useful
fallback option in case the Windows IKEv2 connection fails because
of fragmentation problems.
Tested with Windows XP, 7 and 8.1.
Any interval returned by the RADIUS server in the Access-Accept message
overrides the configured interval. But it might be useful if RADIUS is
only used for accounting.
The maximum for IKEv1 is already 255 due to the 8-bit fragment number.
With an overhead of 17 bytes (x64) per fragment and a default maximum
of 10000 bytes per packet the maximum memory required is 14 kB
for a fragmented message.
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.
The message() hook on bus_t is now called exactly once before (plain) and
once after fragmenting (!plain), not twice for the complete message and again
for each individual fragment, as was the case in earlier iterations.
For inbound messages the hook is called once for each fragment (!plain)
and twice for the reassembled message.
At the time we reset an IKE_SA (e.g. when re-authenticating a not yet
established SA due to a roaming event) such tasks might already be queued
by one of the phase 1 tasks. If the SA is initiated again another task will
get queued by the phase 1 task. This results in e.g. multiple mode config
requests, which most gateways will have problems with.
This reverts commit 3293d14628.
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().
We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange. By storing the last message block as IV
we can't decrypt the first block of such a response.
Fixes#661.
While the examples in RFC 2408 show proposal numbers starting at 1 and
increasing by one for each subsequent proposal this is not mandatory.
Actually, IKEv1 proposals may start at any number, the only requirement
is that the proposal numbers increase monotonically they don't have to
do so consecutively.
Most implementations follow the examples and start numbering at 1 (charon,
racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the
implementations that started with 0 and there might be others out there.
The previous assumption that implementations always start numbering proposals
at 0 caused problems with clients that start numbering with 1 and whose first
proposal consists of multiple protocols (e.g. ESP+IPComp).
Fixes#661.
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.
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.
Due to how reauthentication works for IKEv1 we could get a second
IKE_SA, which might cause problems, when connectivity problems arise
when the connection is initially established.
Fixes#670.
The adopt_children_job_create() function is not available when IKEv1 support
is disabled. Fixes uncommon builds using --enable-ha --disable-ikev1.
Fixes#690.
When having the unity plugin enabled and both peers send the Unity Vendor ID,
we proposed 0.0.0.0/0 as traffic selector, even if no Split-Include has been
received on the SA. This can break compatibility with some responders, as
they don't narrow the TS themselves, but expect the configured TS.
When an initiator starts reauthentication on a connection that uses push
mode to assign a virtual IP, we can't execute the Mode Config before releasing
the virtual IP. Otherwise we would request a new and different lease, which
the client probably can't handle. Defer Mode Config execution, so the same IP
gets first released then reassigned during reauthentication.
If a peer immediately sends DELETE messages when completing Quick Mode rekeying,
the third Quick Mode message and the DELETE are sent simultaneously. This
implies that DELETE messages may arrive before the completing third Quick Mode
message.
Handle this case by ignoring the DELETE INFORMATIONAL in Quick Mode and let
the delete task handle it.
To check if a received IKE_SA_INIT request is a new request or a
retransmit, charon maintains hashes of the pending IKE_SA_INIT
exchanges.
However, the hash calculation is not reentrant because a single hasher
is used for the whole IKE SA manager. It leads to bogus calculations
under high load and hence dropped messages on responder
(IkeInInvalidSpi incremented).
Don't share a single hasher in the IKE SA manager, create a transient
one whenever a message must be hashed.
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
We sent both a notify using IKEv1 and IKEv2. This is a little more aggressive
than required, RFC 5996 says we "SHOULD send an unauthenticated Notify
message of type INVALID_MAJOR_VERSION containing the highest (closest) version
number it supports".
Fixes#657.
As we later potentially use args again, we can't consume it with printf
functions without copying it first. Clone list before passing it to any
consuming function.
Fixes#621.
While the outbound SA actually does not need a replay window, the kernel rejects
zero replay windows on SAs using ESN. The ESN flag is required to use the full
sequence number in ICV calculation, hence we set the replay window.
This restores the behavior we had before 30c009c2.
The use of overlapped I/O was incorrect, as we passed stack based buffers, but
did not cancel/wait for pending completion on all sockets. Our receive-from-all
socket interface is actually tricky to implement using overlapped I/O. Switch
to WSAEventSelect() event management, which can be canceled properly while
working in a select()-like way.
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.
This will be useful if the kernel backend has to know how many policies
follow an SA install, for example if it must install all policies concurrently.
Having this flag set fixes connections initiated by the Windows host, but
unfortunately does not yet fix incoming connections. Connection state issue?
We still see 0xc00000e2 error events, translating to INTERNAL_ERROR.
This gives us more flexibility than using the intransparent FwpmIPsecTunnelAdd,
and fixes the issues we have seen with trap policies. Forward filters are
still missing, but required for site-to-site tunnels.
While MinGW declares all the required symbols, some of them are missing in the
library files. We provide missing variables locally, functions get a stub
that call the GetProcAddress()ed function from the DLL.
Also some MinGW headers define some enum values incorrectly, we overload these
using defines.
This currently has no effect: We don't include AEAD algorithms in the default
ESP proposal, as we don't know if it is supported by the backend. But as we
hopefully get an algorithm query mechanism on kernel interfaces some day, we
add the appropriate functionality nonetheless.
According to RFC 5996 3.3 we should use a separate proposal for AEAD algorithms.
This was not clear in RFC 5282, hence we previously included both AEAD and
non-AEAD algorithms in a single proposal.
Handling the result for enum_from_name() is difficult, as checking for
negative return values requires a cast if the enum type is unsigned. The new
signature clearly differentiates lookup result from lookup value.
Further, this actually allows to convert real -1 enum values, which could not
be distinguished from "not-found" and the -1 return value.
This also fixes several clang warnings where enums are unsigned.
If do_read() returns with EWOULDBLOCK, we must ensure that we actually have
processed the full length header before checking the zero-initialized buffer
length.
Martin Willi