Understanding IKEv2 Protocol
Introduction
Ikev2 packet exchange
NAT-T Support
Password requirements
DOS Attack Protection
LifeTime requirements
Authentication Methods
Conclusion
Introduction
IKE version 2 (IKEv2) is defined in RFC 5996 and enhances the function of performing dynamic key exchange and peer authentication. IKEv2 simplifies the key exchange flows and introduces measures to fix vulnerabilities present in IKEv1. Both IKEv1 and IKEv2 protocols operate in two phases. IKEv2 provides a simpler and more efficient exchange.
IKEv2 Packet Exchange
Phase 1 in IKEv2 is IKE_SA, consisting of the message pair IKE_SA_INIT. IKE_SA is comparable to IKEv1 Phase 1. The attributes of the IKE_SA phase are defined in the Key Exchange Policy. Phase 2 in IKEv2 is CHILD_SA. The first CHILD_SA is the IKE_AUTH message pair. This phase is comparable to IKEv1 Phase 2. Additional CHILD_SA message pairs can be sent for rekey and informational messages. The CHILD_SA attributes are defined in the data policy.
Because IKEv2 is more secure than IKEv1, during the initial negotiation, IKEv2 will use less bandwidth than IKEv1. And the reason the security is stronger in IKEv2 is because IKEv1 peers will use the same encryption key, whereas IKEv2 peers can use different keys.
NAT-T Support
IKEv2 also has built‑in NAT traversal, whereas with IKEv1, you have to enable NAT‑T. There is increased encryption protocol support with IKEv2. And IKEv2 also checks to make sure tunnels are up and alive. If a tunnel is dropped, IKEv2 will attempt to reestablish the tunnel.
Password Requirements
IKEv2 offers increased reliability over IKEv1. So let's say, for example, we have a couple of routers connected to the internet. These are both IKEv2 endpoints. We can tell one endpoint to use the password 1234ABCD, and we can tell the other endpoint to use the password 5678EFGH, and it would be acceptable to both endpoints because IKEv2 allows this.
Dos Attack Protection
Because the message exchanges within IKEv2 are fewer than IKEv1 and cryptographically expensive key material is exchanged in the first two messages (SA_INIT), an attacker could cause a denial-of-service (DoS) condition on an IKEv1-enabled device by sending many SA_INIT requests with a spoofed source address. Subsequently, the gateway would generate key material and dedicate resources to connections that would not be established. The good news is that IKEv2 has the ability to use a stateless cookie. The use of this stateless cookie results in a zero state being assigned to an IKEv2 session if the VPN gateway is under attack.
Tunnel LifeTime Requirements
In IKEv1 implementations, the lifetime of the IKE Phase 1 security association (SA) is negotiated in the first pair of messages (MM1 and MM2). The lifetime configured on the responder must be equal to or less than the lifetime proposed by the initiator in order for Phase 1 to be established. This introduced incompatibilities among different vendors because IKEv1 sessions may not be able to be established if the IKEv1 lifetimes don’t match. In IKEv2, the lifetime is a locally configured value that is not negotiated between peers. This means that a device that is a participant of a VPN tunnel will delete or rekey a session when its local lifetime expires.
Authentication Methods
IKE also supports three authentication methods: pre-shared keys (PSK), digital signatures, and EAP. IKEv2 clients can authenticate via an already established standardized mechanism, in contrast to IKEv1 (since IKEv1 required non-standard extensions). EAP is a standard that allows the use of a number of different authentication methods to validate the identities of IPsec VPN peers. with EAP, basically means the clients would send a username and a password, and the server would then forward this request to RADIUS. The RADIUS server would then allow or deny access if the password is correct or incorrect. This is why it is used natively in IKEv2 implementations. IKEv1 and IKEv2 are incompatible protocols; subsequently, you cannot configure an IKEv1 device to establish a VPN tunnel with an IKEv2 device.
Conclusion
IPSec VPNs would normally use IKEv1. They can be configured with IKEv2, but typically it's IKEv1 that's used. however, IKEv1 can be cracked. In addition, IKEv1 can also be subject to a denial‑of‑service attack. Now, Cisco wanted to replace IPSec VPNs, but they also wanted to be more inclusive of other vendors, and this is where FlexVPNs come in. And FlexVPNs are a standards‑based VPN developed by Cisco. In fact, FlexVPNs only supports IKEv2.
References: OCG & Networklessions.com
................................................................................ Thank you very much..! ...........................................................................