Linux IPsec Workshop 2018

Collection of possible topics for the Linux IPsec workshop.

Active-active HA solution

strongSwan provides kernel patches for an active-active HA solution that are based on ClusterIP. Since this module does not support IPv6 and is deprecated we are interested in discussing the possible options for a similar but state-of-the-art solution (e.g. based on xt_cluster) and maybe even get it upstream.

UDP Encapsulation of ESP for IPv6

UDP encapsulation of ESP is support for IPv4 but strangely not for IPv6 even though natting IPv6 has been possible for a while. For us it is mainly of interest because our Android app requires UDP encapsulation to work in userland. With the upcoming TCP encapsulation this might be less of a problem, but it's usually preferable to use UDP encap over TCP encap.

Marking Inbound Traffic After Decryption

Similar to the new outbound mark that's applied after encryption (XFRMA_OUTPUT_MARK) we'd like to discuss the possibility of adding a similar feature that applies a mark to inbound packets right after decryption. This would simplify applying a mark to specific tunnels (e.g. for QoS) without having to mark before encryption or based on possibly dynamic values like SPI/reqid.

Different Timeouts for Acquire States and SPIs

Currently, SPIs allocated with XFRM_MSG_ALLOCSPI expire after the same timeout that's also used for the temporary states allocated after sending an acquire to the IKE daemon (/proc/sys/net/core/xfrm_acq_expires). It would be preferable to be able to configure the timeout for allocated SPIs separately. These must be kept alive until a CHILD_SA is completely established, which, with IKE_AUTH exchanges that use EAP methods with lots of exchanges, e.g. EAP-TNC with SWIMA, could take quite a while, in particular, on connections with high packet loss. However, keeping acquire states around that long might not be desired (e.g. in the trap-any scenario, although a PFP feature could help here too). Using the lifetime config on struct xfrm_usersa_info that's part of struct xfrm_userspi_info this could easily be implemented (even optional, so if a daemon does not do that the default timeout applies).

Proper way to Handle Virtual IPv6 Addresses

We currently install virtual IPv6 addresses received from a server on a local interface and install specific source routes with that address and the remote subnets. The address is marked deprecated, the idea being that the kernel will only use this address for the explicit routes but not when doing address selection for other destinations. The question is whether this is the proper way of doing this.

Query Available Algorithms via XFRM

To prepare an automatic ESP proposal it would be necessary to query the algorithms the kernel supports via XFRM (similar to the feature provided by PF_KEY via xfrm_probe_algs(), although, not sure how accurate that actually is).