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).