While 3c12905103 ("ipsec: Add function to compare two ipsec_sa_cfg_t
instances") added a comparison function to avoid issues with non-zeroed
padding, hashes were still calculated using chunk_hash().
The addresses are actually the endpoints of the SA, not information on
the matched packet (except that the RFC says to set the ports and
protocol of the packet in the source address, which the Linux kernel
doesn't do). So these are useless, unless transport mode is used, where
the addresses are needed for the wildcard trap policy use case.
The RFC mentions a PROXY address (a single one, not two), that could
apparently be something like the source address in tunnel mode.
However, the description of how this is used in the RFC is quite weird
and neither Linux nor FreeBSD send such an attribute in SADB_ACQUIRE.
Currently supported by libipsec and PF_KEY on macOS (FreeBSD, like Linux,
reports the time the SA was first used in sadb_lifetime_usetime - it also
triggers rekeyings based on that, which Linux doesn't, it also triggers
them if an SA is never used).
Such routes with a gateway that equals the peer's address are problematic
on FreeBSD. And since there is most likely a narrow route for the local
subnet anyway, the exclude routes would be redundant.
When installing routes based on remote traffic selectors, it can be
necessary to install an exclude route for the remote peer to avoid a
routing loop and continue to be able to reach it via IKE/ESP.
However, such routes are only necessary, if the routes we install don't
go via outbound interface. That's the case when using VIPs and routing
via TUN devices, or when using internal source IPs and routing via
their interfaces.
Installing such exclude routes if not necessary can cause issues on
FreeBSD (EINVAL when sending packets to the peer).
Enables us to ignore any future kernel features for routes unless
we actually need to consider them for the source IP routes.
Also enables us to actually really skip IPsec processing for those networks
(because even the routes don't touch those packets). It's more what
users expect.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Don't define structs for macOS as we don't need them (that's true for
most of the others too, though) and at least one is defined inside an extra
ifdef.
Many of the messages sent by the kernel, including confirmations to our
requests, are sent as broadcasts to all PF_KEY sockets. So if an
external tool is used to manage SAs/policies (e.g. unrelated to IPsec)
the receive buffer might be filled, resulting in errors like these:
error sending to PF_KEY socket: No buffer space available
To avoid this, just clear the buffer before sending any message.
Fixes#3225.
This patch adds passing the ESN flag to the kernel if ESN was negotiated
and the appropriate flag is present in the kernel headers, which will
be the case in future FreeBSD releases.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Closesstrongswan/strongswan#155.
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).
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.
Upcoming FreeBSD kernels will support updating the addresses of existing
SAs with new SADB_X_EXT_NEW_ADDRESS_SRC|DST extensions for the SADB_UPDATE
message.
Tobias Brunner