Summary

  • RFC 9611 lets IKEv2 peers negotiate several Child SAs with identical Traffic Selectors so separate CPUs or queues can own independent keys and sequence counters. Matching policy is the point; shared cryptographic state is not.
  • SA_RESOURCE_INFO identifies logical group membership and may carry opaque debugging data. It is not an interoperable CPU map, scheduling command or proof that packets use the named resource. TS_MAX_QUEUE refuses more SAs for one selector pair without banning other selector combinations.
  • A credible capacity claim needs receipts after negotiation: inbound and outbound installation, local resource binding, trigger and scheduler behavior, packet distribution, replay/drop counters, rekey and delete handling, and measured delivered throughput.

The dashboard looks symmetrical. Both gateways show the same selector pair. Several Child SAs have completed. Every negotiation is green. One might conclude that encryption is now spread across several CPUs at both ends.

That conclusion is larger than the evidence. One peer may have installed every inbound SA because it promised to receive traffic on them, while omitting duplicate outbound halves that its smaller hardware will never use. The other may have created several SAs but still steer nearly every packet to the first one. A third implementation may lose a resource-specific SA after a Delete Notify and never recreate it because its packet triggers carry no CPU identity. The protocol state can be valid while the capacity plane remains asymmetric.

RFC 9611 exists because one Child SA can become a scaling boundary. Encryption resources need sequence numbers, keys and anti-replay state. If many CPUs share one outbound sequence counter, locking and synchronization can erase the throughput gained from parallel execution. Disabling replay protection would remove the symptom by weakening the security property. The RFC instead allows multiple Child SAs with identical Traffic Selectors, each with independently derived keying material and its own sequence space.

The design is narrow and useful. It standardizes enough language for peers to agree that several SAs belong to one logical selector group and to refuse excess members precisely. It does not pretend that one peer can operate the other peer's scheduler.

Identical selectors describe coverage, not execution

IKEv2 already allowed multiple Child SAs with identical selectors. What it lacked was a way to say why another apparently redundant SA was being requested. SA_RESOURCE_INFO supplies that signal. The initiator includes it while negotiating the initial or an additional Child SA; a willing responder echoes the notification. Later members are established through ordinary CREATE_CHILD_SA exchanges.

Every member must preserve the negotiated Child-SA properties of the first member: algorithms, TSi and TSr, transport or tunnel mode, compression behavior and the rest of the policy envelope. This sameness prevents a resource group from quietly changing the traffic or security contract. It does not collapse the members into one cryptographic object. Each still receives its own keying material, SPI and sequence state.

That distinction is the architecture. The common layer specifies which traffic may use the group. The local layer chooses which CPU, queue or accelerator owns a member and which packets reach it. A peer can verify the former through negotiation. It cannot infer the latter from selector equality.

The optional Resource Identifier makes this boundary clearer, not weaker. The data should be unique among SAs with the same selectors, but the peer must use it only for debugging. A literal CPU number would reveal hardware information and may help an attacker correlate traffic with a resource. More importantly, the identifier has no portable semantics. queue-7 at one endpoint does not authorize, select or name any resource at the other.

Independent counters are the performance mechanism

ESP sequence numbers are not decorative telemetry. They support anti-replay processing, and outbound assignment must be coherent. On a busy multicore gateway, serializing many workers around one counter can become the bottleneck. RFC 9611's parallelism comes from creating several valid cryptographic domains instead of pretending one mutable domain has no coordination cost.

That produces a precise claim: a resource-specific Child SA can keep its own sequence counter and keys. It does not produce a throughput promise. The RFC reports a contemporary example in which aggregate throughput rose from roughly 5 Gbps on one CPU to 40–60 Gbps on 25–30 CPUs. That observation explains the motivation. It is not a benchmark certificate for another processor, cipher implementation, packet size, NIC, topology or traffic mix.

A test must therefore record more than aggregate bandwidth. It should show packet counts per inbound and outbound SA, the spread across local resources, replay-window and integrity failures, drops during creation or rekey, CPU and accelerator saturation, and application-visible delivery. A total can rise while one member starves, one direction remains serialized or reordering moves pressure into the anti-replay window.

Inbound and outbound commitments are not mirror images

Different resource counts make apparent symmetry unsafe. A smaller peer may decide not to install a second outbound SA for a resource it will never use. It must still install every negotiated inbound SA, because the remote peer is entitled to transmit on each of them. The accepted exchange therefore creates a receive obligation even when it creates no corresponding local transmit demand.

This is why an SA count is an especially poor capacity metric. The same negotiated inventory can represent paired inbound/outbound resources on one host, all inbound plus a smaller outbound set on another, or independently moved halves on a gateway with asymmetric traffic. On an endpoint that generates the protected traffic, the two directions should normally stay paired on the same CPU. A gateway may move them independently.

Moving an SA later has another hidden cost. If the implementation had skipped an unused outbound half, the move may require creating that SAD entry and recovering key material the IKE daemon would otherwise have destroyed. Local key-retention policy becomes part of resource mobility. The peer-visible Resource Identifier says nothing about whether that evidence or capability exists.

Demand creation can race with itself

RFC 9611 allows eager creation of all resource-specific SAs or creation on demand. During the roughly one-round-trip negotiation, a generic SA usable by all CPUs can carry traffic. A packet can also be relayed to a CPU that already has a usable SA, at a performance cost.

The on-demand path is harder to reason about. Both peers can initiate additional SAs at the same time. A triggering packet may travel over the first SA; its reply can trigger negotiation in the opposite direction. Rekey temporarily multiplies state again because new SAs arrive before old ones disappear. The RFC consequently recommends allowing at least twice the available CPU count for a selector combination, rather than treating the physical CPU count as a rigid protocol ceiling.

When the ceiling is reached, the response matters. TS_MAX_QUEUE means no more resource-specific Child SAs for this TSi/TSr pair. NO_ADDITIONAL_SAS is too broad because it could be interpreted as refusing even a Child SA for different selectors. A precise error preserves future choice.

Admission is still not distribution. A peer that accepted eight members may send on one. A peer that refused the ninth may still possess ample useful capacity. Queue limit, installed inventory, active inventory and delivered work are different measurements.

Deletion exposes the need for a return path

Per-resource SAs can be deleted when their resources become idle. That sounds like ordinary lifecycle management until an implementation lacks per-CPU or per-queue trigger messages. After receiving a Delete Notify, it may have no event that tells it when the resource-specific SA should return.

Recreating it immediately can produce an infinite exchange if the peer continues deleting it. Never recreating it can leave both endpoints forever using only the first SA. The deletion was valid in both cases; the problem is the absent decision mechanism after deletion.

This is a recurring infrastructure lesson. A teardown signal is not a restoration policy. A state transition needs a defined owner, trigger, backoff and observation point. Otherwise a clean control-plane history can end in a quietly degraded steady state.

The local packet trigger is therefore an important receipt. Implementations that support per-CPU SAs should extend their SPD-to-IKE trigger to include a CPU or queue identifier. The trigger does not need to become global protocol identity. It needs to let the local system reconstruct the association between demand and a resource.

The trust boundary is deployment-specific

The feature makes most sense between high-volume gateways whose administrators already have a trust relationship. Every additional SA consumes state, and an unbounded request pattern can become denial-of-service pressure or slow per-packet SAD lookup. The RFC recommends limits per selector pair, just as implementations limit half-open negotiations.

Remote-access VPNs have a different incentive structure. Their peers are numerous, less mutually trusted and often outside one operational domain. RFC 9611 does not recommend per-CPU SAs there and does not recommend enabling them by default. A feature designed to remove trusted-gateway contention should not become a client-controlled state multiplier.

This is also why hardware details stay local. A debugging token may help correlate an SA during a joint investigation. It should not disclose a stable CPU number or invite a peer to treat a local execution detail as an entitlement.

A capacity receipt has several signatures

An operator can turn the RFC into a testable evidence chain without enlarging the protocol:

  1. Record the intended selector group and why parallel SAs are needed.
  2. Record each accepted Child SA, SPI, algorithms and independent key/sequence domain.
  3. Verify inbound and outbound SAD installation separately on both endpoints.
  4. Bind each local member to a CPU, queue or accelerator through local evidence, not the peer's opaque token.
  5. Demonstrate that packet triggers and scheduling distribute actual flows across the intended members.
  6. Observe replay, integrity, drop and reordering counters per SA.
  7. Exercise simultaneous creation, rekey overlap, idle deletion and recovery without loops or permanent collapse to one member.
  8. Measure delivered throughput and latency at the service boundary, not only encryption-loop utilization.

The final receipt may show that the design works. It may instead show that the protocol negotiated correctly while a driver, scheduler, trigger, key-retention rule or asymmetric peer became the binding constraint. Both are useful results because they name the layer that actually owns the outcome.

Sources