IKEv1 & IKEv2

I have been dealing with VPNs for the past 20 Years. Primarily I have used IKEv1 as it was the most used. In this post, I will go over what IKEv1 is and the differences between it and IKEv2. There are RFCs you can read, however if you decide to, you probably don’t like yourself that much. I will try to make this as simple as I can so I myself can understand it. Like a wise man once said “If you can’t explain it simply, you don’t understand it well enough.” ~ Albert Einstein. Here is my attempt to try just that.

First things first:

IKEv1 is the legacy version and IKEv2 is fairly new.

An SA is a relationship between two or more entities that describes how the entities will use security services to communicate securely. They are established during Tunnel establishment. IPsec is applied in tunnel mode, which supports the Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols. Sufficit to say, AH is not commonly used nor is it recomended.

DEEPER DIVE
The AH provides authentication only. AH provides data integrity, data origin authentication, and an optional replay protection service. Data integrity is established by using a algorythmic digest such as HMAC-MD5 or HMAC-SHA. 
Data origin authentication is established by using a shared secret key to create the message digest. Replay protection is provided by using a field designatted as sequence number field with the AH header. AH authenticates IP headers and their payloads, with the exception of certain header fields that can be legitimately changed in transit, such as the Time To Live (TTL) field.

The ESP protocol provides data confidentiality (encryption) and authentication (data integrity, data origin authentication, and replay protection). 
ESP can be used with confidentiality only, authentication only, or both confidentiality and authentication. When ESP provides authentication functions, 
it uses the same algorithms as AH, but the coverage is different. AH-style authentication authenticates the entire IP packet, including the outer IP header,
while the ESP authentication mechanism authenticates only the IP datagram portion of the IP packet.

Main Mode or Aggressive Mode
Negotiation is done by two different modes; Main and/or Aggressive. For some people, the word “aggressive” seems stronger than “main” however this is not the fact. Aggressive mode is a source of contention by many of the regualtory bodies today. Because of its weaknesses. You should not judge a book by its cover when dealing with aggresive mode. Avoid it. Usually Aggressive mode is used for remote access VPNs. If you still have remote-access VPNs running IPSec, see about moving to a TLS based remote access VPN solution

DEEPER DIVE
For a successful and secure communication using IPSec, the IKE (Internet Key Exchange) protocols takes part in a two step negotiation. Main mode or Aggressive mode (Phase 1) authenticates and/or encrypts the peers. Quick mode (Phase 2) negotiates the algorithms and agree on which traffic will be sent across the VPN. Below I discuss Aggressive mode (Phase 1).


Aggressive mode can be used within the phase 1 VPN negotiations, as opposed to Main mode. Aggressive mode takes part in fewer packet exchanges. Aggressive mode does not give identity protection of the two IKE peers, unless digital certificates are used. This means VPN peers exchange their identities without encryption (clear text). It is not as secure as main mode, but the advantage to aggressive mode is that it is faster than Main mode.

Tunnel or Transport Modes

Tunnel mode:

Tunnel mode protects the internal routing information by encrypting the IP header of the original packet. The original packet is encapsulated by a another set of IP headers. It is widely implemented in site-to-site VPN scenarios. NAT traversal is supported with the tunnel mode. Additional headers are added to the packet; so the payload MSS is less.

Transport mode:
The transport mode encrypts only the payload and ESP trailer; so the IP header of the original packet is not encrypted. The IPsec Transport mode is implemented for client-to-site VPN scenarios.
NAT traversal is not supported with the transport mode. MSS is higher, when compared to Tunnel mode, as no additional headers are required.

Transport mode is usually used when another tunneling protocol (such as GRE, L2TP) is used to first encapsulate the IP data packet, then IPsec is used to protect the GRE/L2TP tunnel packets.

Lets put it together
Step 1 Interesting traffic initiates the IPSec process—Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.
In this step, you will have created the Proxy IDs for Phase II.

Cisco – Access-list used to match traffic to a crypto map

Fortinet – Under the VPN Menu Item, then Phase II

Checkpoint – User communities (Need to get access to ISO for Checkpoint)

Step 2 IKE phase one—IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase two.

On Cisco ASAs, there are a few locations for the Phase I portions of the VPN:
Crypto ikev1 policy X
Tunnel-group
And Crypto-map to match peer IP.

Fortigate, a little more straight forward since you have it on the Phase 1 portion of the VPN tunnel in the Web GUI and for the Fortigate CLI

The Fortigate has exceptional flexibility in the way it can handle Phase I for VPNs if you shell out to the command prompt (like i enjoy doing).

name : 0
type : static 
interface : 
ip-version : 4 
ike-version : 1 
local-gw : 0.0.0.0
keylife : 86400
authmethod : psk 
mode : main 
peertype : any 
passive-mode : disable 
exchange-interface-ip: disable 
mode-cfg : disable 
proposal : aes128-sha256 aes256-sha256 3des-sha256 aes128-sha1 aes256-sha1 3des-sha1 
localid : 
localid-type : auto 
auto-negotiate : enable 
negotiate-timeout : 30
fragmentation : enable 
dpd : on-demand 
forticlient-enforcement: disable 
comments : 
npu-offload : enable 
dhgrp : 14 5 
suite-b : disable 
wizard-type : custom 
xauthtype : disable 
mesh-selector-type : disable 
idle-timeout : disable 
ha-sync-esp-seqno : enable 
auto-discovery-sender: disable 
auto-discovery-receiver: disable 
auto-discovery-forwarder: disable 
encapsulation : none 
nattraversal : enable 
rekey : enable 
remote-gw : 0.0.0.0
monitor : 
add-gw-route : disable 
psksecret : * 
keepalive : 10
dpd-retrycount : 3
dpd-retryinterval : 20
Step 3 IKE phase two—IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.

Step 4 Data transfer—Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database.

Step 5 IPSec tunnel termination—IPSec SAs terminate through deletion or by timing out.

 

IKEv2

Compared with IKEv1, IKEv2 simplifies the SA negotiation process. IKEv2 uses two exchanges (a total of 4 messages) to create an IKE SA and a pair of IPSec SAs. To create multiple pairs of IPSec SAs, only one additional exchange is needed for each additional pair of SAs. Different authentication methods IKEv2 supports EAP authentication. IKEv2 can use an AAA server to remotely authenticate mobile and PC users and assign private addresses to these users. IKEv1 does not provide this function and must use L2TP to assign private addresses. Different supports for IKE SA integrity algorithms IKE SA integrity algorithms are supported only in IKEv2.

Different implementations of DPD packet retransmission. The retry-interval parameter is supported only in IKEv1. If the NGFW sends a DPD packet but receives no reply within the specified retry-interval, the device records a DPD failure event and retransmits a DPD packet. When the number of failure events reaches 5, both the IKE SA and IPSec SA are deleted. The IKE SA negotiation will be started again when the device has IPSec traffic to handle.

In IKEv2 mode, the retransmission interval increases from 1, 2, 4, 8, 16, 32 to 64 seconds. If no reply is received within eight consecutive transmissions, the peer is considered dead, and the IKE SA and IPSec SA will be deleted. Different supports for manual lifetime settings
In IKEv2, the IKE SA soft lifetime is 9/10 of the IKE SA hard lifetime plus or minus a random value to reduce the likelihood that two endpoints initiate re-negotiation at the same time. Therefore, soft lifetime does not require manual settings in IKEv2.