Internet Key Exchange Protocol Version 2 (IKEv2) Support for Per-Resource Child Security Associations (SAs)
Extracted elements (24)
Aggregate IPsec throughput can scale dramatically with per-resource Child SAs: the document cites an example of throughput increasing from 5 Gbps on 1 CPU to 40–60 Gbps on 25–30 CPUs, whereas a single AES-GCM-encrypted 10 Gbps link is typically reduced to 2–5 Gbps without this mechanism.
IPsec implementations are limited to one hardware queue or CPU per Child SA because sharing cryptographic state, counters, and sequence numbers among multiple CPUs incurs significant performance penalties. By negotiating multiple Child SAs with identical Traffic Selectors, each resource gets its own Sequence Number Counter, eliminating synchronization overhead and enabling parallel packet encryption.
Populate From Packet (PFP) from RFC 4301 was considered as an alternative but rejected: it causes either too many Child SAs (one per network flow) or too few (one flow across multiple CPUs), and it is not widely implemented. Per-resource Child SAs with identical Traffic Selectors are a cleaner solution.
An implementation lacking per-CPU packet trigger support MAY initiate all its Child SAs immediately upon receiving the single trigger message, but must handle the Delete Notify for a per-CPU Child SA carefully to avoid an infinite bring-up loop or a stall where both peers end up with only the first Child SA.
IKEv2 (RFC 7296) already permits multiple Child SAs with identical Traffic Selectors, but provides no way to signal that they are resource-bound. This document adds that signaling capability as an extension, leaving existing IKEv2 behavior unchanged for peers that do not include SA_RESOURCE_INFO.
When the number of CPU/queue resources differs between peers, the peer with fewer resources may skip installing a duplicate outbound Child SA but MUST install all inbound Child SAs it has committed to receiving traffic on.
An implementation that does not accept any further resource-specific Child SAs MUST NOT return the NO_ADDITIONAL_SAS error, as that would incorrectly imply that no other Child SAs with different TSi/TSr are possible. It MUST return TS_MAX_QUEUE instead.
Implementations supporting per-CPU SAs SHOULD extend their local SPD selector and on-demand negotiation triggers to include a CPU or queue identifier in packet trigger (e.g., SADB_ACQUIRE) messages. Implementing per-CPU packet trigger messages is RECOMMENDED.
In the SA_RESOURCE_INFO payload, the Critical flag MUST be 0, Protocol ID MUST be 0 (and MUST be ignored if not 0), and SPI Size MUST be 0 (and MUST be ignored if not 0).
In the TS_MAX_QUEUE payload, the Critical flag MUST be 0, Protocol ID MUST be 0 (and MUST be ignored if not 0), and SPI Size MUST be 0 (and MUST be ignored if not 0).
Peers SHOULD be flexible with the maximum number of Child SAs allowed per TSi/TSr combination to handle rekeying overlap and simultaneous on-demand negotiations. Allowing at least double the number of available CPUs is RECOMMENDED.
Resource-specific Child SAs MUST be negotiated with identical Child SA properties as the initial Child SA, including cryptographic algorithms, Traffic Selectors, Mode (e.g., transport mode), and compression usage. Each Child SA does have its own individually derived keying material.
The SA_RESOURCE_INFO identifying data SHOULD be a unique identifier within all Child SAs sharing the same TS payloads, and the peer MUST only use it for debugging purposes.
When an IPsec endpoint is the same host responsible for generating traffic (not a gateway), the inbound and outbound per-CPU SAs SHOULD remain as a pair on the same CPU to preserve symmetric association.
When rekeying a Child SA, SA_RESOURCE_INFO MAY be included, but regardless, the rekeyed Child SA should be bound to the same resource(s) as the Child SA being rekeyed. Rekeying SHOULD use the same or wider Traffic Selectors.
SA_RESOURCE_INFO is a new IKEv2 Notify Message Status Type (value 16444) that signals the initiator's intent to negotiate a logical group of Child SAs bound to specific resources (e.g., CPUs) sharing the same Traffic Selectors. A responder willing to support this also echoes the notify, optionally with a non-zero Notification Data identifying its own resource.
TS_MAX_QUEUE is a new IKEv2 Notify Message Error Type (value 48) that a responder sends when it is unwilling to create more additional Child SAs for a particular Traffic Selector combination. It carries no data and is distinct from NO_ADDITIONAL_SAS to avoid signaling that no Child SAs with different TSi/TSr are possible.
IANA registered SA_RESOURCE_INFO (value 16444) in the 'IKEv2 Notify Message Status Types' registry, referencing RFC 9611.
IANA registered TS_MAX_QUEUE (value 48) in the 'IKEv2 Notify Message Error Types' registry, referencing RFC 9611.
It is RECOMMENDED that implementations limit the maximum number of additional Child SAs allowed per unique TSi/TSr pair to mitigate denial-of-service attacks, analogous to how implementations limit half-open SAs.
Per-CPU Child SAs are NOT RECOMMENDED for remote access VPN deployments where the trust relationship between administrator peers is typically absent, and allowing them is NOT RECOMMENDED by default.
The optional Resource Identifier in SA_RESOURCE_INFO SHOULD NOT be an identifier that reveals hardware information (e.g., raw CPU number), as it could allow an attacker to deduce which CPU handles which packets and optimize brute-force attacks against the system.
SA_RESOURCE_INFO payload: Next Payload (1 octet), C|RESERVED (1 octet, C MUST be 0), Payload Length (2 octets), Protocol ID (1 octet, MUST be 0), SPI Size (1 octet, MUST be 0), Notify Message Type (2 octets, value 16444), followed by an optional variable-length opaque Resource Identifier field.
TS_MAX_QUEUE payload: Next Payload (1 octet), C|RESERVED (1 octet, C MUST be 0), Payload Length (2 octets), Protocol ID (1 octet, MUST be 0), SPI Size (1 octet, MUST be 0), Notify Message Error Type (2 octets, value 48). There is no data associated with this Notify type.