Enhanced Encapsulating Security Payload (EESP)

Due to the absence of a version number in the packet header of the ESP protocol, ESP can't be updated in a transparent way. Any updates to ESP must be negotiated by IKEv2 and are therefore indiscernible to, intermediate devices such as routers and firewalls. In the recent past, several attempts were taken to introduce a Flow Identifier for certain use cases. Examples are and . Such a Flow Identifier could also be used to perform ECMP based on the inner flows at intermediate devices or endpoints. Additionally to that, there exists a specification of the protocol that has the need of a Flow Identifier, called Network Identifier (VNI) there. PSP also defines a Crypt Offset to expose parts of the headers of the inner packet. EESP provides a solution for all the aforementioned use cases. This document defines Flow Identifier and Crypt Offset Options, the combination thereof along with the Session ID can be used for the PSP use case. Future documents can define the meaning of additional Options for their particular use-case. With this, all existing and potential new use cases can be covered. For instance, it can be used for the case of or etc., or combinations thereof. EESP does not have a trailer as ESP had, instead the Next Header an Pad Length values are moved to the EESP header. Additionally, an Optimized EESP header is defined which eliminates these 2 values when using simple IPv4 or IPv6 tunnel mode. EESP also does not define TFC padding, IP-TFS as of SHOULD be used instead. A detailed discussion about the problems of the ESP protocol can be found in . EESP follows the Security Architecture for the Internet Protocol and uses ESP as of as reference. That means this document is seen as an modern version of ESP (with new protocol number), but it follows the design principles of ESP. Protocol parts that are not mentioned here, MUST be handled exactly the way as specified in . EESP neither updates nor obsoletes . Though this document specifies IKEv2 as a negotiation protocol, EESP may use other protocols for negotiation and key derivation. The packet specification is portable to other keying protocol use cases, such as , and offers versioning at the packet level.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This document uses the following terms defined in IKEv2 : Child SA, CREATE_CHILD_SA, IKE_AUTH exchange, USE_TRANSPORT_MODE This document uses the following terms defined in : PSP (a recursive acronym for PSP Security Protocol), Network Identifier (VNI), Crypt Offset. This document uses the following terms defined in : Equal-cost multi-path (ECMP) This document uses the following terms defined in : Encapsulating Security Payload (ESP). This document uses the following terms defined in : Sub-Child SA.

In this section we define the exact protocol formats and operations. This section is normative.

The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value TBD in its (IPv4) or Next Header (IPv6, Extension) field. illustrates the top-level format of an EESP packet. The EESP header is split into multiple parts.

Top-Level Format of an EESP Packet The packet starts with a 'Base Header' that can be used by protocol parsing engines of middleboxes such as routers or firewalls in addition to the IPsec peer that use it to route the packet to the correct Crypto context. The 'Peer Header' follows the 'Base Header'. The 'Peer Header' is used to support replay protection and to store cryptographic synchronization data, e.g., an Initialization Vector (IV) for the IPsec peer. Unlike ESP, EESP does not have a trailer. Instead, these values have moved to a 'Payload Info Header' directly following the 'Peer Header'. The 'Payload Data' follows these 3 header parts, and has structure that depends on the choice of encryption algorithm and mode. 'Padding' is an optional field following the 'Payload Data', primarily for alignment when using a block cipher. Finally, the packet ends with an optional 'Integrity Check Value' (ICV) (see Section 3.3.2 of ). The length of this ICV depends on the Crypto suite.

The 'Base Header' is comprised of a fixed base header followed by an optional 'Options' field. IPsec Peers and Middleboxes MAY act upon the Base Header and any possible Options.

The fixed portion of the base header is defined as follows.

Fixed Base Header

Version: 7 bits: MUST be set to zero and checked by the receiver. If the version is different than an expected version number (e.g., negotiated via the control channel ), then the packet MUST be dropped by the receiver. Future modifications to the EESP header require a new version number. In particular, the version of EESP defined in this document does not allow for any extensions. Intermediate nodes dealing with unknown versions are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy dependent (e.g., it may dictate dropping such packets).
Packet Format: 1 bit: Set to zero for full EESP packet Format (i.e., the EESP header includes the 'Payload Info Header'), set to 1 for Optimized EESP Packet format.
Opt Len: 8 bits: Length in bytes of the 'Options' field.
Session ID: 16 bit: The Session ID covers additional information that might be needed to route the packet to the correct stateless crypto context. For instance, if a Key Derivation Function (KDF) is used do stateless key derivation, the crypto algorithm ID could be encoded there. The meaning of that field is opaque and MAY be negotiated by IKEv2.
Security Parameter Index (SPI): 32 bits: The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. This combined with the 16-bit Session ID is the Enhanced SPI.

The base header 'Options' field is optional, its size is given in the fixed header field 'Opt Len' and may be zero if no options are present. When present the 'Options' field carries a variable number of type-length-value (TLV) encoded options. The format of these options has been derived from the IPv6 extension header options as defined in Section 4.2 of , with the following exceptions. No special meaning is attached to the top 3 bits of the option type value, and the processing order of the options is not restricted. Option type values are allocated from one of two ranges of values. One range is used for standardized option types and the second range is reserved for private options. This document defines 4 initial standard option types, 'Pad1 Option', 'PadN Option', 'Flow Identifier Option', and 'Crypt Offset Option'. These options are defined in section . Private options use 'Option Type' values from the private option reserved range and can be used for any purposes that are out of scope for standardization. For example they can be used to encode hardware specific information, such as used encryption/authentication algorithms as done in .

When options are present, padding options (i.e., 'Pad1' and 'PadN') MUST be used to align the fields following the 'Options' field. This alignment is dictated by the packet format. For the Full EESP packet format the 'Payload Info Header' must be 4 byte aligned. For the optimized packet format the alignment is given by the contained packet type, namely, 4 byte alignment for an IPv4 packet, and 8 byte alignment for IPv6 packet.

The 'Peer Header' follows the 'Base Header' and 'Options' field. The 'Peer Header' containing an optional 'Sequence Number' and an optional 'Initialization Vector', and the format is shown below. The Peer Header is private to the IPsec peers, Middleboxes MUST NOT act upon the Peer Header fields.

Peer Header When present, the 'Sequence Number' is a full 64bit sequence number. EESP only support 64bit sequence numbers, a.k.a ESN and transmits the entire sequence number on each packet. The actual size of the 'Initialization Vector' depends on the choice of the cipher suite. The 'Sequence Number' and 'Initialization Vector' fields are defined in the following sections.

This unsigned 64-bit field contains a counter value that increases by for each packet sent, i.e., a per-SA packet sequence number. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. The sequence number MUST strictly monotonic increase, sequence numbers MUST NOT repeat and MUST NOT cycle for any given SA. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^64nd packet on an SA. Implementations that do replay protection SHOULD increase the sequence number by one for each sent packet. Even if recommended to increase the sequence number by one, implementations MAY employ other methods to increase the sequence number, as long as the aforementioned requirements are met. Sharing an SA among multiple senders is permitted, though generally not recommended. EESP provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Unless any future Option defining this for a multi-sender SA, the anti-replay features of ESP are not available.

If the algorithm used to encrypt the payload requires cryptographic synchronization data, e.g., an Initialization Vector (IV), then this data is carried explicitly in front of the encrypted part of the packet in the 'Peer Header'. Any encryption algorithm that requires such explicit, per-packet synchronization data MUST indicate the length, any structure for such data, and the location of this data as part of an RFC specifying how the algorithm is used with EESP. (Typically, the IV immediately precedes the ciphertext. See Table 1) If such synchronization data is implicit, the algorithm for deriving the data MUST be part of the algorithm definition RFC. (If included, cryptographic synchronization data, e.g., an Initialization Vector (IV), usually is not encrypted per se (see Table 1), although it sometimes is referred to as being part of the ciphertext.) Counter mode algorithms MAY encode the 64-bit counter of the Initialization Vector (IV) on the Sequence number Field. This option saves 8 header bytes on each packet. Whether or not this option is selected is determined as part of Security Association (SA) establishment.

The Payload Info Header is present in the Full EESP packet format. This packet format is for use when the contained payload is not a single IPv4 or IPv6 packet (e.g., when using Transport Mode or IP-TFS). IPsec Peers and Middleboxes MAY act upon the Payload Info Header.

Payload Info Header

The Next Header is an 8-bit field that identifies the type of data contained in the Payload Data field, e.g., a next layer header and data. The value of this field is chosen from the set of IP Protocol Numbers defined on the web page of the IANA (e.g., a value of 6 indicates TCP and a value of 17 indicates UDP).

The Pad Length field indicates the number of pad bytes immediately following the payload data and is used to align the ICV field. The range of valid values is 0 to 255, where a value of zero indicates that no Padding bytes are present.

Payload Data is adapted from ESP and adjusted to apply to EESP. Payload Data is a variable-length field containing data from the original IP packet. The Payload Data field is mandatory and is an integral number of bytes in length. Note that the beginning of the next layer protocol header MUST be aligned relative to the beginning of the EESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes.

Padding is adapted from ESP and adjusted to apply to EESP. Two primary factors require or motivate use of the Padding field.

If an encryption algorithm is employed that requires the plaintext to be a multiple of some number of bytes, e.g., the block size of a block cipher, the Padding field is used to fill the plaintext (consisting of the Payload Data, Padding, Pad Length, and Next Header fields) to the size required by the algorithm.
Padding also may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary to make sure the ICV is properly aligned.

The sender MAY add 0 to 255 bytes of padding. Inclusion of the Padding field in an EESP packet is optional, subject to the requirements noted above, but all implementations MUST support generation and consumption of padding. For the purposes of ensuring that the ICV is aligned on a 4-byte boundary (second bullet above), the padding computation applies to the Payload Data inclusive of the Payload Info Header, if present. If a combined mode algorithm is used, any replicated data and ICV-equivalent data are included in the Payload Data covered by the padding computation. If Padding bytes are needed but the encryption algorithm does not specify the padding contents, then the following default processing MUST be used. The default processing follows exactly ESP as of . The Padding bytes are initialized with a series of (unsigned, 1-byte) integer values. The first padding byte appended to the plaintext is numbered 1, with subsequent padding bytes making up a monotonically increasing sequence: 1, 2, 3, .... When this padding scheme is employed, the receiver SHOULD inspect the Padding field. (This scheme was selected because of its relative simplicity, ease of implementation in hardware, and because it offers limited protection against certain forms of "cut and paste" attacks in the absence of other integrity measures, if the receiver checks the padding values upon decryption.) If an encryption or combined mode algorithm imposes constraints on the values of the bytes used for padding, they MUST be specified by the RFC defining how the algorithm is employed with ESP. If the algorithm requires checking of the values of the bytes used for padding, this too MUST be specified in that RFC.

Integrity Check Value is handled exactly as in ESP .

The resulting two packet formats are described in this section. When IPv4 or IPv6 tunnel mode is used, the 'Payload Info Header' MAY be omitted. In this optimized mode the payload will always start with an IPv4 or IPv6 header. IPv4 or IPv6 packets always start with a Version field at the first nibble, so it is possible to identify IPv4 and IPv6 by reading the first nibble of the inner packet, and there is no need for a next header field. Additionally, IPv4 and IPv6 also have a field describing the overall size of the inner packet, so a pad length field is also not needed as it can be derived. The packet format without the 'Payload Info Header' is called the "Optimized EESP packet format", while the packet format containing the 'Payload Info Header' is the called the "Full EESP packet format". Which of these two formats are chosen is encoded in the a 'Packet Format' bit in the 'Base Header'. The 2 packet formats are shown below. illustrates the resulting packet format for use with IPv4 or IPv6 Tunnel Mode when the 'Payload Info Header' is elided, and shows the full header version for use in all other modes of operation.

Optimized EESP packet format

Full EESP packet format [*] If included, cryptographic synchronization data, e.g., an 'Initialization Vector' (IV), usually is not encrypted per se, although it often is referred to as being part of the cipher-text. Unlike ESP, the IV is not considered to be a part of the payload data in EESP. If a combined algorithm mode is employed, the explicit IV shown in may be omitted. Because algorithms, modes and options are fixed when an SA is established, the detailed format of EESP packets for a given SA (including the 'Payload Data' substructure) is fixed for all traffic on the SA. The table below refers to the fields in the preceding figures and illustrate how several categories of algorithmic options, each with a different processing model, affect the fields noted above. The processing details are described in later sections. High level layout for fields of an EESP packet

Field	# of bytes	Req'd [1]	Encrypt Covers	Integ Covers	Tx'd
Base Header	8	M		Y	plain
Options	variable	O		Y	plain
Sequence Number	8	O		Y	plain
IV	variable	O		Y	plain
Payload Info Hdr[5]	4	O	Y	Y	cipher [3]
Payload [2]	variable	M or D	Y	Y	cipher [3]
Padding	0-255	M	Y	Y	cipher [3]
ICV Padding	variable	if need		Y	not Tx'd
ICV	variable	M [4]			plain

[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram. If beet mode -> IP datagram. If transport mode -> next header and data. If IP-TFS, IP-TFS header and payload.
[3] Ciphertext if encryption has been selected
[4] Mandatory if a separate integrity algorithm is used
[5] Not present in Optimized Header otherwise mandatory

In the table "optional" means that the field is omitted if the option is not selected, i.e., it is not present in the packet as transmitted or as formatted for computation of an ICV. Whether or not an option is selected is determined as part of Security Association (SA) establishment. Thus, the format of EESP packets for a given SA is fixed for the duration of the SA. In contrast, "mandatory" fields are always present in the EESP packet format for all SAs.

The EESP header 'Options' field carries a variable number of type-length-value (TLV) encoded "options" of the following format:

EESP Header Option Format

Option Type: 8-bit identifier of the type of option.
Opt Data Len: 8-bit unsigned integer. Length of the Option Data field of this option, in octets.
Option Data: Variable-length field. Option-Type-specific data.

This document defines two padding options 'Pad1' and 'PadN', a 'Flow Identifier Option', and a 'Crypt Offset Option'. Future documents can define additional options. Appendix A of contains applicable formatting guidelines for designing new options.

Individual options may have specific alignment requirements, to ensure that multi-octet values within Option Data fields fall on natural boundaries. The alignment requirement of an option is specified using the notation xn+y, meaning the 'Option Type' must appear at an integer multiple of x octets from the start of the 'Options' field, plus y octets. For example:

2n means any 2-octet offset from the start of the 'Options' field.
8n+2 means any 8-octet offset from the start of the 'Options' field, plus 2 octets.

Unless otherwise specified EESP options have no alignment requirements. There are two padding options which are used when necessary to align subsequent options and to pad out the containing options field. These padding options must be recognized by all implementations:

Pad1 Option Note: the format of the Pad1 option is a special case -- it does not have length and value fields. The 'Pad1' option is used to insert one octet of padding into the Options field. If more than one octet of padding is required, the 'PadN' option, described next, should be used, rather than multiple 'Pad1' options.

PadN Option The 'PadN' option is used to insert two or more octets of padding into the 'Options' field. For N octets of padding, the Opt Data Len field contains the value N-2, and the 'Option Data' consists of N-2 zero-valued octets.

Flow Identifier (FID) 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 by IKEv2 or another suitable protocol. The detailed specification of FIDs MAY be provided in subsequent documents. The precise meaning of a FID is opaque to intermediate devices; however, intermediate devices MAY use it for identifying flows for ECMP or similar purposes. e.g. Sub-Child SAs, in could be encoded here.

Flow Identifier Option

Option Type: 8 bits: See
Option Length: 8 bits: See
FID: Variable length, carries characteristic information of the inner flow and MUST NOT change within a given SA.

This option is typically used for within one Datacenter use case such as .

Crypt Offset Option

Option Type: 8 bits: See
Option Length: 8 bits: See
Payload Offset: 6 bits: The offset from the start of the fixed header to the start of the payload header (or the payload for optimized packet format) measured in 4-octet units.
R[eserved]: 2-bits: Reserved MUST be sent 0 and ignored on receipt.
CryptOffset: 6 bits: The offset from the start of the payload header (or the payload for optimized packet format) to the start of the encrypted portion of the packet, measured in 4-octet units. The resulting value MUST NOT be larger than the size of the inner packet.
F[lags]: 2-bits: Flags used for stateless crypto signaling such as the S-bit and D-bit in the PSP specification. QUESTION: Is this used and thus still required by PSP, or can it be removed?

In large-scale deployments, such as data center traffic, stateful IPsec using databases outlined in and can become a performance bottleneck. Traditional IPsec implementations typically maintain three databases: the Security Association Database (SAD), the Security Policy Database (SPD), and the Peer Authorization Database (PAD). SAD and SPD are used in the data path for each packet, while PAD is used to derive and/or exchange keys. Additionally, both the SAD and SPD are divided into two paths: one for sending and another for receiving. A high data rate, combined with frequent changes in the SAD and SPD, can slow down the system. As the data flow increases, adding and removing entries in the control plane creates locking issues and contention in both software and hardware. These operations are resource-intensive and can cause bottlenecks due to software locks or limited hardware insertion speeds, such as memory bandwidth or content-addressable memory limits. These problems are more noticeable in high-speed data paths, where delays from locking can severely affect performance.

When using Stateless Encryption, implementations can bypass the monolithic SAD in the receiving path. Using fields from the EESP packet's SPI + Session ID, the Session ID contains the context ID used by stateless encryption hardware to directly decrypt a packet at line rate, without needing to consult the receive-side SAD on a per-packet basis. For the receiving side, the system may be stateless, as specified in . In this approach, packets are decrypted and authenticated directly, without requiring SAD lookups for each packet. However, Security Policy validation MUST be done later in the stack using policies specified in the socket or route. stateless encryption not only reduces CPU overhead but also reduces stateful checks (such as anti-replay protection or sequence number tracking, packet limit). These checks can be offloaded to hardware or handled asynchronously, further optimizing performance in high-throughput environments like large data centers.

The sending-side Security Policy and symetric key can be associated with a local socket or route instead of a monolithic SPD and SAD. A send call could preappend crypto parameters for stateless encryption and encapsulation in hardware to plain text data.

The data path does not use the PAD, but it is used for key derivation. The Key Derivation Function (KDF) is outside the scope of this document. However, IKEv2 can handle key derivation.

TBD

This document requests IANA allocate an IP protocol number from "Protocol Numbers - Assigned Internet Protocol Numbers" registry

Decimal: TBD
Keyword: EESP
Protocol: Enhanced Encapsulating Security Payload
Reference: This document

This document requests IANA to create a registry called "EESP_OPTIONS Type Registry" under a new category named "EESP_OPTIONS Parameters".

Name: EESP Options Registry
Description: EESP Base Header Options
Reference: This document

The initial content for this registry is as follows:

Initial Registry Values

[Note to RFC Editor: Please remove this section and the reference to 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 . 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 , "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 .

In this section we discuss the security properties of EESP: TBD

TBD