IKE (Internet Key Exchange)-Internet Key exchange
In order to introduce the FLEXVPN based on IKEV2, this paper introduces IKEV1 and IKEv2 differences.
Before starting the introduction, take a look at the application and workflow of IKEV1 in IPSec VPN.
In IPSec VPN, IKE is used to negotiate IPSec SAs. This procedure requires IPSec to first authenticate each other and establish a ISAKMP shared key. An SA is a description of what security services are used for secure communication between two or more peers.
This process is carried out in two phases:
ike-Phase 1: IPSec peer authentication, and a secure channel is established between peers for key exchange.
Phase 1 focuses on the following tasks:
-
- Authenticate the IPSec peer;
- To negotiate the matching IKE SA policy between peers to protect the IKE key exchange;
- Use the validated Diffie-hellman to exchange "keying material" and eventually generate a matching shared key;
- Establish a secure tunnel to negotiate IKE phase 2nd parameters.
Phase 1 has two modes of operation (main mode and aggressive mode)
Main mode: three bidirectional exchanges (consisting of 6 messages) between peers, negotiated to match the IKE SA value between peers, providing a protected channel for subsequent ISAKMP exchanges. ( Ike SA for each peer is bidirectional )
- 1th Exchange: negotiates a hashing algorithm to protect IKE traffic, ensuring that each peer's IKE SA policy matches the same;
- 2nd Exchange: by using Diffie-hellman to exchange keys between peers to generate material, each peer can generate the same shared key; ( the true shared key will not be exchanged through DH )
- 3rd Exchange: Verify peer identity, where identity information is the peer IP address in encrypted form.
Aggressive Mode (Savage mode): only a two-way exchange, the peer will negotiate all the necessary (such as: DH public key, identity information, etc.) in the IKE SA, one-time send to peer. This means that Savage mode has been exchanging information before establishing a secure communication channel. While improving communication efficiency, it reduces security.
ike-Phase 2: Negotiate an IPSec SA to establish an IPSec tunnel.
Phase 2 focuses on the following tasks:
-
- Under the IKE SA protection of Phase 1, the parameters of IPSec SA are negotiated;
- establishing an IPSec SA;
- Periodically renegotiate the IPSec SA to ensure security;
- For additional Diffie-hellman exchange (optional).
Phase 2 has only one mode of operation: Quick mode
Quick mode: after the security tunnel is established in Phase 1, enter the quick mode, negotiate the shared security policy, derive the shared keying material for the IPSec security algorithm, and establish the IPSec SA. After negotiation, each peer will generate at least two one-way IPSec SAs(one inbound and one outbound).
As described above, we have learned about the IKEV1 workflow in IPSec VPN. Now let's look at how IKEv2 is doing. ( either IKEV1 or IKEV2, they play the same role in IPSec VPN, only responsible for the key negotiation and exchange work required for IPSec encryption.) Therefore, only the IKEV2 work process is described below)
During IKEv2 's work, peer negotiation is done by 3 exchanges, and messages can be divided into 4 categories: Ike_sa_init, Ike_auth, Create_child_sa, and Infomational, where Ike_sa_init and Ike_ Auth for the initial exchange, CREATE_CHILD_SA for the establishment of the sub-SA exchange, informational for information exchange.
- ike_sa_init: corresponds to the 1th stage in the IKEV1, which is responsible for negotiating the IKE SA policy and generating keying material. This process exchanges a total of 2 messages. In a single policy, multiple "encryption/integrity/PRF/DH groups" are allowed to be specified "OR".
- Ike_auth: after ike_sa_init generated keying material, through Ike_auth to perform mutual authentication, this process needs to exchange 2 messages, the exchanged messages will be encrypted with the key generated by the Ike_sa_init;
- Creat_child_sa: corresponds to the 2nd stage in the IKEV1, this process exchanges 2 messages. After the initial exchange is completed, it can be initiated by either party, and the message is protected by the negotiated encryption and authentication algorithm in the initial exchange;
- Informational: peer during key negotiation, a party may want to send control information to the other party to notify the occurrence of certain errors or events. Information exchange is to achieve this function. Because in the information exchange, the receiver must respond to the message, so the sender can determine whether the other party is alive.
Thus, in IKEv2, there is no longer a main mode/Savage Mode/Quick mode. The IKEV2 exchanges fewer messages and is therefore more efficient.
The above is a brief introduction to the IKEv2 different from the IKEv1 of the work process, the following to see what are the different features:
- IKEv2 is the "upgraded version" of IKEV1, but it is not backwards compatible. In other words, in the IKEV1 and IKEV2 environments, you have to configure IKEV1 and IKEv2 at the same time;
- IKEv2 does not occupy IKEV1 resources, which means that they can be run on a single device at the same time;
- IKEV2 supports EAP authentication, while IKEV1 does not support it;
- IKEV2 supports Mobike, while IKEV1 is not supported; (Mobike allow IKEv2 for mobile platforms, such as mobile phones, etc.)
- The IKEV2 has built-in NAT traversal capability, while IKEV1 is supported by the extended protocol;
- The IKEV2 can detect the tunnel survival state, while IKEV1 can only use DPD (Dead Peer Detection). DPD has become the standard built-in function in IKEv2. However, the Cisco IOS system by default this feature is disabled, can be configured under the IKEv2 configuration file;
- The IKEV2 has reliability detection and the message needs to be confirmed and sorted. And in the IKEV1 the message is not confirmed;
- IKEV2 anti-Dos attacks by blocking cookies. And the IKEV1 does not possess this characteristic;
- IKEV2 can configure multiple sets of selectors in one policy. Therefore, multiple networks can be negotiated during a switching process;
- IKEV2 allows two encryption engines to handle IPV4 and IPV6 traffic respectively;
- IKEV2 allows for asymmetric authentication, while IKEV1 is only symmetric; (i.e. the same authentication method is used between peers)
- IKEv2, like IKEv1, uses the UDP-500 port, where NAT is required, and the starting port number is UDP-4500.
In summary, IKEV2 has better compatibility (cross-platform, cross-vendor), and more new features (such as built-in NAT, anti-Dos attacks, and tunnel survivability detection, etc.).
IKEv1 and IKEv2 in Cisco VPN--IPSEC VPN