What is Internet Key Exchange (IKE) and How Does It Work?

How does IKE work in IPsec?

IKE is a part of IPsec, a suite of protocols and algorithms used to secure sensitive data transmitted across a network. The Internet Engineering Task Force developed IPsec to provide security through authentication and encryption of IP network packets and secure VPNs.

In IPsec, IKE defines an automatic means of negotiation and authentication for IPsec SAs during the initial connection. This is required for the encryption and decryption process because it negotiates the security that is used for main communication. IKE offers several benefits for IPsec configuration, including automatic negotiation and authentication, antireplay services, certification authority support and the ability to change encryption keys during an IPsec session.

The IKE protocol uses User Datagram Protocol (UDP) packets during transmission, generally needing four to six packets with two to three messages. An IPsec stack intercepts relevant IP packets, encrypting and decrypting them as needed.

To illustrate the use of IKE, imagine two spies who have not met before need to start exchanging secret messages. IKE is when they first meet, using an agreed-upon secret to identify each other, such as “I’ll be at the park bench wearing a red hat; you ask about the snow.” Then, they can agree on how to encrypt and drop off messages. From then on, they never need to meet again in person and only need to follow the agreed way to exchange messages.

Understanding phase 1 and phase 2 of IKE

The original version of IKE sets up secure communications channels in two phases: phase 1 and phase 2.

In phase 1, an authenticated connection between the initiator and responder is established using a preshared key or a digital certificate. The goal is to secure the communications that occur in phase 2.

The Diffie-Hellman key exchange algorithm creates a secure authentication communication channel that is used for further communication. This digital encryption method uses numbers raised to specific powers to produce decryption keys. The negotiation should result in session keys and one bidirectional SA.

Phase 1 operates under one of two modes: main mode or aggressive mode. The main mode consists of both parties sending three two-way exchanges equaling six messages in total. The first two messages confirm encryption and authentication algorithms. The second set of two messages starts with a Diffie-Hellman key exchange, where both parties provide a random number. The third set of messages verifies the identities of each party.

Aggressive mode accomplishes the same task as the main mode but does so in just two exchanges of three messages. Whereas the main mode protects both parties’ identities by encrypting them, the aggressive mode does not.

Phase 2 of IKE negotiates an SA to secure the data that travels through IPsec, using the secure channel created in phase 1. The result is a minimum of two SAs that are unidirectional. Both parties also exchange proposals to determine which security parameter to use in the SA.

Phase 2 operates in only one mode: quick mode. Quick mode provides three resources: proxy IDs, perfect forward secrecy (PFS) and replay protection. The proxy IDs of each participant are shared with each other. PFS delivers keys independent from preceding keys. Replay protection is a security method to protect against replay attacks.

The main and aggressive modes found in phase 1 only apply to IKEv1 and not to IKEv2.

What is IKE version 2 and what are its improvements?

IKEv1 came out in 1998 and was followed by the release of IKEv2 in 2005. IKEv2, updated in 2014, negotiates and authenticates IPsec SAs and provides secure VPN communication channels between devices. This version does not include phases 1 or 2 like its predecessor, but message exchanges still negotiate an IPsec tunnel.

The first of the four messages is a negotiation to decide a security attribute. The second is where each party authenticates its identity. The third includes the creation of additional SAs. The fourth message removes SA relationships, detects IPsec tunnel liveliness and reports errors.

Improvements in IKEv2 over IKEv1 are as follows:

• Requires less bandwidth.
• Demands fewer cryptographic mechanisms to protect packets.
• Requires only one four-message initial exchange mechanism.
• Supports mobile platforms, including smartphones.
• Supports the security of Stream Control Transmission Protocol traffic.
• Provides more resistance to denial-of-service (DoS) attacks.
• Comes equipped with the built-in network address translation (NAT) traversal needed to support routers that perform translations.
• Detects automatically if an IPsec tunnel is still live so that IKE can automatically reestablish a connection if needed.
• Enables message fragmentation and IKEv2 to operate in areas where IP fragments might be blocked and an SA may fail to establish.
• Enables rekeying to build new keys for SA.

Mobility and Multihoming Protocol is an extension of IKE in the v2 specification to support mobile devices, such as smartphones. It helps to quickly reestablish the connection when the device moves between networks.

How does an IKEv2 connection work?

An IKEv2 connection uses less steps than IKEv1:

1. IKE_SA_INIT is the initial exchange where the initiator and responder exchange supported encryption types.
2. IKE_SA_AUTH is where they exchange authentication information and establish the connection.
3. CREATE_CHILD_SA is where they create SAs for each other.

What are the advantages of using IKE?

IKE includes the following benefits:

• Automatic negotiation and authentication.
• Antireplay services.
• Ability to change encryption keys during an IPsec session.
• Calculation of shared keys.
• Fast connection speeds using NAT and NAT traversal.
• Attempts to restore a connection whenever the connection drops.
• Support for a variety of devices, including desktops and smartphones.
• Prevention of DoS and replay attacks.

What are the potential challenges of using IKE?

IKE may pose the following challenges:

• IKEv1 is vulnerable to Bleichenbacher attacks, which obtain information about a device based on the device’s response to receiving modified ciphertext.
• Using IKEv2 in some operating systems (OSes) may require users to make additional manual configurations. For example, if IKE in Junos OS is not explicitly configured, Junos OS defaults to version 1 of IKE.

There is also a chance that a firewall or a network administrator could block IKEv2’s UDP port, causing a VPN to stop working.

What is an L2TP IP VPN Internet Key Exchange?

Internet service providers use Layer Two Tunneling Protocol (L2TP) combined with IPsec to enable a VPN to pass all traffic. By using IKE, this networking protocol negotiates and authenticates secure VPN connections. Using L2TP is a bit slower than other VPNs but enables it to pass the original packets unaltered.

Alternatives to IKE

IKE has been largely replaced by IKEv2. For automatic connections using IPsec, IKEv2 is still the best choice. If a system is being designed from scratch, other methods may be considered.

A manual IPsec tunnel can be configured that does not use IKE. For this to work, all the encryption types need to be preconfigured for both ends of the connection. By cutting out IKE, it can decrease the initial connection time. This may be useful for fixed tunnels, such as for a site-to-site VPN.

Other modern VPN technologies may offer better VPN performance than IPsec with IKE. OpenVPN is a popular and well-understood VPN technology. WireGuard is a recent VPN technology that offers superior performance but is not widely supported yet.

Explore the benefits of Always On VPN and the differences between VPN vs. zero trust vs. software-defined perimeter.