IKEv1 vs IKEv2

Evolution of IKE

Internet Key Exchange (IKE) has evolved from version 1 to version 2, with significant improvements in security, efficiency, and reliability. Understanding both versions is crucial for IPsec implementation.

Protocol Comparison Overview

Feature IKEv1 IKEv2 Advantage
RFC Standard RFC 2409 RFC 7296 IKEv2 (updated)
Message Exchanges 6+ messages 4 messages IKEv2
NAT Traversal Extension (RFC 3947) Built-in IKEv2
MOBIKE Support No Yes IKEv2
DoS Protection Limited Cookie mechanism IKEv2
Error Handling Basic Comprehensive IKEv2
EAP Support XAUTH extension Native EAP IKEv2
Legacy Support Widespread Modern devices IKEv1

IKEv1 Modes

Main Mode

  • Messages: 6 exchanges
  • Identity Protection: Yes
  • DH Exchange: Phase 1
  • Use Case: Pre-shared keys
  • Security: Higher

Aggressive Mode

  • Messages: 3 exchanges
  • Identity Protection: No
  • DH Exchange: Phase 1
  • Use Case: Dynamic IP
  • Security: Lower

IKEv2 Advantages

Efficiency
Improved

Messages: 4 vs 6+

Bandwidth: Lower overhead

Setup Time: Faster

Security
Enhanced

DoS Protection: Cookie mechanism

Cryptography: Modern algorithms

Authentication: Multiple methods

Reliability
Better

Error Handling: Comprehensive

Keep-alive: Dead peer detection

Recovery: Automatic rekey

Features
Advanced

MOBIKE: IP mobility

EAP: Extensible auth

NAT-T: Built-in support

Recommendation

Use IKEv2 for new deployments - It offers significant improvements in security, efficiency, and features. Only use IKEv1 when required for legacy device compatibility.

Next: Phase 1 Negotiation

Phase 1 Negotiation

Secure Channel Establishment

Phase 1 establishes a secure, authenticated channel between IKE peers. This channel is then used to negotiate IPsec Security Associations in Phase 2.

Phase 1 Objectives

Primary Goals

  • Authenticate Peers: Verify identity of remote endpoint
  • Establish Shared Keys: Generate encryption and authentication keys
  • Agree on Security Parameters: Negotiate encryption and hash algorithms
  • Create Secure Channel: Protect subsequent IKE communications

Security Services

  • Confidentiality: Encrypt IKE messages
  • Authentication: Verify message origin
  • Integrity: Detect message tampering
  • Anti-replay: Prevent replay attacks

IKEv1 Phase 1 Process

Main Mode (6 Messages)
Initiator
→
Responder
Message 1-2: Security Association proposals
Message 3-4: Diffie-Hellman exchange + nonces
Message 5-6: Identity + authentication (encrypted)

IKEv2 Initial Exchange

Streamlined Process (4 Messages)
IKE_SA_INIT: SA proposals + DH exchange + nonces
IKE_AUTH: Identity, authentication + first Child SA

Authentication Methods

Method IKEv1 IKEv2 Security Level Scalability
Pre-Shared Key (PSK) Medium Poor
RSA Signatures High Excellent
DSA Signatures High Excellent
ECDSA Signatures High Excellent
EAP XAUTH extension Variable Good

Phase 1 Security Parameters

Example IKEv2 Policy

# Cisco ASA IKEv2 Policy
crypto ikev2 policy 10
 encryption aes-256 aes-192 aes
 integrity sha256 sha
 group 16 14 2
 prf sha256 sha
 lifetime seconds 86400

# Key components:
# - Encryption: AES-256, AES-192, AES-128
# - Integrity: SHA-256, SHA-1
# - DH Groups: 16 (4096-bit), 14 (2048-bit), 2 (1024-bit)
# - PRF: SHA-256, SHA-1
# - Lifetime: 24 hours
Previous: IKEv1 vs IKEv2 Next: Phase 2 Negotiation

Phase 2 Negotiation

IPsec SA Creation

Phase 2 uses the secure channel established in Phase 1 to negotiate IPsec Security Associations that will protect the actual data traffic.

Phase 2 Objectives

  • Negotiate IPsec Parameters: Encryption and authentication algorithms for data
  • Define Traffic Selectors: What traffic should be protected
  • Generate Keys: Derive encryption and authentication keys for IPsec
  • Establish SAs: Create inbound and outbound Security Associations
  • Enable PFS: Optionally generate fresh key material

IKEv1 Quick Mode

Quick Mode Process (3 Messages)
Message 1: IPsec SA proposal + optional DH + traffic selectors
Message 2: IPsec SA acceptance + optional DH
Message 3: Confirmation and SA activation

IKEv2 CREATE_CHILD_SA

Child SA Creation (2 Messages)
CREATE_CHILD_SA Request: IPsec proposals + optional DH + traffic selectors
CREATE_CHILD_SA Response: Accepted proposal + optional DH + traffic selectors

Perfect Forward Secrecy (PFS)

With PFS

  • Security: Each SA uses unique key material
  • Protection: Compromise doesn't affect other SAs
  • Forward Secrecy: Past sessions remain secure
  • Cost: Additional DH exchange overhead

Without PFS

  • Performance: Faster SA establishment
  • Key Derivation: From Phase 1 key material
  • Risk: Phase 1 compromise affects all SAs
  • Resources: Lower CPU usage

Traffic Selectors

Traffic selectors define which packets should be protected by IPsec. They specify source and destination addresses, ports, and protocols.

Selector Type Description Example Use Case
IP Address Source and destination IP ranges 192.168.1.0/24 ⟷ 10.0.1.0/24 Site-to-site VPN
Protocol IP protocol number TCP (6), UDP (17), ICMP (1) Selective protection
Port Range TCP/UDP port numbers Port 80 (HTTP), Port 443 (HTTPS) Application-specific
Wildcard All traffic (0.0.0.0/0) Any ⟷ Any Remote access VPN

IPsec Transform Sets

ESP Transform Examples

# Cisco ASA IPsec Proposal
crypto ipsec ikev2 ipsec-proposal ESP-AES-256-SHA256
 protocol esp encryption aes-256
 protocol esp integrity sha-256

crypto ipsec ikev2 ipsec-proposal ESP-AES-128-GCM
 protocol esp encryption aes-gcm-128
 protocol esp integrity null

# Transform components:
# - Encryption: AES-256-CBC, AES-128-GCM
# - Authentication: SHA-256 HMAC, null (for AEAD)
# - Mode: Tunnel or Transport
# - Lifetime: Time and/or data-based
Previous: Phase 1 Negotiation Next: Diffie-Hellman Groups

Diffie-Hellman Groups

Key Exchange Foundation

Diffie-Hellman (DH) groups define the mathematical parameters used for secure key exchange. The choice of DH group affects both security strength and performance.

DH Group Categories

MODP Groups
Traditional

Type: Modular Exponentiation

Groups: 1, 2, 5, 14, 15, 16

Performance: Moderate

Key Sizes: 768-4096 bits

ECP Groups
Modern

Type: Elliptic Curve

Groups: 19, 20, 21, 25, 26

Performance: Excellent

Key Sizes: 256-521 bits

Common DH Groups

Group Name Type Key Size Security Level Status
1 MODP 768 MODP 768 bits Broken Deprecated
2 MODP 1024 MODP 1024 bits Weak Legacy only
5 MODP 1536 MODP 1536 bits Weak Legacy only
14 MODP 2048 MODP 2048 bits Good Recommended
16 MODP 4096 MODP 4096 bits High Recommended
19 ECP 256 ECDH 256 bits High Preferred
20 ECP 384 ECDH 384 bits Very High Preferred
21 ECP 521 ECDH 521 bits Very High Preferred

Security Strength Comparison

DH Group Equivalent AES Key Security Level Performance
Group 14 (MODP 2048) AES-112 112-bit Moderate
Group 16 (MODP 4096) AES-128 128-bit Slow
Group 19 (ECP 256) AES-128 128-bit Fast
Group 20 (ECP 384) AES-192 192-bit Fast
Group 21 (ECP 521) AES-256 256-bit Fast

DH Group Selection Guidelines

Best Practices

  • Modern Deployments: Use ECP groups (19, 20, 21) for best performance and security
  • Legacy Compatibility: Group 14 (MODP 2048) for older device support
  • High Security: Group 20 (ECP 384) or Group 21 (ECP 521) for sensitive environments
  • Avoid: Groups 1, 2, and 5 due to security vulnerabilities
  • Match Strength: Align DH group security with encryption algorithm strength

DH Group Configuration Example

# Cisco ASA DH Group Configuration
crypto ikev2 policy 10
 encryption aes-256
 integrity sha256
 group 20 19 14    # Prefer ECP 384, then ECP 256, then MODP 2048
 prf sha256

# Order matters - first group is preferred
# Multiple groups provide compatibility options
# Group 20 (ECP 384) offers excellent security and performance
Previous: Phase 2 Negotiation Next: Chapter 5 - IPsec Configuration