Introduction
The Internet Protocol (IP), in its current two versions, IPv4 and IPv6, is the most widely used protocol of the digital age. The great success of this protocol is its versatility in running over multiple technologies, from Ethernet to WiFi, and it is mostly transparent to the public. However, security was not considered in its original design, and the result is the proliferation of multiple attacks based on this protocol. Internet Protocol Security (IPSec) was created to address this problem in IPv6, but was quickly adopted by IPv4 as well.
IPSec is conceived as an extension of the IP protocol to provide security capacities, including origin authentication, integrity, confidentiality, and anti-replay services. This is achieved with a new extension header and by appending a MAC (Message Authentication Code) to the packet and encrypting the payload.
However, the IPSec protocol specification is not limited to a new header. IPSec is a complex framework with a set of rules to decide when to generate the headers and validate the packets, but it also allows the user to dynamically select algorithms and key lengths among other parameters. These properties are wrapped around the notion of Security Association (SA) and Security Policies (SP) and stored in dedicated databases. IPSec is commonly supported by a second protocol, called Internet Key Exchange (IKE), which provides inline authentication and the negotiation of crypto parameters, as well as the periodic renewal of keys.
Relevance
IPSec is a critical protocol in today’s digital services. This is not only because it derives from IP connectivity, but also because several protocols delegate to IPSec their own security. For example, network operators and service providers typically add IPSec to their control protocols (e.g., BGP, DIAMETER, GTP). Other popular IPSec applications include Virtual Private Networks (VPN) and Software-Defined WAN (SD-WAN) variants. Many organizations use these services to provide remote or inter-branch connectivity in their business. Another common use is inter-datacenter connectivity, where cloud and service providers offer security to their customers by adding IPSec when traffic leaves or enters their domains.
One of the most remarkable properties of IPSec is that its application at the IP layer automatically provides security to higher layers and protocols. This makes IPSec an ideal solution for insecure protocols and services, when these cannot be directly modified to provide security due to cost or complexity. Moreover, this property makes IPSec very interesting in light of the development of Cryptographically Relevant Quantum Computers (CRQCs) and the security risk they pose. A quantum-safe IPSec customization can protect many other protocols without directly migrating them to Post-Quantum Cryptography (PQC), facilitating the overall transition.
Transition of IPSec to PQC
IPSec provides security services through a combination of symmetric algorithms (e.g. AES-256) and hash functions (e.g. SHA-3). As a result, today it can be considered robust against the CRQC threat. The problem arises when we want to automate the management of IPSec. We need IKE, currently version 2. IKEv2 is vulnerable to future CRQC because it uses asymmetric cryptography and key exchange methods based on the Diffie-Hellman family. It is therefore not quantum-secure in the way it is standardized today.
This problem can be solved by migrating IKEv2 to PQC. This approach, proposed in RFC 9370 [1], extends and concatenates the mechanisms and algorithms supported. It can be seen as a long-term approach suitable for multiple scenarios, but it will require updating the existing implementation to support new schemas and adopting NIST-standardized algorithms.
However, an alternative to securing current IPSec implementations against CRQC is to replace IKE with other existing solutions.
One proposed solution is to use a complementary technology that is immune to CRQC. Quantum Key Distribution (QKD) allows the secure sharing of keys that IPSec can later use, and does not depend on computer capacity, but on the principles of quantum mechanisms. The availability of commercial QKD systems and standard interfaces (e.g., ETSI QKD 014 [2] or ETSI QKD 004 [3]) allows integration and direct populating of IPSec SA databases.
The QKD systems will take care of key synchronisation and renewal. In addition, the IPSec endpoints will benefit from the QKD for implicit mutual authentication, as any potential impersonation will fail.
This approach provides a robust solution not only to known attacks today (e.g., Shor [4]), but also to new future algorithms. The main drawback of this approach is the cost and complexity, which will only allow network and service operators to use it where a QKD system is affordable.
The Software-Defined Networking (SDN) paradigm is another alternative, without the hardware dependency on QKD. The standardized I2NSF interface, see RFC9061 [5], can leverage an existing SDN controller to replace the IKE protocol. This approach will cover the same functionalities, such as algorithm selection, key distribution, key lifetime, etc. This is an ideal solution for network domains where SDN has already been adopted, such as cloud, transport networks, and SD-WAN. This solution fits on software or hardware accelerated IPSec implementations or devices under the same SDN domain.
Finally, nothing forbids combining previous alternatives to increase the robustness of IPSec. PQC/QKD hybridization of keys is possible, and SDN controllers can coordinate the QKD nodes and the IPSec agents to authenticate and establish connectivity.
