For a while now, I have been hearing about this new version of the IKE protocol but I never really took time to learn about it until now. IKEv2 is not an update to IKEv1; in fact, IKEv2 is not backward compatible with IKEv1. Just think of IKEv2 as a revamp of the IKE protocol in general. In this article, we will discuss the IKEv2 implementation on Cisco IOS.

CCNA Training – Resources (Intense)

Note: Practicing IKEv2

Cisco began supporting IKEv2 on Cisco IOS from IOS version 15.1(1)T, so if you are going to practice this feature, you must use that IOS version or higher. The challenge with this is that GNS3 only supports IOS 15.x on the 7200 and IKEv2 is not supported on the base 7200 platform (not IOS).

One way to go will be to practice using a CSR 1000V that can be installed in VirtualBox and used in GNS3. You can find an article covering that here. Another way will be to use IOU images in GNS3 that support IKEv2. It is illegal to distribute IOU images so please don’t ask for them here.

IKEv2 versus IKEv1

Purpose and benefits

The purpose of IKE remains the same whether IKEv1 or IKEv2β€”to authenticate peers and establish security associations (SAs) used for protecting traffic. However, there are many benefits of IKEv2 over IKEv1, including built-in DoS prevention, support for EAP authentication, in-built NAT-T and so on. You can read more about the benefits here.

Messages exchanged

Another difference between the two versions of IKE is the number of messages exchanged. IKEv1 has two phases: Phase 1 and Phase 2. Phase 1 can either be Main mode (6 messages) or Aggressive mode (3 messages). IKEv1 Phase 2 has only one mode – Quick mode (3 messages). For more details about these modes, you can read the following articles: Main mode, Aggressive mode, Quick mode.

In IKEv2, there are no defined phases as in IKEv1. IKEv2 makes use of four types of messages: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, and INFORMATIONAL and these messages are exchanged in a request-response manner. In most cases, four messages (a pair of IKE_SA_INIT messages and a pair of IKE_AUTH messages) are enough to set up both the IKE SA and the first child SA but there may be variations. As we go on in this IKEv2 series, we will talk more about these message exchanges.

Authentication methods

IKEv1 supports authentication via pre-shared keys, digital signatures, and public key encryption. IKEv2 supports pre-shared keys, digital signatures and EAP. Apart from this, both IPSec peers in IKEv1 must use the same type of authentication, e.g., both pre-shared key or both digital signature. However, IKEv2 supports asymmetric authentication: One side can authenticate using pre-shared keys while the other side uses digital signatures.

Configuration on the Cisco IOS

The way IKEv2 is configured on the Cisco IOS is also considerably different from the way IKEv1 is configured. There are new terminologies that we need to be aware of to successfully configure IKEv2 and we will talk about them now.

IKEv2 components on Cisco IOS

IKEv2 Proposal

This was known as IKE (ISAKMP) policy in IKEv1 and an example is shown below:

In IKEv2, it is known as a proposal and it contains the encryption algorithm, integrity algorithm, Pseudo-Random Function (PRF) algorithm and DH group to be used to negotiate IKE SAs.

Note: On the Cisco IOS, the PRF algorithm is the same with the integrity algorithm so it is not configured separately.

Unlike IKEv1 policies, IKEv2 proposals are named and not numbered. Also, with IKEv2, you can configure more than one algorithm of each type in a proposal and the order of priority will be from left to right. Let’s look at a sample IKEv2 proposal:

As you can see, there are two encryption algorithms: 3DES and AES-CBC-192; there are also two integrity algorithms: MD5 and SHA1; there is only one Diffie-Hellman group. With this configuration, there are four different possible transforms, as listed below in order of priority:

IKEv2 Policy

This is a new concept on the Cisco IOS with IKEv2 that was not available in IKEv1. In IKEv1, all the IKEv1 policies configured on a device are used for negotiation. With IKEv2 policies, you can specify which IKEv2 proposals should be used for negotiation based on different match statements. Currently, you can only match the local address and front door VRF (FVRF).

Side talk: It would have made sense to be able to match the remote peer’s address in the IKEv2 policy but that is not yet supported. I guess it should be added soon.

An example of an IKEv2 policy with two IKEv2 proposals configured is shown below:

IKEv2 Key Ring

To configure the pre-shared key for use in IKEv1, you could just do something like:

In IKEv2, key rings are now used. Key rings allow you to configure symmetric or asymmetric pre-shared keys to be used for authentication. In the example below, I have configured a key ring with asymmetric pre-shared keys:

Note: Do not confuse asymmetric pre-shared keys with asymmetric encryption (PKI). Asymmetric pre-shared keys just means both VPN peers do not have to use the same (symmetric) pre-shared key for authentication.

IKEv2 Profile

If you go back to the IKEv2 proposal above, you will see that we did not define any authentication method. This is because the authentication method is not negotiated in IKEv2. In the Cisco IOS, all nonnegotiable parameters are specified under an IKEv2 profile. These include the authentication method, the identity of the remote peer, key rings and so on.

The IKEv2 profile will then be attached to a crypto map or an IPSec profile (when you are using VTIs to terminate VPN tunnels).

Note: There are other components, such as IPSec transform sets and crypto maps/IPSec profiles, that are not specific to IKEv2 but which must also be configured just like you would under IKEv1.

Recap of the IKEv2 components

I know we have discussed quite a number of new terminologies that you need to be familiar with, so let me summarize them here.

  • IKEv2 proposals contain the transforms (encryption, integrity, DH) that will be negotiated.
  • The IKEv2 proposals must be attached to an IKEv2 policy which allows setting the proposals to be used for different negotiations based on certain match statements.
  • If pre-shared key authentication is being used, an IKEv2 key ring is used to configure the pre-shared keys (symmetric or asymmetric).
  • Nonnegotiable parameters, such the remote peer’s identity, authentication methods and key rings, are configured under an IKEv2 profile, which is then attached to a crypto map or IPSec profile.

In actual fact, to make the IKEv2 configuration easier, Cisco has what it calls IKEv2 Smart Defaults that contain default values for a number of configuration items. Therefore, for a basic configuration, the only things we must configure are the IKEv2 profile and IKEv2 key ring (if PSK authentication is being used).

For example, there is a default IKEv2 proposal shown below:

You can view the other default IKEv2 configuration here.

Summary

In this article, we have begun discussing IKEv2 on the Cisco IOS. We discussed the difference between IKEv1 and IKEv2 and went on to see the configuration components for IKEv2.

In the next article in this series, we will dive deeper into IKEv2 by looking at a configuration example. I hope you have found this article helpful.

References and Further Reading