RFC 4302
IP Authentication Header
RFC 4302: IP Authentication Header 🎀
Okay bestie, this is RFC 4302, the IP Authentication Header (AH) spec 💖. It's a Standards Track protocol from the Network Working Group, written by S. Kent at BBN Technologies in December 2005 ✨. It obsoletes RFC 2402 and doesn't list any updates 🦋. Everything below is the full doc, one part at a time 💅.
Status of This Memo ⭐
Okay so this one is an Internet standards track protocol for the whole Internet community 🌈. It wants discussion and suggestions for improvements 💬. For the current standardization state, check the "Internet Official Protocol Standards" (STD 1) 📚. Distribution is unlimited 🫶.
Copyright Notice 🌸
Copyright (C) The Internet Society (2005) 💜.
Abstract ✨
This doc describes an updated IP Authentication Header (AH), built to give authentication services in IPv4 and IPv6 🔥. It obsoletes RFC 2402 (November 1998) 💀.
Table of Contents 🧚
1. Introduction ....................................................3
2. Authentication Header Format ....................................4
2.1. Next Header ................................................5
2.2. Payload Length .............................................5
2.3. Reserved ...................................................6
2.4. Security Parameters Index (SPI) ............................6
2.5. Sequence Number ............................................8
2.5.1. Extended (64-bit) Sequence Number ...................8
2.6. Integrity Check Value (ICV) ................................9
3. Authentication Header Processing ................................9
3.1. Authentication Header Location .............................9
3.1.1. Transport Mode ......................................9
3.1.2. Tunnel Mode ........................................11
3.2. Integrity Algorithms ......................................11
3.3. Outbound Packet Processing ................................11
3.3.1. Security Association Lookup ........................12
3.3.2. Sequence Number Generation .........................12
3.3.3. Integrity Check Value Calculation ..................13
3.3.3.1. Handling Mutable Fields ...................13
3.3.3.2. Padding and Extended Sequence Numbers .....16
3.3.4. Fragmentation ......................................17
3.4. Inbound Packet Processing .................................18
3.4.1. Reassembly .........................................18
3.4.2. Security Association Lookup ........................18
3.4.3. Sequence Number Verification .......................19
3.4.4. Integrity Check Value Verification .................20
4. Auditing .......................................................21
5. Conformance Requirements .......................................21
6. Security Considerations ........................................22
7. Differences from RFC 2402 ......................................22
8. Acknowledgements ...............................................22
9. References .....................................................22
9.1. Normative References ......................................22
9.2. Informative References ....................................23
Appendix A: Mutability of IP Options/Extension Headers ............25
A1. IPv4 Options ...............................................25
A2. IPv6 Extension Headers .....................................26
Appendix B: Extended (64-bit) Sequence Numbers ....................28
B1. Overview ...................................................28
B2. Anti-Replay Window .........................................28
B2.1. Managing and Using the Anti-Replay Window ............29
B2.2. Determining the Higher-Order Bits (Seqh) of the
Sequence Number ......................................30
B2.3. Pseudo-Code Example ..................................31
B3. Handling Loss of Synchronization due to Significant
Packet Loss ................................................32
B3.1. Triggering Re-synchronization ........................33
B3.2. Re-synchronization Process ...........................331. Introduction 💖
This doc assumes you already know the terms from the "Security Architecture for the Internet Protocol" [Ken-Arch], which we'll call the Security Architecture document 📖. Specifically, you should know what security services the Encapsulating Security Payload (ESP) [Ken-ESP] and AH offer 🔐. You should also know about Security Associations, how ESP can be paired with AH, and which key management options exist 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 doc, are to be read as described in RFC 2119 [Bra97] 🎀.
Okay so AH gives you connectionless integrity and data origin authentication for IP datagrams (we're just calling this "integrity" from here on) 💅. It also protects against replays 🔁. The receiver picks this optional replay service when a Security Association (SA) gets set up ✨. The protocol default has the sender increment the anti-replay sequence number, but the service only works if the receiver actually checks that number 🙈. To use the Extended Sequence Number feature in an interoperable way, though, AH does put a requirement on SA management protocols: they have to be able to negotiate this feature (see Section 2.5.1 below) 🔥.
AH authenticates as much of the IP header as it can, plus the next-level protocol data 🦋. The catch is that some IP header fields can change in transit, and the sender can't predict what they'll be when the packet arrives 😭. AH can't protect those values, so the protection AH gives the IP header is piecemeal 🧩. (See Appendix A.)
AH can be used alone, combined with the IP Encapsulating Security Payload (ESP) [Ken-ESP], or nested (see the Security Architecture document [Ken-Arch]) 🌈. The security services can run between a pair of communicating hosts, a pair of communicating security gateways, or a security gateway and a host 🏰. ESP can give the same anti-replay and similar integrity services, and it also does confidentiality (encryption) 🔒. The big difference between ESP and AH integrity is how much they cover 👑. ESP doesn't protect any IP header fields unless ESP encapsulates them (for example, with tunnel mode) 🥹. For more on using AH and ESP in different network setups, check the Security Architecture document [Ken-Arch] 📚.
Section 7 gives a quick rundown of the differences between this doc and RFC 2402 [RFC2402] 💜.
2. Authentication Header Format 🌸
The protocol header right before the AH header (IPv4, IPv6, or an IPv6 Extension) SHALL have the value 51 in its Protocol (IPv4) or Next Header (IPv6, Extension) field [DH98] 🎯. Figure 1 shows what the AH format looks like ✨.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Integrity Check Value-ICV (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. AH FormatNext up is a table of the fields that make up AH (shown in Figure 1), plus the other fields that go into the integrity computation 🧁. It also shows which fields the ICV covers and what actually gets sent 📦.
What What
# of Requ'd Integ is
bytes [1] Covers Xmtd
------ ------ ------ ------
IP Header variable M [2] plain
Next Header 1 M Y plain
Payload Len 1 M Y plain
RESERVED 2 M Y plain
SPI 4 M Y plain
Seq# (low-order 32 bits) 4 M Y plain
ICV variable M Y[3] plain
IP datagram [4] variable M Y plain
Seq# (high-order 32 bits) 4 if ESN Y not xmtd
ICV Padding variable if need Y not xmtd
[1] - M = mandatory
[2] - See Section 3.3.3, "Integrity Check Value Calculation", for
details of which IP header fields are covered.
[3] - Zeroed before ICV calculation (resulting ICV placed here
after calculation)
[4] - If tunnel mode -> IP datagram
If transport mode -> next header and dataThe subsections below define each field in the AH format 🎀. Every field here is mandatory, meaning it's always in the AH format and gets included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3) 💅.
Note: All the crypto algorithms used in IPsec take their input in canonical network byte order (see the Appendix of RFC 791 [RFC791]) and spit out their output in canonical network byte order too 🧠. IP packets also get sent in network byte order 🌐.
AH doesn't have a version number 🙃. So if backward compatibility is a worry, the two IPsec peers MUST handle it with a signaling mechanism to make sure they're using compatible versions of AH, like IKE [IKEv2] or an out-of-band configuration mechanism 🫶.
2.1. Next Header 🦋
The Next Header is an 8-bit field that says what type of payload comes right after the Authentication Header 🌷. Its value comes from the set of IP Protocol Numbers on the web page of the Internet Assigned Numbers Authority (IANA) 📋. For example, a value of 4 means IPv4, 41 means IPv6, and 6 means TCP 🎀.
2.2. Payload Length 📏
okay so this 8-bit field tells you how long the AH is, measured in 32-bit words (4-byte units), minus "2" 🎀. For example, if an integrity algorithm gives you a 96-bit authentication value, this length field will be "4" (3 32-bit word fixed fields plus 3 32-bit words for the ICV, minus 2) ✨. For IPv6, the total length of the header must be a multiple of 8-octet units 💅.
(bestie, pay attention here 👀 although IPv6 [DH98] calls AH an extension header, its length is measured in 32-bit words, NOT the 64-bit words that the other IPv6 extension headers use 🙈)
For comments on padding of this field, check out Section 2.6, "Integrity Check Value (ICV)", and Section 3.3.3.2.1, "ICV Padding" 🦋.
2.3. Reserved 🫧
this 16-bit field is reserved for future use 🌸. It MUST be set to "zero" by the sender, and it SHOULD be ignored by the recipient. (Note that the value is included in the ICV calculation, but is otherwise ignored by the recipient.) It's giving "included but ignored" energy 💀💅
2.4. Security Parameters Index (SPI) 🔐
the SPI is an arbitrary 32-bit value that the receiver uses to identify the SA an incoming packet is bound to 🧚. For a unicast SA, the SPI can be used by itself to specify an SA, or it can be used together with the IPsec protocol type (in this case AH). Because the receiver generates the SPI value for unicast SAs, whether the value is enough to identify an SA by itself or has to be paired with the IPsec protocol value is a local matter 🍓. The SPI field is mandatory, and this mechanism for mapping inbound traffic to unicast SAs MUST be supported by all AH 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 support unicast traffic need not implement this de-multiplexing algorithm 🌈.
In many secure multicast architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the group security association's SPI 🫶. This SPI assignment is not negotiated or coordinated with the key management (e.g., IKE) subsystems that live in the individual end systems making up the group. So it's possible that a group security association and a unicast security association can use the same SPI at the same time 😭. A multicast-capable IPsec implementation MUST correctly de-multiplex inbound traffic even when SPI collisions happen ⭐.
Each entry in the Security Association Database (SAD) [Ken-Arch] must indicate whether the SA lookup uses the destination, or destination and source, IP addresses, in addition to the SPI 📋. For multicast SAs, the protocol field is not used for SA lookups. For each inbound, IPsec-protected packet, an implementation must search the SAD so that it finds the entry matching the "longest" SA identifier. In this context, if two or more SAD entries match based on the SPI value, then the entry that also matches on the destination, or destination and source, address comparison (as indicated in the SAD entry) is the "longest" match 🔍. This gives us 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 AH packet with that matching SAD entry. Otherwise, proceed to step 2. - Search the SAD for a match on
{SPI, destination address}. If an SAD entry matches, then process the inbound AH 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 AH 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, although 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 that the entries with the longest SA identifiers come first in that linked list. Entries with the shortest SA identifiers are sorted so that they are the last entries in the linked list 📚. A hardware-based implementation may be able to do the longest match search natively, 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 through 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 up 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 set of SPI values in the range 1 through 255 is 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 the 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 establish a new SA, but that SA hasn't been established yet 🥺.)
2.5. Sequence Number 🔢
this unsigned 32-bit field holds a counter value that goes up by one for each packet sent, i.e., a per-SA packet sequence number 📈. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. Sharing an SA among multiple senders is permitted, though generally not recommended 🙃. AH 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-reply features of AH are not available (see Sections 3.3.2 and 3.4.3) 🚫.
The field is mandatory and MUST always be present, even if the receiver doesn't choose to turn on the anti-replay service for a specific SA. Processing of the Sequence Number field is up to the receiver, but all AH implementations MUST be capable of performing the processing described in Section 3.3.2, "Sequence Number Generation", and Section 3.4.3, "Sequence Number Verification". So the sender MUST always transmit this field, but the receiver need not act upon it 💅.
The sender's counter and the receiver's counter are both 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.2 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 transmission of the 2^32nd packet on an SA 🔄. Think of it as a hard reset before the counter runs out 💀.
2.5.1. Extended (64-bit) Sequence Number 🌌
to support high-speed IPsec implementations, a new option for sequence numbers SHOULD be offered, as an extension to the current, 32-bit sequence number field ⚡. Use of an Extended Sequence Number (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 applies to multicast as well as unicast SAs.)
The ESN facility allows the use of a 64-bit sequence number for an SA. (See Appendix B, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the AH header of each packet, which keeps packet overhead low 🦋. The high-order 32 bits are kept as part of the sequence number counter by both the transmitter and the receiver, and they're included in the computation of the ICV, but they are not transmitted 🫢.
2.6. Integrity Check Value (ICV) 🛡️
this is a variable-length field that holds the Integrity Check Value (ICV) for this packet 💖. The field must be an integral multiple of 32 bits (IPv4 or IPv6) in length. The details of ICV processing are described in Section 3.3.3, "Integrity Check Value Calculation", and Section 3.4.4, "Integrity Check Value Verification". This field may include explicit padding, if needed to make sure the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All implementations MUST support such padding and MUST insert only enough padding to satisfy the IPv4/IPv6 alignment requirements. Details on how to compute the required padding length are provided below in Section 3.3.3.2, "Padding" 🧩. The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation 🔐.
3. Authentication Header Processing ⚙️
3.1. Authentication Header Location 📍
AH can be used in two ways: transport mode or tunnel mode 🎀. (For a description of when each should be used, see the Security Architecture document 📖.)
3.1.1. Transport Mode ✨
okay so in transport mode, AH gets tucked in right after the IP header and before the next layer protocol (like TCP, UDP, ICMP, etc.) or before any other IPsec headers that are already in there 🎀. For IPv4, that means AH goes after the IP header (and any options it has), but before the next layer protocol. (quick reminder: "transport" mode does NOT mean it's only for TCP and UDP 🙅♀️). Here's how it looks for a typical IPv4 packet, before and after 💅
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
-------------------------------------------------------
IPv4 |original IP hdr (any options) | AH | TCP | Data |
-------------------------------------------------------
|<- mutable field processing ->|<- immutable fields ->|
|<----- authenticated except for mutable fields ----->|for IPv6, AH is treated like an end-to-end payload 🦋, so it should show up after the hop-by-hop, routing, and fragmentation extension headers. The destination options extension header(s) can go before, after, or both before and after the AH header, depending on what semantics you want ✨. Here's the IPv6 version:
BEFORE APPLYING AH
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
|<--- mutable field processing -->|<-- immutable fields -->|
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or bothESP and AH headers can be mixed together in a bunch of different modes 🌈. The IPsec Architecture document lays out the combos of security associations that must be supported.
Heads up for "bump-in-the-stack" or "bump-in-the-wire" implementations (as defined in the Security Architecture document) 🚨: in transport mode, inbound and outbound IP fragments might make an IPsec implementation do extra IP reassembly/fragmentation, so it can both follow this spec and give transparent IPsec support. Be extra careful doing this when multiple interfaces are in play 😭.
3.1.2. Tunnel Mode 🧚
in tunnel mode, the "inner" IP header holds the ultimate (IP) source and destination addresses, while the "outer" IP header has the addresses of the IPsec "peers" (like security gateways) 🍓. Mixing inner and outer IP versions is allowed, so IPv6 over IPv4 and IPv4 over IPv6 are both fine. In tunnel mode, AH protects the entire inner IP packet, including the entire inner IP header 🔐. Where AH sits relative to the outer IP header is the same as in transport mode. Here are the diagrams for typical IPv4 and IPv6 packets:
----------------------------------------------------------------
IPv4 | | | orig IP hdr* | | |
|new IP header * (any options) | AH | (any options) |TCP| Data |
----------------------------------------------------------------
|<- mutable field processing ->|<------ immutable fields ----->|
|<- authenticated except for mutable fields in the new IP hdr->|
--------------------------------------------------------------
IPv6 | | ext hdrs*| | | ext hdrs*| | |
|new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
--------------------------------------------------------------
|<--- mutable field -->|<--------- immutable fields -------->|
| processing |
|<-- authenticated except for mutable fields in new IP hdr ->|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.3.2. Integrity Algorithms 🔑
the integrity algorithm used for the ICV computation is specified by the SA 💜. For point-to-point communication, good options include keyed Message Authentication Codes (MACs) built on symmetric encryption algorithms (for example AES [AES]) or on one-way hash functions (for example MD5, SHA-1, SHA-256, etc.). For multicast communication, people have come up with a bunch of cryptographic strategies for providing integrity, and research in this area is still going strong 🧠✨.
3.3. Outbound Packet Processing 📤
in transport mode, the sender puts the AH header after the IP header and before a next layer protocol header, just like we covered above 🎀. In tunnel mode, the outer and inner IP header/extensions can be related in a whole bunch of ways 🌸. How the outer IP header/extensions get built during encapsulation is covered in the Security Architecture document.
3.3.1. Security Association Lookup 🔍
AH only gets applied to an outbound packet after an IPsec implementation figures out that the packet is tied to an SA that calls for AH processing 👀. How it decides what IPsec processing (if any) goes on outbound traffic is described in the Security Architecture document.
3.3.2. Sequence Number Generation 🔢
the sender's counter starts at 0 when an SA gets established 🌱. The sender increments the sequence number (or ESN) counter for this SA and drops the low-order 32 bits of the 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 (the default), the sender checks that the counter hasn't cycled before putting the new value into the Sequence Number field 🛡️. Basically, the sender MUST NOT send a packet on an SA if doing so would make the sequence number cycle 🙅♀️. Trying to send a packet that would overflow the sequence number 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 turned on by default, unless the receiver says otherwise (see Section 3.4.3) or the SA was configured with manual key management 🙃. So normally, an AH implementation has the sender set up a new SA when the Sequence Number (or ESN) cycles, or right before it's about to cycle 🔄.
if anti-replay is disabled (as noted above), the sender doesn't need to monitor or reset the counter, like with manual key management (see Section 5) 🤷♀️. The sender still increments the counter though, and once it hits the max 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 B) is selected, only the low-order 32 bits of the sequence number get sent in the Sequence Number field 📦. Both the sender and receiver still keep full 64-bit ESN counters though. The high-order 32 bits are included in the ICV calculation 🧮.
Note: if a receiver decides not to turn on anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol ⚠️. Using ESN means the receiver has to manage the anti-replay window (so it can figure out the right value for the high-order ESN bits, which get used in the ICV computation) 😵💫. That's pretty much the opposite of the whole point of turning off anti-replay for an SA 💀.
3.3.3. Integrity Check Value Calculation 🧩
the AH ICV gets computed over:
- IP or extension header fields before the AH header that are either immutable in transit or predictable in value when they arrive at the endpoint for the AH SA 🎯
- the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number (low-order 32 bits), and the ICV (which is set to zero for this computation), and explicit padding bytes (if any)) 💖
- everything after AH is assumed to be immutable in transit 🫶
- the high-order bits of the ESN (if employed), and any implicit padding required by the integrity algorithm 🌸
3.3.3.1. Handling Mutable Fields 🦋
if a field might get modified during transit, its value is set to zero for the ICV computation 0️⃣. If a field is mutable but its value at the (IPsec) receiver is predictable, then that predictable value gets put into the field for the ICV calculation 🔮. The Integrity Check Value field is also set to zero to get ready for this computation 🧹. Replacing each field's value with zero (instead of just leaving the field out) keeps the alignment intact for the ICV calculation 📐. And the zero-fill approach makes sure the length of these handled fields can't be changed in transit, even though their contents aren't explicitly covered by the ICV 🔒.
as a new extension header or IPv4 option gets created, it'll be defined in its own RFC and SHOULD include (in the Security Considerations section) directions for how it should be handled when calculating the AH ICV 📝. If the IP (v4 or v6) implementation runs into an extension header it doesn't recognize, it'll discard the packet and send an ICMP message, and IPsec never even sees the packet 🙈. If the IPsec implementation runs into an IPv4 option it doesn't recognize, it should zero the whole option, using the second byte of the option as the length 🍃. IPv6 options (in Destination Extension Headers or the Hop-by-Hop Extension Header) have a flag that says whether they're mutable, and that decides how they get processed 🚩.
3.3.3.1.1. ICV Computation for IPv4 💜
3.3.3.1.1.1. Base Header Fields ✨
okay so the IPv4 base header fields get sorted into three buckets, bestie 🎀
Immutable 🔒 (these stay locked in place)
VersionInternet Header LengthTotal LengthIdentificationProtocol(This should be the value for AH.)Source AddressDestination Address(without loose or strict source routing)
Mutable but predictable 🔮
Destination Address(with loose or strict source routing)
Mutable (zeroed prior to ICV calculation) 🫠
Differentiated Services Code Point (DSCP)(6 bits, see RFC 2474 [NBBB98])Explicit Congestion Notification (ECN)(2 bits, see RFC 3168 [RFB01])FlagsFragment OffsetTime to Live (TTL)Header Checksum
Now the reasons, because they're giving main character energy 💅
DSCP - Routers may rewrite the DS field as needed to provide a desired local or end-to-end service, so the sender can't predict its value when it arrives 🍓
ECN - This changes if a router along the route experiences congestion, so the sender can't predict its value upon reception 🌧️
Flags - This field is excluded because an intermediate router might set the DF bit, even if the source did not select it 🚩
Fragment Offset - Since AH is applied only to non-fragmented IP packets, the Offset Field must always be zero, and thus it is excluded (even though it is predictable) 🧩
TTL - This is changed en route as a normal course of processing by routers, so its value at the receiver is not predictable by the sender 🏃♀️
Header Checksum - This will change if any of these other fields change, so its value upon reception can't be predicted by the sender 🥹
3.3.3.1.1.2. Options 🎀
for IPv4 (unlike IPv6), there's no mechanism for tagging options as mutable in transit 😭 so the IPv4 options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable. For IPv4, the entire option is viewed as a unit. So even though the type and length fields within most options are immutable in transit, if an option is classified as mutable, the entire option is zeroed for ICV computation purposes 🧸
3.3.3.1.2. ICV Computation for IPv6 🌸
3.3.3.1.2.1. Base Header Fields 🦋
the IPv6 base header fields are classified like this 👑
Immutable 🔒
VersionPayload LengthNext HeaderSource AddressDestination Address(without Routing Extension Header)
Mutable but predictable 🔮
Destination Address(with Routing Extension Header)
Mutable (zeroed prior to ICV calculation) 🫠
(*) The flow label described in AHv1 was mutable, and in RFC 2460 [DH98] was potentially mutable. To retain compatibility with existing AH implementations, the flow label is not included in the ICV in AHv2. 🫶
3.3.3.1.2.2. Extension Headers Containing Options 🧚
IPv6 options in the Hop-by-Hop and Destination Extension Headers have a bit that tells you whether the option might change (unpredictably) during transit. For any option whose contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options where the bit indicates immutability are included in the ICV calculation. See the IPv6 specification [DH98] for more information 📖
3.3.3.1.2.3. Extension Headers Not Containing Options 💜
The IPv6 extension headers that don't contain options are explicitly listed in Appendix A and classified as immutable, mutable but predictable, or mutable ✨
3.3.3.2. Padding and Extended Sequence Numbers 🌈
3.3.3.2.1. ICV Padding 🎀
As mentioned in Section 2.6, the ICV field may include explicit padding if it's required to make sure the AH header is a multiple of 32 bits (IPv4) or 64 bits (IPv6). If padding is required, its length depends on two things:
- the length of the ICV
- the IP protocol version (v4 or v6)
For example, if the output of the selected algorithm is 96 bits, no padding is required for IPv4 or IPv6. However, if a different length ICV gets generated because of a different algorithm, then padding may be required depending on the length and IP protocol version. The content of the padding field is arbitrarily selected by the sender. (The padding is arbitrary, but need not be random to achieve security.) These padding bytes are included in the ICV calculation, counted as part of the Payload Length, and transmitted at the end of the ICV field so the receiver can perform the ICV calculation 🫠 Inclusion of padding in excess of the minimum amount required to satisfy IPv4/IPv6 alignment requirements is prohibited 🚫
3.3.3.2.2. Implicit Packet Padding and ESN 🔥
If the ESN option is elected for an SA, then the high-order 32 bits of the ESN must be included in the ICV computation. For purposes of ICV computation, these bits are appended (implicitly) immediately after the end of the payload, and before any implicit packet padding 🧩
For some integrity algorithms, the byte string the ICV computation runs over must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH and the 32 high-order bits of the ESN, if enabled) doesn't match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the 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 doesn't specify an answer, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm doesn't specify the padding contents, then the padding octets MUST have a value of zero 🙈
3.3.4. Fragmentation 🧁
If required, IP fragmentation happens after AH processing within an IPsec implementation. So transport mode AH is applied only to whole IP datagrams (not to IP fragments) 🍰 An IPv4 packet that AH has been applied to may itself be fragmented by routers en route, and such fragments must be reassembled prior to AH processing at a receiver. (This doesn't apply to IPv6, where there's no router-initiated fragmentation.) In tunnel mode, AH is applied to an IP packet, whose payload may be a fragmented IP packet. For example, a security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (see the Security Architecture document for details) may apply tunnel mode AH 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 that the packet needs reassembling prior to IPsec processing.
Fragmentation, whether performed by an IPsec implementation or by routers along the path between IPsec peers, significantly reduces performance 📉 Moreover, the requirement for an AH receiver to accept fragments for reassembly creates denial of service vulnerabilities 😱 So an AH implementation MAY choose to not support fragmentation and may mark transmitted packets with the DF bit, to facilitate Path MTU (PMTU) discovery. In any case, an AH 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 🦋
If there is more than one IPsec header/extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied subsequent to the header being processed 💅
3.4.1. Reassembly 🧚
If required, reassembly happens before AH processing. If a packet offered to AH for processing appears to be an IP fragment, i.e., the OFFSET field is nonzero 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, Source Address, Destination Address, and (in IPv6) the Flow ID 📝
NOTE: For packet reassembly, the current IPv4 spec does not require either the zeroing of the OFFSET field or the clearing of the MORE FRAGMENTS flag. For a reassembled packet to be processed by IPsec (as opposed to discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet 🧩
3.4.2. Security Association Lookup 🔍
Upon receipt of a packet containing an IP Authentication Header, the receiver determines the appropriate (unidirectional) SA via lookup in the SAD. For a unicast SA, this determination is based on the SPI or the SPI plus protocol field, as described in Section 2.4. If an implementation supports multicast traffic, the destination address is also used in the lookup (in addition to the SPI), and the sender address also may be used, as described in Section 2.4. (This process is described in more detail in the Security Architecture document.) The SAD entry for the SA also indicates whether the Sequence Number field will be checked and whether 32- or 64-bit sequence numbers are employed for the SA. The SAD entry for the SA also specifies the algorithm(s) employed for ICV computation, and indicates the key required to validate the ICV 🔑
If no valid Security Association exists for this packet, the receiver MUST discard the packet. This is an auditable event. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, and (in IPv6) the Flow ID 🫶
(Note that SA management traffic, such as IKE packets, does not need to be processed based on SPI, i.e., one can de-multiplex this traffic separately based on Next Protocol and Port fields, for example.) 🌸
3.4.3. Sequence Number Verification ✨
okay so every AH implementation MUST support the anti-replay service 🛡️, but the receiver gets to switch it on or off for each SA 🔄. Anti-replay works for unicast SAs and multicast SAs alike. BUT this standard doesn't specify any mechanism for anti-replay on a multi-sender SA (unicast or multicast) 🙈 so if nobody negotiated or manually configured an anti-replay mechanism for that kind of SA, it is recommended that sender and receiver both have Sequence Number checking turned off for it (via negotiation or manual configuration), as noted below. this is giving "know your limits" energy 💅
If the receiver doesn't enable anti-replay for an SA, no inbound checks happen on the Sequence Number at all. From the sender's side though, the default assumption is that anti-replay IS enabled at the receiver. So to keep the sender from doing unnecessary sequence number monitoring and SA setup (see Section 3.3.2, "Sequence Number Generation"), if an SA establishment protocol such as IKE is being used, the receiver SHOULD notify the sender during SA establishment if the receiver won't provide anti-replay protection. 🫶
If the receiver HAS enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first AH check applied to a packet after it's been matched to an SA, so duplicate packets get rejected faster. ⚡
Duplicates are rejected using 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 are rejected. Packets falling inside the window get checked against a list of the 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, computed with the high-order 32 bits for the indicated SA (from their own local counter), when checking 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 counter, the receiver assumes the high-order 32 bits have been incremented, moving to a new sequence number subspace. 🌌 (This algorithm accommodates gaps in reception for a single SA as large as 2**32-1 packets. If a larger gap occurs, additional, heuristic checks for re-synchronization of the receiver's sequence number counter MAY be employed, as described in Appendix B.)
If the received packet falls within the window and isn't a duplicate, OR if the packet is to the right of the window, then the receiver proceeds to ICV verification. If the ICV validation fails, the receiver MUST discard the received IP datagram as invalid. This is an auditable event 📝. The audit log entry for this event SHOULD include the SPI value, date/time, Source Address, Destination Address, the Sequence Number, and (in IPv6) the Flow ID. The receive window only gets updated if the ICV verification succeeds. ✨
A MINIMUM window size of 32 packets MUST be supported, but 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 🔐
the receiver computes the ICV over the appropriate fields of the packet, using the specified integrity algorithm, and checks that it's the same as the ICV included in the ICV field of the packet. The details of that computation are coming up 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. This is an auditable event. The audit log entry SHOULD include the SPI value, date/time received, Source Address, Destination Address, and (in IPv6) the 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 saving the ICV value and replacing it (but not any ICV field padding) with zero. Zero all other fields that may have been modified during transit. (See Section 3.3.3.1, "Handling Mutable Fields", for a discussion of which fields are zeroed before performing the ICV calculation.) If the ESN option is elected for this SA, append the high-order 32 bits of the ESN after the end of the packet. Check the overall length of the packet (as described above), and if it requires implicit padding based on the requirements of the integrity algorithm, append zero-filled bytes to the end of the packet (after the ESN if present) as required. Perform the ICV computation and compare the result with the saved value, using the comparison rules defined by the algorithm specification. (For example, if a digital signature and one-way hash are used for the ICV computation, the matching process is more complex.) 🤓
4. Auditing 📣
Not all systems that implement AH will implement auditing 🤷♀️. However, if AH is incorporated into a system that supports auditing, then the AH implementation MUST also support auditing and MUST allow a system administrator to enable or disable auditing for AH. For the most part, the granularity of auditing is a local matter. However, several auditable events are identified in this specification, and for each of these events a minimum set of information that SHOULD be included in an audit log is defined. Additional information also MAY be included in the audit log for each of these events, and additional events, not explicitly called out in this specification, also MAY result in audit log entries. 🗂️
There is no requirement for the receiver to transmit any message to the purported sender in response to the detection of an auditable event, because of the potential to induce denial of service via such action. Replying to a suspicious sender could be a denial of service trap, so receivers don't have to say a word back 🙊
5. Conformance Requirements 📜
Implementations that claim conformance or compliance with this specification MUST fully implement the AH syntax and processing described here for unicast traffic, and MUST comply with all requirements of the Security Architecture document [Ken-Arch]. Additionally, if an implementation claims to support multicast traffic, it MUST comply with the additional requirements specified for support of such traffic. If the key used to compute an ICV is manually distributed, correct provision of the anti-replay service would require correct maintenance of the counter state at the sender, until the key is replaced, and there likely would be no automated recovery provision if counter overflow were imminent. Thus, a compliant implementation SHOULD NOT provide this service in conjunction with SAs that are manually keyed. 🔑
The mandatory-to-implement algorithms for use with AH are described in a separate RFC [Eas04], to facilitate updating the algorithm requirements independently from the protocol per se. Additional algorithms, beyond those mandated for AH, MAY be supported. 🧪
6. Security Considerations 🚨
Security is CENTRAL to the design of this protocol 🥁, and these security considerations permeate the specification. Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. 🛡️🔥
7. Differences from RFC 2402 🔀
This document differs from RFC 2402 [RFC2402] in the following ways. 👯
- SPI -- modified to specify a uniform algorithm for SAD lookup for unicast and multicast SAs, covering a wider range of multicast technologies. For unicast, the SPI may be used alone to select an SA, or may be combined with the protocol, at the option of the receiver. For multicast SAs, the SPI is combined with the destination address, and optionally the source address, to select an SA. 🎯
- Extended Sequence Number -- added a new option for a 64-bit sequence number for very high-speed communications. Clarified sender and receiver processing requirements for multicast SAs and multi-sender SAs. 🚄
- Moved references to mandatory algorithms to a separate document [Eas04]. 📦
8. Acknowledgements 💌
The author would like to acknowledge the contributions of Ran Atkinson, who played a critical role in initial IPsec activities, and who authored the first series of IPsec standards: RFCs 1825-1827. 👑 Karen Seo deserves special thanks for providing help in the editing of this and the previous version of this specification. The author also would like to thank the members of the IPsec and MSEC working groups who have contributed to the development of this protocol specification. 🌸
9. References 📚
9.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.
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
9.2. Informative References 📚✨
These are the "good to know" sources, bestie, and they're all cited by name. Here's the full list 💅
- [AES] Advanced Encryption Standard (AES), Federal Information Processing Standard 197, National Institutes of Standards and Technology, November 26, 2001.
- [HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress, November 3, 2002.
- [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [NBBB98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [RFB01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
- [RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP MTU discovery options", RFC 1063, July 1988.
- [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
- [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
- [RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
- [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
- [RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
- [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
- [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [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.
Appendix A: Mutability of IP Options/Extension Headers 🦋
A1. IPv4 Options
okay so this table sorts the IPv4 options by "mutability" (how much they're allowed to change in transit) 🫶 If two references are listed, the second one supercedes the first. It's partly based on RFC 1700, "ASSIGNED NUMBERS", (October 1994).
Opt.
Copy Class # Name Reference
---- ----- --- ------------------------- --------
IMMUTABLE -- included in ICV calculation
0 0 0 End of Options List [RFC791]
0 0 1 No Operation [RFC791]
1 0 2 Security [RFC1108] (historic but
in use)
1 0 5 Extended Security [RFC1108] (historic but
in use)
1 0 6 Commercial Security
1 0 20 Router Alert [RFC2113]
1 0 21 Sender Directed Multi- [RFC1770]
Destination Delivery
MUTABLE -- zeroed
1 0 3 Loose Source Route [RFC791]
0 2 4 Time Stamp [RFC791]
0 0 7 Record Route [RFC791]
1 0 9 Strict Source Route [RFC791]
0 2 18 Traceroute [RFC1393]
EXPERIMENTAL, SUPERCEDED -- zeroed
1 0 8 Stream ID [RFC791, RFC1122 (Host
Req)]
0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)]
0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)]
1 0 17 Extended Internet Protocol [RFC1385, DH98 (IPv6)]
0 0 10 Experimental Measurement
1 2 13 Experimental Flow Control
1 0 14 Experimental Access Ctl
0 0 15 ???
1 0 16 IMI Traffic Descriptor
1 0 19 Address ExtensionNOTE: Use of the Router Alert option is potentially incompatible with use of IPsec. Although the option is immutable, its use implies that each router along a packet's path will "process" the packet and consequently might change the packet. This would happen on a hop-by-hop basis as the packet goes from router to router. Prior to being processed by the application to which the option contents are directed (e.g., Resource Reservation Protocol (RSVP)/Internet Group Management Protocol (IGMP)), the packet should encounter AH processing. However, AH processing would require that each router along the path is a member of a multicast-SA defined by the SPI. This might pose problems for packets that are not strictly source routed, and it requires multicast support techniques not currently available.
NOTE: Addition or removal of security labels (e.g., Basic Security Option (BSO), Extended Security Option (ESO), or Commercial Internet Protocol Security Option (CIPSO)) by systems along a packet's path conflicts with the classification of these IP options as immutable and is incompatible with the use of IPsec.
NOTE: End of Options List options SHOULD be repeated as necessary to ensure that the IP header ends on a 4-byte boundary in order to ensure that there are no unspecified bytes that could be used for a covert channel. 🙈
A2. IPv6 Extension Headers
this table does the same thing for IPv6 extension headers 💖
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [DH98]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
TRANSIT)
Hop-by-Hop options [DH98]
Destination options [DH98]
NOT APPLICABLE
Fragmentation [DH98]Options! The Hop-by-Hop and Destination Extension Headers have a bit that says whether the option might change (unpredictably) during transit 🦋 For any option whose contents may change en route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV. The Option Type and Opt Data Len are included in the ICV calculation. All options whose bit marks them as immutable are included in the ICV calculation. See the IPv6 specification [DH98] for more information.
Routing (Type 0) is giving "predictable but moving" 🧚 The IPv6 Routing Header "Type 0" rearranges the address fields within the packet during transit from source to destination. However, the contents of the packet as it will appear at the receiver are known to the sender and to all intermediate hops. So the IPv6 Routing Header "Type 0" is included in the Integrity Check Value calculation as mutable but predictable. The sender must order the field so that it appears as it will at the receiver, prior to performing the ICV computation.
Fragmentation is a whole different vibe 🌸 Fragmentation happens after outbound IPsec processing (Section 3.3), and reassembly happens before inbound IPsec processing (Section 3.4). So the Fragmentation Extension Header, if it exists, is never seen by IPsec.
Note that on the receive side, the IP implementation could leave a Fragmentation Extension Header in place when it does re-assembly. If this happens, then when AH receives the packet, before doing ICV processing, AH MUST "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. 🫶
Note that on the send side, the IP implementation could give the IPsec code a packet with a Fragmentation Extension Header with Offset of 0 (first fragment) and a More Fragments Flag of 0 (last fragment). If this happens, then before doing ICV processing, AH MUST first "remove" (or skip over) this header and change the previous header's "Next Header" field to be the "Next Header" field in the Fragmentation Extension Header. 💅
Appendix B: Extended (64-bit) Sequence Numbers 🌈
B1. Overview
This appendix is about the Extended Sequence Number (ESN) scheme for IPsec (ESP and AH) 🎀 It uses a 64-bit sequence number, but only the low-order 32 bits actually get sent in each packet. It covers both the window scheme used to detect replayed packets and how the high-order bits of the sequence number get figured out, since those are used for both replay rejection and the ICV computation. It also talks about a mechanism for handling loss of synchronization relative to those high-order bits, which never get transmitted in the first place. ✨
B2. Anti-Replay Window 🦋
okay so the receiver keeps an anti-replay window of size W. 🪟 This window limits how far out of order a packet is allowed to be, measured against the packet with the highest sequence number that has been authenticated so far. No minimum or recommended sizes are set for it beyond the 32- and 64-packet values already defined for 32-bit sequence number windows. 🌸 Still, it's suggested that an implementer scale these values to match the interface speed of an implementation that uses the ESN option, and the algorithm below assumes the window is no wider than 2^31 packets. 💅
All 2^32 sequence numbers that share one fixed value for the high-order 32 bits (Seqh) are called a sequence number subspace. ✨ The table below lists the variables and what they mean.
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 you're doing the anti-replay check, or working out which high-order bits to use to authenticate an incoming packet, there are two cases to think about. 🧠
- Case A:
Tl >= (W - 1). The window sits inside one sequence number subspace. (See Figure 1) - Case B:
Tl < (W - 1). 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 where each subspace begins. The two shorter lines above it show the high-order bits that apply. The ==== is the window, and the **** is the future sequence numbers, meaning anything beyond the current highest authenticated sequence number (Th``Tl). 🔥
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 BB2.1. Managing and Using the Anti-Replay Window 🎀
Think of the anti-replay window as a string of bits, where W is the length of that string. W = T - B + 1, and W cannot exceed 2^32 - 1 in value. 💜 The bottom-most bit maps to B, the top-most bit maps to T, and every sequence number from Bl through Tl gets its own bit. That bit tells you whether a packet with that sequence number has been received and authenticated, which is how replays get spotted and rejected. 🙈
When a packet with a 64-bit sequence number (Seq) greater than T shows up and passes validation, the window does the following:
Bis increased by (Seq - T).- (
Seq - T) bits are dropped from the low end of the window. - (
Seq - T) bits are added to the high end of the window. - The top bit is set to show that a packet with that sequence number has been received and authenticated.
- The new bits between
Tand the top bit are set to show that no packets with those sequence numbers have been received yet. Tis set to the new sequence number.
When checking for replayed packets:
- Under Case A: If
Seql >= Bl(whereBl = Tl - W + 1) ANDSeql <= Tl, check the matching bit in the window to see if thisSeqlhas already been seen. If it has, reject the packet. If it hasn't, do the integrity check (see Appendix B2.2 below for howSeqhis determined). - Under Case B: If
Seql >= Bl(whereBl = Tl - W + 1) ORSeql <= Tl, check the matching bit in the window to see if thisSeqlhas already been seen. If it has, reject the packet. If it hasn't, do the integrity check (see Appendix B2.2 below for howSeqhis determined).
B2.2. Determining the Higher-Order Bits (Seqh) of the Sequence Number 🌈
Only Seql gets transmitted with the packet, so the receiver must work out and track which sequence number subspace each packet falls into, meaning it has to determine the value of Seqh. The equations below show how to pick Seqh under "normal" conditions. For recovering from extreme packet loss, see Appendix B3. 🧚
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 = ThB2.3. Pseudo-Code Example 🍓
This pseudo-code walks through the algorithms above for the anti-replay and integrity checks. Seql, Tl, Th, and W are 32-bit unsigned integers, and arithmetic 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 packetB3. Handling Loss of Synchronization due to Significant Packet Loss 🚨
Here's the drama 😭. If there's an undetected loss of 2^32 or more consecutive packets on a single SA, the transmitter and receiver lose synchronization of the high-order bits. That means the equations in Appendix B2.2. stop giving the right value. Unless someone detects and fixes this, every packet after it on that SA fails authentication and gets discarded. The following procedure SHOULD be implemented by any IPsec (ESP or AH) implementation that supports the ESN option. 💀
Honestly, this kind of extended traffic loss seems unlikely if a big chunk of the traffic on the SA is TCP, since the source would stop getting ACKs and quit sending long before 2^32 packets were lost. For any bi-directional application, even ones running above UDP, an outage that long would probably trigger some kind of timeout. ⏳ But a unidirectional application running over UDP might not have any feedback that would reveal a loss this big, and that's the reason we need a recovery method for this case. 🌸
The solution was picked to:
- minimize the impact on normal traffic processing.
- avoid opening a new denial of service attack, such as one where an attacker forces resources to be diverted to a re-synchronization process.
- limit the recovery mechanism to the receiver, because anti-replay is a service only for the receiver, and the transmitter generally isn't aware of whether the receiver is using sequence numbers for this optional service. Recovery mechanisms should be local to the receiver when possible. This also keeps things backward compatible. 🫶
B3.1. Triggering Re-synchronization 🔁
For each SA, the receiver counts the number of consecutive packets that fail authentication. This count is what triggers the re-synchronization process, which should run in the background or on a separate processor. Receiving a valid packet on the SA resets the counter to zero. The trigger value is a local parameter. There's no requirement to support distinct trigger values for different SAs, though an implementer may choose to do so. ✨
B3.2. Re-synchronization Process 💫
Once the trigger point is reached, a "bad" packet gets picked, and authentication is retried with successively larger values for the upper half of the sequence number (Seqh). Each retry increments that value by one. The number of retries should be limited, in case the packet is from the "past" or is just a bogus packet. The limit is a local parameter. (Because the Seqh value is implicitly placed after the AH (or ESP) 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 authentication succeeds via this procedure, the consecutive failure count resets and T is set to the value from the received packet. 🎀
This solution only needs support on the receiver's side, so it stays backward compatible. And since re-synchronization happens either in the background or on an extra processor, it doesn't affect 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 in BCP 78. Apart from what BCP 78 sets out, the authors keep all their rights. 🔒
This document and the information in it are provided "AS IS", 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. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranty 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 over the technology in this document, are valid or in scope. It also doesn't say whether any license under those rights is or isn't available, and it hasn't independently tried to find out whether such rights exist. 🧐 You can find out how rights work for RFC documents in BCP 78 and BCP 79. 📚
Copies of IPR disclosures sent to the IETF Secretariat, and any assurances that licenses will be made available, are in the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for the results of any attempt to get a general license or permission to use proprietary rights, made for implementers or users of this specification. 💼
The IETF invites anyone who's interested to flag 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: rfc4302 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms