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.
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.
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.
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), Virtual 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.
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 Protocol (IPv4) or Next Header (IPv6, Extension) field. eesp-top-level-packet-format 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) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 RFC4303). 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.
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 | Flags | Opt Len | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Version
- 5 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).
- Flags
- 6 bit: The Flags field is used as specified in flags.
- Opt Len
- 5 bits: Length in 4 bytes of the
Optionsfield. - Session ID
- 16 bit: The Session ID covers additional information that might be used to identify the SA and to route the packet to the correct stateless crypto context. For instance, it can be used to encode a Replay Subspace ID or, if a Key Derivation Function (KDF) is used to 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. This document defines the use of the Session ID as a Replay Subspace ID. Other usecases are not covered in this document.
- 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 Flags field in the fixed Base Header is defined as follows:
0 1 2 3 4 5 6 +-+-+-+-+-+-+-+ |F|C|S| R | +-+-+-+-+-+-+-+
- Packet Format (F)
- 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. - Payload Encryption Mode
- 1 bit: If set, the following Layer 4 Header is authenticated, but not encrypted. This bit MUST be set to 0 on any mode other than payload encryption mode . The receiver MUST drop packets with this bit set, if the mode is different to payload encryption mode. See Payload Encryption Mode Processing
- Sequence Number absent (S)
- 1 bit: If set, the peer header does not carry the sequence number field in the packet. This bit MUST be set to the same value for all packets on a given SA.
- Reserved (R)
- 4 bits: Reserved for future versions, MUST be set to 0, and ignored by the receiver.
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 EESP Option Types.
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.
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.
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) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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 EESP 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.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 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.
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.
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.
The Integrity Check Value is a variable-length field computed over the EESP header, and Payload. The ICV field is optional. It is present only if the integrity service is selected and is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. The length of the field is specified by the integrity algorithm selected and associated with the SA. The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.
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. eesp-optimized-packet-format
illustrates the resulting packet format for use with IPv4 or IPv6
Tunnel Mode when the Payload Info Header is elided, and
eesp-full-packet-format shows the full header version for use in all
other modes of operation.
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 | Flags | 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) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Flags | 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) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[*] 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
eesp-packet-separate-algos 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.
| Field | # of bytes | Req’d [1] | Encrypt Covers | Integ Covers | Tx’d |
| <l> | <c> | <c> | <c> | <c> | <c> |
|---|---|---|---|---|---|
| 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.
This section specifies the use of the Session ID as a Replay Subspace ID. The use of the Session ID as a Replay Subspace ID MUST be negotiated by IKEv2, or any other suitable protocol. In this case, Session ID is used as a 16 bits Replay Subspace ID. Replay Subspaces were intially defined in I-D.ponchon-ipsecme-anti-replay-subspaces.
Each number of the 16 bits Replay Subspace ID encodes a single 64 bit anti-replay sequence number space. This means that each core, path, or QoS class, or any combination of those, can then use their own unique anti-replay sequence number subspace. Each anti-replay sequence number subspace uses Sequence Numbers as specified in section Sequence Number.
To make sure that at most 2^64 sequence numbers are used for a given key, a KDF MUST be used used to derive a separate key for each anti-replay sequence number subspace. In this case, the full 64 bits of each anti-replay sequence number subspace can be used.
# ##+caption: Sequence Number with Replay Subspace ID ##+name: seq-nr-subspace ##+begin_src
##+end_src # #- Replay Subspace ID :: 16 bits: #- Sequence Numbber :: 48 bits:
This section defines the IPsec sender’s behavior when transmitting packets using an IPsec Child SA that has been previously configured or negotiated with IKE to use at most N different sequence number subspace IDs.
The sender MAY set the sequence number subspace ID to any value between 0 and N-1. How the different subspace IDs are used is up to the implementation, but as an example, the sender could use different subspace ID values per path or per processing core (or combination of both).
The sender MUST NOT use any subspace ID values greater or equal to N (since the IPsec Child SA has been configured to use at most N different values). This requirement was introduced to improve the implementation performance, as opposed to allowing the sender to use arbitrary subspace ID values.
The sender MUST maintain one sequence number counter per sequence number subspace that it makes use of. But the sender MAY use only some (and as few as a single one) of the available N subspace ID values between 0 and N-1.
When transmitting a packet, the sender MUST use the sequence number counter associated with the sequence number subspace in use for that packet.
This section defines the IPsec receiver’s behavior when receiving packets using an IPsec SA that has been previously configured or negotiated to use at most N different sequence number subspace IDs.
The receiver MUST maintain one anti-replay window and counter for each sequence number subspace being used.
When receiving a packet, the receiver MUST use the anti-replay window and counter associated with the sequence number subspace identified with the subspace ID field.
The receiver MUST drop any packet received with a subpace ID value greater or equal to N. Such packets SHOULD be counted for reporting.
Note: Since the sender may decide to only use a subset of the available N subspace values, the receiver MAY reactively allocate an anti-replay window when receiving the first packet for a given subspace. When doing so, the receiver SHOULD first check the authenticity of the packet before allocating the new anti-replay window.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
- 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 RFC8200 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
Optionsfield. - 8n+2 means any 8-octet offset from the start of the
Optionsfield, 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:
+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
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 I-D.mrossberg-ipsecme-multiple-sequence-counters could be encoded here.
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) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Option Type
- 8 bits: See EESP Header Options
- Option Length
- 8 bits: See EESP Header Options
- FID
- Variable length, carries characteristic information of a inner flow and MUST NOT change for a given inner flow within a SA.
Flow Identifiers characterize the inner i.e. the protected flows. Packets of these flows should not be reordered while EESP protected. Therefore, if a Flow Identifier is used in combination with replay protection, it MUST replicate the 16 bit Replay Subspace ID from the Session ID to the Flow Identifier.
NOTE STK: Is the above text clear?
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 | Replay Subspace ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | ~ Flow Identifier (FID) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Option Type
- 8 bits: See EESP Header Options
- Option Length
- 8 bits: See EESP Header Options
- Replay Subspace ID
- 16 bits:
- FID
- Variable length, carries characteristic information of a inner flow and MUST NOT change for a given inner flow within a SA.
This option is typically used for within one Datacenter use case such as PSP.
NOTE: This is for the use in Datacenters ONLY. It might be moved to a separate document that defines the ‘EESP use for Datacenters’.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Option Type
- 8 bits: See EESP Header Options
- Option Length
- 8 bits: See EESP Header Options
- 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?
EESP may be employed in multiple ways. To secure end-to-end network traffic, transport mode and payload encryption mode may be used. For the VPN usecse, tunnel and beet mode may be employed.
Layer 4 Encapsulation Modes are transport mode, BEET mode and payload encryption mode. Layer 4 Encapsulation Modes distinguish from tunnel mode on the position of the EESP header in the packet. On Layer 4 Encapsulation Modes the EESP header is inserted between the original IPv4/IPv6 header and the following Layer 4 header. In contrast to this, in tunnel mode the full ipv4/IPv6 dataggram is encapsulated. This means the the ESP header is placed in front of the original IPv4/IPv6 dataggram and a new ‘outer IPv4/IPv6 header’ is added in front of the EESP header. The following sections illustrate the positioning of the EESP header
Note that in Layer 4 Encapsulation Modes, for “bump-in-the-stack” or “bump-in- the-wire” implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may require an IPsec implementation to perform extra IP reassembly/fragmentation in order to both conform to this specification and provide transparent IPsec support. Special care is required to perform such operations within these implementations when multiple interfaces are in use.
In transport mode, EESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol. (If AH is also applied to a packet, it is applied to the EESP header, Payload and ICV, if present.) (Note that the term “transport” mode should not be misconstrued as restricting its use to TCP and UDP.) The following diagram illustrates EESP transport mode positioning for a typical IPv4 packet, on a “before and after” basis. (This and subsequent diagrams in this section show the ICV field, the presence of which is a function of the security services and the algorithm/mode selected.)
BEFORE APPLYING EESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING EESP
---------------------------------------------------
IPv4 |orig IP hdr | EESP | | | EESP |
|(any options)| Hdr | TCP | L4 pyld Data | ICV |
---------------------------------------------------
|<---- encryption --->|
|<-------- integrity ------->|
In the IPv6 context, EESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers. Destination options extension header(s) could appear before, after, or both before and after the EESP header depending on the semantics desired. However, because EESP protects only fields after the EESP header, it generally will be desirable to place the destination options header(s) after the EESP header. The following diagram illustrates EESP transport mode positioning for a typical IPv6 packet.
BEFORE APPLYING EESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING EESP
----------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,|EESP|dest| | Layer 4 |EESP|
|IP hdr|routing,fragment.|Hdr |opt*|TCP|Payload Data|ICV |
----------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------->|
* = if present, could be before EESP, after EESP, or both
In payload encryption mode, EESP is inserted exactly at the same position as it is done for transport mode. The only difference to transport mode is that the next layer protocol header following the original IP or IPv6 header is left in cleartext. Additionally to that, the ‘C’ bit in the EESP header flags is set.
The following diagrams illustrate EESP payload encryption mode positioning for a typical IPv4 and IPv6 packet, on a “before and after” basis.
BEFORE APPLYING EESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING EESP
----------------------------------------------------
IPv4 |orig IP hdr | EESP | | | EESP |
|(any options)| Hdr | TCP | L4 pyld Data | ICV |
----------------------------------------------------
|<- encryption ->|
|<-------- integrity -------->|
BEFORE APPLYING EESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING EESP
--------------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,|EESP|dest| | Layer 4 |EESP|
|IP hdr|routing,fragment.|Hdr |opt*|TCP| Payload Data |ICV |
--------------------------------------------------------------
|<- encryption ->|
|<-------- integrity --------->|
* = if present, could be before EESP, after EESP, or both
In BEET mode, EESP is inserted exactly at the same position as it is done for transport mode. The original IP or IPv6 header is relaced by a new one. The new header SHOULD be negotiated by IKEv2 or any other suitable protocol.
Some more text here…
BEFORE APPLYING EESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING EESP
---------------------------------------------------
IPv4 | new IP hdr | EESP | | | EESP |
|(any options)| Hdr | TCP | L4 pyld Data | ICV |
---------------------------------------------------
|<---- encryption --->|
|<-------- integrity ------->|
BEFORE APPLYING EESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING EESP
----------------------------------------------------------
IPv6 | new |hop-by-hop,dest*,|EESP|dest| | Layer 4 |EESP|
|IP hdr|routing,fragment.|Hdr |opt*|TCP|Payload Data|ICV |
----------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------->|
* = if present, could be before EESP, after EESP, or both
In tunnel mode, the “inner” IP header carries the ultimate (IP) source and destination addresses, while an “outer” IP header contains the addresses of the IPsec “peers”, e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, EESP protects the entire inner IP packet, including the entire inner IP header. The position of EESP in tunnel mode, relative to the outer IP header, is the same as for EESP in transport mode. The following diagram illustrates EESP tunnel mode positioning for typical IPv4 and IPv6 packets.
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
The mandatory-to-implement algorithms for use with EESP are the same as for ESP and described in a separate RFC, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for EESP, MAY be supported. Note that although both confidentiality and integrity are optional, at least one of these services MUST be selected, hence both algorithms MUST NOT be simultaneously NULL.
STK NOTE: Is the above ok, or should we mandate for both confidentiality and integrity???
The encryption algorithm employed to protect an EESP packet is specified by the SA via which the packet is transmitted/received. Because IP packets may arrive out of order, and not all packets may arrive (packet loss), each packet must carry any data required to allow the receiver to establish cryptographic synchronization for decryption. This data may be carried explicitly, e.g., as an IV (as described above), or the data may be derived from the plaintext portions of the (outer IP or EESP) packet header. (Note that if plaintext header information is used to derive an IV, that information may become security critical and thus the protection boundary associated with the encryption process may grow.
For example, if one were to use the EESP Sequence Number to derive an IV, the Sequence Number generation logic (hardware or software) would have to be evaluated as part of the encryption algorithm implementation. In the case of FIPS 140-2 NIST01, this could significantly extend the scope of a cryptographic module evaluation.)
Because EESP makes provision for padding of the plaintext, encryption algorithms employed with EESP may exhibit either block or stream mode characteristics. Note that because encryption (confidentiality) MAY be an optional service (e.g., integrity-only EESP), this algorithm MAY be “NULL” RFC4301.
STK NOTE Again: Is the above ok, or should we mandate for both confidentiality and integrity???
To allow an EESP implementation to compute the encryption padding required by a block mode encryption algorithm, and to determine the MTU impact of the algorithm, the RFC for each encryption algorithm used with EESP must specify the padding modulus for the algorithm.
The integrity algorithm employed for the ICV computation is specified by the SA via which the packet is transmitted/received. As was the case for encryption algorithms, any integrity algorithm employed with EESP must make provisions to permit processing of packets that arrive out of order and to accommodate packet loss. The same admonition noted above applies to use of any plaintext data to facilitate receiver synchronization of integrity algorithms. Note that because the integrity service MAY be optional, this algorithm may be “NULL”.
STK NOTE Again: Is the above ok, or should we mandate for both confidentiality and integrity???
To allow an EESP implementation to compute any implicit integrity algorithm padding required, the RFC for each algorithm used with EESP must specify the padding modulus for the algorithm.
If a combined mode algorithm is employed, both confidentiality and integrity services are provided. As was the case for encryption algorithms, a combined mode algorithm must make provisions for per- packet cryptographic synchronization, to permit decryption of packets that arrive out of order and to accommodate packet loss. The means by which a combined mode algorithm provides integrity for the payload, and for the SPI and Sequence Number fields, may vary for different algorithm choices. In order to provide a uniform, algorithm-independent approach to invocation of combined mode algorithms, no payload substructure is defined. For example, the SPI and Sequence Number fields might be replicated within the ciphertext envelope and an ICV may be appended to the EESP payload data. None of these details should be observable externally.
To allow an EESP implementation to determine the MTU impact of a combined mode algorithm, the RFC for each algorithm used with EESP must specify a (simple) formula that yields encrypted payload size, as a function of the plaintext payload and sequence number sizes.
In transport mode, the sender encapsulates the next layer protocol information behind the EESP header fields, and retains the specified IP header (and any IP extension headers in the IPv6 context). In tunnel mode, the outer and inner IP header/extensions can be interrelated in a variety of ways. The construction of the outer IP header/extensions during the encapsulation process is described in the Security Architecture document.
EESP is applied to an outbound packet only after an IPsec implementation determines that the packet is associated with an SA that calls for EESP processing. The process of determining what, if any, IPsec processing is applied to outbound traffic is described in the Security Architecture document.
In this section, we speak in terms of encryption always being applied because of the formatting implications. This is done with the understanding that “no confidentiality” is offered by using the NULL encryption algorithm (RFC 2410). There are several algorithmic options.
If separate confidentiality and integrity algorithms are employed, the Sender proceeds as follows:
- Encapsulate (into the EESP Payload field):
- for transport, beet and payload encryption mode – just the original next layer protocol information.
- for tunnel mode – the entire original IP datagram.
- XXX Add beet any payload enc mode
- Add any necessary encryption padding
- Encrypt the result using the key, encryption algorithm,
and algorithm mode specified for the SA and using any
required cryptographic synchronization data.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the encryption algorithm per the algorithm specification and placed in the Payload field.
- If implicit cryptographic synchronization data is employed, it is constructed and input to the encryption algorithm as per the algorithm specification.
- If integrity is selected, encryption is performed first, before the integrity algorithm is applied, and the encryption does not encompass the ICV field. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service (DoS) attacks. It also allows for the possibility of parallel processing of packets at the receiver, i.e., decryption can take place in parallel with integrity checking. Note that because the ICV is not protected by encryption, a keyed integrity algorithm must be employed to compute the ICV.
- Compute the ICV over the EESP packet minus the ICV field. Thus, the ICV computation encompasses the, base header including any options (if present), SPI, Sequence Number (if present), IV (if present), Payload Info Header (if present), Payload Data and Padding (if present).
For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a block size specified by the algorithm. If the length of EESP packet (as described above) does not match the block size requirements for the algorithm, implicit padding MUST be appended to the end of the EESP packet. (This padding is added after the Payload field) The block size (and hence the length of the padding) is specified by the integrity algorithm specification.
NOTE: This needs review!!! This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this question, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm’s block size.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
If a combined confidentiality/integrity algorithm is employed, the Sender proceeds as follows:
- Encapsulate into the ESP Payload Data field:
- for transport, beet and payload encryption mode – just the original next layer protocol information.
- for tunnel mode – the entire original IP datagram.
- Add any necessary (encryption) Padding.
- Encrypt and integrity protect the result using the key
and combined mode algorithm specified for the SA and using
any required cryptographic synchronization data.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is input to the combined mode algorithm per the algorithm specification and placed in the IV field of the peer header.
- If implicit cryptographic synchronization data is employed, it is constructed and input to the encryption algorithm as per the algorithm specification.
- The Sequence Number (if present) and the SPI are inputs to the algorithm, as they must be included in the integrity check computation. The means by which these values are included in this computation are a function of the combined mode algorithm employed and thus not specified in this standard.
- The (explicit) ICV field MAY be a part of the ESP packet format when a combined mode algorithm is employed. If one is not used, an analogous field usually will be a part of the ciphertext payload. The location of any integrity fields, and the means by which the Sequence Number and SPI are included in the integrity computation, MUST be defined in an RFC that defines the use of the combined mode algorithm with EESP. NOTE STK: Do we need to update RFC4106, RFC 4543, RFC 6054 etc.?
Replay protection is negotiated by the IPsec peers. If a SA chooses to do replay ptotection, the sequence numbers are generated in the following way.
The sender’s counter SHOULD be initialized to 0 when an SA is established. The sender increments the sequence number counter for this SA and inserts this value into the Sequence Number field of the Peer Header. Thus, the first packet sent using a given SA will contain a sequence number of 1. However, peers MAY choose dfferent replay protection algorithms, i.e. not by using sequence numbers that are incremented by one for each packet. In case the peers choose such an agloritthm, the sender MUST ensure that the sequence number is strictly monotonic increasing.
The sender checks to ensure that the counter has not cycled before inserting the new value in the Sequence Number field. In other words, the sender MUST NOT send a packet on an SA if doing so would cause the sequence number to cycle. An attempt to transmit a packet that would result in sequence number overflow is an auditable event. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, and (in IPv6) the cleartext Flow ID.
Typical behavior of an EESP implementation calls for the sender to establish a new SA when the Sequence Number cycles, or in anticipation of this value cycling.
If the key used to compute an ICV is manually distributed, a compliant implementation SHOULD NOT provide anti-replay service. If a user chooses to employ anti-replay in conjunction with SAs that are manually keyed, the sequence number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced.
If necessary, fragmentation is performed after EESP processing within an IPsec implementation. Thus, transport, beet and payload encryption mode EESP is applied only to whole IP datagrams (not to IP fragments). An IP packet to which EESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to EESP processing at a receiver. In tunnel mode, EESP is applied to an IP packet, which may be a fragment of an IP datagram. For example, a security gateway or a “bump-in-the-stack” or “bump-in-the-wire” IPsec implementation (as defined in the Security Architecture document) may apply tunnel mode EESP to such fragments.
NOTE: For Layer 4 Encapsulation Modes – As mentioned at the end of Layer 4 Encapsulation Modes, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet fragmented by the local IP layer, then apply IPsec, and then fragment the resulting packet.
NOTE: For IPv6 – For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing.
Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance. Moreover, the requirement for an EESP receiver to accept fragments for reassembly creates denial of service vulnerabilities. Thus, an EESP implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an EESP implementation MUST support generation of ICMP PMTU messages (or equivalent internal signaling for native host implementations) to minimize the likelihood of fragmentation. Details of the support required for MTU management are contained in the Security Architecture document.
If required, reassembly is performed prior to EESP processing. If a packet offered to EESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
NOTE: For packet reassembly, the current IPv4 spec does NOT require either the zeroing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. In order for a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet.
Upon receipt of a packet containing an EESP Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.1. If an implementation supports multicast traffic, the destination address is also employed in the lookup (in addition to the SPI), and the sender address also may be employed, as described in Section 2.1. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field is present, and whether the (explicit) ICV field should be present (and if so, its size). Also, the SAD entry will specify the algorithms and keys to be employed for decryption and ICV computation (if applicable).
If no valid Security Association exists for this packet, the receiver MUST discard the packet; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the cleartext Flow ID.
All EESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by negotiation on a per-SA basis. This service MUST NOT be enabled unless the EESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs.
However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below.
If anti-replay service is enabled for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
EESP permits two-stage verification of packet sequence numbers. This capability is important whenever an ESP implementation (typically the cryptographic module portion thereof) is not capable of performing decryption and/or integrity checking at the same rate as the interface(s) to unprotected networks. If the implementation is capable of such “line rate” operation, then it is not necessary to perform the preliminary verification stage described below.
The preliminary Sequence Number check is effected utilizing the Sequence Number value in the EESP Header and is performed prior to integrity checking and decryption. If this preliminary check fails,
the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point.
Duplicates are rejected through the use of a sliding receive window. How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.
The “right” edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain sequence numbers lower than the “left” edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window.
If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, and if a separate integrity algorithm is employed, then the receiver proceeds to integrity verification. If a combined mode algorithm is employed, the integrity check is performed along with decryption. In either case, if the integrity check fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window is updated only if the integrity verification succeeds. (If a combined mode algorithm is being used, then the integrity protected Sequence Number must also match the Sequence Number used for anti-replay protection.)
A minimum window size of 64 packets MUST be supported. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does NOT notify the sender of the window size.) The receive window size should be increased for higher-speed environments, irrespective of assurance issues. Values for minimum and recommended receive window sizes for very high-speed (e.g., multi-terabit/second) devices are not specified by this standard.
As with outbound processing, there are several options for inbound processing, based on features of the algorithms employed.
If separate confidentiality and integrity algorithms are employed processing proceeds as follows:
- If integrity has been selected, the receiver computes the
ICV over the EESP packet minus the ICV, using the specified
integrity algorithm and verifies that it is the same as the
ICV carried in the packet. Details of the computation are
provided below.
If the computed and received ICVs match, then the datagram is valid, and it is accepted. If the test fails, then the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the cleartext Flow ID.
Implementation Note:
Implementations can use any set of steps that results in the same result as the following set of steps. Begin by removing and saving the ICV field. Next check the overall length of the EESP packet minus the ICV field. If implicit padding is required, based on the block size of the integrity algorithm, append zero-filled bytes to the end of the ESP packet directly after the Next Header field. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification.
- The receiver decrypts the EESP the paylod info header (if present), Payload Data, Padding, using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. As in Packet Encryption and Integrity Check Value (ICV) Calculation, we speak here in terms of encryption always being applied because of the formatting implications. This is done with the understanding that “no confidentiality” is offered by using the NULL encryption algorithm (RFC 2410).
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the IP field of the peer header and input to the decryption algorithm as per the algorithm specification.
- If implicit cryptographic synchronization data is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification.
- The receiver processes any Padding as specified in the encryption algorithm specification. If the default padding scheme (see Padding (for Encryption)) has been employed, the receiver SHOULD inspect the Padding field before removing the padding prior to passing the decrypted data to the next layer.
- The receiver checks the Next Header field. If the value is “59” (no next header), the (dummy) packet is discarded without further processing.
- The receiver reconstructs the original IP datagram from:
- for layer 4 payload encapsulation modes – outer IP header plus the original next layer protocol information in the ESP Payload field
- for tunnel mode – the entire IP datagram in the ESP Payload field.
The exact steps for reconstructing the original datagram depend on the mode (transport or tunnel) and are described in the Security Architecture document.
At a minimum, in an IPv6 context, the receiver SHOULD ensure that the decrypted data is 8-byte aligned, to facilitate processing by the protocol identified in the Next Header field.
If integrity checking and encryption are performed in parallel, integrity checking MUST be completed before the decrypted packet is passed on for further processing. This order of processing facilitates rapid detection and rejection of replayed or bogus packets by the receiver, prior to decrypting the packet, hence potentially reducing the impact of denial of service attacks.
Note: If the receiver performs decryption in parallel with integrity checking, care must be taken to avoid possible race conditions with regard to packet access and extraction of the decrypted packet.
If a combined confidentiality and integrity algorithm is employed, then the receiver proceeds as follows:
- Decrypts and integrity checks the EESP Payload Info Header (if present), Payload Data, Padding, using the key, algorithm, algorithm mode, and cryptographic synchronization data (if any), indicated by the SA. The SPI from the EESP header, and the (receiver) packet counter value (adjusted as required from the processing described in Section 3.4.3) are inputs to this algorithm, as they are required for the integrity check.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the IV field and input to the decryption algorithm as per the algorithm specification.
- If implicit cryptographic synchronization data, e.g., an IV, is indicated, a local version of the IV is constructed and input to the decryption algorithm as per the algorithm specification.
- If the integrity check performed by the combined mode algorithm fails, the receiver MUST discard the received IP datagram as invalid; this is an auditable event. The log data SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID.
- Process any Padding as specified in the encryption algorithm specification, if the algorithm has not already done so.
- The receiver checks the Next Header field. If the value is “59” (no next header), the (dummy) packet is discarded without further processing.
- Extract the original IP datagram (tunnel mode) or transport-layer frame (layer 4 payload encapsulation modes) from the ESP Payload Data field.
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.
To avoid storing per-SA decryption keys on the receiver side, the decryption keys MAY be derived from the SPI plus a secret known only to the receiver side. Both peers need to agree on a commonly used cipher, key and KDF. This is usually done by using IKEv2, or any other suitalbe protocol. The sender MUST remember the encryption key for the SA, but the receiver can re-derive it for each packet. The same arrangement is repeated in reverse, to provide encryption for response packets flowing from the receiver to the sender.
The KDF used to derive the key for decryption MUST be one of the KDFs specified in NIST02 section 4, and used in the way described there.
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.
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 RFC7296 can handle key derivation.
TBD
Not all systems that implement EESP will implement auditing. However, if EESP is incorporated into a system that supports auditing, then the EESP implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for EESP. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification and for each of these events a minimum set of information that SHOULD be included in an audit log is defined.
- No valid Security Association exists for a session. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- A packet offered to EESP for processing appears to be an IP fragment, i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, Sequence Number, and (in IPv6) the Flow ID.
- Attempt to transmit a packet that would result in Sequence Number overflow. The audit log entry for this event SHOULD include the SPI value, current date/time, Source Address, Destination Address, Sequence Number, and (for IPv6) the cleartext Flow ID.
- The received packet fails the anti-replay checks. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID.
- The integrity check fails. The audit log entry for this event SHOULD include the SPI value, date/time received, Source Address, Destination Address, the Sequence Number, and (for IPv6) the Flow ID.
Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action.
Implementations that claim conformance or compliance with this specification MUST implement the EESP syntax and processing described here for unicast traffic, and MUST comply with all additional packet processing requirements levied by the Security Architecture document RFC4301. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service requires correct maintenance of the counter state at the sender (across local reboots, etc.), until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus, a compliant implementation SHOULD NOT provide anti-replay service in conjunction with SAs that are manually keyed.
The mandatory-to-implement algorithms for use with EESP are described in a separate document RFC4305, to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for EESP, MAY be supported.
Because use of encryption in EESP is optional, support for the “NULL” encryption algorithm also is required to maintain consistency with the way ESP services are negotiated. Support for the confidentiality-only service version of EESP is optional. If an implementation offers this service, it MUST also support the negotiation of the “NULL” integrity algorithm. NOTE that although integrity and encryption may each be “NULL” under the circumstances noted above, they MUST NOT both be “NULL”.
Security is central to the design of this protocol, and thus security considerations permeate the specification. Additional security- relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
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:
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]
[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.
In this section we discuss the security properties of EESP: TBD
TBD
TBD