19 November 2021

On yer IKE

By admin@labtinker.net

I was reviewing a VPN configuration and wondered why the engineer was using IKEv1 (IKE being Internet Key Exchange) instead of IKEv2 and then it occurred to me I was merely following a play in the Bluffers’ Guide to IT: the newer the version, the longer the key, the fresher the acronym, the better it must be. I didn’t really have a deep understanding of the difference between the versions of IKE. So I thought I would do a little research then have a tinker.

My lab was a couple of ASAs in GNS3 with a IPsec VPN between them:

The terminology around VPNs can be confusing and even though this was intended as a practical post it’s probably useful to go over some of it. This is my high-level understanding (I found inconsistencies or perhaps differences of emphasis in sources I consulted)

IPSec itself is a collection of protocols; IKE, (the subject of this post), ESP (Encapsulating Security Payload) and AH (Authentication Header). Let’s forgot AH, as it doesn’t provide encryption which leaves us with IKE and ESP.

IKE itself is a collection of protocols, namely ISAKMP, Oakley and Skeme

ISAKMP (Internet Security Association and Key Management Protocol) describes a framework for establishing security associations between peers; these being authenticated and cryptographically protected channels of communication

IKE and ISKAMP often seemed to be used interchangeably.

IKE has two phases:

IKE Phase one:

This establishes an SA (security association) to protect message exchanges between two IKE peers to enable them to securely negotiate a policy for the SAs in phase two. The phase one SA can be almost considered a management SA between the two peers. In the above example the VPN is between the two ASAs so this SA will be between them.

IKE Phase two

This creates the IPSec SAs for configured local and remote subnets that can be used to securely transfer data. So in the above example the VPN has been configued such that traffic is secured between the subnets that the routers sit on, when it travels between the two ASAs.

IKEv1 has two different modes of operation which are aggressive or main. These are explored and explained here:

https://www.omnisecu.com/tcpip/ikev1-main-aggressive-and-quick-mode-message-exchanges.php

IKEV1 Aggressive Mode

This has to be used when one of the peers doesn’t have a fixed ip address and peer-id is used instead. It has advantage of only needing three exchanges. I set up ikev1 and ikev2 on the ASAs – and for this part of the exercise forced ‘aggressive mode’.

So setting up a ping from R1 to R2 to raise the VPN we see the three phase one exchanges (marked ‘Aggressive’, ‘Quick Mode’ is phase 2)

And we see the identity of the peer sent in the clear:

…which in this instance is the ip address of the ASA (though when dyanmic ip addresses are used it is typically some kind of tag)

IKEV1 Main mode

So converting to main mode with the following command:

crypto map outside_map 10 set phase1-mode main

…though when I repeat the command to show the set up main mode isn’t explicitly stated, presumably as it’s the default.

…and in this instance we see six phase one IKE messages….

This mode doesn’t reveal the identity of the peer as is more secure. What these messages contain and their purpose has been covered in detail here:

https://www.omnisecu.com/tcpip/ikev1-main-aggressive-and-quick-mode-message-exchanges.php

IKEV2

The differences beween the IKEv1 and IKEv2 are summarised here:

https://privecstasy.com/ikev1-vs-ikev2/

Essentially, IKEv2 supports EAP authentication, has a more secure means of connection than aggressive mode, for when you have one peer with a dynamic address, called MOBIKE. It also allows you to use different authentication between peers (eg: psk one way and certificates the other)

The exchange is more efficient than ikev1 main mode: