RFC 4303
IP Encapsulating Security Payload (ESP)
IP Encapsulating Security Payload (ESP) 🎀
Okay bestie, let's talk about RFC 4303 💅 It was written by S. Kent over at BBN Technologies, dated December 2005, and it's a Standards Track doc, so it's the real deal for the Internet community 🌐 It also obsoletes RFC 2406, which is the older ESP spec, so this is the glow-up version ✨
Status of This Memo 📜
This document specifies an Internet standards track protocol for the Internet community, and it's basically asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1), which is the official source of truth. Distribution of this memo is unlimited, so share away 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract 🌸
Okay so this doc is an updated version of the Encapsulating Security Payload (ESP) protocol 💖 ESP is designed to give you a mix of security services in both IPv4 and IPv6, and it's giving versatile. It can provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality 🔐 And just to be clear, this document obsoletes RFC 2406 (November 1998) 👑
Table of Contents 🗂️
1. Introduction ....................................................3
2. Encapsulating Security Payload Packet Format ....................5
2.1. Security Parameters Index (SPI) ...........................10
2.2. Sequence Number ...........................................12
2.2.1. Extended (64-bit) Sequence Number ..................12
2.3. Payload Data ..............................................13
2.4. Padding (for Encryption) ..................................14
2.5. Pad Length ................................................15
2.6. Next Header ...............................................16
2.7. Traffic Flow Confidentiality (TFC) Padding ................17
2.8. Integrity Check Value (ICV) ...............................17
3. Encapsulating Security Protocol Processing .....................18
3.1. ESP Header Location .......................................18
3.1.1. Transport Mode Processing ..........................18
3.1.2. Tunnel Mode Processing .............................19
3.2. Algorithms ................................................20
3.2.1. Encryption Algorithms ..............................21
3.2.2. Integrity Algorithms ...............................21
3.2.3. Combined Mode Algorithms ...........................22
3.3. Outbound Packet Processing ................................22
3.3.1. Security Association Lookup ........................22
3.3.2. Packet Encryption and Integrity Check Value
(ICV) Calculation ..................................22
3.3.2.1. Separate Confidentiality and
Integrity Algorithms ......................23
3.3.2.2. Combined Confidentiality and
Integrity Algorithms ......................24
3.3.3. Sequence Number Generation .........................25
3.3.4. Fragmentation ......................................26
3.4. Inbound Packet Processing .................................27
3.4.1. Reassembly .........................................27
3.4.2. Security Association Lookup ........................27
3.4.3. Sequence Number Verification .......................28
3.4.4. Integrity Check Value Verification .................30
3.4.4.1. Separate Confidentiality and
Integrity Algorithms ......................30
3.4.4.2. Combined Confidentiality and
Integrity Algorithms ......................32
4. Auditing .......................................................33
5. Conformance Requirements .......................................34
6. Security Considerations ........................................34
7. Differences from RFC 2406 ......................................34
8. Backward-Compatibility Considerations ..........................35
9. Acknowledgements ...............................................36
10. References ....................................................36
10.1. Normative References .....................................36
10.2. Informative References ...................................37
Appendix A: Extended (64-bit) Sequence Numbers ....................38
A1. Overview ...................................................38
A2. Anti-Replay Window .........................................38
A2.1. Managing and Using the Anti-Replay Window ............39
A2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................40
A2.3. Pseudo-Code Example ..................................41
A3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................42
A3.1. Triggering Re-synchronization ........................43
A3.2. Re-synchronization Process ...........................431. Introduction 🧚
Okay so this doc assumes you already know the terms and concepts from the "Security Architecture for the Internet Protocol" [Ken-Arch], which we'll call the Security Architecture document 📚 You should be comfy with what security services ESP and the IP Authentication Header (AH) offer, the concept of Security Associations, how ESP can team up with AH, and the different key management options for ESP and AH 🔑
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be read as described in RFC 2119 [Bra97] 🎀
ESP is designed to give you a mix of security services in IPv4 and IPv6 [DH98] 💜 It can be used alone, combined with AH [Ken-AH], or nested (see the Security Architecture document [Ken-Arch]). Security services can be set up between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host 🌈 For more on how to use ESP and AH in different network environments, go check the Security Architecture document [Ken-Arch] 🔍
The ESP header gets inserted after the IP header and before the next layer protocol header (transport mode), or before an encapsulated IP header (tunnel mode). We'll get into these modes more below 🦋
ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality 💖 Which services you actually get depends on the options picked when the Security Association (SA) is set up, and on where the implementation sits in the network topology 🗺️
Encryption-only for confidentiality is allowed by ESP. Real talk though, this will generally only defend you against passive attackers 👀 Using encryption without a strong integrity mechanism on top of it (either in ESP or separately via AH) may make the confidentiality service insecure against some forms of active attacks [Bel96, Kra01]. Also, an underlying integrity service, such as AH, applied before encryption does not necessarily protect that encryption-only confidentiality against active attackers [Kra01] 😭 ESP allows encryption-only SAs because they may offer way better performance and still be secure enough, e.g., when higher-layer authentication/integrity protection is offered independently 🏃♀️ But this standard does not require ESP implementations to offer an encryption-only service, so it's not mandatory 🙅♀️
Data origin authentication and connectionless integrity are joint services, which we'll call "integrity" from here on. (That's the term because, per packet, the computation directly gives connectionless integrity. Data origin authentication comes along indirectly, since the key used to verify integrity is bound to the identity of the IPsec peer. Usually that binding happens through a shared, symmetric key.) 🔗 Integrity-only ESP MUST be offered as a service selection option, e.g., it must be negotiable in SA management protocols, and it MUST be configurable via management interfaces 🛠️ Integrity-only ESP is an attractive alternative to AH in many contexts, e.g., because it's faster to process and more amenable to pipelining in many implementations ⚡
Confidentiality and integrity can be offered independently, but ESP typically uses both, i.e., packets get protected for both confidentiality and integrity 🔒 So there are three possible ESP security service combinations involving these services:
- confidentiality-only (MAY be supported)
- integrity only (MUST be supported)
- confidentiality and integrity (MUST be supported)The anti-replay service may be selected for an SA only if the integrity service is selected for that SA 🙅♀️ Picking this service is solely up to the receiver, so it doesn't need to be negotiated. However, to use the Extended Sequence Number feature in an interoperable way, ESP does put a requirement on SA management protocols to be able to negotiate this feature (see Section 2.2.1 below) 🔢
Traffic flow confidentiality (TFC) generally only works if ESP is used in a way that hides the ultimate source and destination addresses of correspondents, e.g., in tunnel mode between security gateways. It also only works if enough traffic flows between IPsec peers (either naturally or because masking traffic gets generated) to hide the characteristics of specific, individual subscriber traffic flows 🕵️♀️ (ESP can be part of a higher-layer TFC system, e.g., Onion Routing [Syverson], but those systems are outside the scope of this standard.) New TFC features in ESP make it easier to generate and discard dummy traffic and to pad real traffic better, all in a backward-compatible way 🧁
Section 7 gives a quick rundown of the differences between this document and RFC 2406 📝
2. Encapsulating Security Payload Packet Format 💅
The (outer) protocol header (IPv4, IPv6, or Extension) that comes right before the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see the IANA web page at http://www.iana.org/assignments/protocol-numbers) 🔢 Figure 1 shows the top-level format of an ESP packet 🖼️ The packet starts with two 4-byte fields, Security Parameters Index (SPI) and Sequence Number 🍓 After those comes the Payload Data, which has substructure that depends on the encryption algorithm and mode you pick, and on whether TFC padding is used (we'll look at that in more detail later). After the Payload Data come the Padding and Pad Length fields, and then the Next Header field. The optional Integrity Check Value (ICV) field finishes off the packet ✨
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 1Okay so, here's the big picture 🖼️ Figure 1 shows the top-level layout of an ESP packet:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Top-Level Format of an ESP PacketThe asterisk on Payload Data is a little plot twist 🙈 If cryptographic sync data is in the Payload field (like an Initialization Vector, IV, see Section 2.3), it usually isn't encrypted per se, even though people love calling it part of the ciphertext.
The transmitted ESP trailer is made up of the Padding, Pad Length, and Next Header fields 💅 There's also extra implicit ESP trailer data that never actually gets sent, but it still counts in the integrity computation, which I'll get into below.
If you pick the integrity service, the integrity computation covers the SPI, Sequence Number, Payload Data, and the ESP trailer (both explicit and implicit) 🔐 If you pick the confidentiality service, the ciphertext is the Payload Data (minus any cryptographic sync data that might be in there) plus the explicit ESP trailer ✨
Payload Data can have substructure, and that's where it gets spicy 🌶️ An encryption algorithm that needs an explicit IV, like Cipher Block Chaining (CBC) mode, usually sticks that IV in front of the Payload Data it protects. Some algorithm modes do encryption and integrity in one go, and this document calls those "combined mode algorithms" 🦋 Supporting them means the algorithm has to clearly describe the payload substructure it uses to carry its integrity data, periodt.
Some combined mode algorithms only give integrity to data that's encrypted, while others can also cover extra data that isn't encrypted for transmission. The SPI and Sequence Number fields need integrity whenever the integrity service is selected, and they're not encrypted, so they have to be protected no matter which style of combined mode you're using 🧚
When you use any combined mode algorithm, the algorithm itself is expected to hand back both the decrypted plaintext and a pass/fail result for the integrity check 💖 With combined mode algorithms, the ICV that would normally sit at the end of the ESP packet (when integrity is selected) can be left out. And if the ICV is left out and integrity is selected, the combined mode algorithm is responsible for putting an ICV-equivalent way of verifying the packet's integrity inside the Payload Data 🫶
If a combined mode algorithm only gives integrity to encrypted data, the SPI and Sequence Number have to be copied into the Payload Data too 👑
Last but not least, there's a new provision for traffic flow confidentiality padding 🌸 It goes after the Payload Data and before the ESP trailer. Figure 2 shows this substructure for Payload Data. (Heads up: this diagram shows bits on the wire, so even when extended sequence numbers are in use, only 32 bits of the Sequence Number get transmitted, see Section 2.2.1 😭)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| IV (optional) | ^ p
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| Rest of Payload Data (variable) | | y
~ ~ | l
| | | o
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a
| | TFC Padding * (optional, variable) | v d
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Substructure of Payload Data* If tunnel mode is in use, the IPsec implementation can add Traffic Flow Confidentiality (TFC) padding (see Section 2.4) after the Payload Data and before the Padding (0-255 bytes) field 🎀
If a combined algorithm mode is used, the explicit ICV shown in Figures 1 and 2 may be omitted (see Section 3.3.2.2 below) 🙃 Algorithms and modes are locked in when an SA is established, so the detailed format of ESP packets for a given SA (Payload Data substructure included) stays fixed for all traffic on that SA. Iconic consistency 💅
The tables below line up with the fields in the figures above and show how several categories of algorithm options, each with its own processing model, change those fields. The processing details come in later sections 📚
Table 1. Separate Encryption and Integrity Algorithms
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M Y plain
Seq# (low-order bits) 4 M Y plain p
------ a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher[3] |-l
TFC padding [4] variable O Y Y cipher[3] | o
------ a
Padding 0-255 M Y Y cipher[3] d
Pad Length 1 M Y Y cipher[3]
Next Header 1 M Y Y cipher[3]
Seq# (high-order bits) 4 if ESN [5] Y not xmtd
ICV Padding variable if need Y not xmtd
ICV variable M [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] ciphertext if encryption has been selected
[4] Can be used only if payload specifies its "real" length
[5] See section 2.2.1
[6] mandatory if a separate integrity algorithm is used Table 2. Combined Mode Algorithms
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M plain
Seq# (low-order bits) 4 M plain p
--- a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher |-l
TFC padding [3] variable O Y Y cipher | o
--- a
Padding 0-255 M Y Y cipher d
Pad Length 1 M Y Y cipher
Next Header 1 M Y Y cipher
Seq# (high-order bits) 4 if ESN [4] Y [5]
ICV Padding variable if need Y [5]
ICV variable O [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] Can be used only if payload specifies its "real" length
[4] See Section 2.2.1
[5] The algorithm choices determines whether these are
transmitted, but in either case, the result is invisible
to ESP
[6] The algorithm spec determines whether this field is
presentNow the header fields 🎀 The following subsections walk through the fields in the header format. "Optional" means the field gets left out if its option isn't selected, so it's in neither the packet as transmitted nor the version formatted for computing an ICV (see Section 2.7). Whether an option is selected gets decided during Security Association (SA) establishment, so the format of ESP packets for a given SA is locked in for the whole life of that SA 🔒 "Mandatory" fields, on the other hand, are always there in the ESP packet format, for every SA, no exceptions 👑
Note: all the cryptographic algorithms used in IPsec expect their input in canonical network byte order (see Appendix of RFC 791 [Pos81]) and produce their output in canonical network byte order too. IP packets get sent in network byte order as well 🌈
Also, ESP doesn't carry a version number 🥺 So if backward compatibility is a worry, it MUST be handled by using a signaling mechanism between the two IPsec peers to make sure they're running compatible versions of ESP (for example, Internet Key Exchange (IKEv2) [Kau05]) or by using an out-of-band configuration mechanism. Honestly, the peers need to be on the same page or things get messy 💀
2.1. Security Parameters Index (SPI) 🎀
okay bestie, the SPI is an arbitrary 32-bit value 🦋 that a receiver uses to figure out which SA an incoming packet is bound to ✨ the SPI field is mandatory, no exceptions 💅
for a unicast SA, the SPI can be used all by itself to pick out an SA, or it can be paired with the IPsec protocol type (in this case ESP) 🧚 whether the SPI is enough on its own or needs the protocol value too is a local matter 🌸 the reason is that the receiver is the one who generates the SPI for a unicast SA 💖 this mechanism for mapping inbound traffic to unicast SAs MUST be supported by all ESP implementations 👑
if an IPsec implementation supports multicast, then it MUST support multicast SAs using the algorithm below for mapping inbound IPsec datagrams to SAs 🔥 implementations that only do unicast don't need to implement this de-multiplexing algorithm 🙈
in lots of secure multicast architectures (e.g., [RFC3740]), a central Group Controller/Key Server just unilaterally assigns the group security association's SPI 💀 that SPI assignment isn't negotiated or coordinated with the key management (e.g., IKE) subsystems living in the individual end systems that make up the group 😭 so it's possible for a group SA and a unicast SA to be using the same SPI at the same time 🫠 a multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even in the context of SPI collisions 🫶
each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup uses the destination, or the destination and source, IP addresses, in addition to the SPI 🌈 for multicast SAs, the protocol field is not employed for SA lookups 🍓 for each inbound, IPsec-protected packet, an implementation must conduct its search of the SAD so that it finds the entry matching the "longest" SA identifier ✨ here, if two or more SAD entries match based on the SPI value, then the entry that also matches on destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match 🎀 this implies a logical ordering of the SAD search, like so:
- Search the SAD for a match on
{SPI, destination address, source address}. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 2. - Search the SAD for a match on
{SPI, destination address}. If the SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, proceed to step 3. - Search the SAD for a match on only
{SPI}if the receiver has chosen to maintain a single SPI space for AH and ESP, or on{SPI, protocol}otherwise. If an SAD entry matches, then process the inbound ESP packet with that matching SAD entry. Otherwise, discard the packet and log an auditable event.
in practice, an implementation MAY choose any method to speed up this search 🏎️ but its externally visible behavior MUST be functionally equivalent to having searched the SAD in the above order 🧠 for example, a software-based implementation could index into a hash table by the SPI 🍰 the SAD entries in each hash table bucket's linked list are kept sorted so the ones with the longest SA identifiers come first, and the ones with the shortest SA identifiers are sorted so they're the last entries in the linked list 💜 a hardware-based implementation may be able to do the longest match search intrinsically, using commonly available Ternary Content-Addressable Memory (TCAM) features 🔥
the indication of whether source and destination address matching is required to map inbound IPsec traffic to SAs MUST be set either as a side effect of manual SA configuration or via negotiation using an SA management protocol, e.g., IKE or Group Domain of Interpretation (GDOI) [RFC3547] 🌸 typically, Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier made of an SPI, a destination multicast address, and a source address 🦋 an Any-Source Multicast group SA only needs an SPI and a destination multicast address as its identifier ✨
the SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use 🌷 a reserved SPI value will not normally be assigned by IANA unless the use of that assigned SPI value is specified in an RFC 📜 the SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire 🚫 (for example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" while the IPsec implementation has asked its key management entity to set up a new SA but that SA hasn't been established yet 🧚♀️)
2.2. Sequence Number 🔢
this unsigned 32-bit field holds a counter value that goes up by one for each packet sent, aka 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 🫡 sharing an SA among multiple senders is permitted, though generally not recommended 🙃 ESP gives you no way to sync packet counters across multiple senders, or to meaningfully manage a receiver packet counter and window when there are multiple senders 😵💫 so for a multi-sender SA, the anti-replay features of ESP are not available (see Sections 3.3.3 and 3.4.3.) 🚧
the field is mandatory and MUST always be present, even if the receiver doesn't turn on the anti-replay service for a specific SA 💅 processing of the Sequence Number field is at the receiver's discretion, but all ESP implementations MUST be capable of performing the processing described in Sections 3.3.3 and 3.4.3. 🌈 so the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section (3.4.3) below) 🫶
the sender's counter and the receiver's counter are initialized to 0 when an SA is established 🌱 (the first packet sent using a given SA will have a sequence number of 1; see Section 3.3.3 for more details on how the sequence number is generated.) if anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle 🔁 so the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) before the 2^32nd packet is transmitted on an SA ⚠️
⚠️ heads up: when the sequence number is about to run out, the counters MUST be reset by making a brand-new SA with a brand-new key before packet 2^32 goes out. no skipping this one, bestie 😭
2.2.1. Extended (64-bit) Sequence Number 🦋
to support high-speed IPsec implementations, Extended Sequence Numbers (ESNs) SHOULD be implemented, as an extension to the current 32-bit sequence number field ⚡ use of an ESN MUST be negotiated by an SA management protocol 🤝 note that in IKEv2, this negotiation is implicit: the default is ESN unless 32-bit sequence numbers are explicitly negotiated 🌟 (the ESN feature is applicable to multicast as well as unicast SAs.)
the ESN facility lets you use a 64-bit sequence number for an SA 🌈 (see Appendix A, "Extended (64-bit) Sequence Numbers", for details.) only the low-order 32 bits of the sequence number are transmitted in the plaintext ESP header of each packet, which keeps packet overhead low 💜 the high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver, and they're included in the computation of the ICV (if the integrity service is selected) 🧮 if a separate integrity algorithm is used, the high-order bits go in the implicit ESP trailer but aren't transmitted, kind of like integrity algorithm padding bits 🎀 if a combined mode algorithm is used, the algorithm choice decides whether the high-order ESN bits get transmitted or are included implicitly in the computation 🫠 see Section 3.3.2.2 for the processing details 📖
2.3. Payload Data 📦
Payload Data is a variable-length field holding data (from the original IP packet) described by the Next Header field 💖 the Payload Data field is mandatory and is an integral number of bytes in length 🙌 if the algorithm used to encrypt the payload needs cryptographic synchronization data, like an Initialization Vector (IV), then that data is carried explicitly in the Payload field, but it isn't called out as a separate field in ESP 🧚 so an explicit IV is basically invisible to ESP 🫥 (see Figure 2.) any encryption algorithm that needs this kind of explicit, per-packet synchronization data MUST indicate the length, any structure for that data, and where the data is located, as part of an RFC specifying how the algorithm is used with ESP 📜 (typically, the IV immediately precedes the ciphertext. See Figure 2.) if the synchronization data is implicit, the algorithm for deriving it MUST be part of the algorithm definition RFC 🧠 (if it's included in the Payload field, cryptographic synchronization data, like an Initialization Vector (IV), usually isn't encrypted per se (see Tables 1 and 2), although it sometimes gets called part of the ciphertext 🍓)
note that the beginning of the next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows 📏 for IPv4, this alignment is a multiple of 4 bytes 💜 for IPv6, the alignment is a multiple of 8 bytes 🌸
with regard to making sure the (real) ciphertext is aligned when there's an IV, keep these in mind 👀
- for some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext, feeding it into the algorithm directly. in these modes, alignment of the start of the (real) ciphertext is not an issue at the receiver 🙆♀️
- in some cases, the receiver reads the IV in separately from the ciphertext. in these cases, the algorithm specification MUST address how alignment of the (real) ciphertext is to be achieved 🧩
2.4. Padding (for Encryption) 🎀
okay so there are two main reasons the Padding field exists, bestie 💅
- If your encryption algorithm needs the plaintext to be a multiple of some number of bytes (like the block size of a block cipher), the Padding field fills the plaintext out to that size. The plaintext here is the Payload Data, Padding, Pad Length, and Next Header fields all together.
- Padding can also be needed even when the algorithm doesn't care 🙈 It makes sure the ciphertext ends on a 4-byte boundary. The Pad Length and Next Header fields have to be right aligned inside a 4-byte word (see the ESP packet format figures above), so the ICV field (if it's there) lands on a 4-byte boundary.
Extra padding beyond what the algorithm or alignment needs could hide the real length of the payload for TFC 👀 But the Padding field is too limited to do that job well, so please don't use it for that. If you need TFC, use the separate mechanism in Section 2.7 instead. That one's the real deal ✨
The sender MAY add 0 to 255 bytes of padding. Including the Padding field in an ESP packet is optional (subject to the stuff above), but all implementations MUST support generating and consuming padding. Non-negotiable, no cap 💖
- For the block size thing (the first bullet above), the padding math covers the Payload Data but not any IV. It does include the ESP trailer fields. If a combined algorithm mode needs the SPI and Sequence Number sent for integrity (like copying them into the Payload Data), those copies and any ICV-equivalent data get counted in the pad length too. (If ESN is selected, the high-order 32 bits of the ESN join the party as well, but only if the combined mode needs them transmitted for integrity.)
- For the 4-byte alignment of the ICV (the second bullet), the math covers the Payload Data plus the IV, Pad Length, and Next Header fields. If you're using a combined mode algorithm, any replicated data and ICV-equivalent data get included here too.
If padding bytes are needed but the encryption algorithm doesn't say what the padding should contain, then the following default processing MUST be used 🌸 The padding bytes get filled with a series of unsigned, 1-byte integer values. The first padding byte appended to the plaintext is numbered 1, and each one after that keeps going up in a monotonically increasing sequence: 1, 2, 3, ... When this scheme is in use, the receiver SHOULD inspect the Padding field. (This scheme was picked because it's simple, easy to build into hardware, and gives limited protection against certain "cut and paste" attacks when there aren't other integrity measures, as long as the receiver checks the padding values after decryption. Clever, right? 🧠)
If an encryption or combined mode algorithm puts constraints on the values of the padding bytes, those constraints MUST be specified by the RFC that defines how the algorithm gets used with ESP. And if the algorithm needs the padding byte values checked, that MUST be specified in that RFC too 📜
2.5. Pad Length 🌷
The Pad Length field tells you how many pad bytes sit right before it in the Padding field. Valid values run from 0 to 255, and a value of zero means there are no Padding bytes at all. As noted above, this does not count any TFC padding bytes. The Pad Length field is mandatory, so it's always there ✨
2.6. Next Header 🦋
The Next Header is a mandatory, 8-bit field that says what kind of data is in the Payload Data field. It could be an IPv4 or IPv6 packet, or a next layer header and data. The value comes from the IP Protocol Numbers registry on IANA's web page. For example, 4 means IPv4, 41 means IPv6, and 6 means TCP 💜
Now for the spicy part 🌶️ To make it fast to generate and throw away the padding traffic that supports traffic flow confidentiality (see Section 2.4), the protocol value 59 (which means "no next header") MUST be used to mark a "dummy" packet. A transmitter MUST be able to generate dummy packets with that value in the next protocol field, and a receiver MUST be ready to discard them without raising an error. All the other ESP header and trailer fields (SPI, Sequence Number, Padding, Pad Length, Next Header, and ICV) MUST still be present in dummy packets. The plaintext part of the payload (apart from this Next Header field) doesn't need to be well-formed, so the rest of the Payload Data can just be random bytes, lol 🎲 Dummy packets get discarded without prejudice.
Implementations SHOULD provide local management controls so you can turn this on per-SA. The controls should let the user say whether the feature is used and also give parametric controls. For example, an admin might be able to generate random-length or fixed-length dummy packets 🎛️
DISCUSSION: Dummy packets can be slipped in at random intervals to hide the lack of real traffic. You can also "shape" the real traffic to match some distribution, and then add dummy traffic based on that distribution's parameters. Just like the packet length padding for Traffic Flow Security (TFS), the most secure move would be generating dummy packets at whatever rate keeps a constant rate on an SA. If all the packets are the same size, the SA looks like a constant bit rate data stream, kind of like what a link crypto would give you at layer 1 or 2. BUT 😭 this probably isn't practical in lots of setups, like when multiple SAs are active, because it would mean cutting the allowed bandwidth for a site based on how many SAs there are. And that would wreck the whole point of packet switching. Implementations SHOULD provide controls so local admins can manage dummy packet generation for TFC purposes 💅
2.7. Traffic Flow Confidentiality (TFC) Padding 💖
As we mentioned, the Padding field is capped at 255 bytes. That usually isn't enough to hide traffic characteristics when you need traffic flow confidentiality. So there's an optional field inside the payload data that exists specifically for TFC 🧚
An IPsec implementation SHOULD be able to pad traffic by adding bytes after the end of the Payload Data and before the Padding field. This padding (called TFC padding from here on) can only be added if the Payload Data field says how long the IP datagram is. That's always the case in tunnel mode, and it may be the case in transport mode depending on whether the next layer protocol (like IP, UDP, or ICMP) has explicit length info. That length info lets the receiver throw away the TFC padding, since the true length of the Payload Data is now known. (ESP trailer fields are found by counting backwards from the end of the ESP packet, btw 🔍) So, if TFC padding gets added, the field holding the IP datagram length MUST NOT be modified to reflect that padding. This standard doesn't set any requirements for the value of this padding.
Fun fact: existing IPsec implementations could've been using this capability before, quietly and without anyone noticing 👀 But receivers might not have been ready to handle this padding, so the SA management protocol MUST negotiate this service before a transmitter uses it, to keep things backward compatible 🤝 Put this together with the protocol ID 59 convention from Section 2.6 above, and an ESP implementation can generate dummy and real packets with way more length variability for TFC. It's giving unpredictable 🦋
Implementations SHOULD provide local management controls so you can turn this on per-SA. The controls should let the user say whether the feature is used, and also give parametric controls for it ✨
2.8. Integrity Check Value (ICV) 🔐
The Integrity Check Value is a variable-length field, computed over the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer fields (integrity padding and high-order ESN bits, if they apply) get included in the ICV computation too. The ICV field is optional. It only shows up if the integrity service is selected, and it's provided either by a separate integrity algorithm or by a combined mode algorithm that uses an ICV. The length of the field is set by the integrity algorithm chosen and associated with the SA. The integrity algorithm specification MUST specify the length of the ICV, plus the comparison rules and processing steps for validation. No vibes-based validation allowed 💀
3. Encapsulating Security Protocol Processing 🌈
3.1. ESP Header Location 🧚♀️
ESP may be employed in two ways: transport mode or tunnel mode. Let's get into it 💜
3.1.1. Transport Mode Processing
Okay so in transport mode, ESP gets tucked in right after the IP header and before the next layer protocol, like TCP, UDP, ICMP, and so on 🦋. In IPv4 that means ESP sits after the IP header (and any options riding along with it) but before the next layer protocol. (If AH is also applied to a packet, it covers the ESP header, Payload, ESP trailer, and ICV, if present.) (And bestie, "transport" mode does NOT mean it's only for TCP and UDP. Not me getting that wrong 🙈) Here's a before-and-after picture of ESP transport mode on a typical IPv4 packet 🎀 (the ICV field only shows up depending on the security services and the algorithm/mode you picked 💜).
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|Now IPv6 is a different vibe ✨. Here ESP is treated as an end-to-end payload, so it should show up after the hop-by-hop, routing, and fragmentation extension headers. Destination options headers can go before, after, or on both sides of the ESP header, depending on what you're trying to do 💅. Still, since ESP only protects the fields after the ESP header, it's generally a good idea to put the destination options header(s) after the ESP header 🧚. Here's the IPv6 transport mode picture 🌸.
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<------ integrity ------>|
* = if present, could be before ESP, after ESP, or bothOne more thing 👀. For "bump-in-the-stack" or "bump-in-the-wire" implementations (as defined in the Security Architecture document), inbound and outbound IP fragments might need an IPsec implementation to do extra IP reassembly/fragmentation. That's how it conforms to this spec and gives transparent IPsec support. Handling this properly is special care territory when multiple interfaces are in use 😭.
3.1.2. Tunnel Mode Processing
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, and an "outer" IP header holds the addresses of the IPsec "peers" (like the addresses of security gateways) 🌈. Mixing IP versions is allowed too, so IPv6 over IPv4 and IPv4 over IPv6 are both fine 🫶. In tunnel mode, ESP protects the entire inner IP packet, including the whole inner IP header 🔥. Where ESP sits relative to the outer IP header is the same as in transport mode. Here are the typical IPv4 and IPv6 pictures 💖.
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.3.2. Algorithms
Okay, the mandatory-to-implement algorithms for ESP live in a separate RFC 🧁. That's so the algorithm requirements can be updated without touching the protocol itself, which is honestly so smart 👑. You MAY support extra algorithms beyond the ones mandated for ESP. Confidentiality and integrity are both optional, BUT at least one of these services MUST be selected, so both algorithms MUST NOT be NULL at the same time 💀.
3.2.1. Encryption Algorithms
The encryption algorithm for an ESP packet is specified by the SA it's transmitted or received through ✨. IP packets can arrive out of order, and some might never arrive (packet loss), so each packet has to carry whatever data the receiver needs to get cryptographic synchronization for decryption 🦋. That data can be carried explicitly in the payload field (like an IV, as described above), or it can be derived from the plaintext parts of the (outer IP or ESP) packet header 💜. (Heads up: if plaintext header info is used to derive an IV, that info can become security critical, and the protection boundary around encryption might grow. For example, if you used the ESP 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. For FIPS 140-2 [NIST01], this could seriously widen the scope of a cryptographic module evaluation 😭.) Since ESP lets plaintext get padded, encryption algorithms used with ESP can behave like block mode or stream mode 🌸. Because encryption (confidentiality) MAY be optional (like integrity-only ESP), this algorithm MAY be "NULL" [Ken-Arch] 🙈.
To let an ESP implementation work out the encryption padding a block mode algorithm needs, and to figure out the MTU impact, the RFC for each encryption algorithm used with ESP must specify the padding modulus for that algorithm 🎀.
3.2.2. Integrity Algorithms
The integrity algorithm used for the ICV computation is specified by the SA it's transmitted or received through, same as encryption 💅. Any integrity algorithm used with ESP must make provisions for processing packets that arrive out of order and for handling packet loss 🫶. The same warning from above applies to any plaintext data used to help the receiver synchronize integrity algorithms 🔥. Because the integrity service MAY be optional, this algorithm may be "NULL" 🧚.
To let an ESP implementation compute any implicit integrity algorithm padding, the RFC for each algorithm used with ESP must specify the padding modulus for the algorithm 🍓.
3.2.3. Combined Mode Algorithms
If a combined mode algorithm is used, you get both confidentiality and integrity together 👑. Like with encryption algorithms, a combined mode algorithm must make provisions for per-packet cryptographic synchronization, so out-of-order packets can still be decrypted and packet loss is handled ✨. How a combined mode algorithm provides integrity for the payload, and for the SPI and (Extended) Sequence Number fields, can vary between algorithm choices 🌈. To keep things uniform and algorithm-independent when invoking combined mode algorithms, no payload substructure is defined 🦋. For example, the SPI and Sequence Number fields might get replicated inside the ciphertext envelope, and an ICV might get appended to the ESP trailer 💖. None of these details should be observable from the outside 🙈.
To let an ESP implementation figure out the MTU impact of a combined mode algorithm, the RFC for each algorithm used with ESP must specify a (simple) formula that gives the encrypted payload size, based on the plaintext payload size and the sequence number size 💜.
3.3. Outbound Packet Processing
In transport mode, the sender wraps the next layer protocol information between the ESP header and the ESP trailer fields, and keeps the specified IP header (plus any IP extension headers in the IPv6 context) 💅. In tunnel mode, the outer and inner IP header/extensions can be related in a bunch of different ways 🌸. How the outer IP header/extensions get built during encapsulation is described in the Security Architecture document 🎀.
3.3.1. Security Association Lookup
ESP only gets applied to an outbound packet after an IPsec implementation has determined that the packet is tied to an SA that calls for ESP processing ✨. How an implementation decides what IPsec processing (if any) applies to outbound traffic is described in the Security Architecture document 🧚.
3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation
Here we talk as if encryption is always being applied, because of how the formatting works out 🫶. That's the understanding going in, and "no confidentiality" is still an option by using the NULL encryption algorithm (RFC 2410) 🙈. There are several algorithmic options 💫.
3.3.2.1. Separate Confidentiality and Integrity Algorithms 🔐
okay so if you're using separate confidentiality and integrity algorithms, the Sender runs through these steps (it's giving checklist energy ✅):
- Encapsulate (into the
ESP Payloadfield) 📦:- for transport mode -- just the original next layer protocol information.
- for tunnel mode -- the entire original IP datagram.
- Add any necessary padding -- Optional TFC padding and (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
Payloadfield. - 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 is lowkey genius 🧠 because it lets the receiver spot and reject replayed or bogus packets before decrypting, which can help reduce the impact of denial of service (DoS) attacks. It also allows parallel processing at the receiver, so decryption can run at the same time as integrity checking ⚡. Note that because the ICV is not protected by encryption, a keyed integrity algorithm must be employed to compute the ICV 🔑.
- 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
- Compute the ICV over the ESP packet minus the ICV field 🫶. So the ICV computation covers the
SPI,Sequence Number,Payload Data,Padding(if present),Pad Length, andNext Header. (Note that the last 4 fields will be in ciphertext form, because encryption is performed first 🙈.) If the ESN option is enabled for the SA, the high-order 32 bits of the sequence number are appended after theNext Headerfield for purposes of this computation, but they are not transmitted 🤫.
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 the ESP packet (as described above) does not match the block size requirements for the algorithm, implicit padding MUST be appended to the end of the ESP packet. (This padding is added after the Next Header field, or after the high-order 32 bits of the sequence number, if ESN is selected.) The block size (and hence the length of the padding) is specified by the integrity algorithm specification. 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 that 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 0️⃣. Periodt.
3.3.2.2. Combined Confidentiality and Integrity Algorithms 💫
if a combined confidentiality/integrity algorithm is employed, the Sender does this:
- Encapsulate into the ESP Payload Data field 📦:
- for transport mode -- just the original next layer protocol information.
- for tunnel mode -- the entire original IP datagram.
- Add any necessary padding -- includes optional TFC padding and (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
Payloadfield. - If implicit cryptographic synchronization data is employed, it is constructed and input to the encryption algorithm as per the algorithm specification.
- The Sequence Number (or Extended Sequence Number, as appropriate) and the SPI are inputs to the algorithm, because they must be included in the integrity check computation 🔢. How those values get included is a function of the combined mode algorithm employed, so it's 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 ESP 📜.
- 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
3.3.3. Sequence Number Generation 🔢
the sender's counter is initialized to 0 when an SA is established. The sender increments the sequence number (or ESN) counter for this SA and inserts the low-order 32 bits of the value into the Sequence Number field. So the first packet sent using a given SA will contain a sequence number of 1 🥳.
If anti-replay is enabled (the default), the sender checks to make sure 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.
The sender assumes anti-replay is enabled as a default, unless the receiver notifies it otherwise (see Section 3.4.3). So typical behavior of an ESP implementation is for the sender to establish a new SA when the Sequence Number (or ESN) 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. (See Section 5.)
If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter. However, the sender still increments the counter, and when it reaches the maximum value, the counter rolls over back to zero 🎡. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.)
If ESN (see Appendix) is selected, only the low-order 32 bits of the sequence number are transmitted in the Sequence Number field, although both sender and receiver maintain full 64-bit ESN counters 💖. The high-order 32 bits are included in the integrity check in an algorithm/mode-specific fashion. For example, the high-order 32 bits may be appended after the Next Header field when a separate integrity algorithm is employed.
Note: If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), and that is generally contrary to the notion of disabling anti-replay for an SA 🙃.
3.3.4. Fragmentation 🧩
If necessary, fragmentation is performed after ESP processing within an IPsec implementation. So transport mode ESP is applied only to whole IP datagrams (not to IP fragments) 🎯. An IP packet to which ESP has been applied may itself be fragmented by routers en route, and such fragments must be reassembled prior to ESP processing at a receiver. In tunnel mode, ESP 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 ESP to such fragments.
NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, 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 whether 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 ESP receiver to accept fragments for reassembly creates denial of service vulnerabilities 💀. Thus, an ESP implementation MAY choose to not support fragmentation, and it may mark transmitted packets with the DF bit to facilitate Path MTU (PMTU) discovery. In any case, an ESP 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.
3.4. Inbound Packet Processing 📥
3.4.1. Reassembly 🧵
If required, reassembly is performed prior to ESP processing. If a packet offered to ESP 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 theOFFSETfield or the clearing of theMORE FRAGMENTSflag. In order for a reassembled packet to be processed by IPsec (as opposed to being discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet 🎀.
3.4.2. Security Association Lookup 🔍
Okay bestie, when a packet with an ESP Header shows up, the receiver has to figure out which SA it belongs to by looking it up in the SAD 🗂️. That SA is unidirectional. For a unicast SA, the lookup is based on the SPI, or on the SPI plus the protocol field, as Section 2.1 explains. If an implementation handles multicast traffic, it also uses the destination address in the lookup (on top of the SPI), and the sender address may get used too, per Section 2.1. (The Security Architecture document goes deeper on all of this, so go read it if you're curious 📚.)
The SAD entry for the SA also tells you whether the Sequence Number field gets checked, whether the SA uses 32-bit or 64-bit sequence numbers, and whether the (explicit) ICV field should be present, plus its size if so. On top of that, the entry spells out the algorithms and keys for decryption and ICV computation (if applicable). Main character energy 💅
If there's no valid Security Association for a packet, the receiver MUST discard it, and that's 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.
(Side note 🧚: SA management traffic, such as IKE packets, doesn't need to be processed based on SPI. You can demultiplex that traffic separately based on Next Protocol and Port fields, for example.)
3.4.3. Sequence Number Verification 🔢
Every ESP implementation MUST support the anti-replay service, but the receiver can turn it on or off on a per-SA basis 🔀. This service MUST NOT be enabled unless the ESP integrity service is also enabled for the SA, because otherwise the Sequence Number field hasn't been integrity protected 🙈. Anti-replay works for unicast and multicast SAs alike. However, this standard doesn't specify any mechanism for anti-replay on a multi-sender SA (unicast or multicast). Without any negotiation (or manual configuration) of an anti-replay mechanism for that kind of 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 the receiver doesn't enable anti-replay for an SA, no inbound checks happen on the Sequence Number. The sender, though, assumes by default that anti-replay is turned on at the receiver. To keep the sender from doing pointless sequence number monitoring and SA setup (see section 3.3.3), the receiver SHOULD tell the sender during SA establishment if it won't provide anti-replay protection, as long as an SA establishment protocol is being used 🤝.
If the receiver has enabled anti-replay for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For every packet that comes in, the receiver MUST verify that the packet's Sequence Number doesn't duplicate the Sequence Number of any other packet received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it's matched to an SA, so duplicates get rejected fast ⚡.
ESP allows two-stage verification of packet sequence numbers 🎀. This matters whenever an ESP implementation (usually the cryptographic module part of it) can't do decryption and/or integrity checking as fast as the interfaces facing unprotected networks. If the implementation can keep up at "line rate," the preliminary verification stage below isn't needed.
The preliminary Sequence Number check uses the Sequence Number value in the ESP Header, and it runs before integrity checking and decryption. If that preliminary check fails, the packet gets discarded, so the receiver doesn't have to do any cryptographic operations at all 🙌. If the preliminary check passes, the receiver can't update its local counter yet, since the integrity of the Sequence Number hasn't been verified at that point 🔒.
Duplicates get rejected with 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 is the highest validated Sequence Number value received on this SA. Packets with sequence numbers lower than the "left" edge of the window get rejected. Packets falling inside the window get checked against a list of packets already received within the window. If the ESN option is selected for an SA, only the low-order 32 bits of the sequence number are explicitly transmitted. The receiver, though, uses the full sequence number, built with the high-order 32 bits for the indicated SA (from its local counter), when it checks the received Sequence Number against the receive window. When building that full sequence number, if the low-order 32 bits carried in the packet are lower in value than the low-order 32 bits of the receiver's sequence number, the receiver assumes the high-order 32 bits have been incremented and moves to a new sequence number subspace 🌈. (This algorithm handles gaps in reception for a single SA as large as 2**32-1 packets. If a bigger gap happens, additional, heuristic checks for re-synchronization of the receiver sequence number counter MAY be employed, as described in the Appendix.)
If the received packet falls inside the window and isn't a duplicate, or if it's to the right of the window, and a separate integrity algorithm is used, the receiver moves on to integrity verification. If a combined mode algorithm is used, the integrity check happens along with decryption. Either way, if the integrity check fails, the receiver MUST discard the received IP datagram as invalid, and that's 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 only gets updated 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 32 packets MUST be supported when 32-bit sequence numbers are employed. A window size of 64 is preferred and SHOULD be employed as the default 🍓. 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-gigabit/second) devices are not specified by this standard 🚀.
3.4.4. Integrity Check Value Verification 🛡️
Just like with outbound processing, there are several options for inbound processing, and they depend on the features of the algorithms being used 💖.
3.4.4.1. Separate Confidentiality and Integrity Algorithms ✨
okay so if you're using separate confidentiality and integrity algorithms, the receiver goes through these steps in order 💅
- First up, integrity 🔐. If integrity has been selected, the receiver computes the ICV over the ESP packet minus the ICV, using the specified integrity algorithm, and checks that it matches the ICV carried in the packet. The details of the computation are below 👇
If the computed and received ICVs match, the datagram is valid and gets accepted 🎀. If the test fails, the receiver MUST discard the received IP datagram as invalid, and 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 ESP 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, or after the high-order 32 bits of the sequence number if ESN is selected. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification.
- Next, decryption 🔓. The receiver decrypts the ESP Payload Data, Padding, Pad Length, and Next Header using the key, encryption algorithm, algorithm mode, and cryptographic synchronization data (if any) indicated by the SA. Just like in Section 3.3.2, we talk about encryption as always being applied, because of the formatting implications 🧚. This works 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
Payloadfield 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.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the
- Padding time 🌸. The receiver processes any Padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) has been used, the receiver SHOULD inspect the
Paddingfield before removing the padding and passing the decrypted data up to the next layer. - Next Header check 👀. The receiver checks the
Next Headerfield. If the value is"59"(no next header), the (dummy) packet is discarded without further processing. Bye bye, dummy packet 💀. - Rebuilding the original datagram 🧩. The receiver reconstructs the original IP datagram from:
- for transport mode: the 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 rebuilding the 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, so the protocol named in the Next Header field can process it smoothly ✨. This step "discards" any (optional) TFC padding that was added for traffic flow confidentiality 🦋. (If present, this will have been inserted after the IP datagram (or transport-layer frame) and before the Padding field (see Section 2.4).)
If integrity checking and encryption happen in parallel, integrity checking MUST be completed before the decrypted packet is passed on for further processing. This order is giving protection 🛡️. It helps the receiver spot and reject replayed or bogus packets quickly, before it decrypts them, which can potentially reduce 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. ⚠️
3.4.4.2. Combined Confidentiality and Integrity Algorithms 💜
If a combined confidentiality and integrity algorithm is used, the receiver does this instead 🎀:
- Decrypts and integrity checks the ESP Payload Data, Padding, Pad Length, and Next Header, using the key, algorithm, algorithm mode, and cryptographic synchronization data (if any) indicated by the SA. The SPI from the ESP header, and the (receiver) packet counter value (adjusted as required from the processing described in Section 3.4.3), are inputs to this algorithm, because the integrity check needs them 🔍.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the
Payloadfield 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 explicit cryptographic synchronization data, e.g., an IV, is indicated, it is taken from the
- If the integrity check performed by the combined mode algorithm fails, the receiver MUST discard the received IP datagram as invalid, and 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 🧼.
- Next Header check 👀. The receiver checks the
Next Headerfield. If the value is"59"(no next header), the (dummy) packet is discarded without further processing 💀. - Pull out the original IP datagram (tunnel mode) or transport-layer frame (transport mode) from the ESP Payload Data field 🎁. This implicitly discards any (optional) padding that was added for traffic flow confidentiality. (If present, the TFC padding will have been inserted after the IP payload and before the Padding field (see Section 2.4).)
4. Auditing ✨
Not every system that implements ESP will do auditing 📝. But if ESP is part of a system that supports auditing, then the ESP implementation MUST also support auditing, and MUST let a system administrator turn auditing for ESP on or off 🎛️. For the most part, how granular the auditing is counts as a local matter. That said, this specification calls out several auditable events, and for each one it defines a minimum set of information that SHOULD be included in an audit log 📋.
- 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 ESP 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 send any message to the purported sender in response to detecting an auditable event 🤐, because doing so could invite a denial of service attack.
5. Conformance Requirements 🎀
Implementations that claim conformance or compliance with this specification MUST implement the ESP syntax and processing described here for unicast traffic, and MUST comply with all additional packet processing requirements levied by the Security Architecture document [Ken-Arch]. Also, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for supporting that traffic 📡. If the key used to compute an ICV is manually distributed, then getting the anti-replay service right requires keeping the counter state at the sender correct (across local reboots, etc.) until the key is replaced 🔑. There likely would be no automated recovery provision if counter overflow were imminent. So 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 ESP are described in a separate document [Eas04], so the algorithm requirements can be updated independently of the protocol itself 🔄. Additional algorithms, beyond those mandated for ESP, MAY be supported 🌈.
Because using encryption in ESP is optional, support for the "NULL" encryption algorithm is also required, to stay consistent with the way ESP services are negotiated 🤝. Support for the confidentiality-only service version of ESP is optional. If an implementation offers this service, it MUST also support negotiating 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" 🚫✨.
6. Security Considerations 💀🔐
Security is central to the design of this protocol, so security considerations run through the entire specification 🛡️💥. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document.
7. Differences from RFC 2406 ✨
okay bestie, this doc is literally different from RFC 2406 in a bunch of big ways 💅 here's the tea:
- Confidentiality-only service 🔒 it's now a MAY, not a MUST. no pressure!
- SPI 🦋 got a glow-up so there's one uniform algorithm for SAD lookup, for both unicast and multicast SAs, covering a wider range of multicast technologies. for unicast, the
SPIcan be used alone to pick an SA, or combined with the protocol, totally up to the receiver. for multicast SAs, theSPIgets paired with the destination address, and optionally the source address, to pick an SA. - Extended Sequence Number 🚀 added a new option for a 64-bit sequence number for very high-speed communications. also clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs.
- Payload data 🍓 broadened to accommodate combined mode algorithms.
- Padding for improved traffic flow confidentiality 🙈 added a requirement to be able to add bytes after the end of the IP Payload, before the beginning of the
Paddingfield. - Next Header 🧚 added a requirement to be able to generate and discard dummy padding packets (
Next Header = 59). - ICV 💜 broadened to accommodate combined mode algorithms.
- Algorithms 🔥 added combined confidentiality mode algorithms.
- References to mandatory algorithms 📚 moved out into a separate document.
- Inbound and Outbound packet processing 🌈 there are now two paths: (1) separate confidentiality and integrity algorithms and (2) combined confidentiality mode algorithms. because combined mode algorithms joined the party, the encryption/decryption and integrity sections got merged for both inbound and outbound processing. iconic restructuring 👑
8. Backward-Compatibility Considerations ✨
okay so ESP has no version number, and there's no mechanism that lets IPsec peers figure out which version of ESP each one is using or should use 🫠 this section talks through the backward-compat drama that comes with that.
first up: if none of the new ESP v3 features are used, the format of an ESP packet is identical in ESP v2 and v3 💖 if a combined mode encryption algorithm is used (that's a feature only ESP v3 has), the packet format might differ from the ESP v2 spec. BUT a peer that only implements ESP v2 would never negotiate that algorithm, since those are only defined for the ESP v3 context. no drama 🙌
Extended Sequence Number (ESN) negotiation is supported by IKE v2, and it's been handled for IKE v1 by the ESN Addendum to the IKE v1 Domain of Interpretation (DOI) ✨
in the new ESP (v3), we add two provisions to better support traffic flow confidentiality (TFC) 🙈:
- arbitrary padding after the end of an IP packet
- a discard convention using Next Header = 59
the first one is chill for a receiver, because the IP total length field tells everyone where the IP packet ends 🧘 so any TFC padding bytes after the end of the packet should get removed at some point during IP packet processing, after ESP processing, even if the IPsec software doesn't strip that padding itself. this is an ESP v3 feature a sender can use no matter whether the receiver is on ESP v2 or ESP v3 🦋
the second one lets a sender send a payload that's an arbitrary string of bytes that don't necessarily make up a well-formed IP packet, inside of a tunnel, for TFC purposes 🌸 here's the open question: what does an ESP v2 receiver do when the Next Header field in an ESP packet has the value "59"? it might discard the packet when it finds an ill-formed IP header and log the event, but it certainly ought not to crash 😭 because that would be a DoS vulnerability compared to traffic from authenticated peers. so this feature is an optimization an ESP v3 sender can use no matter whether the receiver is ESP v2 or ESP v3 💜
9. Acknowledgements 🫶
the author wants to give a huge shoutout to Ran Atkinson, who played a critical role in the early IPsec days and wrote the first series of IPsec standards: RFCs 1825-1827 👑 Karen Seo deserves special thanks for helping edit this version and the previous one 💕 the author also wants to thank the members of the IPSEC and MSEC working groups who helped develop this protocol spec. the girlies who built this 🥹✨
10. References 📚
10.1. Normative References
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[DH98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[Eas04] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
[Ken-Arch] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
10.2. Informative References
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security Protocols", Proceedings of the Sixth Usenix Unix Security Symposium, July, 1996.
[HC03] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress, November 3, 2002.
[Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[Ken-AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[Kra01] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)", CRYPTO' 2001.
[NIST01] Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2), "Security Requirements for Cryptographic Modules", Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[Syverson] P. Syverson, D. Goldschlag, and M. Reed, "Anonymous Connections and Onion Routing", Proceedings of the Symposium on Security and Privacy, Oakland, CA, May 1997, pages 44-54.
Appendix A: Extended (64-bit) Sequence Numbers ✨
A1. Overview 🔭
this appendix describes an extended sequence number (ESN) scheme for use with IPsec (ESP and AH) 💫 it uses a 64-bit sequence number, but only the low-order 32 bits get transmitted as part of each packet. it covers both the window scheme used to detect replayed packets and how the high-order bits of the sequence number get determined, which are used for both replay rejection and computing the ICV. it also discusses a mechanism for handling loss of synchronization relative to the (not transmitted) high-order bits 🙃
A2. Anti-Replay Window 🪟
okay so the receiver will maintain an anti-replay window of size W 🪟 this window limits how far out of order a packet can be, relative to the packet with the highest sequence number that has been authenticated so far. (no requirement is established for minimum or recommended sizes for this window, beyond the 32- and 64-packet values already established for 32-bit sequence number windows. however, it is suggested that an implementer scale these values consistent with the interface speed supported by an implementation that makes use of the ESN option. also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) all 2^32 sequence numbers associated with any fixed value for the high-order 32 bits (Seqh) will hereafter be called a sequence number subspace 🫧 here's the cheat sheet of variables:
Var. Size
Name (bits) Meaning
---- ------ ---------------------------
W 32 Size of window
T 64 Highest sequence number authenticated so far,
upper bound of window
Tl 32 Lower 32 bits of T
Th 32 Upper 32 bits of T
B 64 Lower bound of window
Bl 32 Lower 32 bits of B
Bh 32 Upper 32 bits of B
Seq 64 Sequence Number of received packet
Seql 32 Lower 32 bits of Seq
Seqh 32 Upper 32 bits of Seqwhen doing the anti-replay check, or when figuring out which high-order bits to use to authenticate an incoming packet, there are two cases 👀
- Case A:
Tl >= (W - 1). in this case, the window is within one sequence number subspace. (See Figure 1) - Case B:
Tl < (W - 1). in this case, the window spans two sequence number subspaces. (See Figure 2)
in the figures below, the bottom line ("----") shows two consecutive sequence number subspaces, with zeros marking the beginning of each subspace 🧱 the two shorter lines above it show the higher-order bits that apply. the "====" is the window, and the "" is future sequence numbers, i.e., those beyond the current highest sequence number authenticated (ThTl) 🔮
Th+1 *********
Th =======*****
--0--------+-----+-----0--------+-----------0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 1 -- Case A Th ====**************
Th-1 ===
--0-----------------+--0--+--------------+--0--
Bl Tl Bl
(Bl+2^32) mod 2^32
Figure 2 -- Case BA2.1. Managing and Using the Anti-Replay Window 🎀
okay so picture the anti-replay window as a string of bits 🧵, where W is the length of that string. W = T - B + 1, and it's capped at 2^32 - 1 💅. The bottom-most bit lines up with B and the top-most bit lines up with T. Every sequence number from Bl through Tl gets its own bit. That bit tells you whether a packet with that sequence number was received and authenticated, so replays can get caught and rejected 🙈.
When a packet with a 64-bit sequence number (Seq) bigger than T shows up and passes validation, the window slides:
Bgoes up by(Seq - T)(Seq - T)bits fall off the low end of the window(Seq - T)bits get added to the high end- The top bit is set, to say a packet with that sequence number was received and authenticated ✨
- The new bits between
Tand the top bit are set to say no packets with those sequence numbers have been received yet Tbecomes the new sequence number
Now for checking replays 👀
- Case A: If
Seql >= Bl(whereBl = Tl - W + 1) ANDSeql <= Tl, check the matching bit in the window to see if thisSeqlwas already seen. If yes, reject the packet. If no, do the integrity check (see Appendix A2.2. below for how to determineSeqh) 🔍 - Case B: If
Seql >= Bl(whereBl = Tl - W + 1) ORSeql <= Tl, check the matching bit in the window to see if thisSeqlwas already seen. If yes, reject the packet. If no, do the integrity check (see Appendix A2.2. below for how to determineSeqh) 🔍
A2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number 🌸
okay so only Seql actually gets sent with the packet, which means the receiver has to figure out which sequence number subspace each packet lives in, aka work out the value of Seqh 🧠. These equations show how to pick Seqh under "normal" conditions. For how to recover from extreme packet loss, check out Section A3 💖
Under Case A (Figure 1):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1
Under Case B (Figure 2):
If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1
If Seql < Bl (where Bl = Tl - W + 1), then Seqh = ThA2.3. Pseudo-Code Example 💻
this pseudo-code shows how all of the above fits together for the anti-replay and integrity checks. Seql', Tl, Th and W are all 32-bit unsigned integers, and the math is mod 2^32 🧁
If (Tl >= W - 1) Case A
If (Seql >= Tl - W + 1)
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else
Seqh = Th + 1
If (pass integrity check)
Tl = Seql (shift bits)
Th = Th + 1
Set bit corresponding to Seql
Pass the packet on
Else reject packet
Else Case B
If (Seql >= Tl - W + 1)
Seqh = Th - 1
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
Seqh = Th
If (Seql <= Tl)
If (pass replay check)
If (pass integrity check)
Set the bit corresponding to Seql
Pass packet on
Else reject packet
Else reject packet
Else
If (pass integrity check)
Tl = Seql (shift bits)
Set the bit corresponding to Seql
Pass packet on
Else reject packetA3. Handling Loss of Synchronization due to Significant Packet Loss 🚨
okay, serious moment 😭. If there's an undetected loss of 2^32 or more consecutive packets on a single SA, the transmitter and receiver lose sync on the high-order bits. That means the equations in Section A2.2. stop giving the right answer. Unless someone detects and fixes this, every later packet on that SA fails authentication and gets thrown out 💀. This is the procedure that SHOULD be implemented by any IPsec (ESP or AH) implementation that supports the ESN option 🔧
Quick note: this kind of huge traffic loss will usually get caught at higher layers before IPsec ever has to run the re-sync stuff in A3.1 and A3.2 🙌. If a big chunk of the SA's traffic is TCP, the sender stops getting ACKs and quits sending way before 2^32 packets go missing. For any bi-directional application, even ones running above UDP, an outage that long would probably trigger some kind of timeout. A unidirectional app over UDP, though, might have no feedback at all to notice a loss this big, and that's why a recovery method is needed for this case 🥺. These observations apply to SAs between security gateways, between hosts, or between a host and a security gateway.
The solution we picked was chosen so it:
- minimizes the impact on normal traffic processing 🏃♀️
- avoids creating a new denial of service opening, like an attacker forcing resources to get diverted into a re-synchronization process 🛡️
- limits the recovery mechanism to the receiver. Anti-replay is only a service for the receiver, and the transmitter usually doesn't know whether the receiver is using sequence numbers for this optional service, so it's better for recovery to stay local to the receiver. This also keeps backward compatibility intact 🫶
A3.1. Triggering Re-synchronization ⏰
For each SA, the receiver counts the number of consecutive packets that fail authentication. That count triggers the re-synchronization process, which should be run in the background or on a separate processor 🧵. Getting a valid packet on the SA resets the counter to zero. The trigger value is a local parameter. There's no requirement to support different trigger values for different SAs, though an implementer may choose to do that 🎀
A3.2. Re-synchronization Process 🔄
Once the trigger point is hit, a "bad" packet gets picked and authentication is retried using successively larger values for the upper half of the sequence number (Seqh). Each retry bumps the value up by one. The number of retries should be capped, just in case the packet is from the "past" or is a bogus one. That limit is a local parameter. (Because the Seqh value is implicitly placed after the ESP (or AH) payload, this procedure might be optimized by running the integrity algorithm over the packet up to the end of the payload, then computing different candidate ICVs by varying the value of Seqh.) If a packet authenticates through this procedure, the consecutive failure count resets and T gets set to the value from the received packet ✨
This solution only needs support on the receiver's side, so it stays backward compatible 🌈. Also, since re-synchronization either happens in the background or uses an extra processor, it doesn't slow down traffic processing, and a denial of service attack can't pull resources away from traffic processing 💪
Author's Address 🖋️
Stephen Kent
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim relate to the technology in this document can be validly claimed, or whether any license under those rights is or isn't available. It also doesn't say it has done any independent work to find such rights. You can find info on how rights work for RFC documents in BCP 78 and BCP 79 📚.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, or the outcome of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society ✨🫶
📦 where this page comes from
- ietf: rfc4303 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms