What is IKEv2 VPN and how good is it really?

In this post, we take a technical deep dive into the IPsec protocol suite, covering the core IKE extensions, and reviewing the benefits and drawbacks of IKEv2 VPN over IKEv1.

Keep reading to discover how IKEv2 VPN almost became the perfect VPN protocol.

Menu:

• IPsec & IKE
  • What is ESP?
  • What is IKE?
  • IKE phases
• IKE extensions: Problems & solutions
  • Dead Peer Detection
  • NAT-Traversal
  • XAUTH
  • Mode Config
• IKEv2 to the rescue?
  • Characteristics of IKEv2 VPN
  • Flaws of IKEv2
    • Remote networks
    • EAP authentication
• What is the future for IKEv2?
• Connect to IKEv2 VPN

IPsec and IKE: The basics

IPsec will be familiar to anyone who has ever dealt with the topic of VPN. However, did you know that IPsec itself is not actually a VPN protocol? In fact, IPsec is the name of a protocol suite consisting of various protocols that each fulfill different purposes.

In this deep dive, we are examining ESP and IKE.

What is ESP?

ESP (Encapsulating Security Payload) is the main VPN protocol used for exchanging encrypted and integrity-protected data and can be used to encrypt the body of an IP packet, or even to tunnel entire IP packets over an IP network like the internet.

Standardized in 1998, ESP is a pretty simple protocol because when it comes to security, simplicity is key. ESP is also a very fast protocol and, due to its flexible nature, can be made one of the most secure VPN protocols available, thanks to support for dozens of different cryptographic methods.

All you need for an ESP tunnel is for both sides to agree on the cryptographic methods used, and a set of cryptographic keys. Then the fun can begin…

…except, how would both sides agree on any methods and how do you transfer security critical keys from one side to the other side if the only thing you have available is a highly insecure medium like the Internet?

That's where another protocol of the suite comes in: IKE (Internet Key Exchange).

What is IKE?

Based upon a more generic protocol named ISAKMP (Internet Security Association and Key Management Protocol), the job of IKE can be described as follows: Establish a secure connection between two endpoints and use that secure connection to negotiate session keys and parameters for an actual IPsec tunnel.

Unlike ESP, which is a layer 4 protocol layered directly on top of IP (i.e. in the same spot where you typically expect protocols like UDP, TCP or ICMP) IKE is a layer 7 protocol sitting on top of UDP and uses port 500. UDP, just like ESP, is a connectionless protocol, meaning it doesn't know the concept of a connection, it just sends packets to a destination with specific parameters and hopes for the best. IKE, on the other hand, understands the concept very well and just uses UDP as a workhorse for transporting network packets because UDP is fast and simple.

The OSI Model

IKE phases

An IKE connection can be split into three phases:

Phase One: Contact

The first phase is to contact an endpoint, agree on cryptographic methods, derive session keys for the current session and perform mutual authentication of the endpoints.

Phase Two: Negotiation

The second phase is to negotiate the parameters and keys for the desired IPsec tunnel.
Those parameters and keys are also referred to as a Security Association (SA.) An IPsec tunnel typically requires two SAs, as SAs are unidirectional; meaning one SA is required for sending data and one is required for receiving data. In some cases, several SAs may be negotiated.

Phase Three: Monitoring

The third and final phase is to monitor the current session and to renew all SAs at regular intervals, because using the same cryptographic keys for too long makes the entire system more and more attackable.

IKE extensions: Main problems and solutions

Despite being a rather complex protocol, IKE lacks some basic functionality that had to be added by extensions later on. Some of these became standardized and are considered official extensions, some never made it past a draft standard, yet were still widely implemented, simply because nothing better existed, so vendors had no choice.

This section contains an overview of those problems and which extensions were introduced to solve them.

Dead Peer Detection

One could argue that IKE was not designed with a client-gateway architecture in mind, rather with a gateway-to-gateway architecture. This means it was designed to establish IPsec connections for tunneling traffic between networks (e.g. the main office and a branch office) and not for a so-called ‘road warrior’ scenario (e.g. home office, field service, business trips).

For example, once in phase three, an IKE connection will typically not exchange data for a longer period of time. This can be an issue for routers performing network address translation (NAT), as those routers will lose their NAT-mapping, causing the IKE connection to break, which goes unnoticed until IKE tries to send data again.
The same issue applies to firewalls performing stateful packet inspection (SPI), as they also lose the state required to let the IKE packets pass through.

Finally, if the other endpoint suddenly goes offline, this will also go unnoticed, since the IPsec tunnel won't notice the lack of response, as not all outgoing traffic will generate any reply traffic.

All of this had to be fixed by introducing an extension named DPD (Dead Peer Detection).

NAT routers and NAT-Traversal

As we just mentioned NAT routers, it’s important to note that these also have an issue handling ESP to begin with, as they usually rewrite port numbers to perform NAT, causing two issues:

1. ESP has no port numbers to begin with, only an index number named SPI (Security Parameters Index) to identify the tunnel.
2. Even if a NAT router could understand ESP, it cannot rewrite the SPI as that would break the packets, which are integrity protected, meaning any change on its way invalidates the packet.

The solution: To detect NAT routers and wrap ESP packets into UDP as required. For this to work, another extension had to be introduced, named NAT-T (NAT-Traversal); however, as vendors would not wait until that extension was finalized, they started implementing NAT-T while it was still a draft standard. For this reason, IPsec clients and gateways today may support any out of seven different draft standards, as well as the final one.

Some of them have different protocol numbers or port numbers, meaning two endpoints can hopefully find a version of NAT-T they can both agree upon. The later drafts and final standard use the well known UDP port 4500.

User authentication (XAUTH)

Big companies usually have a centralized database for their user base (Active Directory, Open Directory/LDAP, RADIUS, etc.) and of course they wanted their VPN users to authenticate against those databases, just like they do when accessing their mail server, internal websites, or logging in to their work computer.

IKE allows endpoints to authenticate with certificates or by using a pre-shared key (a secret password both sides need to know in advance), but many companies had no secure rollout process for user certificates. Using the pre-shared key (PSK) for the user password would work, except how would the gateway know the username required to fetch the right password?

One could try (ab)using the identifier field for this; however, in main exchange mode (one of the two possible ways in which IKE can establish a connection), the password is already required before the identifier has even been sent.

On the other hand, in aggressive exchange mode, an attacker that captures all IKE packets can try to brute force the PSK using an offline attack, meaning your company’s security depends on users picking secure passwords that can withstand such an attack. We all know how bad users are at choosing passwords, don't we?

The solution was an extension named XAUTH (eXtended AUTHentication), which allows all kinds of user authentications from simple to complex, from plain text passwords to password challenges.

XAUTH introduces a new exchange mode (transaction exchanges), that would take place between the first and the second phase of an IKE connection, meaning they take place over an already cryptographically-secured connection and only after passing that phase, would negotiation of an IPsec tunnel be allowed.

This not only allowed user authentication, but also accounting or an easy way to lock out users from a VPN. However, despite being such an important extension, supported by about four out of five gateways today, this extension never made it past draft state and was then abandoned, with no alternative provided.

Automatic configuration and Mode Config

The other thing every big IPsec setup calls for, and every network admin begs for, is automatic configuration.

DHCP was developed for the same reason why users no longer want to assign IP addresses by hand anymore: they also don't want to configure IPsec network parameters for every individual user by hand.

The solution to this challenge has been named MCFG (Mode ConFiG, aka IKECFG or IKEConfig). MCFG builds upon the transaction exchange introduced by XAUTH and just like XAUTH, it never got past an early draft state. Still, it's widely adopted and around two third of all IPsec gateways offer MCFG today.

Using MCFG a gateway can assign a VPN client an IP address and a subnet mask, it can tell the client about available remote DNS servers, and distribute a few other configuration parameters.

Yet even that extension had a major oversight: There's no way to tell a client about available remote networks. This was such an important missing feature that Cisco extended MCFG (yes, they extended an unfinished draft extension to a protocol), adding this feature and naming the whole thing "Easy VPN". Since its introduction, even that proprietary, undocumented extension has been widely adopted by many other vendors simply because of how useful the feature is.

IKEv2 to the Rescue?

With all those extensions, including even more than listed above, IKE quickly became even more complex and a compatibility nightmare. Every client and gateway would support a different feature set or support different draft versions of extensions.

Moreover, many of the extension "standards'' are poorly written and leave a lot of open questions, so it's not even always obvious how to correctly implement them – especially as different implementations disagree on key points.

In 2010 the IETF (Internet Engineering Task Force) finally had enough of all the compatibility issues and standardized IKE version 2 (IKEv2).

Core characteristics of IKEv2 VPN

Right from the get go, IKEv2 would offer DPD and NAT-T as a core functionality. Also, the protocol is no longer based on ISAKMP but is now a protocol of its own, compatible with IKE wherever no change was required but still significantly different in many aspects.

For example, a full ESP tunnel negotiation requires at least exchanging 9 to 11 packets, depending on the chosen exchange mode, whereas IKEv2 just offers a single exchange mode and negotiation only requires 4 packets as a minimum.

Another problem with IKEv1 was that it required one proposal for any combination of suggested security parameters, causing packets to quickly grow huge if too many parameters were offered. Whereas in IKEv2, those parameters are just listed in one, sometimes two proposals, and the other side just picks whatever parameters it prefers, keeping the packets small and simple.

IKEv2 had the potential to solve all of the issues discovered in IKE and make IPsec the greatest VPN protocol suite ever, but spoiler alert: that's not how it all played out.

New mistakes were made, some design decisions are highly questionable but the biggest issue, which leaves many VPN experts perplexed, is that past mistakes have been repeated.

Here are two examples:

Major flaws of IKEv2

Remote networks

While IKEv2 has built-in support for configuration exchange, meaning Mode Config is no longer required, it still lacks a list of remote networks.

This one feature that was so important that Cisco had to extend Mode Config and create their own proprietary protocol for other vendors to make use of was just left out again!
Instead, IKEv2 supports something called Traffic Selector (TS) negotiation but that cannot serve as a replacement for two reasons:

Firstly, the number of remote networks cannot be negotiated that way, so to work as a replacement, the number of available remote networks must be known in advance to the client.

Secondly, unclear intentions can arise. During TS negotiation, the client proposes remote networks, and the gateway restricts these suggestions to related subnets. If the client lacks remote network knowledge, it might suggest tunneling all traffic, and the gateway could then narrow this to available remote networks. The gateway's configuration might permit remote-specific network access or full traffic tunneling. This leads to ambiguity: when the client requests all traffic, it's uncertain if they truly want total tunneling or limited to a remote network. Ultimately, a client could ask for "all traffic," and the gateway might agree, contrary to the client's intent.

This situation is so bad, that one vendor already ported the Cisco Mode Config extension to IKEv2, which again is now proprietary and not supported by other vendors. It would have been so easy to support a remote network list configuration option and, considering all configuration options are optional anyway, there was no real reason not to.

EAP authentication

Another major issue is that instead of using XAUTH, IKEv2 performs user authentication via a protocol named EAP (Extensible Authentication Protocol). The idea to use an existing protocol that is already used by other network protocols and for which code might already be available seems to be a good one at first glance, but in practice that decision causes a lot of drawbacks.

EAP itself only defines a single mandatory authentication scheme that barely anyone is interested in using today. Dozens of EAP extensions exist for any other authentication scheme you can think of, but all of these are optional. Even if a client and a gateway both support EAP, there is no guarantee that they can agree on any common authentication scheme they both support or are allowed to use.

The result is that many IKEv2-compatible gateways don't support EAP at all or they only support EAP with one common scheme that is considered common because it is used by Microsoft Windows; meaning many EAP implementations will at least have support for this specific scheme which is a simple username and password scheme.

As soon as gateways want to offer OTP or 2FA schemes, they refrain from using EAP for that purpose and prefer to rely on their own proprietary way of doing that, which kills compatibility between vendors, as well as gateways and clients.

This could easily have been avoided by having the IKEv2 standard simply declare a set of EAP authentication schemes as mandatory, to ensure that any IKEv2 EAP implementation provided at least the same functionality that XAUTH provided for IKE.

What is the future for IPsec?

The result of these repeated mistakes is that some vendors have given up on IPsec as a client protocol and rather moved on to use their own, proprietary VPN protocols.

Many argue, if you have to add proprietary extensions to IKEv2 to make it a useful standard, you may as well go full proprietary with your very own VPN protocol or use another solution that already covers all your needs, like OpenVPN or WireGuard®.

On the other hand, other vendors simply continued using IKEv1 with all its quirky extensions and skipped IKEv2 support altogether.

In many ways, IKEv2 really is a missed chance, so close to being the perfect solution but as they say a miss is as good as a mile.

Connect to IKEv2 VPN in VPN Tracker

Connecting to IKEv1 or IKEv2 VPN? VPN Tracker is your best choice VPN client for Mac, iPhone and iPad. VPN Tracker's custom IKEv2 engine includes unbeatable support for all relevant IKE extensions, providing seamless compatibility with the most popular IKEv1 and IKEv2 VPN gateways from Cisco, Fortinet, Zyxel, TP Link, Draytek, and more.

Moving away from IKE? We've got your back - VPN Tracker also supports OpenVPN, PPTP (Mac only), L2TP (Mac only), WireGuard, SSTP, SonicWall SSL, Cisco AnyConnect SSL, and Fortinet SSL connections.