This fixes cases where `start_action = trap|start` is used and an acquire
is triggered while the SA is initiated (granted if narrowing is expected,
that's not a recommended configuration as the responder can only use
the first config when there is no packet TS). The resulting second
create-child task will potentially get dropped by the duplicate check,
so the temporary state won't get removed and traffic is blocked until
that expires, neither can acquires get triggered for traffic that doesn't
match the initial SA's policies.
This was the case before bce0c5fd74 ("child-create: Update CHILD_SA IP
addresses before installation") and allows listeners to consider the
traffic selectors of the SA that's about to get installed.
With the sequence numbers we don't have to maintain the reqid to delete
the temporary state.
One exception is with labels. There we currently only install trap
policies with the generic label. SAs created from those don't have
policies installed, so we have to reuse the reqid of the trap even if
narrowing occurs.
And as before, we reuse the reqid without checking traffic selectors if
sequence numbers are not supported.
Note that if a CHILD_SA is manually initiated (i.e. has no sequence
number assigned) right before an acquire is triggered, there are several
possible outcomes depending on whether narrowing occurs. If there is no
narrowing, the same reqid is assigned and the kernel will remove the
temporary SA when the SA is installed (no seq => reqid match).
Afterwards, the queued duplicate CHILD_SA is destroyed and the acquire
state in the trap manager gets removed. If there is narrowing, a new
reqid is allocated, so the installation of the SA will not remove the
temporary state. However, due to the narrowing, the duplicate check
fails and when the duplicate is installed (with sequence number), the
temporary state is deleted (as is the state in the trap manager).
Optionally with "dynamic" traffic selectors resolved. A new method
is added for those cases where we actually want to select potentially
narrowed traffic selectors using a supplied list. The latter now also
always logs details, while the former does not.
Either use the sequence number from the kernel (and potentially update
it if the acquire was retriggered), or generate our own sequence
numbers, which simplifies matching acquires to established/destroyed
CHILD_SAs.
This changes how EAP identities are used from the config. Instead of
setting a statically configured identity != %any, an EAP-Identity
exchange is now always initiated (and required). If the received identity
doesn't match, the peer config is switched to one with a matching
identity (wildcards are supported for that match). This allows switching
to a config with a different EAP method or child settings based on the
EAP identity.
There is currently no "best" match. The configs are evaluated based on
the order returned from the initial peer config lookup.
References strongswan/strongswan#2702
This was originally added with b0e40caafb ("NAT-T conditions were not
inherited during IKE_SA rekeying") in 2008 when there was only a single
inherit() method. Later the inherit_pre() method was added and then
with 094963d1b1 ("ikev2: Apply extensions and conditions before
starting rekeying") in 2014 the extensions and conditions were set
already there.
This avoids conflicts with upstream changes if patched versions of
strongSwan require a number of private extensions and conditions. For
example, the following extensions can be used as usual via the
`enable|supports_extension()` methods:
#define PRIVATE_EXT_1 (EXT_PRIVATE_MARKER | (1<<0))
#define PRIVATE_EXT_2 (EXT_PRIVATE_MARKER | (1<<1))
Defining an enum would also be possible but because the type won't match
the values would have to be cast to `ike_extension_t` when using the
methods.
Similarly, `COND_PRIVATE_MARKER` may be used to define private conditions
that can be used with the `set|has_condition()` methods.
Because the MSB is explicitly not set in `private_extensions|conditions`,
these members may directly be checked against private values, e.g.:
if (this->private_extensions & PRIVATE_EXT_1)
{
}
Listeners can't track those IKE_SAs otherwise. For break-before-make
reauthentications, these events are already triggered because that is
implemented by calling reestablish() on the old IKE_SA.
When using port 4500 for IKE_SA_INIT, Windows Server 2016, 2025 and
possibly others send back all packets to the port initially used by the
client, not the one floated to before sending IKE_AUTH. So if UDP
encapsulation is used, no traffic can be received as the initial socket
can't have UDP decapsulation enabled.
tcpdump output:
```
IP <client-ip>.47547 > <server-ip>.4500: UDP-encap: ESP(spi=0xfd4e5fc2,seq=...)
IP <server-ip>.4500 > <client-ip>.57962: UDP-encap: ESP(spi=0xccc5e213,seq=...)
```
Avoid this by floating early if a non-default destination port is used.
This also ensures we don't send packets from port 500 (without non-ESP
marker) if ephemeral source ports are not used.
Closesstrongswan/strongswan#2664
Signed-off-by: Michael Braun <[email protected]>
Co-authored-by: Tobias Brunner <[email protected]>
Without UDP-encapsulation, the IKE and ESP traffic is not directly related
(other than via IPs), so firewalls might no keep the state for IKE traffic
alive if there is no IKE traffic for a while and constant ESP traffic
prevents DPDs from being exchanged because inbound ESP traffic is
considered.
Closesstrongswan/strongswan#1759
Synchronization for the additional transforms in the IKE and Child SA
proposals is added. Details of the IKE_SA synchronization are changed
to support IKE_INTERMEDIATE exchanges that cause multiple HA_IKE_ADD
messages and key derivations. The cache has been extended to handle
multiple such messages.
Co-authored-by: Thomas Egerer <[email protected]>
When serving as a responder and receiving an INFORMATIONAL exchange
containing INVALID_SYNTAX after IKE_AUTH, the IKE_SA should be deleted.
Currently, it only gets deleted after receiving AUTHENTICATION_FAILED.
RFC7296 section 2.21.2 says:
In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened when processing a response to
IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a Delete payload.
Closesstrongswan/strongswan#2636
If a migrate of a child-create occurs then labels_i and labels_r are
freed, but the pointers are left set. If the task is subsequently
destroyed without being reused, then both of these will be double
freed.
Fix this by setting labels_i and labels_r to NULL in the migrate
method after freeing, similar to other fields that are freed.
Closesstrongswan/strongswan#2552
Fixes: f9b895b49f ("child-create: Add support to handle security labels")
Both variables `inbound_installed` and `outbound_state` are used in
`child_sa_t::destroy()` to determine whether inbound and outbound state
have to be deleted. They are assigned prior to the call to
`kernel_interface_t::add_sa()`. As this call may fail, the destructor may
try to delete a state which it has not been added.
By making the assignment of these variables dependent on the success of
the state addition, we can make sure, a `child_sa_t::destroy()` only
deletes states it has added.
Also removed the redundant checks for `my_spi` and `other_spi` being set
along with the check for the above flags. It seems that when the flags
are set, the SPIs *must* be set.
Signed-off-by: Thomas Egerer <[email protected]>
As the winner of a rekey collision, we previously always triggered the
child_rekey() event once when creating the redundant SA on behalf of the
peer in the passive child-rekey task and then a second time when
creating the winning SA in the active task. However, both calls passed
the replaced CHILD_SA as "old". This made tracking CHILD_SAs impossible
because there was no transition from the redundant, "new" SA of the
first event to the "new", winning SA of the second. Of course, when the
second event was triggered, the redundant SA might not have existed
anymore because the peer is expected to delete it, which could happen
before the CREATE_CHILD_SA response arrives at the initiator.
This refactoring ensures that the child_rekey() event is triggered in
a way that makes the CHILD_SAs trackable in all reasonable (and even
some unreasonable) scenarios. The event is generally only triggered
once after installing the outbound SA for the new/winning CHILD_SA.
This can be when processing the CREATE_CHILD_SA in the active child-rekey
task, or when processing the DELETE for the old SA in a passive
child-delete task. There are some cases where the event is still
triggered twice, but it is now ensured that listeners can properly
transition to the winning SA.
Some corner cases are now also handled correctly, e.g. if a responder's
DELETE for the new CHILD_SA arrives before its CREATE_CHILD_SA response
that actually creates it on the initiator. Also handled properly are
responders of rekeyings that incorrectly send a DELETE for the old
CHILD_SA (previously this caused both, the new and the old SA, to get
deleted).
It also changes that payloads are built before installing the CHILD_SA
on the responder, that is, the KE payload is generated before keys are
derived, so that key_exchange_t::get_public_key() is called before
get_shared_secret(), or its internal equivalent, which could be relevant
for KE implementations that want to ensure that the key can't be
accessed again after the key derivation.
Initially, this is handled with a key derivation for each
IKE_INTERMEDIATE exchange. When rekeying, the keys are derived only
once all IKE_FOLLOWUP_KE exchanges are done.
The message ID of the first IKE_AUTH exchange is a safe-guard against
potential truncation attacks if IKE_INTERMEDIATE exchanges are not used
for multiple key exchanges but some other future use where the number of
exchanges might not depend on the selected proposal.
We currently only support these exchanges for additional key exchanges,
so once we have the final keys derived and the ike-init task is removed,
we don't expect any more of them.
The IKE_SA might be busy with a different task while a request to
terminate it is getting queued, we don't want to use such an IKE_SA to
initiate new CHILD_SAs as these tasks will get lost once the IKE_SA is
terminated.
Tobias Brunner