| Internet-Draft | EESP Stateless Encryption | July 2026 |
| Xia, et al. | Expires 4 January 2027 | [Page] |
This document specifies a stateless encryption profile for Enhanced Encapsulating Security Payload (EESP). The profile is intended for large-scale deployment scenarios in which maintaining per-flow or per-session encryption state is operationally expensive or infeasible. Instead of storing a distinct data key for each secure flow, endpoints derive per-packet or per-context data keys from a smaller set of provisioned root keying material together with packet-carried context.¶
The document describes the deployment motivation, the stateless keying model, the mapping of required fields onto EESP extension points, context construction rules, data-key derivation processing, IV construction requirements, security considerations, and operational considerations. The intent is to realize stateless encryption as an extension profile over EESP, rather than as a parallel encapsulation format.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Large-scale cloud services, AI computing networks, high-performance computing clusters, and pooled NIC/DPU deployments create pressure on conventional IPsec processing pipelines. In such environments, a device may need to support a very large number of protected flows while operating under tight hardware memory constraints. Even when cryptographic processing is available in hardware, maintaining per-flow or per-session data-key state at scale can become a practical bottleneck.¶
EESP [I-D.ietf-ipsecme-eesp] and its IKEv2 negotiation extensions [I-D.ietf-ipsecme-eesp-ikev2] provide a flexible framework for extending protected packet processing, including finer-grained treatment of packet fields and optional metadata carriage. This document builds on that framework and defines a stateless encryption profile for EESP.¶
The key idea is to replace large quantities of stored encryption state with deterministic derivation. A sender and receiver that possess the same provisioned root keying material can derive the same data key from a canonical context carried in, or inferable from, the packet. This approach can reduce the amount of per-flow state that must be stored in endpoints, NICs, DPUs, or accelerators, while still allowing isolation across connections, devices, jobs, or trust groups.¶
This document does not define a new encapsulation protocol parallel to EESP. Instead, it defines how stateless key derivation, context signaling, and IV construction are realized as an EESP extension profile.¶
This document depends on EESP and is intended to be used only in conjunction with EESP-capable endpoints. The stateless encryption mechanism specified here reuses EESP packet-processing structure, EESP extensibility points, and the EESP/IKEv2 negotiation framework.¶
All additional semantics required by this document are expected to be carried through EESP-defined extension mechanisms, including base-header option signaling and peer-coordinated metadata carriage. This document therefore specifies a stateless keying profile over EESP, not a replacement for EESP.¶
Where this document refers to packet fields for stateless derivation, those fields are to be mapped onto EESP extension locations rather than interpreted as a standalone new security header. The exact wire encoding is therefore constrained by EESP and any associated negotiation definitions.¶
Public cloud services provide IPsec VPN access for a massive number of users, and the infrastructure nodes serving those users may need to handle a very large number of secure sessions. If hardware offload is used, the device typically prefers compact and regular cryptographic state. In this environment, storing a distinct data key for each active secure flow can create memory pressure.¶
A stateless encryption approach similar in spirit to the PSP architecture can reduce endpoint state by deriving data keys from provisioned keying material and connection-specific context. This is especially useful when the client and server are not in the same trust domain and when minimizing server-side flow state is more important than eliminating all out-of-band provisioning.¶
Large HPC jobs may involve many instances communicating with one another, creating security association scale that grows rapidly with the number of jobs, participants, and traffic relationships. In such environments, all entities participating in a job may belong to the same trust domain, making shared root keying material operationally feasible.¶
M Jobs
+------------------------------------------+
| +----------------------------------------+-+
| | +--------------------------------------+-+-+
| | | Job 0 | | |
| | | +---------+ +---------+ +---------+ | | |
| | | |Instance1| |Instance2| |Instance3| | | |
| | | +---------+ +---------+ +---------+ | | |
+-+-+--------------------------------------+ | |
+-+----------------------------------------+ |
+------------------+-----------------------+
|
|Deploy Jobs
|to Server Cluster
|
+------------------------------V--------------------------------------+
| Server Cluster |
| |
| +-----------+ +-----------+ +-----------+ |
| |+----------++ |+----------++ |+----------++ |
| ||+---------+++ ||+---------+++ ||+---------+++ |
| |||Instancei||| Ciphertext|||Instancej||| Ciphertext|||Instancek||| |
| ||| Keyi ||<----------->|| Keyj ||<----------->|| Keyk ||| |
| +++---------+|| +++---------+|| +++---------+|| |
| ++----------+| ++----------+| ++----------+| |
| +----+------+ +-----------+ +-------+---+ |
| | Ciphertext | |
| +------------------------------------------------------+ |
| |
+---------------------------------------------------------------------+
A stateless design similar to concepts used in UEC TSS can reduce or eliminate dependence on stored per-connection data keys. This improves scalability when a large number of encrypted communications must be established quickly across a cluster fabric.¶
For large-scale north-south or east-west traffic, NIC or DPU pooling can be used to improve resource utilization and provide transparent service continuity. In such a pool, multiple devices may need to process traffic associated with the same protected tenant, service, or connection namespace.¶
VM Pool
+--------------------------------------------------+
| |
| +----+ +----+ +----+ +----+ |
| | VM | | VM | | VM | | VM | |
| +----+ +----+ +----+ +----+ |
| |
| +----------------------------------+ |
| | | |
| | NIC pool with shared master key | |
| | and security context | |
| | +-----+ +-----+ +-----+ | |
| | | NIC | | NIC | ... | NIC | | |
| | +---X\* +-/-*-+ +---/++ | |
| | / \ \\ / |\ --/ | | |
| +------/--\-/X\--+-\\-----//--+----+ |
+----------/---\/---\\+---\---/----+---------------+
/ /\ \\- \ / |
/ / Ciphertext X\ |
/ / \- | \X \ |
/ // --- \ | // \\ \ |
// --- \ | / \\\\ |
//-- \ |/ \\\|
+--------+ +----\*--+ +----\|--+
| client | | client | | client |
+--------+ +--------+ +--------+
If those devices are in the same trust domain and share provisioned root keying material, a stateless profile can avoid synchronization of a large number of per-flow data keys across the pool. This can simplify load balancing and failover while reducing synchronization overhead.¶
AI computing deployments may contain a large number of CPUs, XPUs, switches, and DPUs participating in coordinated task execution. Some of these entities may belong to the same trust domain, while others may communicate across trust-domain boundaries using proxy-capable infrastructure elements.¶
+-----------------------------+
| Trusted Domain 1 |
| +-----+ +-----+ +-----+ |
| | CPU | | CPU | ... | CPU | |
| +-----+ +-----+ +-----+ |
| +-----+ +-----+ +-----+ |
| | XPU | | XPU | ... | XPU | |
| +-----+ +-----+ +-----+ |
| +-----+ +-----+ +-----+ |
| | XPU | | XPU | ... | XPU | |
| +-----+ +-----+ +-----+ |
++----------+-----+----------++
|DPU/Switch| |DPU/Switch|
+-----+----+ +------+---+
| Global Trusted|Domain
+---------------+-----------------+------------------+
+-----+----+ +----+-----+ +---+------+ +------+---+
|DPU/Switch| |DPU/Switch| |DPU/Switch| |DPU/Switch|
++----------+-----+----------++ ++----------+----+----------+-+
| +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ |
| | CPU | | CPU | ... | CPU | | | | CPU | | CPU | ... | CPU | |
| +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ |
| +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ |
| | XPU | | XPU | ... | XPU | | | | XPU | | XPU | ... | XPU | |
| +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ |
| +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ |
| | XPU | | XPU | ... | XPU | | | | XPU | | XPU | ... | XPU | |
| +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ |
| Trusted Domain 2 | | Trusted Domain 3 |
+-----------------------------+ +-----------------------------+
Intra-domain stateless encryption can reduce key-management latency between accelerators. For cross-domain proxying, a DPU or similar element may derive one data key for traffic in one trust domain and another data key for the adjacent trust domain, then perform secure proxy conversion under tightly controlled policy.¶
Based on the use cases above, a general EESP stateless encryption profile needs the following properties:¶
It supports entities within a trust group sharing common provisioned root keying material.¶
It supports traffic isolation through context construction, so that different connections, devices, jobs, or protection domains derive different data keys.¶
It supports canonical and interoperable derivation inputs, rather than implementation-specific context formatting.¶
It supports root-key lifecycle management and data-key refresh through epoch changes and rekey events.¶
It supports extremely efficient KDF execution because derivation may occur on a per-packet basis.¶
It supports carriage of the information necessary for derivation and IV construction through EESP-compatible signaling.¶
It supports deployment models involving proxy processing across trust domains.¶
This section specifies the abstract stateless keying model used by this profile.¶
Each participating endpoint is provisioned with one or more root keys associated with a local policy scope. The implementation derives a profile-specific master secret from those root keys. This document does not require a specific method for composing multiple root keys, but any such method MUST produce the same master secret at all authorized participants within the same derivation scope.¶
A packet data key is then derived as a function of at least the following inputs:¶
the provisioned master secret,¶
a canonical context,¶
profile identification or domain-separation information, and¶
any additional inputs required by the negotiated KDF.¶
The stateless property means that successful decryption does not depend on the receiver storing a previously negotiated per-flow data key. The receiver reconstructs the same derivation inputs from local provisioning plus packet-visible and policy-visible context, then recomputes the data key.¶
This profile MAY still permit local caching of recently derived data keys as an implementation optimization. Such caching does not change the protocol model and MUST NOT alter the externally visible derivation result.¶
This document requires three classes of information to be available to the receiver:¶
key-derivation context inputs,¶
IV construction inputs, and¶
any selectors needed to interpret confidentiality and integrity processing scope consistently.¶
These items MUST be encoded using EESP-supported structures rather than a new parallel stateless-encryption header. In particular, metadata needed by this profile SHOULD be carried using EESP option signaling and any EESP-defined peer metadata fields appropriate for per-packet interpretation.¶
Typical metadata elements include a Key Scope Identifier, a Device Identifier or Connection Identifier, an Epoch value, a packet counter or nonce-related value, and flags indicating the selected stateless profile behavior. If confidentiality or integrity coverage offsets are used, they MUST be defined in a way consistent with EESP processing semantics rather than as an unrelated parallel mechanism.¶
The following figure is retained to illustrate the logical stateless-encryption metadata set that needs to be mapped onto EESP extension points. It is an informational field layout example only, and MUST NOT be interpreted as defining a new standalone protocol header.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| HL | V | Reserve | COffset |IOffset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DeviceID/ConnectionID (4B-8B) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Master Key Options (variable, optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Epoch | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following option example is likewise retained as an illustration of the logical contents that may need to be carried by EESP option signaling for master-key selection and derivation scope identification.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length |Root Key Index | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Root Key ID (16B-32B) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document intentionally separates logical fields from final bit-level encoding. Concrete wire-format allocation is expected to follow EESP extension design and any associated IANA assignments.¶
To ensure interoperability, the context used for data-key derivation MUST be canonically encoded. The context MUST include enough information to ensure separation between independent protection domains that would otherwise risk deriving the same data key.¶
At minimum, the canonical context for this profile MUST include:¶
a Key Scope Identifier,¶
either a Device Identifier or a Connection Identifier,¶
an Epoch value, and¶
a direction or equivalent domain-separation indicator when the same root keying material can be used in both directions.¶
The profile definition or negotiated transform MUST specify the exact field ordering, field widths, byte order, and any length-prefix or type-prefix rules. Implementations MUST NOT rely on ambiguous local string encodings or implementation-specific serialization.¶
The KDF used by this profile MUST be explicitly identified by negotiation or profile definition. The KDF specification MUST define all inputs, including the master secret input, the canonical context input, any salt or label input, and the output length.¶
A receiver that cannot reconstruct the exact canonical context or cannot identify the negotiated KDF parameters MUST treat the packet as undecryptable. Implementations MUST NOT fall back to heuristics or trial-and-error parsing for context interpretation.¶
A simplified abstract derivation form is:¶
DataKey = KDF(MasterSecret, ProfileLabel, CanonicalContext, OutputLength)¶
The exact KDF instantiation is out of scope for this version until aligned with the relevant EESP key-derivation framework. However, this document requires that the selected construction be interoperable, efficiently implementable, and cryptographically suitable for packet-scale invocation.¶
For AEAD algorithms such as AES-GCM, IV reuse under the same data key is not acceptable. Therefore, this profile MUST ensure that IV construction is unambiguous and prevents reuse within the same data-key scope.¶
This document recommends an IV construction model based on an Epoch value combined with a packet counter or equivalent monotonic sender contribution. A representative abstract form is:¶
IV = Encode(Epoch, PacketCounter, OptionalSenderField)¶
The precise encoding MUST be defined by the negotiated profile. That definition MUST specify counter width, sender responsibility for uniqueness, behavior on counter exhaustion, and any constraints that apply when multiple transmit engines may emit packets for the same derivation scope concurrently.¶
If multiple senders can operate under the same root keying scope and could otherwise generate colliding IV input tuples, the canonical context or IV input set MUST include an additional sender-unique field. An implementation MUST rekey, advance the epoch, or otherwise terminate use of the relevant derivation scope before IV uniqueness can no longer be guaranteed.¶
This profile is intended to be negotiated using the EESP-related IKEv2 framework rather than private bilateral configuration alone. The negotiation design is expected to identify at least the stateless profile, the KDF transform or transform parameters, the context format, and any option behavior required for wire interoperability.¶
Depending on the final EESP/IKEv2 design, this may require one or more new transform values, attributes, notify payloads, or capability indications. The exact allocation strategy is left for subsequent alignment with the companion EESP negotiation document.¶
A successful negotiation MUST result in both peers having an identical understanding of:¶
The security of this profile depends heavily on control-plane protection because compromise of provisioned root keying material can affect all derivation scopes reachable from that material. Deployments MUST protect root keys in storage, transport, and use, and MUST restrict distribution to authorized participants only.¶
When multiple root keys are combined into a master secret, the security properties of the composition method MUST be clearly understood. Operators MUST also evaluate the blast radius of a root-key compromise, especially in deployments where many nodes in one trust group share common keying material.¶
The derivation inputs MUST guarantee data-key separation across protection domains that should not share data keys. In particular, the context format MUST avoid accidental collisions between different devices, connections, or directions.¶
IV reuse under the same data key MUST be prevented. Implementations therefore need clear rules for packet-counter allocation, counter wrap handling, concurrency across transmit engines, and epoch transition.¶
Cross-trust-domain proxy deployments require special care because the proxy may be trusted with keying material or derivation capability for more than one domain. Such deployments MUST define strict authorization boundaries, auditing requirements, and limitations on key exposure. They SHOULD minimize the amount of plaintext and long-lived keying material visible to proxy elements.¶
This profile does not by itself define a universal replay-protection solution for fully stateless receivers. A deployment using reduced receive-side state MUST explicitly evaluate the trade-off between replay detection strength, memory consumption, and implementation complexity.¶
Large-scale deployments need coordinated procedures for root-key rotation, epoch advancement, rollback handling, member admission and removal, and consistency across control-plane systems such as controllers, KMS components, and offload devices.¶
If a deployment uses pre-key, current-key, and next-key style rollover windows, all participants need a well-defined transition policy so that packets sent during a rotation interval remain decryptable for the intended overlap period. Rotation cadence SHOULD account for both cryptographic policy and operational packet volume.¶
Operators SHOULD maintain auditability for key-scope definitions, profile negotiation, epoch transitions, and trust-domain proxy authorization. They SHOULD also define failure procedures for desynchronization between provisioning state and packet-visible epoch or scope metadata.¶
This document is expected to require IANA actions related to EESP extension signaling and EESP-associated IKEv2 negotiation parameters.¶
At minimum, future versions are expected to identify whether new registrations are needed for:¶
one or more EESP option types used by the stateless profile,¶
one or more IKEv2 transform identifiers or transform parameters,¶
any new IKEv2 attributes, and¶
any capability or notify values required for negotiation.¶
The exact registrations are TBD pending alignment with the corresponding EESP and EESP-IKEv2 specifications.¶