idnits 2.17.1 draft-ietf-ipsec-rfc2402bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1509. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 57 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC2402, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 174 has weird spacing: '... Integ is...' == Line 186 has weird spacing: '...ariable if ne...' == Line 824 has weird spacing: '... packet the r...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2005) is 6951 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ken-Arch' is mentioned on line 962, but not defined -- Looks like a reference, but probably isn't: '1' on line 188 -- Looks like a reference, but probably isn't: '2' on line 190 -- Looks like a reference, but probably isn't: '3' on line 192 -- Looks like a reference, but probably isn't: '4' on line 194 == Missing Reference: 'ESP' is mentioned on line 210, but not defined == Missing Reference: 'AES' is mentioned on line 499, but not defined == Missing Reference: 'RFC791' is mentioned on line 1100, but not defined == Missing Reference: 'RFC2113' is mentioned on line 1093, but not defined == Missing Reference: 'RFC1770' is mentioned on line 1094, but not defined ** Obsolete undefined reference: RFC 1770 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1393' is mentioned on line 1101, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'ZSu' is mentioned on line 1109, but not defined == Missing Reference: 'Finn' is mentioned on line 1110, but not defined == Missing Reference: 'Estrin' is mentioned on line 1111, but not defined == Missing Reference: 'VerSteeg' is mentioned on line 1112, but not defined == Missing Reference: 'Lee' is mentioned on line 1113, but not defined == Unused Reference: 'Pos81' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 1039, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'DH98') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'Eas04' == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-01 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 17 errors (**), 0 flaws (~~), 22 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPsec Working Group S. Kent 2 Internet-Draft BBN Technologies 3 draft-ietf-ipsec-rfc2402bis-08.txt October 2004 4 Obsoletes: RFC 2402 5 Expires April 2005 7 IP Authentication Header 8 draft-ietf-ipsec-rfc2402bis-08.txt 10 Status of This Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 10 of RFC2026. Internet-Drafts are working documents of 19 the Internet Engineering Task Force (IETF), its areas, and its 20 working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. Internet-Drafts are draft documents 22 valid for a maximum of 6 months and may be updated, replaced, or 23 obsoleted by other documents at any time. It is inappropriate to use 24 Internet-Drafts as reference material or to cite them other than as a 25 "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/lid-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright (C) The Internet Society (2004). This document is subject 34 to the rights, licenses and restrictions contained in BCP 78, and 35 except as set forth therein, the authors retain all their rights. 37 Abstract 39 This document describes an updated version of the IP Authentication 40 Header (AH), which is designed to provide authentication services in 41 IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). 43 Table of Contents 44 1. Introduction.......................................................3 45 2. Authentication Header Format.......................................4 46 2.1 Next Header...................................................5 47 2.2 Payload Length................................................5 48 2.3 Reserved......................................................6 49 2.4 Security Parameters Index (SPI)...............................6 50 2.5 Sequence Number...............................................8 51 2.5.1 Extended (64-bit) Sequence Number........................8 52 2.6 Integrity Check Value (ICV) ..................................9 53 3. Authentication Header Processing...................................9 54 3.1 Authentication Header Location...............................9 55 3.1.1 Transport Mode..........................................9 56 3.1.2 Tunnel Mode............................................10 57 3.2 Integrity Algorithms........................................11 58 3.3 Outbound Packet Processing..................................11 59 3.3.1 Security Association Lookup............................11 60 3.3.2 Sequence Number Generation.............................12 61 3.3.3 Integrity Check Value Calculation......................12 62 3.3.3.1 Handling Mutable Fields...........................13 63 3.3.3.1.1 ICV Computation for IPv4.....................13 64 3.3.3.1.1.1 Base Header Fields.......................13 65 3.3.3.1.1.2 Options..................................14 66 3.3.3.1.2 ICV Computation for IPv6.....................14 67 3.3.3.1.2.1 Base Header Fields.......................14 68 3.3.3.1.2.2 Extension Headers Containing Options.....15 69 3.3.3.1.2.3 Extension Headers Not Containing Options.15 70 3.3.3.2 Padding & Extended Sequence Numbers...............15 71 3.3.3.2.1 ICV Padding..................................15 72 3.3.3.2.2 Implicit Packet Padding & ESN................16 73 3.3.4 Fragmentation..........................................16 74 3.4 Inbound Packet Processing...................................17 75 3.4.1 Reassembly.............................................17 76 3.4.2 Security Association Lookup............................18 77 3.4.3 Sequence Number Verification...........................18 78 3.4.4 Integrity Check Value Verification.....................20 79 4. Auditing..........................................................20 80 5. Conformance Requirements..........................................21 81 6. Security Considerations...........................................21 82 7. Differences from RFC 2402.........................................21 83 Acknowledgements.....................................................22 84 References...........................................................22 85 Author Information...................................................22 86 Appendix A -- Mutability of IP Options/Extension Headers.............24 87 A1. IPv4 Options.................................................24 88 A2. IPv6 Extension Headers.......................................25 89 Appendix B -- Extended (64-bit) Sequence Numbers.....................27 90 Notices..............................................................33 92 1. Introduction 94 This document assumes that the reader is familiar with the terms and 95 concepts described in the "Security Architecture for the Internet 96 Protocol" [Ken-Arch], hereafter referred to as the Security 97 Architecture document. In particular, the reader should be familiar 98 with the definitions of security services offered by the 99 Encapsulating Security Payload (ESP) [Ken-ESP]and the IP 100 Authentication Header (AH) [Ken-AH], the concept of Security 101 Associations, the ways in which ESP can be used in conjunction with 102 the Authentication Header (AH), and the different key management 103 options available for ESP and AH. 105 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 106 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 107 document, are to be interpreted as described in RFC 2119 [Bra97]. 109 The IP Authentication Header (AH) is used to provide connectionless 110 integrity and data origin authentication for IP datagrams (hereafter 111 referred to as just "integrity"), and to provide protection against 112 replays. This latter, optional service may be selected, by the 113 receiver, when a Security Association is established. (The protocol 114 default requires the sender to increment the Sequence Number used for 115 anti-replay, but the service is effective only if the receiver checks 116 the Sequence Number.) However, to make use of the extended sequence 117 number feature in an interoperable fashion, AH does impose a 118 requirement on SA management protocols to be able to negotiate this 119 new feature (see Section 2.5.1 below). 121 AH provides authentication for as much of the IP header as possible, 122 as well as for next level protocol data. However, some IP header 123 fields may change in transit and the value of these fields, when the 124 packet arrives at the receiver, may not be predictable by the sender. 125 The values of such fields cannot be protected by AH. Thus the 126 protection provided to the IP header by AH is piecemeal. (See 127 Appendix A.) 129 AH may be applied alone, in combination with the IP Encapsulating 130 Security Payload (ESP) [Ken-ESP], or in a nested fashion (see 131 Security Architecture document [Ken-Arch]). Security services can be 132 provided between a pair of communicating hosts, between a pair of 133 communicating security gateways, or between a security gateway and a 134 host. ESP may be used to provide the same anti-replay and similar 135 integrity services, and it also provides a confidentiality 136 (encryption) service. The primary difference between the integrity 137 provided by ESP and AH is the extent of the coverage. Specifically, 138 ESP does not protect any IP header fields unless those fields are 139 encapsulated by ESP (e.g., via use of tunnel mode). For more details 140 on how to use AH and ESP in various network environments, see the 141 Security Architecture document [Ken-Arch]. 143 Section 7 provides a brief review of the differences between this 144 document and RFC 2402. 146 2. Authentication Header Format 148 The protocol header (IPv4, IPv6, or IPv6 Extension) immediately 149 preceding the AH header SHALL contain the value 51 in its Protocol 150 (IPv4) or Next Header (IPv6, Extension) field [DH98]. Figure 1 151 illustrates the format for AH. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Next Header | Payload Len | RESERVED | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Security Parameters Index (SPI) | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Sequence Number Field | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 + Integrity Check Value-ICV (variable) | 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1. AH Format 169 The following table refers to the fields that comprise AH, 170 (illustrated in Figure 1), plus other fields included in the 171 integrity computation, and illustrates which fields are covered by 172 the ICV and what is transmitted. 173 What What 174 # of Requ'd Integ is 175 bytes [1] Covers Xmtd 176 ------ ------ ------ ------ 177 IP Header variable M [2] plain 178 Next Header 1 M Y plain 179 Payload Len 1 M Y plain 180 RESERVED 2 M Y plain 181 SPI 4 M Y plain 182 Seq# (low order 32-bits) 4 M Y plain 183 ICV variable M Y[3] plain 184 IP datagram [4] variable M Y plain 185 Seq# (high order 32-bits) 4 if ESN Y not xmtd 186 ICV Padding variable if need Y not xmtd 188 [1] - M = mandatory 190 [2] - See section 3.3.3 "Integrity Check Value Calculation" for 191 details of which IP header fields are covered. 192 [3] - Zero'd before ICV calculation (resulting ICV placed here 193 after calculation) 194 [4] - If tunnel mode -> IP datagram 195 If transport mode -> next header and data 197 The following subsections define the fields that comprise the AH 198 format. All the fields described here are mandatory, i.e., they are 199 always present in the AH format and are included in the Integrity 200 Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 202 Note: All of the cryptographic algorithms used in IPsec expect their 203 input in canonical network byte order (see Appendix in RFC 791) and 204 generate their output in canonical network byte order. IP packets 205 are also transmitted in network byte order. 207 AH does not contain a version number, therefore if there are concerns 208 about backward compatibility, they MUST be addressed by using a 209 signaling mechanism between the two IPsec peers to ensure compatible 210 versions of AH [ESP], e.g., IKE or an out-of-band configuration 211 mechanism. 213 2.1 Next Header 215 The Next Header is an 8-bit field that identifies the type of the 216 next payload after the Authentication Header. The value of this 217 field is chosen from the set of IP Protocol Numbers defined on the 218 web page of Internet Assigned Numbers Authority (IANA), e.g., a value 219 of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 220 indicates TCP. 222 2.2 Payload Length 224 This 8-bit field specifies the length of AH in 32-bit words (4-byte 225 units), minus "2". Thus, for example, if an integrity algorithm 226 yields a 96-bit authentication value, this length field will be "4" 227 (3 32-bit word fixed fields plus 3 32-bit words for the ICV, minus 228 2). For IPv6, the total length of the header must be a multiple of 229 8-octet units. (Note that although IPv6 [DH98] characterizes AH as an 230 extension header, its length is measured in 32-bit words, not the 231 64-bit words used by other IPv6 extension headers.) See Section 2.6, 232 "Integrity Check Value (ICV)", for comments on padding of this field, 233 and Section 3.3.3.2.1 "ICV Padding". 235 2.3 Reserved 237 This 16-bit field is reserved for future use. It MUST be set to 238 "zero" by the sender, and it SHOULD be ignored by the recipient. 239 (Note that the value is included in the ICV calculation, but is 240 otherwise ignored by the recipient.) 242 2.4 Security Parameters Index (SPI) 244 The SPI is an arbitrary 32-bit value that is used by a receiver to 245 identify the SA to which an incoming packet is bound. For a unicast 246 SA, the SPI can be used by itself to specify an SA, or it may be used 247 in conjunction with the IPsec protocol type (in this case AH). 248 Since, for unicast SAs, the SPI value is generated by the receiver, 249 whether the value is sufficient to identify an SA by itself, or 250 whether it must be used in conjunction with the IPsec protocol value 251 is a local matter. The SPI field is mandatory and this mechanism for 252 mapping inbound traffic to unicast SAs described above MUST be 253 supported by all AH implementations. 255 If an IPsec implementation supports multicast, then it MUST support 256 multicast SAs using the algorithm below for mapping inbound IPsec 257 datagrams to SAs. Implementations that support only unicast traffic 258 need not implement this demultiplexing algorithm. 260 In many secure multicast architectures, e.g., [RFC3740], a central 261 Group Controller/Key Server unilaterally assigns the group security 262 association's SPI. This SPI assignment is not negotiated or 263 coordinated with the key management (e.g., IKE) subsystems that 264 reside in the individual end systems that comprise the group. 265 Consequently, it is possible that a group security association and a 266 unicast security association can simultaneously use the same SPI. A 267 multicast-capable IPsec implementation MUST correctly de-multiplex 268 inbound traffic even in the context of SPI collisions. 270 Each entry in the Security Association Database (SAD) [Ken-Arch] must 271 indicate whether the SA lookup makes use of the destination, or 272 destination and source, IP addresses, in addition to the SPI. For 273 multicast SAs, the protocol field is not employed for SA lookups. For 274 each inbound, IPsec-protected packet, an implementation must conduct 275 its search of the SAD such that it finds the entry that matches the 276 "longest" SA identifier. In this context, if two or more SAD entries 277 match based on the SPI value, then the entry that also matches based 278 on destination, or destination and source, address comparison(as 279 indicated in the SAD entry) is the "longest" match. This implies a 280 logical ordering of the SAD search as follows: 282 1. Search the SAD for a match on {SPI, destination 283 address, source address}. If a SAD entry 284 matches then process the inbound ESP packet with that 285 matching SAD entry. Otherwise, proceed to step 2. 287 2. Search the SAD for a match on {SPI, destination 288 address}. If the SAD entry matches then 289 process the inbound ESP packet with that matching SAD 290 entry. Otherwise, proceed to step 3. 292 3. Search the SAD for a match on only {SPI} if the receiver 293 has chosen to maintain a single SPI space for AH and ESP, 294 or on {SPI, protocol} otherwise. If an SAD 295 entry matches then process the inbound ESP packet with 296 that matching SAD entry. Otherwise, discard the packet 297 and log an auditable event. 299 In practice, an implementation MAY choose any method to accelerate 300 this search, although its externally visible behavior MUST be 301 functionally equivalent to having searched the SAD in the above 302 order. For example, a software-based implementation could index into 303 a hash table by the SPI. The SAD entries in each hash table bucket's 304 linked list are kept sorted to have those SAD entries with the 305 longest SA identifiers first in that linked list. Those SAD entries 306 having the shortest SA identifiers are sorted so that they are the 307 last entries in the linked list. A hardware-based implementation may 308 be able to effect the longest match search intrinsically, using 309 commonly available TCAM features. 311 The indication of whether source and destination address matching is 312 required to map inbound IPsec traffic to SAs MUST be set either as a 313 side effect of manual SA configuration or via negotiation using an SA 314 management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source- 315 Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier 316 composed of an SPI, a destination multicast address, and source 317 address. An Any-Source Multicast group SA requires only an SPI and a 318 destination multicast address as an identifier. 320 The set of SPI values in the range 1 through 255 are reserved by the 321 Internet Assigned Numbers Authority (IANA) for future use; a reserved 322 SPI value will not normally be assigned by IANA unless the use of the 323 assigned SPI value is specified in an RFC. The SPI value of zero (0) 324 is reserved for local, implementation- specific use and MUST NOT be 325 sent on the wire. (For example, a key management implementation might 326 use the zero SPI value to mean "No Security Association Exists" 327 during the period when the IPsec implementation has requested that 328 its key management entity establish a new SA, but the SA has not yet 329 been established.) 331 2.5 Sequence Number 333 This unsigned 32-bit field contains a counter value that increases by 334 one for each packet sent, i.e., a per-SA packet sequence number. For 335 a unicast SA or a single-sender multicast SA, the sender MUST 336 increment this field for every transmitted packet. Sharing an SA 337 among multiple senders is permitted, though generally not 338 recommended. AH provides no means of synchronizing packet counters 339 among multiple senders or meaningfully managing a receiver packet 340 counter and window in the context of multiple senders. Thus, for a 341 multi-sender SA, the anti-reply features of AH are not available (see 342 Sections 3.3.2 and 3.4.3.) 344 The field is mandatory and MUST always be present even if the 345 receiver does not elect to enable the anti-replay service for a 346 specific SA. Processing of the Sequence Number field is at the 347 discretion of the receiver, but all AH implementations MUST be 348 capable of performing the Sequence Number processing described in 349 Section 3.3.2 "Sequence Number Generation" and Section 3.4.3 350 "Sequence Number Verification." Thus the sender MUST always transmit 351 this field, but the receiver need not act upon it. 353 The sender's counter and the receiver's counter are initialized to 0 354 when an SA is established. (The first packet sent using a given SA 355 will have a Sequence Number of 1; see Section 3.3.2 for more details 356 on how the Sequence Number is generated.) If anti-replay is enabled 357 (the default), the transmitted Sequence Number must never be allowed 358 to cycle. Thus, the sender's counter and the receiver's counter MUST 359 be reset (by establishing a new SA and thus a new key) prior to the 360 transmission of the 2^32nd packet on an SA. 362 2.5.1 Extended (64-bit) Sequence Number 364 To support high-speed IPsec implementations, a new option for 365 sequence numbers SHOULD be offered, as an extension to the current, 366 32-bit sequence number field. Use of an Extended Sequence Number 367 (ESN) MUST be negotiated by an SA management protocol. Note that in 368 IKEv2, this negotiation is implicit; the default is ESN unless 32-bit 369 Sequence Numbers are explicitly negotiated. (The ESN feature is 370 applicable to multicast as well as unicast SAs.) 372 The ESN facility allows use of a 64-bit sequence number for an SA. 373 (See Appendix B, "Managing 64-bit Sequence Numbers", for details.) 374 Only the low order 32 bits of the sequence number are transmitted in 375 the AH header of each packet, thus minimizing packet overhead. The 376 high order 32 bits are maintained as part of the sequence number 377 counter by both transmitter and receiver and are included in the 378 computation of the ICV, but are not transmitted. 380 2.6 Integrity Check Value (ICV) 382 This is a variable-length field that contains the Integrity Check 383 Value (ICV) for this packet. The field must be an integral multiple 384 of 32 bits (IPv4 or IPv6) in length. The details of ICV processing 385 are described in Section 3.3.3 "Integrity Check Value Calculation" 386 and Section 3.4.4 "Integrity Check Value Verification." This field 387 may include explicit padding, if required to ensure that the length 388 of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits 389 (IPv6). All implementations MUST support such padding. Details of 390 how to compute the required padding length are provided below in 391 Section 3.3.3.2 "Padding". The integrity algorithm specification 392 MUST specify the length of the ICV and the comparison rules and 393 processing steps for validation. 395 3. Authentication Header Processing 397 3.1 Authentication Header Location 399 AH may be employed in two ways: transport mode or tunnel mode. (See 400 the Security Architecture document for a description of when each 401 should be used.) 403 3.1.1 Transport Mode 405 In transport mode, AH is inserted after the IP header and before a 406 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other 407 IPsec headers that have already been inserted. In the context of 408 IPv4, this calls for placing AH after the IP header (and any options 409 that it contains), but before the next layer protocol. (Note that 410 the term "transport" mode should not be misconstrued as restricting 411 its use to TCP and UDP.) The following diagram illustrates AH 412 transport mode positioning for a typical IPv4 packet, on a "before 413 and after" basis. 415 BEFORE APPLYING AH 416 ---------------------------- 417 IPv4 |orig IP hdr | | | 418 |(any options)| TCP | Data | 419 ---------------------------- 421 AFTER APPLYING AH 422 ------------------------------------------------------- 423 IPv4 |original IP hdr (any options) | AH | TCP | Data | 424 ------------------------------------------------------- 425 |<- mutable field processing ->|<- immutable fields ->| 426 |<----- authenticated except for mutable fields ----->| 428 In the IPv6 context, AH is viewed as an end-to-end payload, and thus 429 should appear after hop-by-hop, routing, and fragmentation extension 430 headers. The destination options extension header(s) could appear 431 before or after or both before and after the AH header depending on 432 the semantics desired. The following diagram illustrates AH 433 transport mode positioning for a typical IPv6 packet. 435 BEFORE APPLYING AH 436 --------------------------------------- 437 IPv6 | | ext hdrs | | | 438 | orig IP hdr |if present| TCP | Data | 439 --------------------------------------- 441 AFTER APPLYING AH 442 ------------------------------------------------------------ 443 IPv6 | |hop-by-hop, dest*, | | dest | | | 444 |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | 445 ------------------------------------------------------------ 446 |<--- mutable field processing -->|<-- immutable fields -->| 447 |<---- authenticated except for mutable fields ----------->| 449 * = if present, could be before AH, after AH, or both 451 ESP and AH headers can be combined in a variety of modes. The IPsec 452 Architecture document describes the combinations of security 453 associations that must be supported. 455 Note that in transport mode, for "bump-in- the-stack" or "bump-in- 456 the-wire" implementations, as defined in the Security Architecture 457 document, inbound and outbound IP fragments may require an IPsec 458 implementation to perform extra IP reassembly/fragmentation in order 459 to both conform to this specification and provide transparent IPsec 460 support. Special care is required to perform such operations within 461 these implementations when multiple interfaces are in use. 463 3.1.2 Tunnel Mode 465 In tunnel mode, the "inner" IP header carries the ultimate (IP) 466 source and destination addresses, while an "outer" IP header contains 467 the addresses of the IPsec "peers," e.g., addresses of security 468 gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 469 over IPv4 and IPv4 over IPv6. In tunnel mode, AH protects the entire 470 inner IP packet, including the entire inner IP header. The position 471 of AH in tunnel mode, relative to the outer IP header, is the same as 472 for AH in transport mode. The following diagram illustrates AH tunnel 473 mode positioning for typical IPv4 and IPv6 packets. 475 ---------------------------------------------------------------- 476 IPv4 | | | orig IP hdr* | | | 477 |new IP header * (any options) | AH | (any options) |TCP| Data | 478 ---------------------------------------------------------------- 479 |<- mutable field processing ->|<------ immutable fields ----->| 480 |<- authenticated except for mutable fields in the new IP hdr->| 482 -------------------------------------------------------------- 483 IPv6 | | ext hdrs*| | | ext hdrs*| | | 484 |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| 485 -------------------------------------------------------------- 486 |<--- mutable field -->|<--------- immutable fields -------->| 487 | processing | 488 |<-- authenticated except for mutable fields in new IP hdr ->| 490 * = if present, construction of outer IP hdr/extensions and 491 modification of inner IP hdr/extensions is discussed in 492 the Security Architecture document. 494 3.2 Integrity Algorithms 496 The integrity algorithm employed for the ICV computation is specified 497 by the SA. For point-to-point communication, suitable integrity 498 algorithms include keyed Message Authentication Codes (MACs) based on 499 symmetric encryption algorithms (e.g., AES [AES]) or on one-way hash 500 functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast 501 communication, a variety of cryptographic strategies for providing 502 integrity have been developed and research continues in this area. 504 3.3 Outbound Packet Processing 506 In transport mode, the sender inserts the AH header after the IP 507 header and before a next layer protocol header, as described above. 508 In tunnel mode, the outer and inner IP header/extensions can be 509 inter-related in a variety of ways. The construction of the outer IP 510 header/extensions during the encapsulation process is described in 511 the Security Architecture document. 513 3.3.1 Security Association Lookup 515 AH is applied to an outbound packet only after an IPsec 516 implementation determines that the packet is associated with an SA 517 that calls for AH processing. The process of determining what, if 518 any, IPsec processing is applied to outbound traffic is described in 519 the Security Architecture document. 521 3.3.2 Sequence Number Generation 523 The sender's counter is initialized to 0 when an SA is established. 524 The sender increments the Sequence Number (or ESN) for this SA and 525 inserts the low-order 32 bits of the value into the Sequence Number 526 field. Thus the first packet sent using a given SA will contain a 527 Sequence Number of 1. 529 If anti-replay is enabled (the default), the sender checks to ensure 530 that the counter has not cycled before inserting the new value in the 531 Sequence Number field. In other words, the sender MUST NOT send a 532 packet on an SA if doing so would cause the Sequence Number to cycle. 533 An attempt to transmit a packet that would result in Sequence Number 534 overflow is an auditable event. The audit log entry for this event 535 SHOULD include the SPI value, current date/time, Source Address, 536 Destination Address, and (in IPv6) the cleartext Flow ID. 538 The sender assumes anti-replay is enabled as a default, unless 539 otherwise notified by the receiver (see 3.4.3) or if the SA was 540 configured using manual key management. Thus typical behavior of an 541 AH implementation calls for the sender to establish a new SA when the 542 Sequence Number (or ESN) cycles, or in anticipation of this value 543 cycling. 545 If anti-replay is disabled (as noted above), the sender does not need 546 to monitor or reset the counter, e.g., in the case of manual key 547 management (see Section 5). However, the sender still increments the 548 counter and when it reaches the maximum value, the counter rolls over 549 back to zero. (This behavior is recommended for multi-sender, 550 multicast SAs, unless anti-replay mechanisms outside the scope of 551 this standard are negotiated between the sender and receiver.) 553 If ESN (see Appendix B) is selected, only the low order 32 bits of 554 the Sequence Number are transmitted in the Sequence Number field, 555 although both sender and receiver maintain full 64-bit ESN counters. 556 However, the high order 32 bits are included in the ICV calculation. 558 3.3.3 Integrity Check Value Calculation 560 The AH ICV is computed over: 561 o IP or extension header fields before the AH header that are 562 either immutable in transit or that are predictable in value 563 upon arrival at the endpoint for the AH SA 564 o the AH header (Next Header, Payload Len, Reserved, SPI, 565 Sequence Number (low order 32 bits), and the Integrity Check 566 Value (which is set to zero for this computation), and 567 explicit padding bytes (if any)) 568 o everything after AH is assumed to be immutable in transit 569 o the high order bits of the ESN (if employed), and any implicit 570 padding required by the integrity algorithm 572 3.3.3.1 Handling Mutable Fields 574 If a field may be modified during transit, the value of the field is 575 set to zero for purposes of the ICV computation. If a field is 576 mutable, but its value at the (IPsec) receiver is predictable, then 577 that value is inserted into the field for purposes of the ICV 578 calculation. The Integrity Check Value field is also set to zero in 579 preparation for this computation. Note that by replacing each 580 field's value with zero, rather than omitting the field, alignment is 581 preserved for the ICV calculation. Also, the zero-fill approach 582 ensures that the length of the fields that are so handled cannot be 583 changed during transit, even though their contents are not explicitly 584 covered by the ICV. 586 As a new extension header or IPv4 option is created, it will be 587 defined in its own RFC and SHOULD include (in the Security 588 Considerations section) directions for how it should be handled when 589 calculating the AH ICV. If the IP (v4 or v6) implementation 590 encounters an extension header that it does not recognize, it will 591 discard the packet and send an ICMP message. IPsec will never see 592 the packet. If the IPsec implementation encounters an IPv4 option 593 that it does not recognize, it should zero the whole option, using 594 the second byte of the option as the length. IPv6 options (in 595 Destination extension headers or the Hop by Hop extension header) 596 contain a flag indicating mutability, which determines appropriate 597 processing for such options. 599 3.3.3.1.1 ICV Computation for IPv4 601 3.3.3.1.1.1 Base Header Fields 603 The IPv4 base header fields are classified as follows: 605 Immutable 606 Version 607 Internet Header Length 608 Total Length 609 Identification 610 Protocol (This should be the value for AH.) 611 Source Address 612 Destination Address (without loose or strict source routing) 614 Mutable but predictable 615 Destination Address (with loose or strict source routing) 617 Mutable (zeroed prior to ICV calculation) 618 DSCP (6 bits, see RFC2474 [NBBB98]) 619 ECN (2 bits, see RFC3168 [RFB01]) 620 Flags 621 Fragment Offset 622 Time to Live (TTL) 623 Header Checksum 625 DSCP - Routers may rewrite the DS field as needed to provide a 626 desired local or end-to-end service, thus its value upon reception 627 cannot be predicted by the sender. 629 ECN - This will change if a router along the route experiences 630 congestion, and thus its value upon reception cannot be predicted by 631 the sender. 633 Flags -- This field is excluded since an intermediate router might 634 set the DF bit, even if the source did not select it. 636 Fragment Offset -- Since AH is applied only to non-fragmented IP 637 packets, the Offset Field must always be zero, and thus it is 638 excluded (even though it is predictable). 640 TTL -- This is changed en-route as a normal course of processing by 641 routers, and thus its value at the receiver is not predictable by the 642 sender. 644 Header Checksum -- This will change if any of these other fields 645 changes, and thus its value upon reception cannot be predicted by the 646 sender. 648 3.3.3.1.1.2 Options 650 For IPv4 (unlike IPv6), there is no mechanism for tagging options as 651 mutable in transit. Hence the IPv4 options are explicitly listed in 652 Appendix A and classified as immutable, mutable but predictable, or 653 mutable. For IPv4, the entire option is viewed as a unit; so even 654 though the type and length fields within most options are immutable 655 in transit, if an option is classified as mutable, the entire option 656 is zeroed for ICV computation purposes. 658 3.3.3.1.2 ICV Computation for IPv6 660 3.3.3.1.2.1 Base Header Fields 662 The IPv6 base header fields are classified as follows: 664 Immutable 665 Version 666 Payload Length 667 Next Header 668 Source Address 669 Destination Address (without Routing Extension Header) 671 Mutable but predictable 672 Destination Address (with Routing Extension Header) 674 Mutable (zeroed prior to ICV calculation) 675 DSCP (6 bits, see RFC2474 [NBBB98]) 676 ECN (2 bits, see RFC3168 [RFB01]) 677 Flow Label (*) 678 Hop Limit 680 (*) The flow label described in AHv1 was mutable, and in 681 RFC 2460 [DH98] was potentially mutable. To retain 682 compatibility with existing AH implementations, the 683 flow label is not included in the ICV in AHv2. 685 3.3.3.1.2.2 Extension Headers Containing Options 687 IPv6 options in the Hop-by-Hop and Destination Extension Headers 688 contain a bit that indicates whether the option might change 689 (unpredictably) during transit. For any option for which contents 690 may change en-route, the entire "Option Data" field must be treated 691 as zero-valued octets when computing or verifying the ICV. The 692 Option Type and Opt Data Len are included in the ICV calculation. 693 All options for which the bit indicates immutability are included in 694 the ICV calculation. See the IPv6 specification [DH98] for more 695 information. 697 3.3.3.1.2.3 Extension Headers Not Containing Options 699 The IPv6 extension headers that do not contain options are explicitly 700 listed in Appendix A and classified as immutable, mutable but 701 predictable, or mutable. 703 3.3.3.2 Padding & Extended Sequence Numbers 705 3.3.3.2.1 ICV Padding 707 As mentioned in section 2.6, the ICV field may include explicit 708 padding if required to ensure that the AH header is a multiple of 32 709 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is 710 determined by two factors: 712 - the length of the ICV 713 - the IP protocol version (v4 or v6) 715 For example, if the output of the selected algorithm is 96-bits, no 716 padding is required for either IPv4 or for IPv6. However, if a 717 different length ICV is generated, due to use of a different 718 algorithm, then padding may be required depending on the length and 719 IP protocol version. The content of the padding field is arbitrarily 720 selected by the sender. (The padding is arbitrary, but need not be 721 random to achieve security.) These padding bytes are included in the 722 ICV calculation, counted as part of the Payload Length, and 723 transmitted at the end of the ICV field to enable the receiver to 724 perform the ICV calculation. 726 3.3.3.2.2 Implicit Packet Padding & ESN 728 If the ESN option is elected for an SA, then the high order 32 bits 729 of the ESN must be included in the ICV computation. For purposes of 730 ICV computation, these bits are appended (implicitly) immediately 731 after the end of the payload, and before any implicit packet padding. 733 For some integrity algorithms, the byte string over which the ICV 734 computation is performed must be a multiple of a blocksize specified 735 by the algorithm. If the IP packet length (including AH and the 32 736 high order bits of the ESN, if enabled) does not match the blocksize 737 requirements for the algorithm, implicit padding MUST be appended to 738 the end of the packet, prior to ICV computation. The padding octets 739 MUST have a value of zero. The blocksize (and hence the length of 740 the padding) is specified by the algorithm specification. This 741 padding is not transmitted with the packet. The document that defines 742 an integrity algorithm MUST be consulted to determine if implicit 743 padding is required as described above. If the document does not 744 specify an answer to this, then the default is to assume that 745 implicit padding is required (as needed to match the packet length to 746 the algorithm's blocksize.) If padding bytes are needed but the 747 algorithm does not specify the padding contents, then the padding 748 octets MUST have a value of zero. 750 3.3.4 Fragmentation 752 If required, IP fragmentation occurs after AH processing within an 753 IPsec implementation. Thus, transport mode AH is applied only to 754 whole IP datagrams (not to IP fragments). An IPv4 packet to which AH 755 has been applied may itself be fragmented by routers en route, and 756 such fragments must be reassembled prior to AH processing at a 757 receiver. (This does not apply to IPv6, where there is no router- 758 initiated fragmentation.) In tunnel mode, AH is applied to an IP 759 packet, the payload of which may be a fragmented IP packet. For 760 example, a security gateway or a "bump-in-the-stack" or "bump-in-the- 761 wire" IPsec implementation (see the Security Architecture document 762 for details) may apply tunnel mode AH to such fragments. 764 NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, 765 bump-in-the-stack and bump-in-the-wire implementations may have to 766 first reassemble a packet fragmented by the local IP layer, then 767 apply IPsec, and then fragment the resulting packet. 769 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 770 implementations, it will be necessary to examine all the extension 771 headers to determine if there is a fragmentation header and hence 772 that the packet needs reassembling prior to IPsec processing. 774 Fragmentation, whether performed by an IPsec implementation or by 775 routers along the path between IPsec peers, significantly reduces 776 performance. Moreover, the requirement for an AH receiver to accept 777 fragments for reassembly creates denial of service vulnerabilities. 778 Thus an AH implementation MAY choose to not support fragmentation and 779 may mark transmitted packets with the DF bit, to facilitate PMTU 780 discovery. In any case, an AH implementation MUST support generation 781 of ICMP PMTU messages (or equivalent internal signaling for native 782 host implementations) to minimize the likelihood of fragmentation. 783 Details of the support required for MTU management are contained in 784 the Security Architecture document. 786 3.4 Inbound Packet Processing 788 If there is more than one IPsec header/extension present, the 789 processing for each one ignores (does not zero, does not use) any 790 IPsec headers applied subsequent to the header being processed. 792 3.4.1 Reassembly 794 If required, reassembly is performed prior to AH processing. If a 795 packet offered to AH for processing appears to be an IP fragment, 796 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 797 the receiver MUST discard the packet; this is an auditable event. The 798 audit log entry for this event SHOULD include the SPI value, 799 date/time, Source Address, Destination Address, and (in IPv6) the 800 Flow ID. 802 NOTE: For packet reassembly, the current IPv4 spec does NOT require 803 either the zeroing of the OFFSET field or the clearing of the MORE 804 FRAGMENTS flag. In order for a reassembled packet to be processed by 805 IPsec (as opposed to discarded as an apparent fragment), the IP code 806 must do these two things after it reassembles a packet. 808 3.4.2 Security Association Lookup 810 Upon receipt of a packet containing an IP Authentication Header, the 811 receiver determines the appropriate (unidirectional) SA via lookup in 812 the SAD. For a unicast SA, this determination is based on the SPI or 813 the SPI plus protocol field, as described in Section 2.4. If an 814 implementation supports multicast traffic, the destination address is 815 also employed in the lookup (in addition to the SPI), and the sender 816 address also may be employed, as described in Section 2.4. (This 817 process is described in more detail in the Security Architecture 818 document.) The SAD entry for the SA also indicates whether the 819 Sequence Number field will be checked, whether 32 or 64-bit Sequence 820 Numbers are employed for the SA, specifies the algorithm(s) employed 821 for ICV computation, and indicates the key required to validate the 822 ICV. 824 If no valid Security Association exists for this packet the receiver 825 MUST discard the packet; this is an auditable event. The audit log 826 entry for this event SHOULD include the SPI value, date/time, Source 827 Address, Destination Address, and (in IPv6) the Flow ID. 829 (Note that SA management traffic, e.g., IKE packets, does not need to 830 be processed based on SPI, i.e., one can demultiplex this traffic 831 separately, e.g., based on Next Protocol and Port fields.) 833 3.4.3 Sequence Number Verification 835 All AH implementations MUST support the anti-replay service, though 836 its use may be enabled or disabled by the receiver on a per-SA basis. 837 Anti-replay is applicable to unicast as well as multicast SAs. 838 However, this standard specifies no mechanisms for providing anti- 839 replay for a multi-sender SA (unicast or multicast). In the absence 840 of negotiation (or manual configuration) of an anti-replay mechanism 841 for such an SA, it is recommended that sender and receiver checking 842 of the sequence number for the SA be disabled (via negotiation or 843 manual configuration), as noted below. 845 If the receiver does not enable anti-replay for an SA, no inbound 846 checks are performed on the Sequence Number. However, from the 847 perspective of the sender, the default is to assume that anti-replay 848 is enabled at the receiver. To avoid having the sender do 849 unnecessary sequence number monitoring and SA setup (see section 850 3.3.2 "Sequence Number Generation"), if an SA establishment protocol 851 such as IKE is employed, the receiver SHOULD notify the sender, 852 during SA establishment, if the receiver will not provide anti- 853 replay protection. 855 If the receiver has enabled the anti-replay service for this SA, the 856 receive packet counter for the SA MUST be initialized to zero when 857 the SA is established. For each received packet, the receiver MUST 858 verify that the packet contains a Sequence Number that does not 859 duplicate the Sequence Number of any other packets received during 860 the life of this SA. This SHOULD be the first AH check applied to a 861 packet after it has been matched to an SA, to speed rejection of 862 duplicate packets. 864 Duplicates are rejected through the use of a sliding receive window. 865 How the window is implemented is a local matter, but the following 866 text describes the functionality that the implementation must 867 exhibit. 869 The "right" edge of the window represents the highest, validated 870 Sequence Number value received on this SA. Packets that contain 871 Sequence Numbers lower than the "left" edge of the window are 872 rejected. Packets falling within the window are checked against a 873 list of received packets within the window. 875 If the ESN option is selected for an SA, only the low-order 32 bits 876 of the sequence number are explicitly transmitted; but the receiver 877 employs the full sequence number computed using the high-order 32 878 bits for the indicated SA (from his local counter) when checking the 879 received Sequence Number against the receive window. In constructing 880 the full Sequence Number, if the low order 32 bits carried in the 881 packet are lower in value than the low order 32 bits of the 882 receiver's Sequence Number, the receiver assumes that the high order 883 32 bits have been incremented, moving to a new sequence number 884 subspace. (This algorithm accommodates gaps in reception for a single 885 SA as large as 2**32-1 packets. If a larger gap occurs, additional, 886 heuristic checks for resynchronization of the receiver's Sequence 887 Number counter MAY be employed, as described in Appendix B.) 889 If the received packet falls within the window and is not a 890 duplicate, or if the packet is to the right of the window, then the 891 receiver proceeds to ICV verification. If the ICV validation fails, 892 the receiver MUST discard the received IP datagram as invalid. This 893 is an auditable event. The audit log entry for this event SHOULD 894 include the SPI value, date/time, Source Address, Destination 895 Address, the Sequence Number, and (in IPv6) the Flow ID. The receive 896 window is updated only if the ICV verification succeeds. 898 A MINIMUM window size of 32 packets MUST be supported; but a window 899 size of 64 is preferred and SHOULD be employed as the default. 900 Another window size (larger than the MINIMUM) MAY be chosen by the 901 receiver. (The receiver does NOT notify the sender of the window 902 size.) The receive window size should be increased for higher speed 903 environments, irrespective of assurance issues. Values for minimum 904 and recommended receive window sizes for very high speed (e.g., 905 multi-gigabit/second) devices are not specified by this standard. 907 3.4.4 Integrity Check Value Verification 909 The receiver computes the ICV over the appropriate fields of the 910 packet, using the specified integrity algorithm, and verifies that it 911 is the same as the ICV included in the ICV field of the packet. 912 Details of the computation are provided below. 914 If the computed and received ICV's match, then the datagram is valid, 915 and it is accepted. If the test fails, then the receiver MUST 916 discard the received IP datagram as invalid. This is an auditable 917 event. The audit log entry SHOULD include the SPI value, date/time 918 received, Source Address, Destination Address, and (in IPv6) the Flow 919 ID. 921 Implementation Note: 923 Implementations can use any set of steps that results in the same 924 result as the following set of steps. Begin by saving the ICV 925 value and replacing it (but not any ICV field padding) with zero. 926 Zero all other fields that may have been modified during transit. 927 (See section 3.3.3.1, "Handling Mutable Fields", for a discussion 928 of which fields are zeroed before performing the ICV calculation.) 929 If the ESN option is elected for this SA, append the high order 32 930 bits of the ESN after the end of the packet. Check the overall 931 length of the packet (as described above), and if it requires 932 implicit padding based on the requirements of the integrity 933 algorithm, append zero-filled bytes to the end of the packet 934 (after the ESN if present) as required. Perform the ICV 935 computation and compare the result with the saved value, using the 936 comparison rules defined by the algorithm specification. (For 937 example, if a digital signature and one-way hash are used for the 938 ICV computation, the matching process is more complex.) 940 4. Auditing 942 Not all systems that implement AH will implement auditing. However, 943 if AH is incorporated into a system that supports auditing, then the 944 AH implementation MUST also support auditing and MUST allow a system 945 administrator to enable or disable auditing for AH. For the most 946 part, the granularity of auditing is a local matter. However, 947 several auditable events are identified in this specification and for 948 each of these events a minimum set of information that SHOULD be 949 included in an audit log is defined. Additional information also MAY 950 be included in the audit log for each of these events, and additional 951 events, not explicitly called out in this specification, also MAY 952 result in audit log entries. There is no requirement for the 953 receiver to transmit any message to the purported sender in response 954 to the detection of an auditable event, because of the potential to 955 induce denial of service via such action. 957 5. Conformance Requirements 959 Implementations that claim conformance or compliance with this 960 specification MUST fully implement the AH syntax and processing 961 described here for unicast traffic, and MUST comply with all 962 requirements of the Security Architecture document [Ken-Arch]. 963 Additionally, if an implementation claims to support multicast 964 traffic, it MUST comply with the additional requirements specified 965 for support of such traffic. If the key used to compute an ICV is 966 manually distributed, correct provision of the anti-replay service 967 would require correct maintenance of the counter state at the sender, 968 until the key is replaced, and there likely would be no automated 969 recovery provision if counter overflow were imminent. Thus a 970 compliant implementation SHOULD NOT provide this service in 971 conjunction with SAs that are manually keyed. 973 The mandatory-to-implement algorithms for use with AH are described 974 in a separate RFC [Eas04], to facilitate updating the algorithm 975 requirements independently from the protocol per se. Additional 976 algorithms, beyond those mandated for AH, MAY be supported. 978 6. Security Considerations 980 Security is central to the design of this protocol, and these 981 security considerations permeate the specification. Additional 982 security-relevant aspects of using the IPsec protocol are discussed 983 in the Security Architecture document. 985 7. Differences from RFC 2402 987 This document differs from RFC 2402 in the following ways. 989 o SPI -- modified to specify a uniform algorithm for SAD lookup 990 for unicast and multicast SAs, covering a wider range of 991 multicast technologies. For unicast, the SPI may be used alone 992 to select an SA, or may be combined with the protocol, at the 993 option of the receiver. For multicast SAs, the SPI is 994 combined with the destination address, and optionally the 995 source address, to select an SA. 996 o Sequence number -- added a new option for a 64-bit sequence 997 number for very high-speed communications. Clarified sender 998 and receiver processing requirements for multicast SAs and 999 multi-sender SAs. 1000 o Moved references to mandatory algorithms to a separate 1001 document [Eas04]. 1003 Acknowledgements 1005 The author would like to acknowledge the contributions of Ran 1006 Atkinson, who played a critical role in initial IPsec activities, and 1007 who authored the first series of IPsec standards: RFCs 1825-1827. 1008 Karen Seo deserves special thanks for providing help in the editing 1009 of this and the previous version of this specification. The author 1010 also would like to thank the members of the IPsec and MSEC working 1011 groups who have contributed to the development of this protocol 1012 specification. 1014 References 1016 Normative 1018 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 1019 Requirement Level", BCP 14, RFC 2119, March 1997. 1021 [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 1022 (IPv6) Specification", RFC 2460, December 1998. 1024 [Eas04] Eastlake, D., "Cryptographic Algorithm Implementation 1025 Requirements For ESP And AH", RFC ???, ??? 200? 1027 [Ken-Arch]Kent, S., and Seo, K., "Security Architecture for the 1028 Internet Protocol", RFC ???, ??? 200?. 1030 [Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1031 1981 1033 Informative 1035 [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for 1036 IP", Internet-Draft, draft-ietf-ssm-arch-01.txt, November 1037 3, 2002. 1039 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange 1040 (IKE)", RFC 2409, November 1998. 1042 [Ken-AH] Kent, S., "IP Authentication Header (AH)", RFC ???, ??? 1043 200?. 1045 [Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1046 ???, ???? 200?. 1048 [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1049 of the Differentiated Services Field (DS Field) in the IPv4 1050 and IPv6 Headers", RFC 2474, December 1998. 1052 [RFB01] Ramakrishnan, K., Floyd S., Black D., "The Addition of 1053 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1054 September 2001. 1056 [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group 1057 Domain of Interpretation", RFC 3547, July 2003. 1059 [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security 1060 Architecture", RFC 3740, March 2004. 1062 Author Information 1064 Stephen Kent 1065 BBN Technologies 1066 10 Moulton Street 1067 Cambridge, MA 02138 1068 USA 1069 Phone: +1 (617) 873-3988 1070 EMail: kent@bbn.com 1072 Appendix A -- Mutability of IP Options/Extension Headers 1074 A1. IPv4 Options 1076 This table shows how the IPv4 options are classified with regard to 1077 "mutability". Where two references are provided, the second one 1078 supercedes the first. This table is based in part on information 1079 provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). 1081 Opt. 1082 Copy Class # Name Reference 1083 ---- ----- --- ------------------------- -------- 1084 IMMUTABLE -- included in ICV calculation 1085 0 0 0 End of Options List [RFC791] 1086 0 0 1 No Operation [RFC791] 1087 1 0 2 Security [RFC1108(historic but 1088 in use)] 1089 1 0 5 Extended Security [RFC1108(historic but 1090 in use)] 1091 1 0 6 Commercial Security [expired I-D, now US MIL 1092 STD] 1093 1 0 20 Router Alert [RFC2113] 1094 1 0 21 Sender Directed Multi- [RFC1770] 1095 Destination Delivery 1096 MUTABLE -- zeroed 1097 1 0 3 Loose Source Route [RFC791] 1098 0 2 4 Time Stamp [RFC791] 1099 0 0 7 Record Route [RFC791] 1100 1 0 9 Strict Source Route [RFC791] 1101 0 2 18 Traceroute [RFC1393] 1103 EXPERIMENTAL, SUPERCEDED -- zeroed 1104 1 0 8 Stream ID [RFC791, RFC1122 (Host 1105 Req)] 1106 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 1107 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1108 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 1109 0 0 10 Experimental Measurement [ZSu] 1110 1 2 13 Experimental Flow Control [Finn] 1111 1 0 14 Experimental Access Ctl [Estrin] 1112 0 0 15 ??? [VerSteeg] 1113 1 0 16 IMI Traffic Descriptor [Lee] 1114 1 0 19 Address Extension [Ullmann IPv7] 1116 NOTE: Use of the Router Alert option is potentially incompatible with 1117 use of IPsec. Although the option is immutable, its use implies that 1118 each router along a packet's path will "process" the packet and 1119 consequently might change the packet. This would happen on a hop by 1120 hop basis as the packet goes from router to router. Prior to being 1121 processed by the application to which the option contents are 1122 directed, e.g., RSVP/IGMP, the packet should encounter AH processing. 1123 However, AH processing would require that each router along the path 1124 is a member of a multicast-SA defined by the SPI. This might pose 1125 problems for packets that are not strictly source routed, and it 1126 requires multicast support techniques not currently available. 1128 NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by 1129 systems along a packet's path conflicts with the classification of 1130 these IP Options as immutable and is incompatible with the use of 1131 IPsec. 1133 NOTE: End of Options List options SHOULD be repeated as necessary to 1134 ensure that the IP header ends on a 4 byte boundary in order to 1135 ensure that there are no unspecified bytes which could be used for a 1136 covert channel. 1138 A2. IPv6 Extension Headers 1140 This table shows how the IPv6 Extension Headers are classified with 1141 regard to "mutability". 1143 Option/Extension Name Reference 1144 ----------------------------------- --------- 1145 MUTABLE BUT PREDICTABLE -- included in ICV calculation 1146 Routing (Type 0) [DH98] 1148 BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING 1149 TRANSIT) 1150 Hop by Hop options [DH98] 1151 Destination options [DH98] 1153 NOT APPLICABLE 1154 Fragmentation [DH98] 1156 Options -- IPv6 options in the Hop-by-Hop and Destination 1157 Extension Headers contain a bit that indicates whether the option 1158 might change (unpredictably) during transit. For any option for 1159 which contents may change en-route, the entire "Option Data" field 1160 must be treated as zero-valued octets when computing or verifying 1161 the ICV. The Option Type and Opt Data Len are included in the ICV 1162 calculation. All options for which the bit indicates immutability 1163 are included in the ICV calculation. See the IPv6 specification 1164 [DH98] for more information. 1166 Routing (Type 0) -- The IPv6 Routing Header "Type 0" will 1167 rearrange the address fields within the packet during transit from 1168 source to destination. However, the contents of the packet as it 1169 will appear at the receiver are known to the sender and to all 1170 intermediate hops. Hence, the IPv6 Routing Header "Type 0" is 1171 included in the Integrity Check Value calculation as mutable but 1172 predictable. The sender must order the field so that it appears as 1173 it will at the receiver, prior to performing the ICV computation. 1175 Fragmentation -- Fragmentation occurs after outbound IPsec 1176 processing (section 3.3) and reassembly occurs before inbound IPsec 1177 processing (section 3.4). So the Fragmentation Extension Header, if 1178 it exists, is not seen by IPsec. 1180 Note that on the receive side, the IP implementation could 1181 leave a Fragmentation Extension Header in place when it does re- 1182 assembly. If this happens, then when AH receives the packet, before 1183 doing ICV processing, AH MUST "remove" (or skip over) this header 1184 and change the previous header's "Next Header" field to be the "Next 1185 Header" field in the Fragmentation Extension Header. 1187 Note that on the send side, the IP implementation could give 1188 the IPsec code a packet with a Fragmentation Extension Header with 1189 Offset of 0 (first fragment) and a More Fragments Flag of 0 (last 1190 fragment). If this happens, then before doing ICV processing, AH 1191 MUST first "remove" (or skip over) this header and change the 1192 previous header's "Next Header" field to be the "Next Header" field 1193 in the Fragmentation Extension Header. 1195 Appendix B -- Extended (64-bit) Sequence Numbers 1197 B1. Overview 1199 This appendix describes an extended sequence number (ESN) scheme for 1200 use with IPsec (ESP and AH) that employs a 64-bit sequence number, 1201 but in which only the low order 32 bits are transmitted as part of 1202 each packet. It covers both the window scheme used to detect 1203 replayed packets and the determination of the high order bits of the 1204 sequence number that are used both for replay rejection and for 1205 computation of the ICV. It also discusses a mechanism for handling 1206 loss of synchronization relative to the (not transmitted) high order 1207 bits. 1209 B2. Anti-Replay Window 1211 The receiver will maintain an anti-replay window of size W. This 1212 window will limit how far out of order a packet can be, relative to 1213 the packet with the highest sequence number that has been 1214 authenticated so far. (No requirement is established for minimum or 1215 recommended sizes for this window, beyond the 32 and 64-packet values 1216 already established for 32-bit sequence number windows. However, it 1217 is suggested that an implementer scale these values consistent with 1218 the interface speed supported by an implementation that makes use of 1219 the ESN option. Also, the algorithm described below assumes that the 1220 window is no greater than 2^31 packets in width.) All 2^32 sequence 1221 numbers associated with any fixed value for the high order 32 bits 1222 (Seqh) will hereafter be called a sequence number subspace. The 1223 following table lists pertinent variables and their definitions. 1225 Var. Size 1226 Name (bits) Meaning 1227 ---- ------ --------------------------- 1228 W 32 Size of window 1229 T 64 Highest sequence number authenticated so far, 1230 upper bound of window 1231 Tl 32 Lower 32 bits of T 1232 Th 32 Upper 32 bits of T 1233 B 64 Lower bound of window 1234 Bl 32 Lower 32 bits of B 1235 Bh 32 Upper 32 bits of B 1236 Seq 64 Sequence number of received packet 1237 Seql 32 Lower 32 bits of Seq 1238 Seqh 32 Upper 32 bits of Seq 1240 When performing the anti-replay check, or when determining which high 1241 order bits to use to authenticate an incoming packet, there are two 1242 cases: 1244 + Case A: Tl >= (W - 1). In this case, the window is within one 1245 sequence number subspace. (See Figure 1) 1246 + Case B: Tl < (W - 1). In this case, the window spans two 1247 sequence number subspaces. (See Figure 2) 1249 In the figures below, the bottom line ("----") shows two consecutive 1250 sequence number subspaces, with zero's indicating the beginning of 1251 each subspace. The two shorter lines above it show the higher order 1252 bits that apply. The "====" represents the window. The "****" 1253 represents future sequence numbers, i.e., those beyond the current 1254 highest sequence number authenticated (ThTl). 1256 Th+1 ********* 1258 Th =======***** 1260 --0--------+-----+-----0--------+-----------0-- 1261 Bl Tl Bl 1262 (Bl+2^32) mod 2^32 1264 Figure 1 -- Case A 1266 Th ====************** 1268 Th-1 === 1270 --0-----------------+--0--+--------------+--0-- 1271 Bl Tl Bl 1272 (Bl+2^32) mod 2^32 1274 Figure 2 -- Case B 1276 B2.1. Managing and Using the Anti-Replay Window 1278 The anti-replay window can be thought of as a string of bits where 1279 `W' defines the length of the string. W = T - B + 1 and cannot 1280 exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and 1281 the top-most bit corresponds to T and each sequence number from Bl 1282 through Tl is represented by a corresponding bit. The value of the 1283 bit indicates whether or not a packet with that sequence number has 1284 been received and authenticated, so that replays can be detected and 1285 rejected. 1287 When a packet with a 64-bit sequence number (Seq) greater than T is 1288 received and validated, 1289 + B is increased by (Seq - T) 1290 + (Seq - T) bits are dropped from the low end of the window 1291 + (Seq - T) bits are added to the high end of the window 1292 + The top bit is set to indicate that a packet with that sequence 1293 number has been received and authenticated 1294 + The new bits between T and the top bit are set to indicate that 1295 no packets with those sequence numbers have been received yet. 1296 + T is set to the new sequence number 1298 In checking for replayed packets, 1300 + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND 1301 Seql <= Tl, then check the corresponding bit in the window to see 1302 if this Seql has already been seen. If yes, reject the packet. 1303 If no, perform integrity check (see Section 2.2. below for 1304 determination of SeqH). 1306 + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR 1307 Seql <= Tl, then check the corresponding bit in the window to see 1308 if this Seql has already been seen. If yes, reject the packet. 1309 If no, perform integrity check (see Section 2.2. below for 1310 determination of Seqh). 1312 B2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number 1314 Since only `Seql' will be transmitted with the packet, the receiver 1315 must deduce and track the sequence number subspace into which each 1316 packet falls, i.e., determine the value of Seqh. The following 1317 equations define how to select Seqh under "normal" conditions; see 1318 Section 3 for a discussion of how to recover from extreme packet 1319 loss. 1321 + Under Case A (Figure 1): 1322 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th 1323 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1 1325 + Under Case B (Figure 2): 1326 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 1327 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th 1329 B2.3. Pseudo-code Example 1331 The following pseudo-code illustrates the above algorithms for anti- 1332 replay and integrity checks. The values for `Seql', `Tl', `Th' and 1333 `W', are 32-bit unsigned integers. Arithmetic is mod 2^32. 1335 If (Tl >= W - 1) Case A 1336 If (Seql >= Tl - W + 1) 1337 Seqh = Th 1338 If (Seql <= Tl) 1339 If (pass replay check) 1340 If (pass integrity check) 1341 Set bit corresponding to Seql 1342 Pass the packet on 1343 Else reject packet 1344 Else reject packet 1345 Else 1346 If (pass integrity check) 1347 Tl = Seql (shift bits) 1348 Set bit corresponding to Seql 1349 Pass the packet on 1350 Else reject packet 1351 Else 1352 Seqh = Th + 1 1353 If (pass integrity check) 1354 Tl = Seql (shift bits) 1355 Th = Th + 1 1356 Set bit corresponding to Seql 1357 Pass the packet on 1358 Else reject packet 1359 Else Case B 1360 If (Seql >= Tl - W + 1) 1361 Seqh = Th - 1 1362 If (pass replay check) 1363 If (pass integrity check) 1364 Set the bit corresponding to Seql 1365 Pass packet on 1366 Else reject packet 1367 Else reject packet 1368 Else 1369 Seqh = Th 1370 If (Seql <= Tl) 1371 If (pass replay check) 1372 If (pass integrity check) 1373 Set the bit corresponding to Seql 1374 Pass packet on 1375 Else reject packet 1376 Else reject packet 1377 Else 1378 If (pass integrity check) 1379 Tl = Seql (shift bits) 1380 Set the bit corresponding to Seql 1381 Pass packet on 1382 Else reject packet 1384 B3. Handling Loss of Synchronization due to Significant Packet Loss 1386 If there is an undetected packet loss of 2^32 or more consecutive 1387 packets on a single SA, then the transmitter and receiver will lose 1388 synchronization of the high order bits, i.e., the equations in 1389 Section 2.2. will fail to yield the correct value. Unless this 1390 problem is detected and addressed, subsequent packets on this SA will 1391 fail authentication checks and be discarded. The following procedure 1392 SHOULD be implemented by any IPsec (ESP or AH) implementation that 1393 supports the ESN option. 1395 Note that this sort of extended traffic loss seems unlikely to occur 1396 if any significant fraction of the traffic on the SA in question is 1397 TCP, because the source would fail to receive ACKs and would stop 1398 sending long before 2^32 packets had been lost. Also, for any bi- 1399 directional application, even ones operating above UDP, such an 1400 extended outage would likely result in triggering some form of 1401 timeout. However, a unidirectional application, operating over UDP 1402 might lack feedback that would cause automatic detection of a loss of 1403 this magnitude, hence the motivation to develop a recovery method for 1404 this case. 1406 The solution we've chosen was selected to: 1408 + minimize the impact on normal traffic processing 1410 + avoid creating an opportunity for a new denial of service attack 1411 such as might occur by allowing an attacker to force diversion of 1412 resources to a resynchronization process. 1414 + limit the recovery mechanism to the receiver -- since anti-replay 1415 is a service only for the receiver, and the transmitter generally 1416 is not aware of whether the receiver is using sequence numbers in 1417 support of this optional service, it is preferable for recovery 1418 mechanisms to be local to the receiver. This also allows for 1419 backwards compatibility. 1421 B3.1. Triggering Resynchronization 1423 For each SA, the receiver records the number of consecutive packets 1424 that fail authentication. This count is used to trigger the 1425 resynchronization process which should be performed in the background 1426 or using a separate processor. Receipt of a valid packet on the SA 1427 resets the counter to zero. The value used to trigger the 1428 resynchronization process is a local parameter. There is no 1429 requirement to support distinct trigger values for different SAs, 1430 although an implementer may choose to do so. 1432 B3.2. Resynchronization Process 1434 When the above trigger point is reached, a "bad" packet is selected 1435 for which authentication is retried using successively larger values 1437 for the upper half of the sequence number (Seqh). These values are 1438 generated by incrementing by one for each retry. The number of 1439 retries should be limited, in case this is a packet from the "past" 1440 or a bogus packet. The limit value is a local parameter. (Because 1441 the Seqh value is implicitly placed after the ESP (or AH) payload, it 1442 may be possible to optimize this procedure by executing the integrity 1443 algorithm over the packet up to the end point of the payload, then 1444 compute different candidate ICV's by varying the value of Seqh.) 1445 Successful authentication of a packet via this procedure resets the 1446 consecutive failure count and sets the value of T to that of the 1447 received packet. 1449 This solution requires support only on the part of the receiver, 1450 thereby allowing for backwards compatibility. Also, because 1451 resynchronization efforts would either occur in the background or 1452 utilize an additional processor, this solution does not impact 1453 traffic processing and a denial of service attack cannot divert 1454 resources away from traffic processing. 1456 Notices 1458 The IETF takes no position regarding the validity or scope of any 1459 intellectual property or other rights that might be claimed to 1460 pertain to the implementation or use of the technology described in 1461 this document or the extent to which any license under such rights 1462 might or might not be available; neither does it represent that it 1463 has made any effort to identify any such rights. Information on the 1464 IETF's procedures with respect to rights in standards-track and 1465 standards- related documentation can be found in BCP-11. Copies of 1466 claims of rights made available for publication and any assurances of 1467 licenses to be made available, or the result of an attempt made to 1468 obtain a general license or permission for the use of such 1469 proprietary rights by implementers or users of this specification can 1470 be obtained from the IETF Secretariat. 1472 The IETF invites any interested party to bring to its attention any 1473 copyrights, patents or patent applications, or other proprietary 1474 rights which may cover technology that may be required to practice 1475 this standard. Please address the information to the IETF Executive 1476 Director. 1478 Copyright (C) The Internet Society (2004). This document is subject 1479 to the rights, licenses and restrictions contained in BCP 78, and 1480 except as set forth therein, the authors retain all their rights. 1482 This document is subject to the rights, licenses and restrictions 1483 contained in BCP 78, and except as set forth therein, the authors 1484 retain all their rights. 1486 This document and translations of it may be copied and furnished to 1487 others, and derivative works that comment on or otherwise explain it 1488 or assist in its implementation may be prepared, copied, published 1489 and distributed, in whole or in part, without restriction of any 1490 kind, provided that the above copyright notice and this paragraph are 1491 included on all such copies and derivative works. However, this 1492 document itself may not be modified in any way, such as by removing 1493 the copyright notice or references to the Internet Society or other 1494 Internet organizations, except as needed for the purpose of 1495 developing Internet standards in which case the procedures for 1496 copyrights defined in the Internet Standards process must be 1497 followed, or as required to translate it into languages other than 1498 English. 1500 The limited permissions granted above are perpetual and will not be 1501 revoked by the Internet Society or its successors or assigns. 1503 This document and the information contained herein are provided on an 1504 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1505 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1506 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1507 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1508 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1509 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1511 Expires April 2005