Securing IPsec Tunnels via IKE Protocol on AsterNOS-VPP

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 ?

1. What is IKEv1 ?

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 ?

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.

Ⅳ. Asterfusion Platform Support for IKE Protocol

On the Asterfusion platform, IKE v2 protocol is the default for establishing IPsec tunnels. The supported parameters are as follows:

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.

Conclusion: Optimizing IPsec with IKEv2 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.

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