User:chrisTX/IPSec

Related articles

• strongSwan

This article gives an outline of IPsec. IPsec is commonly described as a virtual private network (VPN), but it is more accurately a protocol suite that can be used to deploy a VPN. The Linux kernel contains support for the encryption and signing of packages of an IPsec protected connection, but the establishment of that connection needs to be done by other software, like strongSwan.

IPsec overview

Since IPsec has been originally standardised in 1998, it has been extended numerous times with expansions and consequently features a vast number of modes and protocols. Describing all of the features is by far beyond the scope of this article. Instead, we will give an overview and then focus on the most commonly used combination. An illustrated, but quite technical introduction to IPsec can be found in the strongSwan documentation.

AH and ESP

At its core, IPsec features two OSI layer 4 protocols to encapsulate traffic: Authentication Headers (AH) and Encapsulating Security Payload (ESP). When IPsec was conceived, encryption was seen as a rather expensive operation, which is why these two variants exist. ESP can be thought of as a protocol that encrypts traffic, while AH only authenticates it, which is to say that the recipient of a packet validates its origin. Since encryption has become the standard nowadays, AH is rarely used outside of specialised deployments. This article will therefore skip AH entirely and focus on discussing ESP.

A technical description of ESP can be found in the strongSwan documentation here. In simple terms, when ESP is used, a packet is encrypted with a negotiated algorithm and authenticated.

Transport and tunnel mode

Both ESP and AH feature two different modes called transport mode and tunnel mode. The difference is that transport mode merely encrypts the contents of a packet but leaves the original IP header intact, whereas in tunnel mode, the IP header is also encapsulated. This is to say, transport mode delivers similar functionality to TLS by just encrypting communications between two hosts. This can be useful for a point-to-point VPN setup between two machines. It used to be common practice to combine L2TP and IPsec in transport mode to create a combination called L2TP/IPsec. Nowadays, this is only used when connecting to legacy setups or if protocols other than IP are to be encapsulated. There is a guide available on how such a combination would be set up under Openswan_L2TP/IPsec_VPN_client_setup.

Security associations

IPsec operates on a set of negotiated encryption setups for ESP, called Wikipedia:IPsec#Security_association security associations (SA). Each packet contains a security parameters index (SPI) that is used to associate the packet with the security association it belongs to. There would be different SAs in each direction, so normally they come in pairs. Security associations are established through a protocol called Wikipedia:Internet_Security_Association_and_Key_Management_Protocol_(ISAKMP). This protocol is only a framework though and several actual protocols operate within this framework to provide the actual exchange. Leaving aside some rarely used protocols, the common, almost universal protocol for this task is Internet Key Exchange (IKE). IKE exists in two versions, IKEv1 and IKEv2. IKEv1 is severely limited in comparison to IKEv2 and only used in legacy setups today.

IKEv1 and IKEv2

In IKEv2, there are different security associations in a connection. Most importantly, IKEv2 creates a security association commonly called IKE_SA. This is used as a sort of encrypted channel to set up various so called CHILD_SAs under. Unlike many other VPN protocols, IPsec offers having multiple connections in a single IPsec session. The entire authentication process is separated in the IKE_SA. Depending on the various options, the IKE_SA can be established with various methods, or even a combination of them. Examples are X.509 certificates or EAP.

Each CHILD_SA is then created in the context of this already authenticated connection of IKE_SA. A CHILD_SA has its own encryption key and encryption algorithms, as well as traffic selectors (TS) that define what is being routed through this connection. Both sides have a local and a remote TS that they offer during connection. This could be understand as the local TS being what access a host offers to the network around them, whereas a remote TS is what network access they would like to request. If the incoming remote TS and the local TS do not match, the TS is being 'narrowed' to the common denominator of both.

IKEv1 works similarly, but the protocol had significant problems. Chiefly, it would be that IKEv2 supports NAT traversal, while IKEv1 does not. Other issues were that the protocol was not designed with mobile users in mind. IKEv2 has an extension called MOBIKE that allows the IP addresses of endpoints to change and supports multihoming. For a mobile device changes of IP addresses, for example by connecting to a WLAN instead of using mobile data, are common. IKEv1 was also poorly specified leaving a lot of room for interpretation. This caused the protocol to be very often extended by proprietary software in a way that was not compatible with other vendors. Some security improvements were also made for IKEv2, and the protocol is secured against certain denial of service (DoS) attacks that are possible with IKEv1.

Most IPsec software still supports IKEv1 but strongly recommends using IKEv2.

Comparison with WireGuard

In order to understand what IPsec better, it is helpful to compare it to the other kernel-based VPN solution in Linux, WireGuard. Both solutions offer a kernel-based VPN, which makes them achieve very high network throughput. WireGuard follows a completely different philosophy than IPsec, though: It wants to be as simple as possible. Features like assigning IP addresses dynamically, different modes of encryption, an equivalent to the transport mode and much more are missing from WireGuard. For that, WireGuard offers simple public keys that can even be converted in a QR code for easy scanning to mobile devices. IPsec on the other hand is effectively bound to X.509 certificates in a modern setup, which can be more complicated to set up.

Security wise, WireGuard uses a combination of X25519 for key exchange, with a pre-shared key (PSK) being used to provide some quantum-resistance and ChaCha20-Poly1305 as encryption. This is a cryptographically very potent solution, and there is no room for misconfiguring anything. IPsec does not have a fixed set of algorithms; everything depends on the specific configuration. Thus, it is possible to create a nearly identical setup of combining X25519 and ChaCha20-Poly1305 or creating a particularly poor one with obsolete ciphers and key exchanges.

In fact, as of 6.0, strongSwan supports multiple key exchanges with RFC:9370 and it is now possible to combine ML-KEM with X25519 to achieve quantum-safe forward safety. The PSK in WireGuard is fixed and does not provide such: If an attacker gains access to a machine, all past communication protected by this PSK can be deciphered. In its whitepaper, section 5.2, they explain their approach as follows:

While pre-sharing symmetric encryption keys is usually troublesome from a key management perspective and might be more likely stolen, the idea is that by the time quantum computing advances to break Curve25519, this pre-shared symmetric key has been long forgotten. And, more importantly, in the shorter term, if the pre-shared symmetric key is compromised, the Curve25519 keys still provide more than sufficient protection. In lieu of using a completely post-quantum crypto system, which as of writing are not practical for use here, this optional hybrid approach of a pre-shared symmetric key to complement the elliptic curve cryptography provides a sound and acceptable trade-off for the extremely paranoid.

This view is not necessarily shared by the cryptography community anymore. Multiple vendors like Fortinet and Palo Alto enabled this ML-KEM combination in their IPsec solutions, and OpenSSH considered it critical to enable a hybrid ML-KEM and X25519 solution as default already.

Another aspect is performance: ChaCha20-Poly1305 is very fast in a software implementation, but ciphers like AES-GCM are much faster when hardware acceleration like AES-NI is available. TLS implements both algorithms for this reason, so that the preferred one for each device can be chosen, and IPsec can similarly offer both. WireGuard is restricted to ChaCha20-Poly1305 and therefore requires more CPU resources than IPsec with AES-GCM would in such a scenario.

Unlike WireGuard, IPsec is a standardised protocol suite with many different implementations. WireGuard is available for practically all platforms from the same team, the same code base. IPsec on the other hand will often have devices talking to each other with their software stacks being made by completely different vendors. This means that implementation differences can complicate things or cause issues. Admittedly, with IKEv2 this problem is less pronounced, but IKEv1 was commonly used together with some non-standard, proprietary extension to the protocol that could make connections challenging. But even today, Windows for example supports much fewer cryptographic algorithms than strongSwan or other vendors do. If Windows clients are supposed to connect to a network, care must be taken, whereas WireGuard will work all the same.

It's worth noting that the implementation by various vendors also means that there's fast kernel-backed implementations available on their respective platforms. On Apple systems like iOS and macOS, there's no kernel module for WireGuard available and so the client there runs in userspace akin to OpenVPN. The same applies for most Android systems, although it is possible to modify the ROM and grant WireGuard superuser rights in order to have a kernel implementation. On stock ROMs, the security model of Android prevents any kernel implementation from being possible. In comparison, IPsec is offered as a kernel implementation on all of these platforms. This means, it is to be expected that IPsec wins out here.

Lastly, ESP is inherently lower level than the WireGuard implementation running atop UDP. IPsec can also encapsulate its ESP packages with UDP - if IKEv2 is being used -, but this is usually only done when a NAT is present. This means IPsec can depending on the network be potentially more efficient on the wire than WireGuard would be. Either way, such effects are absolutely minimal and not really a concern in practice.

Interoperability

IPsec is commonly used to connect to either proprietary implementations by various network equipment vendors or Windows systems. Mobile devices like iOS and Android also work somewhat differently.

Windows

In order to create a modern, secure IPsec configuration for Windows, PowerShell has to be used. Unfortunately, Microsoft has not yet made a UI for this. The cmdlets that are used to create such a configuration are Add-VpnConnection and Set-VpnConnectionIPsecConfiguration. As an example, one could do this:

Add-VpnConnection -Name "vpn.example.org" -ServerAddress "vpn.example.org" -TunnelType "Ikev2" -AuthenticationMethod "MachineCertificate"
Set-VpnConnectionIPsecConfiguration -ConnectionName "vpn.example.org" -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants GCMAES256 -EncryptionMethod GCMAES256 -IntegrityCheckMethod SHA384 -PfsGroup ECP384 -DHGroup ECP384 -PassThru -Force

This would create a VPN connection that's authenticated with machine certificates, and uses AES256-GCM as encryption, SHA-384 as PRF, and ECDH with P-384 as key exchange. Both IKE_SA and CHILD_SA would use the same cryptography here.