The Enhanced Encapsulating Security Payload (EESP), specified in I-D.klassert-ipsecme-eesp, introduces enhancements to the Encapsulating Security Payload (ESP) defined in [RFC4303]. These improvements address evolving requirements in modern IPsec deployments. EESP offers increased flexibility for hardware offloads at the packet level. It supports carrying inner packet flow identifiers for the use with ECMP, RSS hardware, and IPsec peers prior to decryption. EESP also enables the establishment of Sub Child SAs with independent sequence number spaces. Additionally, it supports the use of 64-bit sequence numbers in each packet or the omission of sequence numbers when the Replay Protection service is disabled. EESP packets carry a version number, enabling easier support for future extensions.
This document specifies the negotiation of EESP Security Associations (SAs) within the Internet Key Exchange Protocol Version 2 (IKEv2) protocol [RFC7296]. It details the creation, rekeying, and deletion of EESP SAs, as well as the negotiation of EESP specific transform properties and properties.
The extensions defined here enable EESP SAs to coexist with ESP SAs in stateful decryption configurations, sharing a common SPI namespace while introducing new capabilities to enhance IPsec’s performance and versatility in modern use cases.
This document does not obsolete or update any existing RFCs. While stateless implementations of EESP are referenced, their negotiation, which is similar to PSP, is outside the scope of this document.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.
It is assumed that readers are familiar with the IKEv2 negotiation RFC7296, IPsec architecture RFC4301 and ESP RFC4303. This document uses a notation and conventions from IKEv2 [RFC7296] to negotiate EESP.
This document uses the following terms defined in IKEv2 RFC7296: Child SA, CREATE_CHILD_SA exchange, IKE_AUTH exchange, USE_TRANSPORT_MODE
This document uses the following terms defined in PSP: PSP (a recursive acronym for PSP Security Protocol), Network Identifier (VNI), Crypt Offset.
This document uses the following terms defined in RFC2992: Equal-cost multi-path (ECMP)
This document uses the following terms defined in RFC4303: Encapsulating Security Payload (ESP).
This document uses the following terms defined in I-D.mrossberg-ipsecme-multiple-sequence-counters: Sub-Child SA.
This document uses the following terms defined in I-D.ietf-ipsecme-ikev2-rename-esn : Replay Protection.
This document uses the following terms defined in I-D.ietf-ipsecme-g-ikev2: Sender-ID, Data-Security SA, GWP_SENDER_ID_BITS, GCKS policy.
To negotiate of EESP Security Associations (SAs), as specified
in I-D.klassert-ipsecme-eesp. Propose Protocol ID EESP input
SA Payload, Proposal payload.
These extensions provide the ability to establish EESP SAs using
the IKE_AUTH or the CREATE_CHILD_SA exchanges. The initiator includes
EESP-specific transforms and attributes in the proposal, allowing
the responder to evaluate and establish the SA if supported.
IKEv2 Notify Message Status Type USE_WESP_MODE, RFC5840, is not supported when negotiating EESP SA. As the WESP functionality is part of EESP protocol. If this notification is received it MUST be discarded.
The ESP_TFC_PADDING_NOT_SUPPORTED, RFC7296, notification is not supported in EESP, instead use IP-TFS, USE_AGGFRAG, RFC9347. If this notification is received it MUST be discarded.
To negotiate an EESP Child SA, use the IKEv2 IKE_AUTH or CREATE_CHILD_SA new SA exchange. The SA Payload, Proposal MUST have Security Protocol Identifier, Proto Id = EESP which is specified in I-D.klassert-ipsecme-eesp, as specified in this document, and uses the EESP Transform attributes defined in EESP SA Transforms.
Rekeying an EESP SA follows the same procedure as rekeying an ESP SA, as specified in Sections 1.3.3 and 2.8 of RFC7296. During the rekeying process, the EESP SA Transforms MUST remain identical to those negotiated when the SA was initially established.
EESP SA always exist in pairs. Deleting EESP SA follows the same procedure as deleting Child SA using IKEv2 INFORMATIONAL exchange as specified in Section 1.4.1 RFC7296
EESP introduces several transform properties that are negotiated during the establishment of an EESP SA. These properties MUST be identical for the duration of the SA. When the SA is rekeyed, the new SA MUST inherit all EESP transform properties negotiated for the original EESP SA.
| Type | Description | Used In | Reference |
|---|---|---|---|
| TBD4 | EESP Version(EESPV) | (EESP) | [this document] |
| TBD5 | EESP Sub SA(EESPSUBSA) | (EESP) | [this document] |
| TBD6 | EESP Session ID(EESPSID) | (EESP) | [this document] |
| TBD7 | EESP Flow ID(EESPFID) | (EESP) | [this document] |
SA Payload | +--- Proposal #1 ( Proto ID = EESP(TBD1), SPI size = 4, | | 8 transforms, SPI = 0x052357bb ) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) | +-- Transform SN ( Name = Full 64 bit Sequence Number) | +-- Transform EESPV ( Name = V1 ) | +-- Transform EESPSUBSA ( Name = ) | +-- Transform EESPSSID ( Name = ) | +-- Transform EESPFID ( Name = )
EESP provides an optional Replay service using Full 64 bit Sequence Numbers(TBD9), carried in the packet. To enable Replay service the initiator SHOULD propose Sequence Numbers Transforms, SN = (Full 64 bit Sequence Number(TBD9)) in Substructure of the Proposal Substructure inside the Security Association (SA) payload in the IKEv2 Exchange. When the responder select Full 64 bit SN a receiver MUST enable Reply Protection.
When the Transform Type IKEv2-SN is not present in initiator’s Child SA proposal during negotiation of an EESP Child SA, the Sequence Number field MUST NOT be transmitted in the EESP packet.
When the Replay Prtection is not negotiated, i.e., when the 64 bit sequence number is not carried in the EESP packet, an EESP receiver should not act on address or port changes. It should not initiate a dynamic address update without the use of IKEv2 Mobility RFC4555. Since the Replay Protection service is disabled, an attacker could replay packets with a different source address. An attacker could disrupt the connection by capturing and replaying a single packet with different source address or port number.
If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this may be carried explicitly in every EESP packet.
With the Implicit Initialization Vector (IIV) encryption algorithm, as specified in RFC8750, the IV MUST be omitted in the EESP packet. To enable this functionality, IIV transforms defined in IKEv2-Enc MUST be used during negotiation. Furthermore, the IKEv2-SN extension MUST be negotiated to support the use of a Full 64-bit Sequence Numbers in EESP packets. If the the proposal does not include Full 64-bit Sequence Numbers return error INVALID_SN.
Each SA need an EESP Base Header version which is specified I-D.klassert-ipsecme-eesp. An Initiator may propose multipe EESPV and the responder MUST choose one proposal.
EESP Flow Identifier (EESPFID) Options are used to carry characteristic information of the inner flow and SHOULD NOT change on per packet basis inside any inner flow to avoid packet reordering. The Flow Identifier SHOULD be negotiated when creating EESP SA.
An EESP Sub SA is a unidirectional Security Association derived from an existing EESP Child SA pair. It inherits all properties except keys, sequence number space, and IV space. These three are unique for each Sub SA. This allows finer granularity for managing uni-directional traffic flows. Sub SAs avoid the overhead associated with bidirectional Child SAs for identical traffic selectionsRFC7296, RFC9611. They enable more efficient resource utilization and improved performance, particularly in scenarios requiring high flexibility. Each Sub SA is uniquely identified by a Sub SA ID, which is used to derive a unique key. The Sub SA ID is carried in each EESP packet, either in the Session ID field or in the Flow ID field, as negotiated during the establishment of the EESP Child SA.
Advantages of Sub SAs compared to Child SAs with different keys:
- Possibility for unidirectional SAs. Compared to RFC9611, when a per-resource SA is established, it is bidirectional. However, both directions of the SA MAY not always be in use. Using CREATE_CHILD_SA does not allow unidirectional SAs.
- No extra setup time, i.e., zero round-trip time to set up additional Sub SAs. This would be more efficient than using large IKE window size specified in RFC7296 to manage multiple SAs.
- Sub SAs are more efficient to create, rekey, and delete. Their
lifecycle management is simpler compared to traditional Child SAs.
- When using hierarchical key derivation, especially when using hardware key derivation, Sub SA keys can be derived on-the-fly per packet. This reduces “Data-plane performance degradation due to the use of a larger number of keys” as noted in I-D.ponchon-ipsecme-anti-replay-subspaces.
To negotiate Sub SA SUB_SA_ID in Session ID Transform. Or in a Flow IDs Transform. TBD: expand Sub SA with Flow ID negotiation
AEAD transforms, such as AES-GCM or those specified in RFC8750, require that the IV does not repeat within a single Sub SA. Each Sub SA uses a distinct key, ensuring proper cryptographic separation. While the IV may repeat across different Sub SAs, this complies with the requirement that each key must be paired with a unique IV.
Each Sub SA MUST maintain an independent sequence number space when using full 64-bit sequence numbers. For a specific key within a Sub SA, sequence numbers MUST BE unique and follow a monotonically increasing order to meet cryptographic requirements.
An EESP SA primarily uses UDP encapsulation to facilitate NAT traversal. However, an additional use case for UDP encapsulation is to introduce source port entropy, which supports ECMP or/and RSS (Receive Side Scaling) mechanisms. In such scenarios, the initiator MAY also use a distinct, ephemeral source port for Sub SA IDs greater than zero. Both peers MAY independently select different source ports for the same Sub SA ID.
It is important to note that IKE messages MUST NOT utilize these ephemeral source ports. Instead, IKE traffic should be confined to the source and destination ports to ensure proper protocol operation and maintain compatibility with existing implementations.
When using ephemeral source ports, the receiver can only set the source port upon arrival of an EESP packet with that Sub SA ID. If the receiver is pre-populating a Sub SA, it may have to install it with a source port set to zero and, upon arrival of a packet, update the source port using a mapping change.
Additionally, when multiple Sub SAs exist, the receiver SHOULD maintain a mapping table to track the source port associated with each Sub SA independently. This ensures that traffic is correctly routed and prevents ambiguity in handling packets associated with different Sub SAs when a NAT is present.
When the EESP SA is negotiated with a Sub SA Keys (SUB_SA_ID), each Sub SA derives its own unique keys. This allows each Sub SA its own independent Sequence Number space, and independent IV space.
The requirements:
- Independent keys for each Sub SA
- Ability to derive Sub SA keys on the fly with least amount of memory usage
- Minimal memory requirements
- Keyderviation support multiple SAs, such as EESP, AH
- Use the same Crypto primitive as used for encryption e.g. AES-*
Hierarchical key derivation use Sub SA ID, which is carried in EESP Seesion ID or in EESP Flow ID(TLV), as an input to the key dervivation.
Two KDF are propsed below and eventually choose one of them.
KEYMAT = prf+(SK_d, Ni | Nr | Sub SA ID)
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this request is the first Child SA created or the fresh Ni and Nr from the CREATE_CHILD_SA exchange if this is a subsequent creation.
For CREATE_CHILD_SA exchanges including an optional Key Exchange the keying material is defined as:
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr | Sub SA ID)
where g^ir (new) is the shared secret from the ephemeral Key Exchange of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros in the high-order bits if necessary to make it the length of the modulus).
KEYMAT = prf+(prf(SK_d, Ni | Nr | Sub SA ID))
One advantage of Hierarchical KDF is KEYMAT for the Sub SAs can be generated on the fly, for every packet, when available memory is limited, for example PSP. This is usually the case when key derivation is implemented in hardware. When implimenting in hardware choose a hardware friendly prf+.
During the EESP SA rekey, new keys are derived using the new Ni and Nr values. If a Key Exchange (KE) method was used in the rekying, CREATE_CHILD_SA exchange, the new key MAY also include g^ir as part of the derivation process.
KEYMAT = prf+(SK_d, Ni | Nr | Sub SA ID)
or
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr | Sub SA ID)
When there is an additionl Key Exchange in rekey.
Even though each Sub SA can be independently rekeyed, for simplicity and security, all Sub SAs MUST be rekeyed together when either a cryptographic limit or a time-based limit is reached.
The time-based limit, also described in Section 2.8 of [RFC7296], ensures periodic key replacement to minimize the risks associated with long-term key exposure, even if the cryptographic limit has not been reached.
When rekeying is triggered for any of the Sub SA by whichever limit—cryptographic or time- based—is reached first, subseqenty all Sub SAs must rekeyed.
When using EESP with a group SA, as specified in I-D.ietf-ipsecme-g-ikev2, the Sender-ID MUST be used for deriving a unique key for each sender. This ensures that each sender maintains a distinct IV and/or sequence number space. When using independent keys, the Implicit IV (IIV) transforms may be used.
The Sender-ID is carried in each packet within the Session ID field, allowing efficient and reliable key differentiation for data security and integrity.
The maximum length of GWP_SENDER_ID_BITS in GCKS policy is 16 bits when using the Session ID to carry the Sender-ID.
[Note: we could allow 32 bit or any lenght field for GWP_SENDER_ID_BITS then it would have be carried in a EESP Options TLV and not in Session ID]
The Session ID is a multi-purpose attribute with mutually exclusive values. The initiator MUST propose a single value in the Child SA proposal, Transform EESPSSID (Value). The responder MUST either accept the proposed value or reject it with an INVALID_SESSION_ID error message, indicating a supported value.
UDP encapsulation for EESP is largely similar to the ESP UDP encapsulation specified in RFC3948, with the primary difference being the UDP source port used by the EESP Sub SA may be different from IKE_SA source port.for more flexible handling of EESP traffic, particularly ECMP support along the path and in the NIC.
A receiver indenting to support both ESP and EESP encapsulated in UDP must start ESP SPI, most significant bit of the SPI, with zero.
This option is typically used for within one Datacenter use case such as PSP. To negotiate, the initiator sends USE_CRYPTOFFSET together with USE_TRANSPORT_MODE and the responder respond with the same. USE_EESP_CRYPTOFFSET is not supported in Tunnel mode or BEET mode.
#
NOTE Add EESP draft UDP section reference.
This document defines new Protocol ID in the “IKEv2 Security Protocol Identifiers” registry, IKEv2-SP:
| Protocol ID | Protocol | Reference |
|---|---|---|
| [TBD1] | EESP | [this document] |
This document defines new transforms in “IKEv2 Transform Type Values” registry, IKEv2-Transforms
| Type | Description | Used In | Reference |
|---|---|---|---|
| TBD4 | EESP Version(EESPV) | (EESP) | [this document] |
| TBD5 | EESP Sub SA(EESPSUBSA) | (EESP) | [this document] |
| TBD6 | EESP Session ID(EESPSID) | (EESP) | [this document] |
| TBD7 | EESP Flow ID(EESPFID) | (EESP) | [this document] |
| Value | Notify Message Status Type | Reference |
|---|---|---|
| TBD8 | USE_EESP_CRYPTOFFSET | [this document] |
Several tables in IKEv2-IANA that specify ESP as protocol should be extended with EESP. Should we list each table one by one or specify as replace ESP, with ESP, EESP.e.g in the Transform Type Values, replace ‘IKE and ESP’ with ‘IKE, ESP, and EESP’
Changes the “Used In” column for the existing allocations as follows;
This document defines new Notify Message types in the “IKEv2 Notify Message Error Types” registry:
| Value | Notify Message Error Type | Reference |
|---|---|---|
| [TBD2] | INVALID_SESSION_ID | [this document] |
| [TBD3] | INVALID_SUB_SA | [this document] |
| [TBD10] | INVALID_SN | [this document] |
This document defines a new value in the IKEv2 “Transform Type 5 - Sequence Numbers Properties Transform IDs” registry:
| Value | Name | Reference |
|---|---|---|
| [TBD9] | Full 64-bit Sequence Numbers | [this document] |
A new set of registries is created for EESP-IKEv2 on IKEv2 parameters page IKEv2-IANA. The terms Reserved, Expert Review and Private Use are to be applied as defined in RFC8126
IANA is requested to create a new registry named ‘EESP Session ID Transform’ in the ‘Internet Key Exchange Version 2 (IKEv2) Parameters’, IKEv2-IANA page.
- Name: EESP Session ID Transform Registry
- Description: EESP Base Header Session ID
- Reference: This document
| Session ID | Name | Reference |
| ------------+------------- | ||
| 0 | Unspecified | [this document] |
| 1 | ENCRYPION_ID | [this document] |
| 2 | SUB_SA_ID | [this document] |
IANA is requested to create a new registry named ‘EESP Session Flow ID Transform’ in the ‘Internet Key Exchange Version 2 (IKEv2) Parameters’, IKEv2-IANA page.
- Name: EESP Flow ID Transform Registry
- Description: EESP Flow Identifier
- Reference: This document
| Flow ID | Name | Reference |
|---|---|---|
| 0 | Unspecified | [this document] |
| 1 | VNI32 | [this document] |
| 2 | VNI64 | [this document] |
| 3 | SUB_SA_16 | [this document] |
[Note to RFC Editor: Please remove this section and the reference to RFC7942 before publication.]
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC7942. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
According to RFC7942, “this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit”.
Authors are requested to add a note to the RFC Editor at the top of this section, advising the Editor to remove the entire section before publication, as well as the reference to RFC7942.
EESP option Crypt Offset I-D.klassert-ipsecme-eesp section [XXX] allows exposing transport headers for telemetry. It is indented use of within data center.
When an EESP receiver implementation uses Stateless Decryption, it may not rely on single Security Policy Database (SPD) as specified in the IPsec Architecture document RFC4301, section 4.4.1. However, the receiver MUST validate the negotiated Security Policy through other means to ensure compliance with the intended security requirements. For by adding Security Policy to the socket or route entry. Also comply with ICMP processing specified in section 6 of RFC4301.
Additional security relevant aspects of using the IPsec protocol are discussed in the Security Architecture document RFC4301
TBD
TBD