Internet Key Exchange (IKE) Version 2

In Part One, we focused on the protocol differences between versions 1 and 2 of Internet Key Exchange (with an emphasis on new features introduced in IKEv2). Our emphasis here will be on how version 2 is implemented on the Cisco IOS router.

After examining the Configuring Internet Key Exchange Version 2 (IKEv2) RFC, I have concluded that the commands and options included are an initial implementation with more options to come in a future code release. IKE version 2 is supported for site-to-site VPNs but not EasyVPN (or remote access). Also, while mentioned in the Cisco document, the Extensible Authentication Protocol (EAP) authentication options are not implemented in the CLI commands.

Many of the IKE version 2 configuration commands are specified using crypto ikev2 syntax. Besides this distinguishing feature, an IKEv2 parameter set is referenced using crypto ikev2 proposal name (versus the policy number in older crypto isakmp statements). While the choice of encryption algorithms (DES, 3DES, and AES 128,192, or 256-bit) has not changed, message hash choices now include sha256 and sha384 in addition to the traditional md5 and sha1. Diffie-Hellman group support is expanded beyond the long-supported groups 1, 2, and 5 to include groups 14, 15, 16, 19, and 20.

One nice feature (in this author’s opinion) within the proposal configuration is the inclusion of a mandatory {local | remote} keyword choices when configuring authentication and the pre-shared key. Using this in conjunction with a match address sub-configuration mode command allows for per-peer specific proposal matching, a feature previously not possible with the IKEv1 implementation. Incidentally, an additional authentication option is possible with IKEv2, ecdsa-sig, or, the Elliptical Curve Digital Signature Algorithm. This offers a viable choice for communication with portable encryption devices such as USB keys.  By having the local/remote choices for the pre-shared key, an asymmetric implementation is possible whereby different keys are used to authenticate a peer-to-peer association versus the old method which required symmetric keys.

IKEv2 CLI presents even more options in both its implementations of the crypto identity as well as Dead Peer Detection (DPD). The identity now includes explicit options to be used with digital certificates:

  • DN (Distinguished Name) typically associated with a device hostname
  • Serial allows for association with the certificate Serial Number
  • OU (Organizational Unit) typically associated with the group name

Address, fqdn, and email are available as other options. A Fully Qualified Domain Name (or fqdn) is often implemented either as host.domainname or user@domainname.

Another parameter which can be set for the identity is a trustpoint, an option previously included in configuration of a crypto map. Dead Peer Detection configuration, while optional, now requires the use of a keyword: on-demand | periodic.

The first one of these issues the DPD message only as a check immediately prior to data transmission; the second is the traditional IKEv1 implementation of a “heartbeat”.

In this article

Join the Conversation