IPSECME Working Group S. Klassert
Internet-Draft A. Antony
Intended status: Standards Track secunet
Expires: 17 April 2025 C. Hopps
LabN Consulting, L.L.C.
14 October 2024
Enhanced Encapsulating Security Payload (EESP)
draft-klassert-ipsecme-eesp-01
Abstract
This document describes the Enhanced Encapsulating Security Payload
(EESP) protocol, which builds on the existing IP Encapsulating
Security Payload (ESP) protocol. It is designed to modernize and
overcome limitations in the ESP protocol.
EESP adds Session IDs (e.g., to support CPU pinning and stateless
encryption), changes some previously mandatory fields to optional,
and moves the ESP trailer into the EESP header. Additionally, EESP
adds header options adapted from IPv6 to allow for future extension.
New header options are defined which add Flow IDs (e.g., for CPU
pinning and QoS support), and a crypt-offset to allow for exposing
inner flow information for middlebox use.
Status of This Memo
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 17 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Klassert, et al. Expires 17 April 2025 [Page 1]
Internet-Draft EESP October 2024
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4
2.1. EESP packet format . . . . . . . . . . . . . . . . . . . 5
2.2. Base Header . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Fixed Base Header . . . . . . . . . . . . . . . . . . 6
2.2.2. Base Header Options . . . . . . . . . . . . . . . . . 7
2.3. Peer Header . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Sequence Number . . . . . . . . . . . . . . . . . . . 8
2.3.2. Initialization Vector . . . . . . . . . . . . . . . . 9
2.4. Payload Info Header . . . . . . . . . . . . . . . . . . . 9
2.4.1. Next Header . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. Pad Length . . . . . . . . . . . . . . . . . . . . . 10
2.5. Payload Data . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Padding (for Encryption) . . . . . . . . . . . . . . . . 10
2.7. Integrity Check Value (ICV) . . . . . . . . . . . . . . . 11
2.8. Full and Optimized Packet Formats . . . . . . . . . . . . 11
3. EESP Header Options . . . . . . . . . . . . . . . . . . . . . 15
3.1. EESP Option Types . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Padding Options . . . . . . . . . . . . . . . . . . . 15
3.1.2. EESP Flow Identifier Option . . . . . . . . . . . . . 16
3.1.3. EESP Crypt Offset Option . . . . . . . . . . . . . . 17
4. Enhanced Encapsulating Security Protocol Processing . . . . . 18
4.1. Stateless Encryption . . . . . . . . . . . . . . . . . . 18
Klassert, et al. Expires 17 April 2025 [Page 2]
Internet-Draft EESP October 2024
4.1.1. Receiving without SAD . . . . . . . . . . . . . . . . 18
4.1.2. Sending without SPD . . . . . . . . . . . . . . . . . 19
4.1.3. Peer Authentication Database . . . . . . . . . . . . 19
5. UDP Encapsulation . . . . . . . . . . . . . . . . . . . . . . 19
6. IKEv2 Negotiation . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.1. EESP IP Protocol Number . . . . . . . . . . . . . . . . . 19
7.2. EESP Options Registry . . . . . . . . . . . . . . . . . . 19
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. Normative References . . . . . . . . . . . . . . . . . . . . 21
12. Informative References . . . . . . . . . . . . . . . . . . . 21
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
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
[I-D.ponchon-ipsecme-anti-replay-subspaces] and
[I-D.he-ipsecme-vpn-shared-ipsecsa]. 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 [PSP] 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 [I-D.ponchon-ipsecme-anti-replay-subspaces] or
[I-D.he-ipsecme-vpn-shared-ipsecsa] 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 [RFC9347] SHOULD be used instead. A detailed
discussion about the problems of the ESP protocol can be found in
[I-D.mrossberg-ipsecme-multiple-sequence-counters].
Klassert, et al. Expires 17 April 2025 [Page 3]
Internet-Draft EESP October 2024
EESP follows the Security Architecture for the Internet Protocol
[RFC4301] and uses ESP as of [RFC4303] 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 [RFC4303]. EESP neither updates nor obsoletes
[RFC4303].
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 [PSP], and offers versioning at the packet level.
1.1. Requirements Language
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 [RFC2119].
1.2. Terminology
This document uses the following terms defined in IKEv2 [RFC7296]:
Child SA, CREATE_CHILD_SA, 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.
2. Protocol Definition
In this section we define the exact protocol formats and operations.
This section is normative.
Klassert, et al. Expires 17 April 2025 [Page 4]
Internet-Draft EESP October 2024
2.1. EESP packet format
The (outer) protocol header (IPv4, IPv6, or Extension) that
immediately precedes the ESP header SHALL contain the value TBD in
its [Protocol] (IPv4) or Next Header (IPv6, Extension) field.
Figure 1 illustrates the top-level format of an EESP packet. The
EESP header is split into multiple parts.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Base Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Peer Header (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Info Header (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data (variable) |
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Integrity Check Value-ICV (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: 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'.
Klassert, et al. Expires 17 April 2025 [Page 5]
Internet-Draft EESP October 2024
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 [RFC4303]). The length of this ICV
depends on the Crypto suite.
2.2. Base Header
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.
2.2.1. Fixed Base Header
The fixed portion of the base header is defined as follows.
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 |1| Opt Len | Session ID + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: 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
Klassert, et al. Expires 17 April 2025 [Page 6]
Internet-Draft EESP October 2024
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.
2.2.2. Base Header Options
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 [RFC8200], 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 Section 3.1.
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 [PSP].
2.2.2.1. Options Field End-Alignment
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.
Klassert, et al. Expires 17 April 2025 [Page 7]
Internet-Draft EESP October 2024
2.3. Peer Header
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 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.
2.3.1. Sequence Number
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
Klassert, et al. Expires 17 April 2025 [Page 8]
Internet-Draft EESP October 2024
are not available.
2.3.2. Initialization Vector
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.
2.4. Payload Info Header
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | Reserved | Next Header | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Payload Info Header
2.4.1. Next 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).
Klassert, et al. Expires 17 April 2025 [Page 9]
Internet-Draft EESP October 2024
2.4.2. Pad Length
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.
2.5. Payload Data
Payload Data is adapted from ESP [RFC4303] 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.
2.6. Padding (for Encryption)
Padding is adapted from ESP [RFC4303] 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.
Klassert, et al. Expires 17 April 2025 [Page 10]
Internet-Draft EESP October 2024
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
[RFC4303]. 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.
2.7. Integrity Check Value (ICV)
Integrity Check Value is handled exactly as in ESP [RFC4303].
2.8. Full and Optimized Packet Formats
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. Figure 5 illustrates the
resulting packet format for use with IPv4 or IPv6 Tunnel Mode when
the 'Payload Info Header' is elided, and Figure 6 shows the full
header version for use in all other modes of operation.
Klassert, et al. Expires 17 April 2025 [Page 11]
Internet-Draft EESP October 2024
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 |1| Opt Len | Session ID + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Options (variable, optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV* (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv4/IPv6 Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L4 Payload Data (variable) |
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Integrity Check Value-ICV (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Optimized EESP packet format
Klassert, et al. Expires 17 April 2025 [Page 12]
Internet-Draft EESP October 2024
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 |0| Opt Len | Session ID + |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Options (variable, optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV* (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | Reserved | Next Header | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L4 Payload Data (variable) |
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Integrity Check Value-ICV (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: 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
Table 1 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.
Klassert, et al. Expires 17 April 2025 [Page 13]
Internet-Draft EESP October 2024
+=============+============+===========+=========+========+========+
| Field | # of bytes | Req'd [1] | Encrypt | Integ | Tx'd |
| | | | Covers | Covers | |
+=============+============+===========+=========+========+========+
| Base Header | 8 | M | | Y | plain |
+-------------+------------+-----------+---------+--------+--------+
| Options | variable | O | | Y | plain |
+-------------+------------+-----------+---------+--------+--------+
| Sequence | 8 | O | | Y | plain |
| Number | | | | | |
+-------------+------------+-----------+---------+--------+--------+
| IV | variable | O | | Y | plain |
+-------------+------------+-----------+---------+--------+--------+
| Payload | 4 | O | Y | Y | cipher |
| Info Hdr[5] | | | | | [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 |
+-------------+------------+-----------+---------+--------+--------+
Table 1: High level layout for fields of an EESP packet
* [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.
Klassert, et al. Expires 17 April 2025 [Page 14]
Internet-Draft EESP October 2024
3. EESP Header Options
The EESP header 'Options' field carries a variable number of type-
length-value (TLV) encoded "options" of the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 7: 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.
3.1. EESP Option Types
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 [RFC8200] contains
applicable formatting guidelines for designing new options.
3.1.1. Padding 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:
3.1.1.1. Pad1 option
Klassert, et al. Expires 17 April 2025 [Page 15]
Internet-Draft EESP October 2024
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Figure 8: 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.
3.1.1.2. PadN option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Figure 9: 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.
3.1.2. EESP Flow Identifier Option
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 [I-D.mrossberg-ipsecme-multiple-sequence-counters] could be
encoded here.
Klassert, et al. Expires 17 April 2025 [Page 16]
Internet-Draft EESP October 2024
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ Flow Identifier (FID) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Flow Identifier Option
Option Type 8 bits: See Section 3
Option Length 8 bits: See Section 3
FID Variable length, carries characteristic information of the inner
flow and MUST NOT change within a given SA.
3.1.3. EESP Crypt Offset Option
This option is typically used for within one Datacenter use case such
as [PSP].
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 |Payl.Offset| R |CryptOffset| F |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Crypt Offset Option
Option Type 8 bits: See Section 3
Option Length 8 bits: See Section 3
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.
Klassert, et al. Expires 17 April 2025 [Page 17]
Internet-Draft EESP October 2024
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?
4. Enhanced Encapsulating Security Protocol Processing
4.1. Stateless Encryption
In large-scale deployments, such as data center traffic, stateful
IPsec using databases outlined in [RFC4301] and [RFC4303] 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.
4.1.1. Receiving without SAD
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 [Encryption]
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 [PSP]. 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.
Klassert, et al. Expires 17 April 2025 [Page 18]
Internet-Draft EESP October 2024
4.1.2. Sending without SPD
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.
4.1.3. Peer Authentication Database
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 [RFC7296] can handle key
derivation.
5. UDP Encapsulation
TBD
6. IKEv2 Negotiation
TBD
7. IANA Considerations
7.1. EESP IP Protocol Number
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
7.2. EESP Options Registry
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
Klassert, et al. Expires 17 April 2025 [Page 19]
Internet-Draft EESP October 2024
The initial content for this registry is as follows:
Value EESP Header Options Types Reference
------- ------------------------------ ---------------
0 Pad1 [this document]
1 PadN [this document]
2 Crypt Offset [this document]
3 FID [this document]
4-223 Unassigned [this document]
224-255 Private [this document]
Figure 12: Initial Registry Values
8. Implementation Status
[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].
9. Security Considerations
In this section we discuss the security properties of EESP: TBD
Klassert, et al. Expires 17 April 2025 [Page 20]
Internet-Draft EESP October 2024
10. Acknowledgments
TBD
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for
Encapsulating Security Payload (ESP) and Its Use for IP
Traffic Flow Security (IP-TFS)", RFC 9347,
DOI 10.17487/RFC9347, January 2023,
<https://www.rfc-editor.org/info/rfc9347>.
12. Informative References
[Encryption]
IANA, "IKEv2 Parameters",
<https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml#ikev2-parameters-5>.
Klassert, et al. Expires 17 April 2025 [Page 21]
Internet-Draft EESP October 2024
[I-D.he-ipsecme-vpn-shared-ipsecsa]
He, Q., Pan, W., Chen, X., and B. Ding, "Shared Use of
IPsec Tunnel in a Multi-VPN Environment", Work in
Progress, Internet-Draft, draft-he-ipsecme-vpn-shared-
ipsecsa-01, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-he-ipsecme-
vpn-shared-ipsecsa-01>.
[I-D.mrossberg-ipsecme-multiple-sequence-counters]
Rossberg, M., Klassert, S., and M. Pfeiffer, "Broadening
the Scope of Encapsulating Security Payload (ESP)
Protocol", Work in Progress, Internet-Draft, draft-
mrossberg-ipsecme-multiple-sequence-counters-02, 15
February 2024, <https://datatracker.ietf.org/doc/html/
draft-mrossberg-ipsecme-multiple-sequence-counters-02>.
[I-D.ponchon-ipsecme-anti-replay-subspaces]
Ponchon, P., Shaikh, M., Dernaika, H., Pfister, P., and G.
Solignac, "IPsec and IKE anti-replay sequence number
subspaces for traffic-engineered paths and multi-core
processing", Work in Progress, Internet-Draft, draft-
ponchon-ipsecme-anti-replay-subspaces-03, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ponchon-
ipsecme-anti-replay-subspaces-03>.
[Protocol] IANA, "Assigned Internet Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>.
[PSP] Google, "PSP Architecture Specification",
<https://github.com/google/psp/blob/main/doc/
PSP_Arch_Spec.pdf>.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
Appendix A. Additional Stuff
TBD
Authors' Addresses
Klassert, et al. Expires 17 April 2025 [Page 22]
Internet-Draft EESP October 2024
Steffen Klassert
secunet Security Networks AG
Email: steffen.klassert@secunet.com
Antony Antony
secunet Security Networks AG
Email: antony.antony@secunet.com
Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org
Klassert, et al. Expires 17 April 2025 [Page 23]