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.
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 SNP ( Name = ESN(1) ) | +-- Transform EESPV ( Name = ) | +-- Transform EESPSUBSA ( Name = ) | +-- Transform EESPSSID ( Name = ) | +-- Transform EESPFID ( Name = )
EESP provides an optional Replay service using a 64 bit Sequence Number, carried in the packet. To enable Replay service the initiator SHOULD propose SNP Transforms SNP = (1, Name 64 bit ESN) in Substructure of the Proposal Substructure inside the Security Association (SA) payload in the IKEv2 Exchange. When the responder select 64 bit ESN a receiver MUST enable Reply Protection.
When the Transform Type IKEv2-SNP 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 SNP 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. Otherwise, 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.
When using the Implicit Initialization Vector (IIV) encryption algorithm RFC8750, the IV MUST be omitted. To negotiate this, IIV transforms specified in IKEv2-Enc MUST be used. Additionally, IKEv2-SNP MUST be negotiated to carry a 64-bit ESN in the EESP packet.
Each SA need an EESP Base Header version which is specified I-D.klassert-ipsecme-eesp.
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.
A 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 one-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 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
When the EESP SA is negotiated with a Sub SA Keys (SUB_SA_ID), each Sub SA need to derive its own unique keys. This allows each Sub SA its own independent Sequence Number space, and independent IV space.
Initially we are proposing three Key Derivation Functions(KDF) for Sub SAs. Based on community feedback, further research and advise from cryptographers one method will be chosen.
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
To iteratively derive keys create a large keymt. e.g. for the nth
KEYMAT = prf+(SK_d, Ni | Nr) When there is no additional Key Exchange.
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) When there is additional Key Exchange Paload, a.k.a. PFS.
Where SK_d is derived from IKE negotiation, as specified in Section 2.14 of RFC7296
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).
For example for Sub SA ID n, use nth set of keys from the KEYMAT. The order is specified in Section 2.17 of RFC7296.
With existing prf+ function the keymat length is rather limited. RFC7296 limit the iteration to 256. However, with modern prf+, more specifically XOF, functions, such as KMAC specified in NIST800-185 , or HopMAC/TurboSHAKE specified I-D.irtf-cfrg-kangarootwelve the KEYMAT can be infinitely,(2^40 bytes), long.
An XOF differs from a traditional PRF, hash, function in that it is designed to generate very long, and variable length output. Unlike the IKEv2 prf+ an XOF can generate longer outputs directly without iterative call.
Typical length of of 256 bit encryption is 36 bytes, (32 + 4 salt for IV), in one direction. Using an AEAD for 64K Sub SAs maximum KEYMAT length would be:
4718592 bytes = 2^16 * 2 * 36 bytes. i.e. 4.5 Mega Bytes
When using non AEAD algorithms KEMAT size would roughly double of the above, about 9 Mega Bytes.
The memory requirment fot generate could be reduced by changing prf+ function interface to return portion of the KEYMAT when using iterative feedback mode.
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_child, Sub SA ID)
Where SK_child is the key derived for the Child SA as specified in RFC7296 section 2.17
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+.
An alternative key derivation :
KEYMAT = prf+(SK_d, Ni | Nr | Flow ID)
NOTE: does using using Ni|Nr|g^ir KDF input matters? Is there a perfernece? Any advise from the cryptographers?
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_child, Sub SA ID)
or depending on which one of the above KDF is chossen.
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr | Sub SA ID)
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.
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 is similar to ESP UDP encapsulation, specified in RFC3948, with one difference on source port. The EESP allows use fo different source port than IKE as specified in RFC3947, RFC7296 for Address and Port Agility and ECMP when using Sub SA. The Sub SA ID 0, MUST use the identical source and destination ports as the IKE SA. Other Sub SA may use use different source port while destination port 4500.
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 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] |
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