RFC 2406
IP Encapsulating Security Payload (ESP)
RFC 2406: IP Encapsulating Security Payload (ESP) 💖
okay bestie, this is RFC 2406, and it's giving networking royalty ✨ It's a Standards Track document dated November 1998. The authors are S. Kent of BBN Corp and R. Atkinson of @Home Network. It obsoletes RFC 1827, so 1827 is out and this one is the new main character 👑
Status of This Memo 📜
so this doc specifies an Internet standards track protocol for the Internet community, and it's basically inviting everyone to discuss it and send in suggestions for improvements 🫶 If you want to know where this protocol stands in terms of standardization and status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 And yes, distribution of this memo is unlimited 🌈
Copyright Notice 💅
Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀
Table of Contents 🗂️
1. Introduction..................................................2
2. Encapsulating Security Payload Packet Format..................3
2.1 Security Parameters Index................................4
2.2 Sequence Number .........................................4
2.3 Payload Data.............................................5
2.4 Padding (for Encryption).................................5
2.5 Pad Length...............................................7
2.6 Next Header..............................................7
2.7 Authentication Data......................................7
3. Encapsulating Security Protocol Processing....................7
3.1 ESP Header Location......................................7
3.2 Algorithms..............................................10
3.2.1 Encryption Algorithms..............................10
3.2.2 Authentication Algorithms..........................10
3.3 Outbound Packet Processing..............................10
3.3.1 Security Association Lookup........................11
3.3.2 Packet Encryption..................................11
3.3.3 Sequence Number Generation.........................12
3.3.4 Integrity Check Value Calculation..................12
3.3.5 Fragmentation......................................13
3.4 Inbound Packet Processing...............................13
3.4.1 Reassembly.........................................13
3.4.2 Security Association Lookup........................13
3.4.3 Sequence Number Verification.......................14
3.4.4 Integrity Check Value Verification.................15
3.4.5 Packet Decryption..................................16
4. Auditing.....................................................17
5. Conformance Requirements.....................................18
6. Security Considerations......................................18
7. Differences from RFC 1827....................................18
Acknowledgements................................................19
References......................................................19
Disclaimer......................................................20
Author Information..............................................21
Full Copyright Statement........................................221. Introduction ✨
okay so ESP (the Encapsulating Security Payload) is a header built to give you a whole mix of security services, and it works in both IPv4 and IPv6 🌈 You can use it on its own, pair it with the IP Authentication Header (AH) [KA97b], or nest things, like with tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], which we'll just call the Security Architecture document from here on 📚). 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. If you want the deets on using ESP and AH in different network environments, the Security Architecture document [KA97a] is where it's at 🦋
The ESP header goes right after the IP header and before the upper layer protocol header (that's transport mode) or before an encapsulated IP header (that's tunnel mode) 💅 We'll get into those modes more below.
ESP gives you confidentiality, data origin authentication, connectionless integrity, an anti-replay service (basically a form of partial sequence integrity 🔥), and limited traffic flow confidentiality 🫶 Which of these you actually get depends on the options picked when the Security Association gets established, and also on where the implementation sits. Confidentiality can be selected all on its own, independent of everything else. BUT, and this is a big but 😭, using confidentiality without integrity/authentication (whether that's in ESP or separately in AH) can expose your traffic to certain kinds of active attacks that could undermine the confidentiality service itself (see [Bel96]). Data origin authentication and connectionless integrity are joint services, which we'll call "authentication" from here, and they're offered as an option alongside (optional) confidentiality. The anti-replay service can only be selected if data origin authentication is selected, and whether it's switched on is totally at the receiver's discretion 👑 (Even though the default is for the sender to increment the Sequence Number used for anti-replay, the service only works if the receiver actually checks the Sequence Number 🙈) Traffic flow confidentiality needs tunnel mode, and it's most effective at a security gateway, where traffic aggregation might be able to mask the true source-destination patterns 🎀 Note that although both confidentiality and authentication are optional, at least one of them MUST be selected 🚨
Okay, next: it's assumed you already know the terms and concepts from the Security Architecture document. Honestly, you should be familiar with the security services offered by ESP and AH, the concept of Security Associations, the ways ESP can be used together with the Authentication Header (AH), and the different key management options for ESP and AH 🧚 (On that last topic, the current key management options required for both AH and ESP are manual keying and automated keying via IKE [HC98].)
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97] 🌸
2. Encapsulating Security Payload Packet Format 🍓
The protocol header (IPv4, IPv6, or Extension) sitting right before the ESP header will contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2] 💜
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) | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |erage*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Authentication Data (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * If included in the Payload field, cryptographic
synchronization data, e.g., an Initialization Vector (IV, see
Section 2.3), usually is not encrypted per se, although it
often is referred to as being part of the ciphertext.Here's the vibe: the following subsections define the fields in the header format. "Optional" means the field is omitted if the option isn't selected, i.e., it's present in neither the packet as transmitted nor as formatted for computation of an Integrity Check Value (ICV, see Section 2.7). Whether or not an option is selected gets defined as part of Security Association (SA) establishment. So the format of ESP packets for a given SA is fixed for the duration of the SA 🔒 By contrast, "mandatory" fields are always present in the ESP packet format, for all SAs 💖
2.1. Security Parameters Index 🦋
The SPI is an arbitrary 32-bit value that, together with the destination IP address and security protocol (ESP), uniquely identifies the Security Association for this datagram 🪪 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 📜 It's ordinarily selected by the destination system when an SA gets established (see the Security Architecture document for more details). The SPI field is mandatory ✨
The SPI value of zero (0) is reserved for local, implementation-specific use, and it MUST NOT be sent on the wire 🙅 For example, a key management implementation MAY use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA hasn't been established yet 🧚
2.2. Sequence Number 🔢
This unsigned 32-bit field contains a monotonically increasing counter value (the sequence number) 📈 It's mandatory, and it's always present even if the receiver doesn't elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the receiver's discretion. In other words, the sender MUST always transmit this field, but the receiver doesn't need to act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below) 👑
The sender's counter and the receiver's counter get 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) prior to the transmission of the 2^32nd packet on an SA 🔑 It's giving "rotate your keys before you hit the limit" energy, no cap 💀
2.3. Payload Data ✨
Okay bestie, Payload Data is the variable-length field that holds whatever the Next Header field says it is 📦 It's mandatory and has to be a whole number of bytes long, no fractions allowed 💖 If the encryption algorithm needs cryptographic synchronization data, like an Initialization Vector (IV), then that data MAY be carried explicitly in the Payload field 🦋 Any encryption algorithm that needs explicit, per-packet sync data MUST indicate the length, the structure, and the location of that data, as part of an RFC that spells out how the algorithm gets used with ESP 📜 And if the sync data is implicit, the algorithm for deriving it MUST be part of the RFC 🧠
Now, about making sure the real ciphertext lines up properly when there's an IV in the mix 👀
- For some IV-based modes of operation, the receiver treats the IV as the start of the ciphertext and feeds it straight into the algorithm. In these modes, lining up 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) 💅
Several things can require or motivate using the Padding field, so let's go through them 🫶
- If an encryption algorithm needs the plaintext to be a multiple of some number of bytes (think the block size of a block cipher), the Padding field fills the plaintext out to that size. The plaintext here means the Payload Data, Pad Length and Next Header fields, plus the Padding itself. 🌸
- Padding can also be needed no matter what the encryption algorithm wants, just to make sure the resulting ciphertext ends on a 4-byte boundary. The Pad Length and Next Header fields must be right aligned within a 4-byte word, like the ESP packet format figure above shows, so that the Authentication Data field (if present) lands on a 4-byte boundary. 🎀
- Extra padding beyond what the algorithm or alignment needs can be used to hide the real length of the payload, which helps with (partial) traffic flow confidentiality. Heads up though: all that extra padding costs bandwidth, so use it with care 🍓
The sender MAY add 0-255 bytes of padding. Including the Padding field in an ESP packet is optional, but all implementations MUST support generating and consuming padding 🧚
Two quick things to keep straight about the padding math:
a. For making sure the bits being encrypted are a multiple of the algorithm's blocksize (the first bullet above), the padding computation applies to the Payload Data only. The IV, Pad Length and Next Header fields are not counted. 💜
b. For making sure the Authentication Data sits on a 4-byte boundary (the second bullet above), the padding computation applies to the Payload Data including the IV, Pad Length and Next Header fields. 🦋
If Padding bytes are needed but the encryption algorithm doesn't specify what goes in them, 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 the rest keep counting up in a monotonically increasing sequence: 1, 2, 3, ... When this padding scheme is used, the receiver SHOULD inspect the Padding field. 👑 (Why this scheme? It was picked because it's simple, easy to build in hardware, and it offers limited protection against certain "cut and paste" attacks when there are no other integrity measures, as long as the receiver checks the padding values when decrypting. Iconic design choice, honestly. ✨)
Any encryption algorithm that needs Padding other than the default above MUST define the Padding contents (for example zeros or random data) and any receiver processing those Padding bytes require, in an RFC that specifies how the algorithm is used with ESP. In those situations, the encryption algorithm and mode you pick decide what the Padding field contains, as defined in that algorithm's RFC. The relevant algorithm RFC MAY specify that a receiver MUST inspect the Padding field, or that a receiver MUST inform senders how it will handle the Padding field. 🌈
2.5. Pad Length 🎀
The Pad Length field tells you how many pad bytes come right before it 🫶 Valid values are 0-255, and a value of zero means there are no Padding bytes at all. The Pad Length field is mandatory, so no skipping it 💖
2.6. Next Header 🦋
The Next Header is an 8-bit field that identifies the type of data in the Payload Data field. Examples are an extension header in IPv6 or an upper layer protocol identifier 🧚 The value comes from the set of IP Protocol Numbers in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The Next Header field is mandatory, bestie 📜
2.7. Authentication Data 🌸
The Authentication Data is a variable-length field holding an Integrity Check Value (ICV), which is computed over the ESP packet minus the Authentication Data itself 🔐 The length of the field depends on the authentication function you selected. This field is optional, and it only shows up if the authentication service was selected for the SA in question. The authentication algorithm specification MUST specify the length of the ICV, plus the comparison rules and processing steps for validation. It's giving "read the spec" energy 💅
3. Encapsulating Security Protocol Processing 🔥
3.1. ESP Header Location 🧚
Like AH, ESP can be used in two ways: transport mode or tunnel mode 💜 Transport mode only applies to host implementations, and it protects upper layer protocols but not the IP header 🦋 (Side note: for "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document, inbound and outbound IP fragments may need the IPsec implementation to do extra IP reassembly/fragmentation so it conforms to this specification and gives transparent IPsec support. That requires special care when multiple interfaces are in use. ⚠️)
In transport mode, ESP goes after the IP header and before an upper layer protocol like TCP, UDP, ICMP, etc., or before any other IPsec headers that were already inserted. For IPv4, that means ESP goes after the IP header (and any options it has), but before the upper layer protocol. (Quick reminder: "transport" mode doesn't mean it's only for TCP and UDP. An ICMP message MAY be sent using either "transport" mode or "tunnel" mode 🌈) Here's the before and after for a typical IPv4 packet, with the "ESP trailer" covering any Padding plus the Pad Length and Next Header fields:
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 |Auth|
-------------------------------------------------
|<----- encrypted ---->|
|<------ authenticated ----->|For IPv6, ESP is treated as an end-to-end payload, so it should show up after hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) could sit before or after the ESP header depending on the semantics you want. 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 a typical IPv6 packet:
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|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
* = if present, could be before ESP, after ESP, or bothESP and AH headers can be combined in a bunch of different modes. The IPsec Architecture document describes the combinations of security associations that must be supported 🧠
Tunnel mode ESP can be used in either hosts or security gateways. When ESP runs in a security gateway (to protect subscriber transit traffic), tunnel mode must be used 👑 In tunnel mode, the "inner" IP header carries the ultimate source and destination addresses, while an "outer" IP header can have different IP addresses, like the addresses of the security gateways. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header 🔥 The position of ESP relative to the outer IP header is the same as in transport mode. Here's how it looks for typical IPv4 and IPv6 packets:
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
-----------------------------------------------------------
|<--------- encrypted ---------->|
|<----------- authenticated ---------->|
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth|
------------------------------------------------------------
|<--------- encrypted ----------->|
|<---------- authenticated ---------->|
* = if present, construction of outer IP hdr/extensions
and modification of inner IP hdr/extensions is
discussed below.3.2. Algorithms 🧁
okay so the mandatory-to-implement algorithms are all listed in Section 5, "Conformance Requirements" 📋, so go check there bestie. Other algorithms MAY be supported ✨. Now here's the tea: even though confidentiality and authentication are both optional, at least one of them MUST be selected, which means both algorithms MUST NOT be simultaneously NULL 🙅♀️. You can't switch off BOTH, babe 💀.
3.2.1. Encryption Algorithms 🔐
The encryption algorithm is specified by the SA 💌. ESP is designed for use with symmetric encryption algorithms 🗝️. Because IP packets may arrive out of order, each packet must carry any data the receiver needs to set up cryptographic synchronization for decryption 🧩. That data can ride along explicitly in the Payload field (like an IV, which we talked about above), or it can be derived from the packet header. Since ESP makes room for padding the plaintext, encryption algorithms used with ESP may behave like block mode or stream mode algorithms 🌊. And since encryption is optional, this algorithm may be "NULL" 🫥.
3.2.2. Authentication Algorithms 🛡️
The authentication algorithm used for the ICV computation is specified by the SA 🪪. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (for example, DES) or on one-way hash functions (for example, MD5 or SHA-1) 🔑. For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate 📡, though performance and space considerations currently rule those out 😤. And since authentication is optional, this algorithm may be "NULL" too 🙈.
3.3. Outbound Packet Processing 📤
In transport mode, the sender wraps the upper layer protocol information up in the ESP header and trailer, and keeps the specified IP header (plus any IP extension headers in the IPv6 context) 🎀. In tunnel mode, the outer and inner IP headers and extensions can be related to each other in a whole bunch of different ways 🌀. How the outer IP header gets built during encapsulation is explained in the Security Architecture document 📖. If security policy requires more than one IPsec header or extension, the order those security headers get applied MUST be defined by security policy 📋. Yes, the policy has to decide, it's not optional 💅.
3.3.1. Security Association Lookup 🔎
ESP only gets applied to an outbound packet after the IPsec implementation has determined that the packet is associated with an SA that calls for ESP processing 💫. How the implementation figures out what IPsec processing (if any) goes on outbound traffic is covered in the Security Architecture document 📚.
3.3.2. Packet Encryption 🔒
In this section we talk as if encryption is always being applied, because of how the formatting works out 📐. That's done with the understanding that "no confidentiality" is what you get when you use the NULL encryption algorithm 🫶. So the sender does the following:
- Encapsulates (into the ESP
Payloadfield):- For transport mode: just the original upper layer protocol information.
- For tunnel mode: the entire original IP datagram.
- Adds any necessary padding 🧵.
- Encrypts the result (
Payload Data,Padding,Pad Length, andNext Header) using the key, the encryption algorithm, the algorithm mode indicated by the SA, and the cryptographic synchronization data (if there is any) 🪄.- If explicit cryptographic synchronization data, for example 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, for example an IV, is indicated, it is constructed and input to the encryption algorithm as per the algorithm specification.
- If explicit cryptographic synchronization data, for example an IV, is indicated, it is input to the encryption algorithm per the algorithm specification and placed in the
The exact steps for building the outer IP header depend on the mode (transport or tunnel), and those are described in the Security Architecture document 🗺️.
If authentication is selected, encryption happens FIRST, before the authentication, and the encryption does not cover the Authentication Data field 🫧. This order makes it quicker for the receiver to spot and toss out replayed or bogus packets before decrypting anything, which can help soften denial of service attacks 🛑. It also makes parallel processing possible at the receiver, since decryption can run at the same time as authentication 🏃♀️💨. Heads up though: because Authentication Data isn't protected by encryption, a keyed authentication algorithm must be used to compute the ICV 🔐.
Quick reminder: the order is encrypt first, then authenticate. Flip that and the whole safety net gets weaker 🚨.
3.3.3. Sequence Number Generation 🔢
The sender's counter gets set to 0 when an SA is established 🌱. The sender increments the Sequence Number for this SA and drops the new value into the Sequence Number field 📝. So the very first packet sent on a given SA has a Sequence Number of 1 🥇.
If anti-replay is enabled (which is the default), the sender checks that the counter hasn't cycled before putting the new value in the Sequence Number field 🔍. Put another way, the sender MUST NOT send a packet on an SA if doing so would cause the Sequence Number to cycle 🚫. Trying to send a packet that would overflow the Sequence Number is an auditable event 📋. (Side note: this approach to Sequence Number management doesn't need modular arithmetic, so no math flex required 🤓.)
The sender assumes anti-replay is enabled by default, unless the receiver says otherwise (see 3.4.3) 🙋♀️. So if the counter has cycled, the sender will set up a new SA and key (unless the SA was configured with manual key management) 🔄.
If anti-replay is disabled, the sender doesn't need to monitor or reset the counter, for example when manual key management is in use (see Section 5) 😌. However, the sender still increments the counter, and when it hits the maximum value, the counter rolls over back to zero 🎡.
3.3.4. Integrity Check Value Calculation 🧮
If authentication is selected for the SA, the sender computes the ICV over the ESP packet minus the Authentication Data 🧾. That means the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header are all covered by the ICV computation 💜. Note that those last four fields will be in ciphertext form, since encryption happens before authentication 🔏.
Some authentication algorithms need the byte string being run through the ICV computation to be a multiple of a blocksize that the algorithm specifies 📏. If the length of that byte string doesn't match the blocksize requirements, implicit padding MUST be appended to the end of the ESP packet (after the Next Header field) before the ICV computation 🧩. The padding octets MUST have a value of zero 0️⃣. The blocksize, and therefore the length of the padding, is set by the algorithm specification 📐. This padding is NOT transmitted with the packet 🫥. Also, MD5 and SHA-1 are treated as having a 1-byte blocksize because of their internal padding conventions 🤯.
3.3.5. Fragmentation 🧩
If it's needed, fragmentation happens after ESP processing inside an IPsec implementation 🪡. So transport mode ESP is only applied to whole IP datagrams, not to IP fragments 🚫🧩. An IP packet that ESP has already been applied to can still get fragmented by routers along the way 🛣️, and those fragments must be reassembled before ESP processing at the receiver 🪢. In tunnel mode, ESP is applied to an IP packet whose payload may itself be a fragmented IP packet 🎁. 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 beginning of Section 3.1, bump-in-the-stack and bump-in-the-wire implementations may have to first reassemble a packet that the local IP layer fragmented, then apply IPsec, and then fragment the resulting packet 🧵🔁.
NOTE: For IPv6, bump-in-the-stack and bump-in-the-wire implementations will need to walk through all the extension headers to figure out whether there's a fragmentation header, and therefore whether the packet needs reassembling before IPsec processing 🕵️♀️.
3.4. Inbound Packet Processing 📥
3.4.1. Reassembly 🪡
If it's required, reassembly happens before ESP processing 🧶. If a packet offered to ESP for processing looks like an IP fragment, meaning the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, the receiver MUST discard the packet 🗑️. That's an auditable event 📋. The audit log entry for this event SHOULD include the SPI value, the date and time received, the Source Address, the Destination Address, the Sequence Number, and (in IPv6) the Flow ID 📝✨.
NOTE: For packet reassembly, the current IPv4 spec does NOT require zeroing theOFFSETfield or clearing theMORE FRAGMENTSflag 😬. For a reassembled packet to get processed by IPsec (instead of being thrown out as an apparent fragment), the IP code must do both of those things after it reassembles a packet 🔧.
3.4.2. Security Association Lookup 🗝️
When a (reassembled) packet containing an ESP Header comes in, the receiver figures out the right (unidirectional) SA 🧭. It does that based on the destination IP address, the security protocol (ESP), and the SPI 🎯. (This process is described in more detail in the Security Architecture document 📖.) The SA tells the receiver whether the Sequence Number field gets checked, whether the Authentication Data field should be present, and which algorithms and keys to use for decryption and ICV computation (where that applies) 🔐.
If no valid Security Association exists for this session (say, the receiver doesn't have a key), the receiver MUST discard the packet 🙅♀️. That's an auditable event too 📋. The audit log entry for this event SHOULD include the SPI value, the date and time received, the Source Address, the Destination Address, the Sequence Number, and (in IPv6) the cleartext Flow ID 💖.
3.4.3 Sequence Number Verification 🔢✨
Okay bestie, every ESP implementation MUST support the anti-replay service 🛡️, but the receiver can switch it on or off per SA, so it's a per-SA vibe. This service MUST NOT be enabled unless authentication is also enabled for that SA, because otherwise the Sequence Number field isn't integrity protected 🙈. Also, there's no way to manage transmitted Sequence Number values across multiple senders pointing at one SA (unicast, broadcast, or multicast, it doesn't matter). So the anti-replay service SHOULD NOT be used in a multi-sender environment that uses a single SA. Not ideal, not me 💀
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 enabled at the receiver 🤷♀️. To stop 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, when an SA establishment protocol like IKE is in use. Communication is everything, periodt 💅
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 Sequence Number isn't a duplicate 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 ⚡.
Duplicates get rejected with a sliding receive window 🪟. (How the window is implemented is a local matter, but the next bit describes what the implementation has to do.) A MINIMUM window size of 32 MUST be supported. A window size of 64 is preferred and SHOULD be used as the default 👑.
A receiver MAY pick a window size that's bigger than the MINIMUM 🌸. (The receiver does NOT tell the sender what the window size is, so keep that little secret 🤫.)
The "right" edge of the window is the highest validated Sequence Number received on this SA 📈. Packets with Sequence Numbers lower than the "left" edge get rejected 🚫. Packets inside the window get checked against a list of packets already received inside the window. There's an efficient way to do that check using a bit mask, and it's described in the Security Architecture document 🧠.
If a received packet is inside the window and new, or it's to the right of the window, then the receiver moves on to ICV verification 🔍. If ICV validation fails, the receiver MUST discard the received IP datagram as invalid, and 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 only gets updated if ICV verification succeeds ✅.
DISCUSSION:
If the packet is inside the window and new, or it's outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. Authenticate first, update second, no skipping steps 🫶
3.4.4 Integrity Check Value Verification 🔐
If authentication was selected, the receiver computes the ICV over the ESP packet minus the Authentication Data, using the specified authentication algorithm. Then it checks that the result is the same as the ICV in the Authentication Data field of the packet. The details of that computation are below 🧩.
If the computed ICV and the received ICV 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 (in IPv6) the cleartext Flow ID 📋.
DISCUSSION:
Start by removing and saving the ICV value (the Authentication Data field) 🫧. Next, check the overall length of the ESP packet minus the Authentication Data. If implicit padding is needed based on the blocksize of the authentication algorithm, append zero-filled bytes to the end of the ESP packet, right after the Next Header field. Then do the ICV computation and compare the result with the saved value, using the comparison rules from the algorithm specification. (For example, if a digital signature and a one-way hash are used for the ICV computation, the matching process is more complex 🤓.)
3.4.5 Packet Decryption 🎀
Like in section 3.3.2, "Packet Encryption," we talk about encryption as always being applied, because of the formatting implications 📦. This is with the understanding that "no confidentiality" is offered by using the NULL encryption algorithm 🫠. So the receiver does this:
- 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 🔓.
- If explicit cryptographic synchronization data, e.g., an IV, is indicated, it's taken from the Payload field and fed into 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 gets built and fed into the decryption algorithm as per the algorithm specification.
- Processes any padding as specified in the encryption algorithm specification. If the default padding scheme (see Section 2.4) was used, the receiver SHOULD inspect the Padding field before removing the padding and passing the decrypted data to the next layer 👀.
- Rebuilds the original IP datagram from:
- For transport mode: the original IP header plus the original upper layer protocol information in the ESP Payload field.
- For tunnel mode: the tunnel IP header + the entire IP datagram in the ESP Payload field.
The exact steps for rebuilding the original datagram depend on the mode (transport or tunnel), and they're described in the Security Architecture document 📚. At a minimum, in an IPv6 context, the receiver SHOULD make sure the decrypted data is 8-byte aligned, so the protocol named in the Next Header field can process it easily 🧃.
If authentication was selected, verification and decryption MAY be done serially or in parallel ⏩. If it's serial, ICV verification SHOULD go first. If it's parallel, verification MUST be completed before the decrypted packet is passed on for further processing. This order helps the receiver quickly detect and reject replayed or bogus packets before decrypting them, which can reduce the impact of denial of service attacks 🛑. Note:
If the receiver decrypts in parallel with authentication, care must be taken to avoid possible race conditions around packet access and rebuilding the decrypted packet 🏃♀️💨.
There are a few ways decryption can "fail" 😬:
a. The selected SA may not be correct. The SA could be mis-selected because the SPI, destination address, or IPsec protocol type fields got tampered with. If those errors map the packet to another extant SA, they look exactly like a corrupted packet (case c). Tampering with the SPI can be detected by using authentication. However, an SA mismatch might still happen because of tampering with the IP Destination Address or the IPsec protocol type field 🕵️♀️.
b. The pad length or pad values could be wrong. Bad pad lengths or pad values can be detected whether or not authentication is used 🧐.
c. The encrypted ESP packet could be corrupted. This can be detected if authentication is selected for the SA 🔍.
In case (a) or (c), the erroneous result of the decryption operation (an invalid IP datagram or transport-layer frame) won't necessarily be detected by IPsec. That's the responsibility of later protocol processing 🫣.
4. Auditing 🧾
Not every system that implements ESP will do auditing 🤷♀️. But if ESP is part of a system that supports auditing, 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. However, 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 📑. 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's no requirement for the receiver to send any message to the purported sender in response to an auditable event, because doing that 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, and MUST comply with all requirements of the Security Architecture document 💯. If the key used to compute an ICV is manually distributed, correctly providing the anti-replay service would require correctly maintaining the counter state at the sender until the key is replaced. There likely wouldn't be any automated recovery if counter overflow were imminent 😱. So a compliant implementation SHOULD NOT provide this service with SAs that are manually keyed. A compliant ESP implementation MUST support the following mandatory-to-implement algorithms 📋:
- DES in CBC mode [MD97]
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
- NULL Authentication algorithm
- NULL Encryption algorithm
Since ESP encryption and authentication are optional, support for the 2 "NULL" algorithms is required to stay consistent with the way these services get negotiated 🧃. NOTE that while authentication and encryption can each be "NULL," they MUST NOT both be "NULL" 🚫💖.
6. Security Considerations 🔒💀
Security is central to the design of this protocol 🛡️👑, so security considerations are woven all through the specification 🕸️. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document, so go check that out too 📖🫶.
7. Differences from RFC 1827 ✨
okay bestie, so this doc is basically the glow-up of RFC 1827 🦋 Back then, RFC 1827 [ATK95] gave you a "shell," and you had to finish it by defining transforms. The problem was that transforms kept multiplying in every direction, so this version became a full framework and context for ESP instead 💅 It also lists the security services ESP may offer, which is giving organized.
The biggest change is that fields that used to live in transform documents are now part of this base ESP spec 🌸 For example, the fields needed for authentication and anti-replay are defined here, even though using that service is optional. The fields for encryption padding and next protocol identification are here too, and so is the packet processing that goes with them. Main character energy for the base spec 👑
Acknowledgements 💖
The ideas in this spec were derived from or influenced by the US Government's SP3 security protocol, ISO/IEC's NLSP, and the proposed swIPe security protocol. [SDNS89, ISO92, IB93].
This document has been evolving for over 3 years through lots of versions and iterations 🫶 Tons of people put in serious ideas and energy along the way. The authors want to thank Karen Seo for her huge help with review, editing, background research, and coordination for this version. They also want to thank the members of the IPsec and IPng working groups, with special shoutouts (in alphabetic order) to Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina Yuan 🌈
References 📚
[ATK95] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, August 1995.
[Bel96] Steven M. Bellovin, "Problem Areas for the IP Security
Protocols", Proceedings of the Sixth Usenix Unix Security
Symposium, July, 1996.
[Bra97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IB93] John Ioannidis & Matt Blaze, "Architecture and
Implementation of Network-layer Security Under Unix",
Proceedings of the USENIX Security Symposium, Santa Clara,
CA, October 1993.
[ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[KA97a] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[KA97b] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[MD97] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994. See also:
http://www.iana.org/numbers.html
[SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, as published
in NIST Publication NIST-IR-90-4250, February 1990.Disclaimer 🙈
Real talk: the views and specification in here belong to the authors, and they aren't necessarily the views of their employers. The authors and their employers specifically disclaim any responsibility for problems that come from implementing or using this spec, whether the implementation is correct or incorrect ngl 💀
Author Information 🎀
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.com
Randall Atkinson
@Home Network
425 Broadway,
Redwood City, CA 94063
USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.netFull Copyright Statement 🧚
Legal stuff, but it matters, so here it is exactly as written 🫶
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.📦 where this page comes from
- ietf: rfc2406 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms