If CHILD_SAs are created while waiting for the third QM message we'd not
notice the redundancy and updown events would be triggered unevenly.
This is consistent with the behavior on the initiator, which already does
this check right before installation. Moving the existing check is not
possible due to the narrow hook and moving the installation changes which
peer installs the SAs first and could have other side-effects (e.g. in
error or conflict cases). Still, this might result in CHILD_SA state
discrepancies between the two peers.
Fixes#3060.
If the key type was specified but the ID was NULL or matched a subject, it
was possible that a certificate was returned that didn't actually match
the requested key type.
Closesstrongswan/strongswan#141.
Also expose a method to call arbitrary commands, which allows calling not
yet wrapped commands. Exceptions are raised for all commands if the response
includes a negative "success" key (similar to how it's done in the Python
bindings).
Luckily, the type is only used once when generating payloads and there it
doesn't matter because the encoding rules are the same.
Closesstrongswan/strongswan#135.
Instead of assuming passwords are simply ASCII-encoded we now assume they are
provided UTF-8-encoded, which is quite likely nowadays. The UTF-8 byte
sequences are not validated, however, only valid code points are encoded
as UTF-16LE.
Fixes#3014.
Previously, the initiator would install the SA in transport mode if the
peer sent back the USE_TRANSPORT_MODE notify, even if that was not
requested originally.
The only messages that are generally sent encrypted but could be sent
unencrypted are INFORMATIONALs (currently only used for IKEv1 and ME
connectivity checks). This should prevent issues if the keymat_t behaves
incorrectly and does not return an aead_t when it actually should.
Might be useful for users of other daemons too. Note that compared to the
previous implementation in charon-tkm, the mask/label are applied in
network order.
Closesstrongswan/strongswan#134.
Previously, attributes in an incorrectly sent CFG_REPLY would still be passed
to attribute handlers. This does not prevent handlers from receiving
unrequested attributes if they requested at least one other.
This is mainly to see what's necessary to create them (in case we
integrate this into the daemon) and to experiment in our testing
environment without having to add a patched version of iproute2 (the
4.20.0 version in stretch-backports doesn't support XFRM interfaces
yet). The regular version of iproute2 can be used for other operations
with these interfaces (delete, up, addrs etc.).
The bits not written to are marked tainted by valgrind, don't print
them in the debug messages. Also use more specific printf-specifiers
for other values.
There was a race condition between install() and uninstall()
where one thread was in the process of installing a trap
entry, and had destroyed the child_sa, while the other
thread was uninstalling the same trap entry and ended up
trying to destroy the already destroyed child_sa, resulting
in a segmentation fault in the destroy_entry() function.
The uninstall() function needs to wait until all the threads
are done with the installing before proceeding to uninstall
a trap entry.
Closesstrongswan/strongswan#131.
This can be the case for IKEv1 since 419ae9a20a ("ikev1: Default remote
identity to %any for PSK lookup if not configured").
Closesstrongswan/strongswan#128.
This seems to avoid broadcast loops (i.e. processing and reinjecting the
same broadcast packet over and over again) as the packets we send via
AF_PACKET socket are neither marked nor from that interface.
In order to avoid that the kernel uses virtual tunnel IPs for traffic
over physical interfaces we previously deprecated the virtual IP. While
this is working it is not ideal. This patch adds address labels for
virtual IPs, which should force the kernel to avoid such addresses to
reach any destination unless there is an explicit route that uses it as
source address.
Using parse_time() directly actually overwrites the next member in the
child_cfg_create_t struct, which is start_action, which can cause
incorrect configs if inactivity is parsed after start_action.
Fixes#2954.
A temporary DROP policy is added to avoid traffic leak
while the SA is being updated. It is added with
manual_prio set but when the temporary policy is removed
it is removed with manual_prio parameter set to 0.
The call to del_policies_outbound does not match the original
policy and we end up with an ever increasing refcount.
If we try to manually remove the policy, it is not removed
due to the positive refcount. Then new SA requests fail with
"unable to install policy out for reqid 1618,
the same policy for reqid 1528 exists"
Fixes: 35ef1b032d ("child-sa: Install drop policies while updating IPsec SAs and policies")
Closesstrongswan/strongswan#129.
In 7b7290977 ("controller: Add option to force destruction of an IKE_SA")
the 'force' option was added as 3rd parameter to controller_t::terminate_ike.
However in vici's 'clear_start_action', the argument was incorrectly
placed as the 2nd parameter - constantly sending 0 (FALSE) as the
'unique_id' to terminate, rendering calls to 'handle_start_actions'
having undo=TRUE being unable to terminate the relevant conn.
For example, this is log of such a bogus 'unload-conn':
strongswan[498]: 13[CFG] vici client 96 requests: unload-conn
strongswan[498]: 13[CFG] closing IKE_SA #9
strongswan[498]: 13[IKE] unable to terminate IKE_SA: ID 0 not found
strongswan[498]: 09[CFG] vici client 96 disconnected
here, the unloaded conn's IKE id was 9, alas 'terminate_ike_execute'
reports failure to terminate "ID 0".
Fix by passing 'id, FALSE' arguments in the correct order.
Fixes: 7b7290977 ("controller: Add option to force destruction of an IKE_SA")
Signed-off-by: Shmulik Ladkani <shmulik@metanetworks.com>
Closesstrongswan/strongswan#127.
This is particularly important for higher number of segments, but even
with small numbers there is a significant difference. For instance,
with 4 segments the fourth segment had no IPs assigned with the old
code, no matter how large the pool, because none of the eight bits used
for the segment check hashed/mapped to it.
Upcoming versions of FreeBSD will include an SADB_X_EXT_SA2 extension in
acquires that contains the reqid set on the matching policy. This allows
handling acquires even when no policies are installed (e.g. to work with
FreeBSD's implementation of VTI interfaces, which manage policies
themselves).
In case a subnet is moved from one interface to another the policies can
remain as is but the route has to change. This currently doesn't happen
automatically and there is no option to update the policy or route so
removing and reinstalling the policies is the only option.
Fixes#2820.
The peer might not have seen the CREATE_CHILD_SA response yet, receiving a
DELETE for the SA could then trigger it to abort the rekeying, causing
the deletion of the newly established SA (it can't know whether the
DELETE was sent due to an expire or because the user manually deleted
it). We just treat this SA as if we received a DELETE for it. This is
not an ideal situation anyway, as it causes some traffic to get dropped,
so it should usually be avoided by setting appropriate soft and hard limits.
References #2815.
If a lot of QUICK_MODE tasks are queued and the other side
sends a DPD request, there is a good chance for timeouts.
Observed this in cases where other side is quite slow in responding
QUICK_MODE requests (e.g. Cisco ASA v8.x) and about 100 CHILD_SAs
are to be spawned.
Closesstrongswan/strongswan#115.
The task manager for IKEv1 issues a retransmit send alert in the
retransmit_packet() function. The corresponding retransmit cleared alert
however is only issued for exchanges we initiated after processing the
response in process_response().
For quick mode exchanges we may retransmit the second packet if the peer
(the initiator) does not send the third message in a timely manner. In
this case the retransmit send alert may never be cleared.
With this patch the retransmit cleared alert is issued for packets that
were retransmitted also when we are the responding party when we receive
the outstanding response.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
For inbound processing, it can be rather useful to apply the mark to the
packet in the SA, so the associated policy with that mark implicitly matches.
When using %unique as match mark, we don't know the mark beforehand, so
we most likely want to set the mark we match against.
%unique (and the upcoming %same key) are usable in specific contexts only.
To restrict the user from using it in other places where it does not get the
expected results, reject such keywords unless explicitly allowed.
We don't retransmit DPD requests like we do requests for proper exchanges,
so increasing the number with each sent DPD could result in the peer's state
getting out of sync if DPDs are lost. Because according to RFC 3706, DPDs
with an unexpected sequence number SHOULD be rejected (it does mention the
possibility of maintaining a window of acceptable numbers, but we currently
don't implement that). We partially ignore such messages (i.e. we don't
update the expected sequence number and the inbound message stats, so we
might send a DPD when none is required). However, we always send a response,
so a peer won't really notice this (it also ensures a reply for "retransmits"
caused by this change, i.e. multiple DPDs with the same number - hopefully,
other implementations behave similarly when receiving such messages).
Fixes#2714.
This is mainly for HA where a passive SA was already created when the
IKE keys were derived. If e.g. an authentication error occurs later that
SA wouldn't get cleaned up.
The reload of the configuration of the loggers so far only included
the log levels. In order to support the reload of all other options,
a reload function may be implemented.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
The options control whether the DF and ECN header bits/fields are copied
from the unencrypted packets to the encrypted packets in tunnel mode (DF only
for IPv4), and for ECN whether the same is done for inbound packets.
Note: This implementation only works with Linux/Netlink/XFRM.
Based on a patch by Markus Sattler.
During a test with ~12000 established SAs it was noted that vici
related operations hung.
The operations took over 16 minutes to finish. The time was spent in
the vici message parser, which was assigning the message over and over
again, to get rid of the already parsed portions.
First fixed by cutting the consumed parts off without copying the message.
Runtime for ~12000 SAs is now around 20 seconds.
Further optimization brought the runtime down to roughly 1-2 seconds
by using an fd to read through the message variable.
Closesstrongswan/strongswan#103.
The code to support parallel Netlink queries (commit 3c7193f) made use
of nlmsg_len member from struct nlmsghdr to allocate and copy the
responses. Since NLMSG_NEXT is later used to parse these responses, they
must be aligned, or the results are undefined.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
macOS supports AES_GCM_ICV16 natively using PF_KEYv2.
This change enables AES_GCM if the corresponding definition is detected
in the headers.
With this change it is no longer necessary to use the libipsec module to
use AES_GCM on macOS.
Closesstrongswan/strongswan#107.
Removing and readding the entry to a potentially different row/segment,
while driving out waiting and new threads, could prevent threads from
acquiring the SA even if they were waiting to check it out by unique
ID (which doesn't change), or if they were just trying to enumerate it.
With this change the row and segment doesn't change anymore and waiting
threads may acquire the SA. However, those looking for an IKE_SA by SPIs
might get one back that has a different SPI (but that's probably not
something that happens very often this early).
This was noticed because we check out SAs by unique ID in the Android
app to terminate them after failed retransmits if we are not reestablishing
the SA (otherwise we continue), and this sometimes failed.
Fixes: eaedcf8c00 ("ike-sa-manager: Add method to change the initiator SPI of an IKE_SA")
Instead of logging the search parameters for IKE configs (which were already
before starting the lookup) we log the configured settings.
The peer config lookup is also changed slightly by doing the IKE config
match first and skipping some checks if that or the local peer identity
doesn't match.
Although being already logged on level 2, these messages are usually just
confusing if they pop up randomly in the log when e.g. querying the configs
or installing traps. So after this the log messages will only be logged when
actually proposing or selecting traffic selectors during IKE.
This way we don't rely on the order of equally matching configs as
heavily anymore (which is actually tricky in vici) and this also doesn't
require repeating weak algorithms in all configs that might potentially be
selected if there are some clients that require them.
There is currently no ordering, so an explicitly configured exactly matching
proposal isn't a better match than e.g. the default proposal that also
contains the proposed algorithms.
In some scenarios we might find multiple usable peer configs with different
IKE proposals. This is a problem if we use a config with non-matching
proposals that later causes IKE rekeying to fail. It might even be a problem
already when creating the CHILD_SA if the proposals of IKE and CHILD_SA
are consistent.
This allows switching to probing mode if the client is on a public IP
and this is the active task and connectivity gets restored. We only add
NAT-D payloads if we are currently behind a NAT (to detect changed NAT
mappings), a MOBIKE update that might follow will add them in case we
move behind a NAT.
In case the PRF's set_key() or allocate_bytes() method failed, skeyseed
was not initialized and the chunk_clear() call later caused a crash.
This could have happened with OpenSSL in FIPS mode when MD5 was
negotiated (and test vectors were not checked, in which case the PRF
couldn't be instantiated as the test vectors would have failed).
MD5 is not included in the default proposal anymore since 5.6.1, so
with recent versions this could only happen with configs that are not
valid in FIPS mode anyway.
Fixes: CVE-2018-10811
We now check if there are other routes tracked for the same destination
and replace the installed route instead of just removing it. Same during
installation, where we previously didn't replace existing routes due to
NLM_F_EXCL. Routes with virtual IPs as source address are preferred over
routes without.
This should allow using trap policies with virtual IPs on Linux.
Fixes#85, #2162.
The client identifier serves as unique identifier just like a unique MAC
address would, so even with identity_leases disabled some DHCP servers
might assign unique leases per identity.
This increases the chances that subject DNs that might have been cut
off with the arbitrary previous limit of 64 bytes might now be sent
successfully.
The REQUEST message has the most static overhead in terms of other
options (17 bytes) as compared to DISCOVER (5) and RELEASE (7).
Added to that are 3 bytes for the DHCP message type, which means we have
288 bytes left for the two options based on the client identity (host
name and client identification). Since both contain the same value, a
FQDN identity, which causes a host name option to get added, may be
142 bytes long, other identities like subject DNs may be 255 bytes
long (the maximum for a DHCP option).
According to RFC 2131, the minimum size of the 'options' field is 312
bytes, including the 4 byte magic cookie. There also does not seem to
be any restriction regarding the message length, previously the length
was rounded to a multiple of 64 bytes. The latter might have been
because in BOOTP the options field (or rather vendor-specific area as it
was called back then) had a fixed length of 64 bytes (so max(optlen+4, 64)
might actually have been what was intended), but for DHCP the field is
explicitly variable length, so I don't think it's necessary to pad it.
Since we won't read from the socket reducing the receive buffer saves
some memory and it should also minimize the impact on other processes that
bind the same port (Linux distributes packets to the sockets round-robin).
DHCP servers will respond to port 67 if giaddr is non-zero, which we set
if we are not broadcasting. While such messages are received fine via
RAW socket the kernel will respond with an ICMP port unreachable if no
socket is bound to that port. Instead of opening a dummy socket on port
67 just to avoid the ICMPs we can also just operate with a single
socket, bind it to port 67 and send our requests from that port.
Since SO_REUSEADDR behaves on Linux like SO_REUSEPORT does on other
systems we can bind that port even if a DHCP server is running on the
same host as the daemon (this might have to be adapted to make this work
on other systems, but due to the raw socket the plugin is not that portable
anyway).
The previous code compared the port in the packet to the client port and, if
successful, checked it also against the server port, which, therefore, never
matched, but due to incorrect offsets did skip the BPF_JA. If the client port
didn't match the code also skipped to the instruction after the BPF_JA.
However, the latter was incorrect also and processing would have continued at
the next instruction anyway. Basically, DHCP packets to any port were accepted.
What's not fixed with this is that the kernel returns an ICMP Port
unreachable for packets sent to the server port (67) because we don't
have a socket bound to it.
Fixes: f0212e8837 ("Accept DHCP replies on bootps port, as we act as a relay agent if server address configured")
We don't have MOBIKE and the fallback to reauthentication does also not
make much sense as that doesn't affect the CHILD_SAs for IKEv1. So
instead of complicating the code we just ignore roam events for IKEv1
for now.
Closesstrongswan/strongswan#100.
Tobias Brunner