IKEv1 vs IKEv2: Key Differences and Why Modern IPsec Networks Prefer IKEv2

Introduction

The IKE (Internet Key Exchange) protocol plays a crucial role in establishing IPsec gateways and tunnels. It negotiates security parameters and keys to provide Security Associations (SAs) for the ESP/AH protocols, thereby enabling encryption protection for IPsec tunnels.

On the Asterfusion Open Networking product line, the AsterNOS-VPP system supports the IKEv2 protocol and its mainstream algorithm suites for efficiently building secure IPsec tunnels.

This article will first introduce the basic principles and workflow of the IKE protocol. Then, it will detail the supported IKE configuration parameters on the Asterfusion platform and explain how these parameters are used to complete SA negotiation for securing tunnel traffic.

Ⅰ. What is IKE Protocol and Its Role in IPsec

In the process of establishing an IPsec tunnel, there are generally two stages. The first stage involves establishing the IKE SA, which completes identity authentication, negotiates security parameters, and determines security policies and keys to ensure the security of the second stage. The second stage is the establishment of the IPsec SA, which is the data tunnel used for encrypting the actual traffic.

In this process, the Internet Key Exchange (IKE) protocol primarily functions in the first stage. It is a control protocol specifically used for “negotiating security parameters and establishing keys.” IKE protocol provides Security Associations (SAs) and keys to protocols such as AH/ESP in the second stage, which are responsible for the actual encryption and decryption of data. Through Diffie-Hellman key exchange, identity authentication, and parameter negotiation, IKE protocol automatically establishes and manages the various SAs required for IPsec, eliminating the complexity and risks associated with manual key distribution and SA configuration.

In a typical IPsec VPN scenario, the two communication parties (security gateways or hosts) first use IKE to establish an IKE SA to protect subsequent control messages. Based on this IKE SA, one or more IPsec SAs (also called CHILD SAs) are negotiated. These SAs define the encryption algorithms, authentication algorithms, keys, and traffic selectors used by the IPsec tunnel to protect the real business traffic. IKE itself is responsible only for generating and managing keys and negotiating algorithms; it does not directly encrypt or decrypt business data. This task is handled by ESP/AH at the IP layer.

Ⅱ. What are IKEv1 and IKEv2 Protocol?

1. What is IKEv1 Protocol?

Defined in RFC 2409, IKEv1 is the earliest key management protocol widely deployed in IPsec. It is based on the ISAKMP framework and integrates the design principles of Oakley and SKEME. It uses a two-phase structure—Phase 1 and Phase 2—to achieve identity authentication and SA negotiation.

• Phase 1: Establishes an ISAKMP/IKE SA between the two ends using either Main Mode or Aggressive Mode, completing identity authentication and basic encryption parameter negotiation.
• Phase 2: Uses Quick Mode to negotiate one or more IPsec SAs on top of the existing IKE SA, which are used to carry ESP/AH traffic. Optionally, an additional DH exchange can be performed to achieve Perfect Forward Secrecy (PFS).

IKEv1 supports multiple authentication methods (pre-shared keys, digital signatures, public-key encryption), and it allows a wide range of encryption/authentication algorithms and DH group selections. However, the message exchange process is more complex, and IKEv1 has limited support for scenarios like NAT traversal and EAP authentication.

2. What is IKEv2 Protocol ?

IKEv2, defined in RFC 4306, is designed to replace IKEv1 and related ISAKMP/DOI documents (RFC 2407/2408/2409). It simplifies and unifies the protocol while providing better scalability. IKEv2 is explicitly designed to be incompatible with IKEv1, but both versions can share UDP ports (typically 500/4500).

The main improvements of IKEv2 over IKEv1 include:

• Merging Phase 1 and Phase 2 into four types of exchanges: IKE_SA_INIT, IKE_AUTH, CREATE_CHILD_SA, and INFORMATIONAL. This reduces the number of messages and simplifies the state machine.
• Built-in support for NAT Traversal, rekeying, EAP authentication, and configuration delivery (internal addresses, DNS, routing).
• Clearer mechanisms for algorithm negotiation and cryptographic suite, making it easier to introduce new algorithms.

In IKEv2, the first IKE_SA_INIT exchange is used to negotiate the IKE SA’s encryption algorithms, exchange DH values, and Nonces. The following IKE_AUTH exchange handles identity authentication and the negotiation of the first CHILD SA. Subsequent CREATE_CHILD_SA exchanges establish or re-negotiate additional CHILD SAs, while the INFORMATIONAL exchange is used for SA deletion, error notifications, and other control messages.

Ⅲ. IKE Protocol Negotiation Phases and Key Parameters

1. IKEv1 Phases and Modes

In IKEv1, the protocol logic is divided into two phases and several modes:

Phase 1: In Phase 1, the IKEv1 protocol has two modes: Main Mode and Aggressive Mode.

The main task of this phase is mutual authentication and the establishment of a bidirectional IKE SA, which is used to protect subsequent Phase 2 IKE Quick Mode exchanges (packets 1–3).

• Main Mode: A three-round trip (six messages), which sequentially completes policy negotiation, DH and Nonce exchange, and identity authentication, offering identity protection.

Messages 1–2: The first two messages are exchanged as a pair. The initiator sends a policy set to the responder, who then compares it with its own policies. If a match is found, the responder replies with the corresponding policy.

Messages 3–4: The next two messages exchange DH values to perform key exchange, generating the shared secret key.

Messages 5–6: The final two messages perform identity verification based on the parameters negotiated in IKE protocol messages 1–2.

• Aggressive Mode: A one-round trip (three messages) where algorithm negotiation, DH, and identity authentication are completed with fewer messages. It is faster but offers less identity protection and fewer negotiable attributes.

Phase 2: Only use Quick Mode: After the IKE SA is established, Phase 2 negotiates the actual IPsec SAs that will be used to protect data traffic. The encrypted/validated data is protected through the negotiated algorithms, SPIs (Security Parameter Index), and traffic selectors (TS), and an optional DH exchange can be conducted for Perfect Forward Secrecy (PFS).

In a typical IKEv1 negotiation, key parameters involved include:

• Encryption Algorithm: Algorithms like DES, 3DES, AES-CBC for protecting IKE messages and/or IPsec data flows.
• Hash/Integrity Algorithm: Algorithms like MD5, SHA-1, SHA-2 for generating hash values, HMAC, and providing message integrity and authentication.
• Authentication Method: Pre-shared keys, digital signatures (RSA/DSA), public-key encryption, etc.
• Diffie-Hellman Group (DH Group): Defines the security strength of the key exchange (e.g., MODP Group 1/2/5 or higher), and whether PFS is enabled in Phase 2.
• Nonce: Random values used to derive SKEYID, SKEYID_d/a/e or IKEv2’s SK_d/e/a, protecting against replay attacks.
• Identity (ID): Identifiers such as IP address, FQDN (Fully Qualified Domain Name), or User FQDN, used for identity binding during authentication.

Through the combination of these parameters, IKE protocol derives the key materials for IKE SA and IPsec SA, ensuring the confidentiality, integrity, and replay protection of the IPsec tunnel’s data.

2. IKEv2 Initial Exchange and CHILD SA

In IKEv2 protocol, the negotiation process is divided into two stages: Initial Exchange and Child SA Creation/Re-negotiation.

First Stage: The initial exchanges are carried out using IKE_SA_INIT and IKE_AUTH to establish the IKE SA. These exchanges are primarily used for identity authentication and setting up the foundation for secure communication.

• IKE_SA_INIT: Exchanges SA proposals, DH values (KE), Nonce (Ni/Nr), and negotiates the encryption algorithm, integrity algorithm, PRF, and DH group to be used in the IKE SA.
• IKE_AUTH: Under the protection of the IKE SA, this exchange carries identity (IDi/IDr), certificates (CERT), and authentication data (AUTH), while also negotiating the first CHILD SA (which includes ESP/AH algorithms, SPI, and traffic selectors).

Second Stage: The CREATE_CHILD_SA and INFORMATIONAL exchanges follow the establishment of the IKE SA. These are typically used to create or re-negotiate CHILD SAs and transfer additional control information.

• CREATE_CHILD_SA: This exchange is used to create or re-negotiate CHILD SAs. It may optionally perform another DH exchange to provide Perfect Forward Secrecy (PFS). The CHILD SA is the actual secure tunnel used for encrypting and protecting IP packets in IPsec, specifically for the ESP (Encapsulating Security Payload) or AH (Authentication Header) protocols.
• INFORMATIONAL: This exchange is used for deleting SAs, notifying errors, or performing keepalive checks (empty messages) for control operations.

The core parameters in IKEv2 are similar to IKEv1, but they are organized using a “cryptographic suite + traffic selector” approach. This makes it easier to express and negotiate multiple algorithm combinations and traffic ranges in a unified manner.

Ⅳ. IKEv1 vs IKEv2: Key Differences

Although both IKEv1 and IKEv2 are designed to establish and manage SAs, IKEv2 introduces a simplified architecture and several enhancements that make it the preferred choice in modern networks.

Feature	IKEv1	IKEv2
RFC	RFC 2409	RFC 4306 and later updates
Negotiation Model	Two-phase architecture (Phase 1 + Phase 2)	Unified exchange-based architecture
Initial SA Establishment	Main Mode or Aggressive Mode	IKE_SA_INIT + IKE_AUTH
IPsec SA Creation	Quick Mode	CREATE_CHILD_SA
SA Architecture	IKE SA and IPsec SA negotiated separately	CHILD SAs managed under a single IKE SA
Configuration Delivery	Vendor-specific extensions	Built-in support
Message Exchanges	More messages and states	Fewer messages and simplified state machine
Cryptographic Suite Negotiation	Less flexible	More extensible and standardized

As shown in the table above, IKEv2 introduces a simplified and more extensible architecture compared to IKEv1. By replacing the traditional Phase 1 and Phase 2 negotiation model with a unified exchange framework, IKEv2 reduces protocol complexity and improves scalability. These enhancements make IKEv2 better suited for modern IPsec VPN deployments and the foundation for most current VPN solutions.

Ⅴ. Why Most Modern Networks Prefer IKEv2

Modern networks increasingly prefer IKEv2 because it is faster, more stable, and more secure than IKEv1, and is particularly well-suited for mobile devices and complex network environments.

Faster setup and better performance: IKEv2 uses a simpler exchange process, typically requiring only 4 messages to establish IKE SA and IPsec SA, compared to 6–9 in IKEv1. It also supports NAT-T natively, making it faster and more reliable in NAT and firewall environments.

Mobile-friendly with MOBIKE: IKEv2 supports MOBIKE, allowing VPN sessions to survive IP changes when switching between Wi-Fi and 4G/5G. It can automatically restore connections without manual re-authentication, making it ideal for mobile and remote work scenarios.

Stronger security: It supports modern encryption algorithms (e.g., AES, ChaCha20) and integrates with EAP and certificate-based authentication, improving flexibility and protection against MITM attacks. It also fixes several security weaknesses in IKEv1.

Better reliability and auto-recovery: IKEv2 can automatically re-establish VPN sessions after interruptions, reducing the need for manual reconnection and improving user experience in unstable networks.

Lower overhead and better scalability: Fewer messages and optimized SA handling reduce bandwidth usage and improve scalability, making it more suitable for large-scale deployments such as site-to-site VPNs and cloud environments.

Ⅵ. How AsterNOS-VPP Accelerates IPsec

Traditional IPsec gateways in high-bandwidth scenarios are primarily constrained by their CPU processing model: both IKE negotiation and ESP encryption/decryption rely on general-purpose CPUs. Under 10G/25G and higher traffic rates, this leads to substantial interrupt overhead and context-switching costs, resulting in reduced encryption throughput and increased latency jitter. At the same time, the control plane (e.g., routing protocols and IKE keepalive) may also be resource-starved, impacting overall system stability.

To address this issue, AsterNOS-VPP introduces a three-layer decoupled architecture:

The Control Plane (SONiC) is responsible for IKE, SA management, and configuration provisioning.

Data Plane A (VPP software acceleration) is based on Vector Packet Processing. It performs ESP encapsulation and decryption in user space using batch processing, avoiding the performance penalties of per-packet Linux kernel processing.

Data Plane B (hardware offload) leverages a DPDK crypto engine to offload AES and integrity computations to hardware, enabling zero-copy encryption/decryption to support line-rate forwarding.

Through the coordination of these three layers, AsterNOS maintains an open SONiC-based control plane while delivering a hierarchical acceleration architecture that spans software and hardware for high-performance IPsec processing.

All relevant configurations are made under the ipsec <name> view. The Enterprise SONiC AsterNOS-VPP provides comprehensive IKE parameter configuration capabilities, including:

1. IKE Protocol Negotiation Parameters (Corresponding to IKE_SA)

• crypto_alg: Encryption algorithms, supporting aes-cbc, aes-ctr, aes-gcm-16, 3des, blowfish, etc.
• integ_alg: Authentication algorithms, supporting AES derivatives, SHA-2, SHA-1, etc.
• dh: DH algorithms, supporting modp-768, modp-1024, modp-1536, etc.
• ike local/remote type: Configures ID type and ID value for local and remote users, corresponding to IDi and IDr in IKEv2 messages (identity identifiers).

2. SA Parameters (Corresponding to CHILD_SA)

• sa: Configures encryption algorithms, supporting aes-cbc, aes-ctr, aes-gcm-16, AES-GCM (128/192/256), etc.
• crypto_alg_size: Key lengths, range 0-65535.
• integ_alg: Authentication algorithms, supporting hmac-sha2-256-128 and other SHA-2 options, aes-128/192/256-gmac for AES-related authentication.

3. Traffic Selector

Through the following two configurations, Traffic Selectors (TSi and TSr) are defined, as referenced on pages 7-8 of RFC 4306. These specify which traffic is encrypted:

• ike traffic_selector local ip4 addr_start x.x.x.x addr_end x.x.x.x
• ike traffic_selector remote ip4 addr_start x.x.x.x addr_end x.x.x.x

For example, if you configure the following settings on the device:

• ike traffic_selector local ip4 addr_start 10.1.1.0 addr_end 10.1.1.255
• ike traffic_selector remote ip4 addr_start 10.1.2.0 addr_end 10.1.2.255

These settings ensure that only traffic from 10.1.1.0/24 to 10.1.2.0/24 will be routed through the encrypted tunnel, while other traffic will be forwarded normally.

For more deployment scenarios, please visit our IPSec Gateway Configuration Case, which covers site-to-site VPNs, Hub-and-Spoke VPNs, and NAT-T traversal.

Conclusion: Optimizing IPsec with IKEv2 Protocol and Hardware Acceleration on AsterNOS

On the AsterNOS platform, a database-driven control plane is employed, while the negotiation process of IKEv2 protocol still relies on the traditional general-purpose CPU. It handles complex identity authentication and key exchange logic. Once the negotiation is complete, the generated Security Association (SA) is pushed to the data plane.

In the AsterNOS-VPP architecture, vectorized software acceleration via VPP is typically used for ESP encryption and decryption in standard scenarios. However, in extreme cases, VPP can communicate directly with underlying hardware acceleration units (Crypto VF) via the DPDK Cryptodev interface, eliminating repeated memory copying and directly sending the data to physical interfaces.

With IKEv2, AsterNOS provides more efficient and stable performance, natively supporting EAP authentication and NAT traversal capabilities. Combined with DPDK VPP hardware acceleration, this enables Asterfusion platforms to break the traditional 10G/25G IPsec bottleneck, significantly enhancing IPsec capabilities.

FAQ

1. What is the difference between IKE SA and IPsec SA?

IKE SA is used to protect the IKE signaling channel. It secures control-plane communication, including authentication, key exchange, and SA management.

IPsec SA is used to protect user data traffic. It defines how ESP/AH processes packets, including encryption, integrity, and traffic selectors.

2. Is IKEv2 more secure than IKEv1?

IKEv2 is considered more secure due to protocol-level improvements rather than only cryptographic differences. Security also depends on the chosen cryptographic algorithms, but IKEv2 provides a more modern and secure protocol framework.

3. Does IKEv2 support NAT traversal?

Yes.

IKEv2 supports NAT traversal natively using UDP encapsulation (NAT-T).
When NAT is detected, ESP packets are encapsulated in UDP (typically port 4500) to allow traversal through NAT devices.

4. What is a CHILD SA?

A CHILD SA is a security association negotiated under an IKE SA in IKEv2.

It is responsible for protecting actual IPsec traffic using ESP or AH.

A CHILD SA defines:

• Encryption and integrity algorithms
• SPI (Security Parameter Index)
• Traffic selectors (which traffic is protected)
• Lifetime and rekey parameters

In practice, a CHILD SA represents the active IPsec protection state for data traffic.

5. Can I use IKEv2 with SD-WAN?

Yes.

IKEv2 is widely used in SD-WAN, SASE, and site-to-site VPN architectures.

It is preferred because it supports:

• Fast rekey and recovery
• Mobility and multi-homing (e.g., MOBIKE extension)
• Dynamic tunnel establishment in cloud and edge environments
• Stable operation in frequently changing network conditions

6. How is IPsec acceleration implemented?

IPsec acceleration is achieved by AsterNOS-VPP in following aspects:

• Separating control plane (SONiC) from data forwarding
• Using VPP for user-space software packet acceleration
• Leveraging hardware crypto offload via DPDK

➡️ This hybrid design enables scalable, line-rate IPsec performance on high-bandwidth networks while maintaining an open and programmable control plane.

Contact US !

• To request a proposal, send an E-Mail to bd@cloudswit.ch
• To receive timely and relevant information from Asterfusion, sign up at AsterNOS Community Portal
• To submit a case, visit Support Portal
• To find user manuals for a specific command or scenario, access AsterNOS Documentation
• To find a product or product family, visit Asterfusion-cloudswit.ch