IKEv1 vs IKEv2
IKE Versions and VPN Negotiations
Internet Key Exchange (IKE) is a protocol used to establish secure communication channels between devices for Virtual Private Network (VPN) connections. There are two main versions of IKE: IKEv1 and IKEv2.
IKEv1 Negotiations
IKEv1 negotiations occur in two phases:
Phase 1:
- Establishes a secure authenticated communication channel between the VPN peers.
- Supports two modes: Main Mode and Aggressive Mode.
Main Mode:
- Involves 6 messages exchanged in 3 round trips.
- Provides identity protection by exchanging identities after establishing encryption.
- Suitable for site-to-site VPNs with static IP addresses.
Aggressive Mode:
- Involves 3 messages in 2 round trips.
- Faster but less secure as identities are exchanged before encryption.
- Suitable for remote access VPNs with dynamic IP addresses.
Phase 2:
- Negotiates IPsec Security Associations (SAs) for data transmission over the VPN tunnel.
- Agrees on encryption, authentication algorithms, and key lifetimes.[2]
IKEv2 Negotiations
IKEv2 streamlines the negotiation process by combining aspects of Phase 1 and Phase 2 from IKEv1:
- No separate modes like Main Mode or Aggressive Mode.
- Combines IKE SA and initial IPsec SA negotiation into a single exchange.
- Provides identity protection while minimizing round trips.[4]
- NAT Traversal and Dead Peer Detection are always enabled.[2]
Use of IKE with VPNs
IKE is an essential component of IPsec VPNs, providing the following functions:
- Authenticates VPN peers through pre-shared keys or digital certificates.
- Negotiates cryptographic algorithms and keys for data encryption and authentication.
- Establishes secure communication channels (IKE SAs) for exchanging IPsec parameters.
- Manages the lifecycle of IPsec SAs, including rekeying and expiration.[1][2][3]
By using IKE, VPN devices can securely negotiate parameters and establish encrypted tunnels for transmitting data over untrusted networks.[5]
IKEv1 Message Exchanges
Phase 1 (Main Mode):
- Initiator sends a proposal with supported algorithms and Diffie-Hellman public value.
- Responder sends its proposal and Diffie-Hellman public value.
- Initiator sends its ID (IP address or domain name).
- Responder sends its ID and a hash of previously exchanged values.
- Initiator sends a hash of previously exchanged values for authentication.
- Responder sends an acknowledgment to complete Phase 1.
IKEv1 (Aggressive Mode):
- Initiator sends proposals, D-H value, nonce, and ID
- Responder sends selected proposal, D-H value, nonce, ID, and auth data
- Initiator sends auth data
Phase 2 (Quick Mode):
- Initiator sends a proposal for IPsec SA parameters.
- Responder sends its IPsec SA proposal.
- Initiator sends a hash of negotiated parameters.
- Responder sends an acknowledgment to complete Phase 2.
IKEv2 Message Exchanges
- Initiator sends IKE_SA_INIT request with proposals for IKE SA.
- Responder sends IKE_SA_INIT response with chosen proposal.
- Initiator sends IKE_AUTH request with identity and authentication data.
- Responder sends IKE_AUTH response with identity and authentication.
After this initial exchange, further messages like CREATE_CHILD_SA are used to negotiate IPsec SAs and exchange additional data.
The key differences are that IKEv2 combines the two phases into fewer exchanges, provides identity protection by default, and supports features like NAT traversal and Dead Peer Detection out of the box.
Citations:
[1] https://community.meraki.com/t5/Security-SD-WAN/IKE-Negotiation-Phase-does-not-start-for-Site-to-Site-VPN-with/m-p/148590
[2] https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/mvpn/general/ipsec_vpn_negotiations_c.html
[3] https://community.juniper.net/discussion/negotiations-errors-on-vpn-tunnel-need-help
[4] https://crypto.stackexchange.com/questions/15601/does-ikev2-protocol-have-two-modes-like-ike
[5] https://live.paloaltonetworks.com/t5/general-topics/ike-sa-negotiation-is-started-as-initiator-non-rekey/td-p/406276