RFC 2402
IP Authentication Header
RFC 2402: IP Authentication Header 🎀
okay bestie, this is RFC 2402, and it's giving the spec for the IP Authentication Header (AH) 💅 It's from November 1998, written by S. Kent (BBN Corp) and R. Atkinson (@Home Network) as part of the Network Working Group. It's a Standards Track doc, so this is an actual Internet standards protocol, not just a vibe 🫶 It obsoletes RFC 1826 (the older AH spec), and it doesn't update any other RFCs. Section 7 has the full list of differences from RFC 1826 ✨
Status of This Memo ✨
this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. distribution of this memo is unlimited 🦋
Copyright Notice 💜
Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒
Table of Contents 🧚
1. Introduction......................................................2
2. Authentication Header Format......................................3
2.1 Next Header...................................................4
2.2 Payload Length................................................4
2.3 Reserved......................................................4
2.4 Security Parameters Index (SPI)...............................4
2.5 Sequence Number...............................................5
2.6 Authentication Data ..........................................5
3. Authentication Header Processing..................................5
3.1 Authentication Header Location...............................5
3.2 Authentication Algorithms....................................7
3.3 Outbound Packet Processing...................................8
3.3.1 Security Association Lookup.............................8
3.3.2 Sequence Number Generation..............................8
3.3.3 Integrity Check Value Calculation.......................9
3.3.3.1 Handling Mutable Fields............................9
3.3.3.1.1 ICV Computation for IPv4.....................10
3.3.3.1.1.1 Base Header Fields.......................10
3.3.3.1.1.2 Options..................................11
3.3.3.1.2 ICV Computation for IPv6.....................11
3.3.3.1.2.1 Base Header Fields.......................11
3.3.3.1.2.2 Extension Headers Containing Options.....11
3.3.3.1.2.3 Extension Headers Not Containing Options.11
3.3.3.2 Padding...........................................12
3.3.3.2.1 Authentication Data Padding..................12
3.3.3.2.2 Implicit Packet Padding......................12
3.3.4 Fragmentation..........................................12
3.4 Inbound Packet Processing...................................13
3.4.1 Reassembly.............................................13
3.4.2 Security Association Lookup............................13
3.4.3 Sequence Number Verification...........................13
3.4.4 Integrity Check Value Verification.....................15
4. Auditing.........................................................15
5. Conformance Requirements.........................................16
6. Security Considerations..........................................16
7. Differences from RFC 1826........................................16
Acknowledgements....................................................17
Appendix A -- Mutability of IP Options/Extension Headers............18
A1. IPv4 Options.................................................18
A2. IPv6 Extension Headers.......................................19
References..........................................................20
Disclaimer..........................................................21
Author Information..................................................22
Full Copyright Statement............................................221. Introduction ✨
okay so the IP Authentication Header (AH) is used to give you connectionless integrity and data origin authentication for IP datagrams (we'll just call it "authentication" from here) 🔐 it also protects against replays 🙅♀️ the receiver gets to pick this replay protection, which is optional, when a Security Association is set up. (even though the default has the sender bump the Sequence Number used for anti-replay, it only actually works if the receiver checks that Sequence Number 👀)
AH covers as much of the IP header as it can, plus the upper level protocol data 💖 but some IP header fields can change in transit, and the sender can't predict what they'll look like when the packet reaches the receiver 😭 so AH can't protect those values, and the protection it gives the IP header is kinda piecemeal, ngl 🧩
AH can be used alone, together with the IP Encapsulating Security Payload (ESP) [KA97b], or nested using tunnel mode (see "Security Architecture for the Internet Protocol" [KA97a], which we'll call the Security Architecture document) 🌈 security services can run between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host ✨ ESP can give the same security services, and it also gives a confidentiality (encryption) service 🫢 the main difference between ESP's authentication and AH's is how much gets covered. ESP doesn't protect any IP header fields unless ESP encapsulates them (tunnel mode) 💅 for more on how to use AH and ESP in different network environments, check the Security Architecture document [KA97a] 📚
this doc assumes you already know the terms and concepts from the Security Architecture document 🤓 in particular, you should know what security services AH and ESP offer, what Security Associations are, how AH can work alongside ESP, and the different key management options for AH and ESP. (on that last one, 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. Authentication Header Format ✨
the protocol header (IPv4, IPv6, or Extension) right before the AH header will have the value 51 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Authentication Data (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the next subsections define the fields that make up the AH format 🧩 every field described here is mandatory, meaning they're always there in the AH format and they're included in the Integrity Check Value (ICV) computation (see Sections 2.6 and 3.3.3) 💜
2.1. Next Header 🌸
Next Header is an 8-bit field that tells you what type the next payload after the Authentication Header is 📦 its value comes from the set of IP Protocol Numbers defined in the most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned Numbers Authority (IANA) 🍓
2.2. Payload Length 🌷
this 8-bit field gives the length of AH in 32-bit words (4-byte units), minus "2" 🧮 (all IPv6 extension headers, per RFC 1883, encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header length, measured in 64-bit words. AH is an IPv6 extension header, but since its length is measured in 32-bit words, the "Payload Length" gets calculated by subtracting 2 (32-bit words).) 🤯 in the "standard" case of a 96-bit authentication value plus the 3 32-bit word fixed portion, this length field will be "4" ✨ a "null" authentication algorithm may be used only for debugging purposes 🐛 using it would give this field a "1" for IPv4 or a "2" for IPv6, since there wouldn't be a matching Authentication Data field (see Section 3.3.3.2.1 on "Authentication Data Padding") 🙈
2.3. Reserved 🫧
this 16-bit field is reserved for future use 🔮 it MUST be set to "zero." (heads up that the value is included in the Authentication Data calculation, but the recipient otherwise ignores it) 🫶
2.4. Security Parameters Index (SPI) 🗝️
the SPI is an arbitrary 32-bit value that, together with the destination IP address and the security protocol (AH), uniquely identifies the Security Association for this datagram 🪪 the SPI values from 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use 🚫 a reserved SPI value won't normally be assigned by IANA unless the use of that assigned SPI value is specified in an RFC 📜 it's usually picked by the destination system when an SA gets set up (see the Security Architecture document for more details) 💖
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 MAY use the zero SPI value to mean "No Security Association Exists" while the IPsec implementation has asked its key management entity to set up a new SA, but that SA hasn't been established yet 🧚
2.5. Sequence Number 🔢
this unsigned 32-bit field holds a monotonically increasing counter value (the sequence number) 📈 it's mandatory and always present, even when the receiver doesn't turn on the anti-replay service for a specific SA 🙃 how the Sequence Number field gets processed is up to the receiver, which means the sender MUST always transmit this field, but the receiver doesn't have to act on it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section below) 🦋
the sender's counter and the receiver's counter both start at 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 gets generated.) if anti-replay is enabled (which is 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 therefore a new key) before the 2^32nd packet gets transmitted on an SA 🔑✨
2.6. Authentication Data
okay so this is the variable-length field that holds the Integrity Check Value (ICV) for the packet 🔐 It has to be an integral multiple of 32 bits in length, and the nitty gritty of how the ICV gets computed is in Section 3.3.2 below ✨ This field may include explicit padding 🎀 The padding is there so the length of the AH header ends up as an integral multiple of 32 bits (IPv4) or 64 bits (IPv6) 💜 All implementations MUST support such padding 🫶 Details on how to work out the padding length are coming up below 🦋 And the authentication algorithm specification MUST specify the length of the ICV, plus the comparison rules and processing steps for validation. no notes, that's just how it has to be 💅
3. Authentication Header Processing ✨
3.1. Authentication Header Location
Like ESP, AH can be used in two ways: transport mode or tunnel mode 🦋 Transport mode is only for host implementations, and it protects upper layer protocols plus a selected set of IP header fields 🌸 (Side note, bestie: 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 an IPsec implementation to do extra IP reassembly/fragmentation so it both conforms to this spec and gives transparent IPsec support 🧩 Being careful here is key when multiple interfaces are in use 👀)
In transport mode, AH goes after the IP header and before an upper layer protocol, like TCP, UDP, ICMP, etc., or before any other IPsec headers that have already been added 💖 For IPv4 that means AH sits after the IP header (and any options in it) but before the upper layer protocol. (And "transport" mode doesn't mean it's only for TCP and UDP, okay?? For example, an ICMP message MAY be sent using either "transport" mode or "tunnel" mode 🙈) Here's what AH transport mode looks like on a typical IPv4 packet, before and after 👇
BEFORE APPLYING AH
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING AH
---------------------------------
IPv4 |orig IP hdr | | | |
|(any options)| AH | TCP | Data |
---------------------------------
|<------- authenticated ------->|
except for mutable fieldsIn IPv6, AH 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 come before or after the AH header, depending on the semantics you want ✨ Here's a typical IPv6 packet in AH transport mode:
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 |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
* = if present, could be before AH, after AH, or bothESP and AH headers can be combined in a bunch of different modes 🌈 The IPsec Architecture document describes which combinations of security associations must be supported 📜
Tunnel mode AH can be used in hosts or security gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire" implementations, as defined in the Security Architecture document) 🏰 When AH is running in a security gateway to protect 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 ones for security gateways 🎀 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's how it looks for typical IPv4 and IPv6 packets:
------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | |
|(any options)| AH | (any options) |TCP | Data |
------------------------------------------------
|<- 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|
--------------------------------------------------------------
|<-- authenticated except for mutable fields in new IP hdr ->|
* = construction of outer IP hdr/extensions and modification
of inner IP hdr/extensions is discussed below.3.2. Authentication Algorithms
The SA is what decides which authentication algorithm gets used for the ICV computation 🔑 For point-to-point communication, good options include keyed Message Authentication Codes (MACs) built on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1) 🍓 For multicast communication, one-way hash algorithms paired with asymmetric signature algorithms are appropriate, but performance and space considerations currently rule those out 😭 The mandatory-to-implement authentication algorithms are described in Section 5 "Conformance Requirements" 📋 Other algorithms MAY be supported too 🌸
3.3. Outbound Packet Processing
In transport mode, the sender pops the AH header in after the IP header and before an upper layer protocol header, just like we covered above 💖 In tunnel mode, the outer and inner IP header/extensions can be related to each other in a bunch of ways 🌀 How the outer IP header/extensions get built during encapsulation is described in the Security Architecture document 📖
If more than one IPsec header/extension is needed, the order the security headers get applied in MUST be defined by security policy 🔐 For simplicity of processing, each IPsec header SHOULD ignore the existence of IPsec headers that are going to be applied later (so, not zeroing their contents or trying to guess what they'll look like) 🧠 (A native IP or bump-in-the-stack implementation could predict the contents of later IPsec headers it applies itself, but it won't be able to predict any IPsec headers added by a bump-in-the-wire implementation between the host and the network 🙃)
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 outbound traffic gets sorted into what IPsec processing (if any) it needs is described in the Security Architecture document 📚
3.3.2. Sequence Number Generation
The sender's counter starts at 0 when an SA gets set up ⭐ The sender bumps the Sequence Number for that 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 🛡️ 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 🚨 (Also, this way of managing the Sequence Number doesn't need modular arithmetic, which is kinda neat 🤓)
The sender assumes anti-replay is turned on 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 watch or reset the counter, like in the case of manual key management (see Section 5.) 💤 Even so, the sender still increments the counter, and when it hits the max value it rolls over back to zero 🎡
3.3.3. Integrity Check Value Calculation
The AH ICV is computed over three things 🧮
- the IP header fields that are either immutable in transit or whose values can be predicted when they arrive at the endpoint for the AH SA
- the AH header (Next Header, Payload Len, Reserved, SPI, Sequence Number, and the Authentication Data, which gets set to zero for this computation, plus any explicit padding bytes, if there are any)
- the upper level protocol data, which is assumed to be immutable in transit 🔒
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 🧊 If a field is mutable but its value at the (IPsec) receiver is predictable, then that predicted value gets put into the field for the ICV calculation 🔮 The Authentication Data field also gets set to zero to get ready for this computation 🫧 Replacing each field's value with zero (instead of just leaving the field out) keeps alignment intact for the ICV calculation 📐 And the zero-fill approach makes sure the length of these handled fields can't change in transit, even though their contents aren't explicitly covered by the ICV 🦋
When a new extension header or IPv4 option gets created, it'll be defined in its own RFC, and it 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 will never see 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) carry a flag for mutability, and that flag decides how those options 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 🔒
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) 🫠
Type of Service (TOS)FlagsFragment OffsetTime to Live (TTL)Header Checksum
Now the tea on why the mutable ones get zeroed ☕
- TOS 🙃 gets excluded because some routers are known to change this field, even though the IP spec doesn't consider TOS to be a mutable header field.
- Flags 🚩 gets excluded since an intermediate router might set the DF bit, even if the source did not select it.
- Fragment Offset 🧩 gets excluded because AH is only applied to non-fragmented IP packets, so the Offset Field must always be zero. It's excluded even though it's predictable, which is kinda iconic lol.
- TTL ⏳ is changed en-route as a normal part of router processing, so its value at the receiver isn't predictable by the sender.
- Header Checksum 🧮 will change if any of those other fields change, so the sender can't predict its value when it arrives.
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 gets zeroed for ICV computation purposes. Main character energy 👑
3.3.3.1.2 ICV Computation for IPv6 🌈
3.3.3.1.2.1 Base Header Fields ✨
The IPv6 base header fields get sorted like this, periodt 💖
Immutable 🔒
VersionPayload LengthNext Header(This should be the value for AH.)Source AddressDestination Address(without Routing Extension Header)
Mutable but predictable 🔮
Destination Address(with Routing Extension Header)
Mutable (zeroed prior to ICV calculation) 🫠
ClassFlow LabelHop Limit
3.3.3.1.2.2 Extension Headers Containing Options 🧸
okay so IPv6 options in 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 has to 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 says immutable are included in the ICV calculation too. For more info, check the IPv6 specification [DH95] 📚🫶
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. Easy peasy 🍓
3.3.3.2 Padding 🎀
3.3.3.2.1 Authentication Data Padding 🫧
As mentioned in section 2.6, the Authentication Data field explicitly includes padding so 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 either IPv4 or IPv6, literally so simple 🙌 But 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 it doesn't need to be random to achieve security 🔐) These padding bytes are included in the Authentication Data calculation, counted as part of the Payload Length, and transmitted at the end of the Authentication Data field so the receiver can perform the ICV calculation ✨
3.3.3.2.2 Implicit Packet Padding 🌸
For some authentication algorithms, the byte string the ICV computation runs over must be a multiple of a blocksize the algorithm specifies. If the IP packet length (including AH) 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 so the length of the padding) comes from the algorithm specification. This padding is not transmitted with the packet 🫣 Also, MD5 and SHA-1 are viewed as having a 1-byte blocksize because of their internal padding conventions, which is a whole mood 🧠
3.3.4 Fragmentation 🧩
If required, IP fragmentation happens after AH processing within an IPsec implementation. So transport mode AH is only applied to whole IP datagrams (not to IP fragments) 🙅♀️ An IP packet with AH applied can itself get fragmented by routers en route, and those fragments must be reassembled prior to AH processing at a receiver. 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 🚀
3.4 Inbound Packet Processing 📥
If there is more than one IPsec header or extension present, the processing for each one ignores (does not zero, does not use) any IPsec headers applied after the header being processed. Boundaries, bestie 🫶
3.4.1 Reassembly 🧵
If required, reassembly happens before AH processing. If a packet offered to AH 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. 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 theOFFSETfield or the clearing of theMORE FRAGMENTSflag. For a reassembled packet to get processed by IPsec (instead of being discarded as an apparent fragment), the IP code must do these two things after it reassembles a packet. 🙃
3.4.2 Security Association Lookup 🔎
When a packet containing an IP Authentication Header shows up, the receiver figures out the right (unidirectional) SA based on the destination IP address, security protocol (AH), and the SPI 💌 (The Security Architecture document goes deeper on this process.) The SA tells the receiver whether the Sequence Number field will be checked, which algorithm(s) get used for ICV computation, and which key(s) are needed to validate the ICV.
If no valid Security Association exists for this session (for example, the receiver has no key), 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.
3.4.3 Sequence Number Verification 🔢
All AH implementations MUST support the anti-replay service, though the receiver can turn its use on or off on a per-SA basis 🛡️ (Note that there are no provisions for managing transmitted Sequence Number values among multiple senders directing traffic to a single SA, whether the destination address is unicast, broadcast, or multicast. So the anti-replay service SHOULD NOT be used in a multi-sender environment that uses a single SA. Big warning 🚨) If the receiver doesn't enable anti-replay for an SA, no inbound checks get performed on the Sequence Number. From the sender's perspective, though, the default is to assume anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.2), if an SA establishment protocol such as IKE is 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 receiver 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 packet received during the life of this SA. This SHOULD be the first AH check applied to a packet after it's matched to an SA, which speeds up rejecting duplicates 🏃♀️💨
Duplicates get rejected through a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality the implementation must exhibit 🪟) A minimum window size of 32 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 "right" edge of the window represents the highest validated Sequence Number value received on this SA. Packets with Sequence Numbers lower than the "left" edge of the window get rejected. Packets falling within the window get checked against a list of received packets within the window. An efficient way to do this check, based on a bit mask, is described in the Security Architecture document 🧮
If the received packet falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to ICV verification. If 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 is updated only if the ICV verification succeeds ✅
DISCUSSION:
Note that if the packet is either inside the window and new, or is outside the window on the "right" side, the receiver MUST authenticate the packet before updating the Sequence Number window data. 🔐💜
3.4.4. Integrity Check Value Verification ✨
okay so the receiver recomputes the ICV over the right fields of the packet, using the agreed authentication algorithm, and checks that it matches the ICV sitting in the Authentication Data field 🧐 Full details are below 👇
If the computed and received ICVs match, the datagram is valid and it 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 💅
DISCUSSION: 🧠 Start by saving the ICV value and replacing it (but not any Authentication Data padding) with zero. Zero all other fields that may have been modified during transit. (See section 3.3.3.1 for a discussion of which fields are zeroed before performing the ICV calculation.) Check the overall length of the packet, and if it requires implicit padding based on the requirements of the authentication algorithm, append zero-filled bytes to the end of the packet 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. Totally fine 🙂 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. Nobody is getting a reply just because they tripped an alarm 🙅♀️🚨
5. Conformance Requirements ✅
Implementations that claim conformance or compliance with this specification MUST fully implement the AH 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, 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. Real talk, that's a lot to keep track of 😭 A compliant AH implementation MUST support the following mandatory-to-implement algorithms:
- HMAC with MD5 [MG97a]
- HMAC with SHA-1 [MG97b]
6. Security Considerations 🔐
Security is central to the design of this protocol, and these security considerations permeate the specification. Like, it's literally everywhere 💜 Additional security-relevant aspects of using the IPsec protocol are discussed in the Security Architecture document. Go read that one too, bestie 📚🔥
7. Differences from RFC 1826 🆚
This specification of AH differs from RFC 1826 [ATK95] in several important respects, but the fundamental features of AH remain intact. One goal of the revision of RFC 1826 was to provide a complete framework for AH, with ancillary RFCs required only for algorithm specification. For example, the anti-replay service is now an integral, mandatory part of AH, not a feature of a transform defined in another RFC. Carriage of a sequence number to support this service is now required at all times. The default algorithms required for interoperability have been changed to HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons. The list of IPv4 header fields excluded from the ICV computation has been expanded to include the OFFSET and FLAGS fields. Glow-up era 🌸
Another motivation for revision was to provide additional detail and clarification of subtle points. This specification provides rationale for exclusion of selected IPv4 header fields from AH coverage and provides examples on positioning of AH in both the IPv4 and v6 contexts. Auditing requirements have been clarified in this version of the specification. Tunnel mode AH was mentioned only in passing in RFC 1826, but now is a mandatory feature of AH. Discussion of interactions with key management and with security labels has been moved to the Security Architecture document. Everything got a proper upgrade ✨🎀
Acknowledgements 🫶
For over 3 years, this document has evolved through multiple versions and iterations. During this time, many people have contributed significant ideas and energy to the process and the documents themselves. The authors would like to thank Karen Seo for providing extensive help in the review, editing, background research, and coordination for this version of the specification. The authors would also like to thank the members of the IPsec and IPng working groups, with special mention of the efforts of (in alphabetic order): Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William Simpson, and Nina Yuan. The squad goals are unmatched 👑💖
Appendix A -- Mutability of IP Options/Extension Headers 🦋
A1. IPv4 Options 🧩
This table shows how the IPv4 options are classified with regard to "mutability". Where two references are provided, the second one supercedes the first. This table is based in part on information provided in RFC1700, "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 [expired I-D, now US MIL STD]
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 Proto [RFC1385, RFC1883 (IPv6)]
0 0 10 Experimental Measurement [ZSu]
1 2 13 Experimental Flow Control [Finn]
1 0 14 Experimental Access Ctl [Estrin]
0 0 15 ??? [VerSteeg]
1 0 16 IMI Traffic Descriptor [Lee]
1 0 19 Address Extension [Ullmann IPv7]NOTE: 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., RSVP/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. Multicast chaos, no thank you 😵💫
NOTE: Addition or removal of any security labels (BSO, ESO, 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 which could be used for a covert channel. Sneaky bytes are not invited to this party 🕵️♀️
A2. IPv6 Extension Headers 🌈
This table shows how the IPv6 Extension Headers are classified with regard to "mutability".
Option/Extension Name Reference
----------------------------------- ---------
MUTABLE BUT PREDICTABLE -- included in ICV calculation
Routing (Type 0) [RFC1883]
BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT)
Hop by Hop options [RFC1883]
Destination options [RFC1883]The table picks up with the Fragmentation row 🧚
NOT APPLICABLE
Fragmentation [RFC1883]- Options 🎀: IPv6 options in 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. Every option where the bit says it's immutable is included in the ICV calculation. For more info, check the IPv6 specification [DH95] 💖
- Routing (Type 0) 🦋: The IPv6 Routing Header "Type 0" rearranges the address fields inside the packet on its way from source to destination. But the packet as the receiver will see it is known to the sender and to every intermediate hop, so the IPv6 Routing Header "Type 0" is included in the Authentication Data calculation as mutable but predictable. The sender must put the field in the order it will have at the receiver before doing the ICV computation. Main character energy 👑
- Fragmentation 🌸: 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 one exists, never gets 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 that 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 hand 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 that 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 💅
References 📚
- [ATK95] Atkinson, R., "The IP Authentication Header", RFC 1826, August 1995.
- [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
- [DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 (IPv6) Specification", RFC 1883, December 1995.
- [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [KA97a] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [KA97b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, 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
Disclaimer 🫧
The views and specification here are those of the authors and are not necessarily those of their employers. The authors and their employers specifically disclaim responsibility for any problems arising from correct or incorrect implementation or use of this specification.
Author Information 🦋
Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140
USA
Phone: +1 (617) 873-3988
EMail: kent@bbn.comRandall Atkinson
@Home Network
425 Broadway,
Redwood City, CA 94063
USA
Phone: +1 (415) 569-5000
EMail: rja@corp.home.netCopyright (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: rfc2402 1998-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms