This is currently not an issue for CHILD_SA rekeying tests as these only
check rekeyings of the CHILD_SA created with the IKE_SA, i.e. there is
no previous DH group to reuse.
For the CHILD_SA created with the IKE_SA the group won't be set in the
proposal, so we will use the first one configure just as if the SA was
created new with a CREATE_CHILD_SA exchange. I guess we could
theoretically try to use the DH group negotiated for IKE but then this
would get a lot more complicated as we'd have to check if that group is
actually contained in any of the CHILD_SA's configured proposals.
This way we get proper error handling if the DH group the peer requested
is not actually supported for some reason (otherwise we'd just retry to
initiate with the configured group and get back another notify).
IKE_SAs newly created via HA_IKE_ADD message don't have any IKE or peer
config assigned yet (this happens later with an HA_IKE_UPDATE message).
And because the state is initially set to IKE_CONNECTING the roam() method
does not immediately return, as it later would for passive HA SAs. This
might cause the check for explicitly configured local addresses to crash
the daemon with a segmentation fault.
Fixes#2500.
Otherwise, the remote identity is ignored when matching owner identities
of PSKs and this way matching PSKs that explicitly have %any assigned is
improved.
Fixes#2497.
This allows us to use it without having to initialize libcharon, which
was required for the logging (we probably could have included debug.h
instead of daemon.h to workaround that but this seems more correct).
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.
Tobias Brunner