If you look at the history of IPsec, two things stand out: There are three versions, each of which made the previous one obsolete. The first dates from 1995, the second from 1998, and the third from 2005. The current state of the architecture dates from December 2005. Some implementation specifications regarding the use of encryption algorithms, on the other hand, are older and have not (yet) been adapted.
Optional Authentication Header since 2005
What distinguishes the current version of IPsec from the previous version is the elimination of the requirement to support the Authentication Header (AH). For the security of network traffic between two points, IPsec supports two security protocols, Authentication Header (AH) and Encapsulating Payload (ESP). AH ensures integrity and data origin of the packet, while ESP encrypts the payload and ensures its integrity and data origin.
In the current version of IPsec, support and use of the Authentication Header is optional. However, without AH, the header remains unprotected. Protection against spoofing and insertion attacks is gone.
Protection of the header
Besides the AH, there are two other technical ways to protect the header efficiently. One is to include the header in the Additional Data of an AEAD cipher like AES-GCM. With an AEAD cipher, additional data can be authenticated in addition to the encrypted payload. Integrity and data origin of the header can thus be ensured easily and efficiently. The other option is to extend the coverage of integrity protection and data origin confirmation to the header. This works, for example. in the combination of AES-CBC with SHA512.
There is only one problem: The IETF RFCs for using AES-GCM and SHA2 exclude such coverage. The historical reason: both RFCs were written and published before the release of the current version of IPsec, when the Authentication Header was still mandatory.
The problem with Authentication Header
AH brings disadvantages in two areas at once: processing and overhead. For what could technically be solved without additional overhead, AH generates an overhead of 28 bytes per packet. In addition, it requires more processing steps because the AH needs its own Security Association (SA) and the security protocol is executed before the encryption and after the decryption of the payload. Due to the inefficiencies, it is quite understandable that most vendors of security products and products with IPsec functionality no longer support the AH. However, this also creates additional attack vectors that can be exploited.
Basic rules of network encryption
In the area of network encryption, the best protection is one that encrypts as much as possible and adds integrity protection and data origin confirmation (authentication) to as many parts of the packet or frame as possible. Only the fields that are allowed to change in transit cannot have integrity protection combined with data origin confirmation.
Network Address Translation (NAT) causes certain address fields to change during transport. There are vendors that allow the range to be protected by authentication to be defined and divided into fields. This allows fields that are allowed to change during transport to be excluded from authentication.
Differences in IP networks
Not every IP network changes a field of the header during transport. For IP networks, it depends on whether it is IPv4 or IPv6, what type of addresses it is, and whether it is static or dynamic connections. Additionally, it depends on whether NAT is used and when encryption is used.
The problem with the mainstream industry
The mainstream industry pretends to be dynamic and progressive. This is marketing. The IETF pretends to be security-oriented and up-to-date. Unfortunately, the IETF - like NIAP, by the way - is vendor-driven. The focus is not on security, but on mainstream industry interests. Therefore, the choice of header fields to be authenticated is not found in IETF RFCs nor in the products of the volume market leaders.
For the industry in general, it seems easier to minimize the development effort and to influence the corresponding standard-setting bodies in their interest. The "interoperability" criterion can be used superficially to keep progress at bay.
IPsec is indispensable
IPsec as an interoperable security architecture for IP networks is indispensable. However, this does not mean that the IPsec architecture and the use of algorithms must be frozen at the 2005 level.
In the case of the Internet Key Exchange (IKE), both the architecture and the range of supported and required algorithms have evolved. In the area of "traffic security", however, the status of December 2005 still applies. The last 14 years have not brought any progress. However, the removal of the requirement to support the Authentication Header was a step backwards in terms of security.
How can this be changed?
It is up to several parties to adapt IPsec to current requirements and possibilities: The vendors, the IETF and the customers. Until customers look at exactly what they are buying and what protection is provided, they are complicit in the current situation. Security expert Bruce Schneier has articulated this extremely well: "The market rewards time-to-market, performance and price. Security and longevity are given scant attention. This is a market failure".
WireGuard as an alternative
WireGuard www.wireguard.com is now an established open source alternative to IPsec, but only where it is supported. It comes standard with the Linux kernel and with Android. In addition, there are implementations for Windows, macOS, iOS and other operating systems. WireGuard is much less complex than IPsec and requires much fewer resources. Unlike IPsec, the cipher suite to be used is not negotiated, but is predetermined. It consists of Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF and is built on the Noise protocol framework. However, it is quite possible to run WireGuard with another ciphersuite like AES-GCM and any elliptic curve: github.com/dnkolegov/nist-wireguard. A version with Russian ciphersuites is also available: github.com/bi-zone/ruwireguard-go.
WireGuard itself is not (yet) a complete solution. For the distribution of the authentication information as well as for the management, additional software is needed - especially for larger installations - which is available as open source only sparsely and with limited functionality. As with IPSec, however, there are commercial vendors that offer a complete solution, both as a cloud-based SaaS and as an on-premise version for enterprise use.
WireGuard has several features that make it superior to IPsec, both security-wise and network-wise.
Other alternatives
For inter-site IP networks, there are solutions that do not use IPsec for encryption and are therefore not interoperable with IPsec. On the other hand, some of them solve the security of IP networks more efficiently and also cover the header during authentication. And in terms of real-time encryption, they are clearly superior to IPsec. Meanwhile, there are solutions that support up to 100Gb/sec full-duplex in real time and any packet size. Some vendors also integrate full DoS/DDoS protection for both the data plane and the control plane. However, IPsec is required for interoperability with IPsec.
This article was originally published in German on September 6 2019 on Inside-IT. This is an updated version.