IKE Properties

– Negotiate SA attributes, determine transforms, hashing and more
– Generate and refresh keys using DH
– Authenticate peer devices using attributes like IP, FQDN, LDAP DN and more
– It has two phases IKE v1 (Phase 1 and 2) IKE v2 (Init and Auth)
– Main mode & aggressive mode
– ISAKMP negotiates SA for IPSEC. Quick mode & sdoi mode

 

IKE v2 Advantages
– Simplifies the existing IKEv1
– Single RFC, including NAT-T, EAP and remote address acquisition
– Replaces the 8 initial exchanges with a single 4 message exchange
– Reduces the latency for the IPSEC SA setup and increases connection establishment speed.
– Increases robustness against DOS attack.
– Improves reliability through the use of sequence numbers, acknowledgements, and error correction.
– Forward Compatibility
– Simple cryptographic mechanisms
– Traffic selector negotiation:
– IKEv1: Responder can just say yes/no. IKEv2: Negotiation ability added
– Reliability
– All messages are request/response.
– Initiator is responsible for retransmission if it doesn’t receive a response.

 

IKE v1 IKE v2
Developed in 1998, based on RFC 4995 Developed in 2006, based on RFC 5996
Pre-shared key and certificate for authentication Pre-shared key, certificate and EAP variants. Supports  for asymmetric authentication. Side A Preshared Key and Side B Certificates.
No reliability Reliable. Introduces retransmission and acknowledgement functions. ack and sequenced
Phase 1 generates 6 messages (main mode) 3 messages (aggressive mode) Reduced bandwidth requirements. generates only 4 messages at all. When EAP is used in IKEv2, an additional 2 messages may be required.
Negotiation of the first CHILD_SA required 3 messages. Subsequent CHILD_SAs require 3 messages Negotiation of the first CHILD_SA required no messages since it is piggybacked onto the negotiation of the IKE_SA. Subsequent CHILD_SAs require 2 messages
No NAT traversal (NAT-T) Incorporation of NAT traversal built-in. Supports NAT traversal using UDP port 4500.
No liveness check Liveness check to detect whether the tunnel is still alive or not.
Security Association lifetimes are explicitly negotiated Security Association lifetimes are not explicitly negotiated. Each peer maintains its own local policy for Security Association lifetime. When the lifetime is about to expire, a rekeying operation is initiated.
MOBIKE not available. Introduces MOBIKE. MOBIKE allows IKEv2 to be used in mobile platforms like phones and by users with multi-homed setups.

 

Both protocols run over UDP port 500.
Both protocols provide identify protection, denial-of-service protection mechanism, and perfect forward secrecy.
Both protocols utilize two phases. The first phase in each is used to create the IKE_SA. The second phase is used to establish child SAs using the IKE_SA. In IKEv2, the first child SA is piggybacked on the IKE_AUTH exchange that is used to complete the mutual peer authentication.