We do something similar in reestablish() for break-before-make reauth.
If we don't abort we'd be sending an IKE_AUTH without any TS payloads.
References #2430.
This causes problems e.g. on Android where we handle the alert (and
reestablish the IKE_SA) even though it usually is no problem if the
peer retries with the requested group. We don't consider it as a
failure on the initiator either.
In case we send retransmits for an IKE_SA_INIT where we propose a DH
group the responder will reject we might later receive delayed responses
that either contain INVALID_KE_PAYLOAD notifies with the group we already
use or, if we retransmitted an IKE_SA_INIT with the requested group but
then had to restart again, a KE payload with a group different from the
one we proposed. So far we didn't change the initiator SPI when
restarting the connection, i.e. these delayed responses were processed
and might have caused fatal errors due to a failed DH negotiation or
because of the internal retry counter in the ike-init task. Changing
the initiator SPI avoids that as we won't process the delayed responses
anymore that caused this confusion.
When requiring unique flags for CHILD_SAs, allow the configuration to
request different marks for each direction by using the %unique-dir keyword.
This is useful when different marks are desired for each direction but the
number of peers is not predefined.
An example use case is when implementing a site-to-site route-based VPN
without VTI devices.
A use of 0.0.0.0/0 - 0.0.0.0/0 traffic selectors with identical in/out marks
results in outbound traffic being wrongfully matched against the 'fwd'
policy - for which the underlay 'template' does not match - and dropped.
Using different marks for each direction avoids this issue as the 'fwd' policy
uses the 'in' mark will not match outbound traffic.
Closesstrongswan/strongswan#78.
Initiation might later fail, of course, but we don't really
require an IP address when installing, that is, unless the remote
traffic selector is dynamic. As that would result in installing a
0.0.0.0/0 remote TS which is not ideal when a single IP is expected as
remote.
This splits the SA installation also on the initiator, so we can avoid
installing the outbound SA if we lost a rekey collision, which might
have caused traffic loss depending on the timing of the DELETEs that are
sent in both directions.
This way we get the log message in stroke and swanctl as last message
when establishing a connection. It's already like this for the IKE_SA
where IKE_ESTABLISHED is set after the corresponding log message.
Fixes#2364.
If we find a redundant CHILD_SA (the peer probably rekeyed the SA before
us) we might not want to delete the old SA because the peer might still
use it (same applies to old CHILD_SAs after rekeyings). So only delete
them if configured to do so.
Fixes#2358.
The correct truncation is 128-bit but some implementations insist on
using 96-bit truncation. With strongSwan this can be negotiated using
an algorithm identifier from a private range. But this doesn't work
with third-party implementations. This adds an option to use 96-bit
truncation even if the official identifier is used.
After deleting a rekeyed CHILD_SA we uninstall the outbound SA but don't
destroy the CHILD_SA (and the inbound SA) immediately. We delay it
a few seconds or until the SA expires to allow delayed packets to get
processed. The CHILD_SA remains in state CHILD_DELETING until it finally
gets destroyed.
The responder has all the information needed to install both SAs before
the initiator does. So if the responder immediately installs the outbound
SA it might send packets using the new SA which the initiator is not yet
able to process. This can be avoided by delaying the installation of the
outbound SA until the replaced SA is deleted.
Using install() for the inbound SA and register_outbound() for the
outbound SA followed by install_policies(), will delay the installation of
the outbound SA as well as the installation of the outbound policies
in the kernel until install_outbound() is called later.
Much like in commit a68454b, we now use a global atomic counter to keep
track of the number of IKE_SAs currently registered. This should improve
scalability for a large number of segments even more.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
This provides a solution for configs where there is e.g. a catch-all %any
PSK, while more specific PSKs would be found by the identities of configs
that e.g. use FQDNs as local/remote addresses.
Fixes#2223.
Memory is allocated with calloc, hence set to zero, thus assigning the
numerical value 0 is not required.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Some devices always use the oldest IKE_SA to send DPDs and will delete
all IKE_SAs when there is no response. If uniqueness is not enforced
rekeyed IKE_SAs might not get deleted until they expire so we should
respond to DPDs.
References #2090.
When multihomed, a setup might prefer to dynamically stay on the cheapest
available path by using MOBIKE migrations. If the cheapest path goes away and
comes back, we currently stay on the more expensive path to reduce noise and
prevent potential migration issues. This is usually just fine for links not
generating real cost.
If we have more expensive links in the setup, it can be desirable to always
migrate to the cheapest link available. By setting charon.prefer_best_path,
charon tries to migrate to the path using the highest priority link, allowing
an external application to update routes to indirectly control MOBIKE behavior.
This option has no effect if MOBIKE is unavailable.
Disabling MOBIKE and statically configuring a local address should be
enough indication that the user doesn't want to roam to a different
address. There might not be any routes that indicate we can use the
current address but it might still work (e.g. if the address is on an
interface that is not referenced in any routes and the address itself
is neither). This way we avoid switching to another address for routes
that might be available on the system.
We currently don't make much use of COND_STALE anyway when MOBIKE is not
enabled, e.g. to avoid sending DPDs if the connection is seemingly down.
With MOBIKE enabled we don't exactly check that state but we do don't
send DPDs if there is no route/source address available.
The SA ID (src, dst, proto, spi) is unique on ingress.
As such, explicit inbound marking is not needed to match an SA.
On the other hand, requiring inbound SAs to use marks forces the
installation of a mechanism for marking traffic (e.g. iptables) based
on some criteria.
Defining the criteria becomes complicated, for example when required to
support multiple SAs from the same src, especially when traffic is UDP
encapsulated.
This commit removes the assignment of the child_sa mark_in to the inbound SA.
Policies can be arbitrated by existing means - e.g, via netfilter policy
matching or using VTI interfaces - without the need to classify the flows prior
to state matching.
Since the reqid allocator regards the mark value, there is no risk of matching
the wrong policy.
And as explicit marking was required for route-based VPN to work before this
change, it should not cause regressions in existing setups.
Closesstrongswan/strongswan#59.
If this is the first message by the peer, i.e. we expect MID 0, the
message is not pre-processed in the task manager so we ignore it in the
task.
We also make sure to ignore such messages if the extension is disabled
and the peer already sent us one INFORMATIONAL, e.g. a DPD (we'd otherwise
consider the message with MID 0 as a retransmit).
If the responder never sent a message the expected MID is 0. While
the sent MID (M1) SHOULD be increased beyond the known value, it's
not necessarily the case.
Since M2 - 1 would then equal UINT_MAX setting that MID would get ignored
and while we'd return 0 in the notify we'd actually expect 1 afterwards.
If a responder is natted it will usually be a static NAT (unless it's a
mediated connection) in which case adding these notifies makes not much
sense (if the initiator's NAT mapping had changed the responder wouldn't
be able to reach it anyway). It's also problematic as some clients refuse
to respond to DPDs if they contain such notifies.
Fixes#2126.
If we silently delete the IKE_SA the other peer might still use it even
if only to send DPDs. If we don't answer to DPDs that might result in the
deletion of the new IKE_SA too.
This is the minimum size an IPv6 implementation must support. This makes
it the default for IPv4 too, which presumably is also generally routable
(otherwise, setting this to 0 falls back to the minimum of 576 for IPv4).
They are only required if drop policies would otherwise prevent
forwarding traffic. This reduces the number of policies and avoids
conflicts e.g. with SPD hash thresholds.
Some tasks might get removed immediately once the IKE_SA_INIT response has
been handled even if there were notifies that require a restart of the
IKE_SA (e.g. COOKIE or INVALID_KE_PAYLOAD). Such a task is ike_vendor,
which caused vendor IDs not to get sent in a retry. This change ensures
all required tasks are queued after the reset, which some callers did
already anyway.
These seem to indicate the major and minor version of the protocol, like
e.g. for the DPD vendor ID. Some implementations seem to send versions
other than 1.0 so we just ignore these for now when checking for known
vendor IDs.
Fixes#2088.
By aborting the active task we don't have to wait for potential
retransmits if the other peer does not respond to the current task.
Since IKEv1 has no sequential message IDs and INFORMATIONALs are no real
exchanges this should not be a problem.
Fixes#1537
References #429, #1410Closesstrongswan/strongswan#48
Depending on the lifetimes a CHILD_SA we rekeyed as responder might
expire shortly afterwards. We don't want to rekey it again.
When retrying due to an INVALID_KE_PAYLOAD notify the expected state
is CHILD_REKEYING if it is anything else (e.g. due to a collision) we
ignore it.
We also abort the exchange properly if we don't find the CHILD_SA, no
need for an empty INFORMATIONAL exchange anymore.
If a passive rekeying fails due to an INVALID_KE_PAYLOAD we don't want
to consider this task later when resolving collisions. This previously
might have caused the wrong SA to get deleted/installed based on the nonces
in the unsuccessful exchange.
Such a task is not initiated unless a certain time has passed. This
allows delaying certain tasks but avoids problems if we'd do this
via a scheduled job (e.g. if the IKE_SA is rekeyed in the meantime).
If the IKE_SA is rekeyed the delay of such tasks is reset when the
tasks are adopted i.e. they get executed immediately on the new IKE_SA.
This hasn't been implemented for IKEv1 yet.
If the peer does not detect the rekey collision and deletes the old
IKE_SA and then receives the colliding rekey request it will respond with
TEMPORARY_FAILURE. That notify may arrive before the DELETE does, in
which case we may just conclude the rekeying initiated by the peer.
Also, since the IKE_SA is destroyed in any case when we receive a delete
there is no point in storing the delete task in collide() as process_i()
in the ike-rekey task will never be called.
We conclude the rekeying before deleting the IKE_SA. Waiting for the
potential TEMPORARY_FAILURE notify is no good because if that response
does not reach us the peer will not retransmit it upon our retransmits
of the rekey request if it already deleted the IKE_SA after receiving
our response to the delete.
This makes handling such IKE_SAs more specifically compared to keeping them
in state IKE_CONNECTING or IKE_ESTABLISHED (which we did when we lost a
collision - even triggering the ike_updown event), or using IKE_REKEYING for
them, which would also be ambiguous.
For instance, we can now reject anything but DELETES for such SAs.
Moving to the new SA only after receiving the DELETE for the old SA was
not ideal as it rendered the new SA unusable (because it simply didn't
exist in the manager) if the DELETE was delayed/got dropped.
This happens if the peer deletes the redundant SA before we are able to
handle the response. The deleted SA will be in state CHILD_INSTALLED but
we don't want to trigger the child_updown() event for it or recreate it.
Generally, we will not find the CHILD_SA by searching for it with the
outbound SPI (the initiator of the DELETE sent its inbound SPI) - and if
we found a CHILD_SA it would most likely be the wrong one (one in which
we used the same inbound SPI as the peer used for the one it deletes).
And we don't actually want to destroy the CHILD_SA at this point as we
know we already initiated a DELETE ourselves, which means that task
still has a reference to it and will destroy the CHILD_SA when it
receives the response from the other peer.
If two CHILD_SAs with mark=%unique are created concurrently they could
otherwise end up with either the same mark or different marks in both
directions.
This is the case for the IKE_SA_INIT and the initial IKEv1 messages, which
are pre-generated in tasks as at least parts of it are used to generate
the AUTH payload. The IKE_SA_INIT message will never be fragmented, but
the IKEv1 messages might be, so we can't just call generate_message().
Fixes#1478.
Some peers send an INITIAL_CONTACT notify after they received our XAuth
username. The XAuth task waiting for the third XAuth message handles
this incorrectly and closes the IKE_SA as no configuration payloads are
contained in the message. We queue the INFORMATIONAL until the XAuth
exchange is complete to avoid this issue.
Fixes#1434.
This provides a fix if symmetrically overlapping policies are
installed as e.g. the case in the ikev2/ip-two-pools-db scenario:
carol 10.3.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
alice 10.4.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
Among others, the following FWD policies are installed on moon:
src 10.3.0.1/32 dst 10.4.0.0/16
...
tmpl ...
src 10.4.0.0/16 dst 10.3.0.1/32
...
src 10.4.0.1/32 dst 10.3.0.0/16
...
tmpl ...
src 10.3.0.0/16 dst 10.4.0.1/32
...
Because the network prefixes are the same for all of these they all have the
same priority. Due to that it depends on the install order which policy gets
used. For instance, a packet from 10.3.0.1 to 10.4.0.1 will match the
first as well as the last policy. However, when handling the inbound
packet we have to use the first one as the packet will otherwise be
dropped due to a template mismatch. And we can't install templates with
the "outbound" FWD policies as that would prevent using different
IPsec modes or e.g. IPComp on only one of multiple SAs.
Instead we install the "outbound" FWD policies with a lower priority
than the "inbound" FWD policies so the latter are preferred. But we use
a higher priority than default drop policies would use (in case they'd
be defined with the same subnets).
If there is currently no route to reach the other peer we just default
to left=%any. The local address is only really used to resolve
leftsubnet=%dynamic anyway (and perhaps for MIPv6 proxy transport mode).
Fixes#1375.
An old (already rekeyed) CHILD_SA would get switched back into CHILD_REKEYING
state. And we actually want to change the currently installed CHILD_SA to
that state and later CHILD_REKEYED and properly call e.g. child_rekey() and
not do this again with an old CHILD_SA. Instead let's only check installed
or currently rekeying CHILD_SAs (in case of a rekey collision). It's also
uncommon that there is a CHILD_SA in state CHILD_REKEYED but none in state
CHILD_INSTALLED or CHILD_REKEYING, which could happen if e.g. a peer deleted
and recreated a CHILD_SA after a rekeying. But in that case we don't want
to treat the new CHILD_SA as rekeying (e.g. in regards to events on the bus).
If there is a DROP shunt that matches outbound forwarded traffic it
would get dropped as the FWD policy we install only matches decrypted
inbound traffic. That's because the Linux kernel first checks the FWD
policies before looking up the OUT policy and SA to encrypt the packets.
A thread might check out a new IKE_SA via checkout_new() or
checkout_by_config() and start initiating it while the daemon is
terminating and the IKE_SA manager is flushed by the main thread.
That SA is not tracked yet so the main thread is not waiting for it and
the other thread is able to check it in and creating an entry after flush()
already terminated causing a memory leak.
Fixes#1348.
We do these checks after the SA is fully established.
When establishing an SA the responder is always able to install the
CHILD_SA created with the IKE_SA before the initiator can do so.
During make-before-break reauthentication this could cause traffic sent
by the responder to get dropped if the installation of the SA on the
initiator is delayed e.g. by OCSP/CRL checks.
In particular, if the OCSP/CRL URIs are reachable via IPsec tunnel (e.g.
with rightsubnet=0.0.0.0/0) the initiator is unable to reach them during
make-before-break reauthentication as it wouldn't be able to decrypt the
response that the responder sends using the new CHILD_SA.
By delaying the revocation checks until the make-before-break
reauthentication is completed we avoid the problems described above.
Since this only affects reauthentication, not the original IKE_SA, and the
delay until the checks are performed is usually not that long this
doesn't impose much of a reduction in the overall security.
On failure the SA is deleted and reestablished as configured. The task
is activated after the REAUTH_COMPLETE task so a make-before-break reauth
is completed before the new SA might get torn down.
This allows for different signature schemes for IKE authentication and
trustchain verification.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
An attacker could blindly send a message with invalid nonce data (or none
at all) to DoS an initiator if we just destroy the SA. To prevent this we
ignore the message and wait for the one by the correct responder.
If the SA got redirected this would otherwise cause a reauthentication with
the original gateway. Reestablishing the SA to the original gateway, if e.g.
the new gateway is not reachable makes sense though.
We handle this similar to how we do reestablishing IKE_SAs with all CHILD_SAs,
which also includes the one actively queued during IKE_AUTH.
To delete the old SA we use the recently added ike_reauth_complete task.
To prevent the creation of the CHILD_SA we set a condition on the
IKE_SA. We also schedule a delete job in case the client does not
terminate the IKE_SA (which is a SHOULD in RFC 5685).
According to the mode-config draft there is no prefix sent for
IPv6 addresses in IKEv1. We still accept 17 bytes long addresses for
backwards compatibility with older strongSwan releases.
Fixes#1304.
When charon rekeys a CHILD_SA after a soft limit expired, it is only
deleted after the hard limit is reached. In case of packet/byte limits
this may not be the case for a long time since the packets/bytes are
usually sent using the new SA. This may result in a very large number of
stale CHILD_SAs and kernel states. With enough connections configured this
will ultimately exhaust the memory of the system.
This patch adds a strongswan.conf setting that, if enabled, causes the old
CHILD_SA to be deleted by the initiator after a successful rekeying.
Enabling this setting might create problems with implementations that
continue to use rekeyed SAs (e.g. if the DELETE notify is lost).
If it was necessary to pass the local certificates we could probably
clone the config (but we don't do that either when later looking for the
key to actually authenticate).
Passing auth adds the same subject cert to the config over and over
again (I guess we could also try to prevent that by searching for
duplicates).
If there is no path to the other peer there is no point in trying to
send a NAT keepalive.
If the condition changes back and forth within the keepalive interval there
is a chance that multiple jobs get queued.
This could be helpful when debugging deadlocks that manifest around
wait_for_entry(), as it helps identifying other involved threads (the
thread object is seen in the thread_main() call in each thread's backtrace).
With IKEv1 we have to reuse IKE_SAs as otherwise the responder might
detect the new SA as reauthentication and will "adopt" the CHILD_SAs of
the original IKE_SA, while the initiator will not do so. This could
cause CHILD_SA rekeying to fail later.
Fixes#1236.
When handling a rekey collision we might have to delete an already
installed redundant CHILD_SA (or expect the other peer to do so).
We don't want to trigger updown events for these as neither do we do
so for successfully rekeyed CHILD_SAs.
Fixes#853.
If the retransmit of an initial message is processed concurrently with the
original message it might not have been handled as intended as the
thread processing the retransmit might not have seen the correct value
of entry->processing set by the thread handling the original request.
For IKEv1, i.e. without proper message IDs, there might still be races e.g.
when receiving a retransmit of the initial IKE message while processing the
initiator's second request.
Fixes#1269.
If we mistakenly detect a new IKE_SA as a reauthentication the client
won't request the previous virtual IP, but since we already migrated
it we already triggered the assign_vips() hook, so we should reassign
the migrated virtual IP.
Fixes#1152.
We already did so during Phase 1 but because all three Quick Mode
message have the same message ID we occasionally dropped the third
message as retransmit, so we do it there too. For INFORMATIONAL
and TRANSACTION exchanges we don't expect more than one inbound message
with the same message ID so we still use them there.
Fixes#1198.
Thomas Egerer