idnits 2.17.1 draft-ietf-ipsec-rfc2402bis-09.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 1508. ** 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 823 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 6941 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 961, 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: 'AES' is mentioned on line 498, but not defined == Missing Reference: 'RFC791' is mentioned on line 1099, but not defined == Missing Reference: 'RFC2113' is mentioned on line 1092, but not defined == Missing Reference: 'RFC1770' is mentioned on line 1093, but not defined ** Obsolete undefined reference: RFC 1770 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1393' is mentioned on line 1100, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'ZSu' is mentioned on line 1108, but not defined == Missing Reference: 'Finn' is mentioned on line 1109, but not defined == Missing Reference: 'Estrin' is mentioned on line 1110, but not defined == Missing Reference: 'VerSteeg' is mentioned on line 1111, but not defined == Missing Reference: 'Lee' is mentioned on line 1112, but not defined == Unused Reference: 'Pos81' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 1038, 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 (~~), 21 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-09.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, e.g., IKE or an out-of-band configuration mechanism. 212 2.1 Next Header 214 The Next Header is an 8-bit field that identifies the type of the 215 next payload after the Authentication Header. The value of this 216 field is chosen from the set of IP Protocol Numbers defined on the 217 web page of Internet Assigned Numbers Authority (IANA), e.g., a value 218 of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 219 indicates TCP. 221 2.2 Payload Length 223 This 8-bit field specifies the length of AH in 32-bit words (4-byte 224 units), minus "2". Thus, for example, if an integrity algorithm 225 yields a 96-bit authentication value, this length field will be "4" 226 (3 32-bit word fixed fields plus 3 32-bit words for the ICV, minus 227 2). For IPv6, the total length of the header must be a multiple of 228 8-octet units. (Note that although IPv6 [DH98] characterizes AH as an 229 extension header, its length is measured in 32-bit words, not the 230 64-bit words used by other IPv6 extension headers.) See Section 2.6, 231 "Integrity Check Value (ICV)", for comments on padding of this field, 232 and Section 3.3.3.2.1 "ICV Padding". 234 2.3 Reserved 236 This 16-bit field is reserved for future use. It MUST be set to 237 "zero" by the sender, and it SHOULD be ignored by the recipient. 238 (Note that the value is included in the ICV calculation, but is 239 otherwise ignored by the recipient.) 241 2.4 Security Parameters Index (SPI) 243 The SPI is an arbitrary 32-bit value that is used by a receiver to 244 identify the SA to which an incoming packet is bound. For a unicast 245 SA, the SPI can be used by itself to specify an SA, or it may be used 246 in conjunction with the IPsec protocol type (in this case AH). 247 Since, for unicast SAs, the SPI value is generated by the receiver, 248 whether the value is sufficient to identify an SA by itself, or 249 whether it must be used in conjunction with the IPsec protocol value 250 is a local matter. The SPI field is mandatory and this mechanism for 251 mapping inbound traffic to unicast SAs described above MUST be 252 supported by all AH implementations. 254 If an IPsec implementation supports multicast, then it MUST support 255 multicast SAs using the algorithm below for mapping inbound IPsec 256 datagrams to SAs. Implementations that support only unicast traffic 257 need not implement this demultiplexing algorithm. 259 In many secure multicast architectures, e.g., [RFC3740], a central 260 Group Controller/Key Server unilaterally assigns the group security 261 association's SPI. This SPI assignment is not negotiated or 262 coordinated with the key management (e.g., IKE) subsystems that 263 reside in the individual end systems that comprise the group. 264 Consequently, it is possible that a group security association and a 265 unicast security association can simultaneously use the same SPI. A 266 multicast-capable IPsec implementation MUST correctly de-multiplex 267 inbound traffic even in the context of SPI collisions. 269 Each entry in the Security Association Database (SAD) [Ken-Arch] must 270 indicate whether the SA lookup makes use of the destination, or 271 destination and source, IP addresses, in addition to the SPI. For 272 multicast SAs, the protocol field is not employed for SA lookups. For 273 each inbound, IPsec-protected packet, an implementation must conduct 274 its search of the SAD such that it finds the entry that matches the 275 "longest" SA identifier. In this context, if two or more SAD entries 276 match based on the SPI value, then the entry that also matches based 277 on destination, or destination and source, address comparison(as 278 indicated in the SAD entry) is the "longest" match. This implies a 279 logical ordering of the SAD search as follows: 281 1. Search the SAD for a match on {SPI, destination 282 address, source address}. If an SAD entry 283 matches then process the inbound AH packet with that 284 matching SAD entry. Otherwise, proceed to step 2. 286 2. Search the SAD for a match on {SPI, destination 287 address}. If an SAD entry matches then process 288 the inbound AH packet with that matching SAD 289 entry. Otherwise, proceed to step 3. 291 3. Search the SAD for a match on only {SPI} if the receiver 292 has chosen to maintain a single SPI space for AH and ESP, 293 or on {SPI, protocol} otherwise. If an SAD 294 entry matches then process the inbound AH packet with 295 that matching SAD entry. Otherwise, discard the packet 296 and log an auditable event. 298 In practice, an implementation MAY choose any method to accelerate 299 this search, although its externally visible behavior MUST be 300 functionally equivalent to having searched the SAD in the above 301 order. For example, a software-based implementation could index into 302 a hash table by the SPI. The SAD entries in each hash table bucket's 303 linked list are kept sorted to have those SAD entries with the 304 longest SA identifiers first in that linked list. Those SAD entries 305 having the shortest SA identifiers are sorted so that they are the 306 last entries in the linked list. A hardware-based implementation may 307 be able to effect the longest match search intrinsically, using 308 commonly available TCAM features. 310 The indication of whether source and destination address matching is 311 required to map inbound IPsec traffic to SAs MUST be set either as a 312 side effect of manual SA configuration or via negotiation using an SA 313 management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source- 314 Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier 315 composed of an SPI, a destination multicast address, and source 316 address. An Any-Source Multicast group SA requires only an SPI and a 317 destination multicast address as an identifier. 319 The set of SPI values in the range 1 through 255 are reserved by the 320 Internet Assigned Numbers Authority (IANA) for future use; a reserved 321 SPI value will not normally be assigned by IANA unless the use of the 322 assigned SPI value is specified in an RFC. The SPI value of zero (0) 323 is reserved for local, implementation- specific use and MUST NOT be 324 sent on the wire. (For example, a key management implementation might 325 use the zero SPI value to mean "No Security Association Exists" 326 during the period when the IPsec implementation has requested that 327 its key management entity establish a new SA, but the SA has not yet 328 been established.) 330 2.5 Sequence Number 332 This unsigned 32-bit field contains a counter value that increases by 333 one for each packet sent, i.e., a per-SA packet sequence number. For 334 a unicast SA or a single-sender multicast SA, the sender MUST 335 increment this field for every transmitted packet. Sharing an SA 336 among multiple senders is permitted, though generally not 337 recommended. AH provides no means of synchronizing packet counters 338 among multiple senders or meaningfully managing a receiver packet 339 counter and window in the context of multiple senders. Thus, for a 340 multi-sender SA, the anti-reply features of AH are not available (see 341 Sections 3.3.2 and 3.4.3.) 343 The field is mandatory and MUST always be present even if the 344 receiver does not elect to enable the anti-replay service for a 345 specific SA. Processing of the Sequence Number field is at the 346 discretion of the receiver, but all AH implementations MUST be 347 capable of performing the Sequence Number processing described in 348 Section 3.3.2 "Sequence Number Generation" and Section 3.4.3 349 "Sequence Number Verification." Thus the sender MUST always transmit 350 this field, but the receiver need not act upon it. 352 The sender's counter and the receiver's counter are initialized to 0 353 when an SA is established. (The first packet sent using a given SA 354 will have a Sequence Number of 1; see Section 3.3.2 for more details 355 on how the Sequence Number is generated.) If anti-replay is enabled 356 (the default), the transmitted Sequence Number must never be allowed 357 to cycle. Thus, the sender's counter and the receiver's counter MUST 358 be reset (by establishing a new SA and thus a new key) prior to the 359 transmission of the 2^32nd packet on an SA. 361 2.5.1 Extended (64-bit) Sequence Number 363 To support high-speed IPsec implementations, a new option for 364 sequence numbers SHOULD be offered, as an extension to the current, 365 32-bit sequence number field. Use of an Extended Sequence Number 366 (ESN) MUST be negotiated by an SA management protocol. Note that in 367 IKEv2, this negotiation is implicit; the default is ESN unless 32-bit 368 Sequence Numbers are explicitly negotiated. (The ESN feature is 369 applicable to multicast as well as unicast SAs.) 371 The ESN facility allows use of a 64-bit sequence number for an SA. 372 (See Appendix B, "Managing 64-bit Sequence Numbers", for details.) 373 Only the low order 32 bits of the sequence number are transmitted in 374 the AH header of each packet, thus minimizing packet overhead. The 375 high order 32 bits are maintained as part of the sequence number 376 counter by both transmitter and receiver and are included in the 377 computation of the ICV, but are not transmitted. 379 2.6 Integrity Check Value (ICV) 381 This is a variable-length field that contains the Integrity Check 382 Value (ICV) for this packet. The field must be an integral multiple 383 of 32 bits (IPv4 or IPv6) in length. The details of ICV processing 384 are described in Section 3.3.3 "Integrity Check Value Calculation" 385 and Section 3.4.4 "Integrity Check Value Verification." This field 386 may include explicit padding, if required to ensure that the length 387 of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits 388 (IPv6). All implementations MUST support such padding. Details of 389 how to compute the required padding length are provided below in 390 Section 3.3.3.2 "Padding". The integrity algorithm specification 391 MUST specify the length of the ICV and the comparison rules and 392 processing steps for validation. 394 3. Authentication Header Processing 396 3.1 Authentication Header Location 398 AH may be employed in two ways: transport mode or tunnel mode. (See 399 the Security Architecture document for a description of when each 400 should be used.) 402 3.1.1 Transport Mode 404 In transport mode, AH is inserted after the IP header and before a 405 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other 406 IPsec headers that have already been inserted. In the context of 407 IPv4, this calls for placing AH after the IP header (and any options 408 that it contains), but before the next layer protocol. (Note that 409 the term "transport" mode should not be misconstrued as restricting 410 its use to TCP and UDP.) The following diagram illustrates AH 411 transport mode positioning for a typical IPv4 packet, on a "before 412 and after" basis. 414 BEFORE APPLYING AH 415 ---------------------------- 416 IPv4 |orig IP hdr | | | 417 |(any options)| TCP | Data | 418 ---------------------------- 420 AFTER APPLYING AH 421 ------------------------------------------------------- 422 IPv4 |original IP hdr (any options) | AH | TCP | Data | 423 ------------------------------------------------------- 424 |<- mutable field processing ->|<- immutable fields ->| 425 |<----- authenticated except for mutable fields ----->| 427 In the IPv6 context, AH is viewed as an end-to-end payload, and thus 428 should appear after hop-by-hop, routing, and fragmentation extension 429 headers. The destination options extension header(s) could appear 430 before or after or both before and after the AH header depending on 431 the semantics desired. The following diagram illustrates AH 432 transport mode positioning for a typical IPv6 packet. 434 BEFORE APPLYING AH 435 --------------------------------------- 436 IPv6 | | ext hdrs | | | 437 | orig IP hdr |if present| TCP | Data | 438 --------------------------------------- 440 AFTER APPLYING AH 441 ------------------------------------------------------------ 442 IPv6 | |hop-by-hop, dest*, | | dest | | | 443 |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | 444 ------------------------------------------------------------ 445 |<--- mutable field processing -->|<-- immutable fields -->| 446 |<---- authenticated except for mutable fields ----------->| 448 * = if present, could be before AH, after AH, or both 450 ESP and AH headers can be combined in a variety of modes. The IPsec 451 Architecture document describes the combinations of security 452 associations that must be supported. 454 Note that in transport mode, for "bump-in- the-stack" or "bump-in- 455 the-wire" implementations, as defined in the Security Architecture 456 document, inbound and outbound IP fragments may require an IPsec 457 implementation to perform extra IP reassembly/fragmentation in order 458 to both conform to this specification and provide transparent IPsec 459 support. Special care is required to perform such operations within 460 these implementations when multiple interfaces are in use. 462 3.1.2 Tunnel Mode 464 In tunnel mode, the "inner" IP header carries the ultimate (IP) 465 source and destination addresses, while an "outer" IP header contains 466 the addresses of the IPsec "peers," e.g., addresses of security 467 gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 468 over IPv4 and IPv4 over IPv6. In tunnel mode, AH protects the entire 469 inner IP packet, including the entire inner IP header. The position 470 of AH in tunnel mode, relative to the outer IP header, is the same as 471 for AH in transport mode. The following diagram illustrates AH tunnel 472 mode positioning for typical IPv4 and IPv6 packets. 474 ---------------------------------------------------------------- 475 IPv4 | | | orig IP hdr* | | | 476 |new IP header * (any options) | AH | (any options) |TCP| Data | 477 ---------------------------------------------------------------- 478 |<- mutable field processing ->|<------ immutable fields ----->| 479 |<- authenticated except for mutable fields in the new IP hdr->| 481 -------------------------------------------------------------- 482 IPv6 | | ext hdrs*| | | ext hdrs*| | | 483 |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| 484 -------------------------------------------------------------- 485 |<--- mutable field -->|<--------- immutable fields -------->| 486 | processing | 487 |<-- authenticated except for mutable fields in new IP hdr ->| 489 * = if present, construction of outer IP hdr/extensions and 490 modification of inner IP hdr/extensions is discussed in 491 the Security Architecture document. 493 3.2 Integrity Algorithms 495 The integrity algorithm employed for the ICV computation is specified 496 by the SA. For point-to-point communication, suitable integrity 497 algorithms include keyed Message Authentication Codes (MACs) based on 498 symmetric encryption algorithms (e.g., AES [AES]) or on one-way hash 499 functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast 500 communication, a variety of cryptographic strategies for providing 501 integrity have been developed and research continues in this area. 503 3.3 Outbound Packet Processing 505 In transport mode, the sender inserts the AH header after the IP 506 header and before a next layer protocol header, as described above. 507 In tunnel mode, the outer and inner IP header/extensions can be 508 inter-related in a variety of ways. The construction of the outer IP 509 header/extensions during the encapsulation process is described in 510 the Security Architecture document. 512 3.3.1 Security Association Lookup 514 AH is applied to an outbound packet only after an IPsec 515 implementation determines that the packet is associated with an SA 516 that calls for AH processing. The process of determining what, if 517 any, IPsec processing is applied to outbound traffic is described in 518 the Security Architecture document. 520 3.3.2 Sequence Number Generation 522 The sender's counter is initialized to 0 when an SA is established. 523 The sender increments the Sequence Number (or ESN) for this SA and 524 inserts the low-order 32 bits of the value into the Sequence Number 525 field. Thus the first packet sent using a given SA will contain a 526 Sequence Number of 1. 528 If anti-replay is enabled (the default), the sender checks to ensure 529 that the counter has not cycled before inserting the new value in the 530 Sequence Number field. In other words, the sender MUST NOT send a 531 packet on an SA if doing so would cause the Sequence Number to cycle. 532 An attempt to transmit a packet that would result in Sequence Number 533 overflow is an auditable event. The audit log entry for this event 534 SHOULD include the SPI value, current date/time, Source Address, 535 Destination Address, and (in IPv6) the cleartext Flow ID. 537 The sender assumes anti-replay is enabled as a default, unless 538 otherwise notified by the receiver (see 3.4.3) or if the SA was 539 configured using manual key management. Thus typical behavior of an 540 AH implementation calls for the sender to establish a new SA when the 541 Sequence Number (or ESN) cycles, or in anticipation of this value 542 cycling. 544 If anti-replay is disabled (as noted above), the sender does not need 545 to monitor or reset the counter, e.g., in the case of manual key 546 management (see Section 5). However, the sender still increments the 547 counter and when it reaches the maximum value, the counter rolls over 548 back to zero. (This behavior is recommended for multi-sender, 549 multicast SAs, unless anti-replay mechanisms outside the scope of 550 this standard are negotiated between the sender and receiver.) 552 If ESN (see Appendix B) is selected, only the low order 32 bits of 553 the Sequence Number are transmitted in the Sequence Number field, 554 although both sender and receiver maintain full 64-bit ESN counters. 555 However, the high order 32 bits are included in the ICV calculation. 557 3.3.3 Integrity Check Value Calculation 559 The AH ICV is computed over: 560 o IP or extension header fields before the AH header that are 561 either immutable in transit or that are predictable in value 562 upon arrival at the endpoint for the AH SA 563 o the AH header (Next Header, Payload Len, Reserved, SPI, 564 Sequence Number (low order 32 bits), and the Integrity Check 565 Value (which is set to zero for this computation), and 566 explicit padding bytes (if any)) 567 o everything after AH is assumed to be immutable in transit 568 o the high order bits of the ESN (if employed), and any implicit 569 padding required by the integrity algorithm 571 3.3.3.1 Handling Mutable Fields 573 If a field may be modified during transit, the value of the field is 574 set to zero for purposes of the ICV computation. If a field is 575 mutable, but its value at the (IPsec) receiver is predictable, then 576 that value is inserted into the field for purposes of the ICV 577 calculation. The Integrity Check Value field is also set to zero in 578 preparation for this computation. Note that by replacing each 579 field's value with zero, rather than omitting the field, alignment is 580 preserved for the ICV calculation. Also, the zero-fill approach 581 ensures that the length of the fields that are so handled cannot be 582 changed during transit, even though their contents are not explicitly 583 covered by the ICV. 585 As a new extension header or IPv4 option is created, it will be 586 defined in its own RFC and SHOULD include (in the Security 587 Considerations section) directions for how it should be handled when 588 calculating the AH ICV. If the IP (v4 or v6) implementation 589 encounters an extension header that it does not recognize, it will 590 discard the packet and send an ICMP message. IPsec will never see 591 the packet. If the IPsec implementation encounters an IPv4 option 592 that it does not recognize, it should zero the whole option, using 593 the second byte of the option as the length. IPv6 options (in 594 Destination extension headers or the Hop by Hop extension header) 595 contain a flag indicating mutability, which determines appropriate 596 processing for such options. 598 3.3.3.1.1 ICV Computation for IPv4 600 3.3.3.1.1.1 Base Header Fields 602 The IPv4 base header fields are classified as follows: 604 Immutable 605 Version 606 Internet Header Length 607 Total Length 608 Identification 609 Protocol (This should be the value for AH.) 610 Source Address 611 Destination Address (without loose or strict source routing) 613 Mutable but predictable 614 Destination Address (with loose or strict source routing) 616 Mutable (zeroed prior to ICV calculation) 617 DSCP (6 bits, see RFC2474 [NBBB98]) 618 ECN (2 bits, see RFC3168 [RFB01]) 619 Flags 620 Fragment Offset 621 Time to Live (TTL) 622 Header Checksum 624 DSCP - Routers may rewrite the DS field as needed to provide a 625 desired local or end-to-end service, thus its value upon reception 626 cannot be predicted by the sender. 628 ECN - This will change if a router along the route experiences 629 congestion, and thus its value upon reception cannot be predicted by 630 the sender. 632 Flags -- This field is excluded since an intermediate router might 633 set the DF bit, even if the source did not select it. 635 Fragment Offset -- Since AH is applied only to non-fragmented IP 636 packets, the Offset Field must always be zero, and thus it is 637 excluded (even though it is predictable). 639 TTL -- This is changed en-route as a normal course of processing by 640 routers, and thus its value at the receiver is not predictable by the 641 sender. 643 Header Checksum -- This will change if any of these other fields 644 changes, and thus its value upon reception cannot be predicted by the 645 sender. 647 3.3.3.1.1.2 Options 649 For IPv4 (unlike IPv6), there is no mechanism for tagging options as 650 mutable in transit. Hence the IPv4 options are explicitly listed in 651 Appendix A and classified as immutable, mutable but predictable, or 652 mutable. For IPv4, the entire option is viewed as a unit; so even 653 though the type and length fields within most options are immutable 654 in transit, if an option is classified as mutable, the entire option 655 is zeroed for ICV computation purposes. 657 3.3.3.1.2 ICV Computation for IPv6 659 3.3.3.1.2.1 Base Header Fields 661 The IPv6 base header fields are classified as follows: 663 Immutable 664 Version 665 Payload Length 666 Next Header 667 Source Address 668 Destination Address (without Routing Extension Header) 670 Mutable but predictable 671 Destination Address (with Routing Extension Header) 673 Mutable (zeroed prior to ICV calculation) 674 DSCP (6 bits, see RFC2474 [NBBB98]) 675 ECN (2 bits, see RFC3168 [RFB01]) 676 Flow Label (*) 677 Hop Limit 679 (*) The flow label described in AHv1 was mutable, and in 680 RFC 2460 [DH98] was potentially mutable. To retain 681 compatibility with existing AH implementations, the 682 flow label is not included in the ICV in AHv2. 684 3.3.3.1.2.2 Extension Headers Containing Options 686 IPv6 options in the Hop-by-Hop and Destination Extension Headers 687 contain a bit that indicates whether the option might change 688 (unpredictably) during transit. For any option for which contents 689 may change en-route, the entire "Option Data" field must be treated 690 as zero-valued octets when computing or verifying the ICV. The 691 Option Type and Opt Data Len are included in the ICV calculation. 692 All options for which the bit indicates immutability are included in 693 the ICV calculation. See the IPv6 specification [DH98] for more 694 information. 696 3.3.3.1.2.3 Extension Headers Not Containing Options 698 The IPv6 extension headers that do not contain options are explicitly 699 listed in Appendix A and classified as immutable, mutable but 700 predictable, or mutable. 702 3.3.3.2 Padding & Extended Sequence Numbers 704 3.3.3.2.1 ICV Padding 706 As mentioned in section 2.6, the ICV field may include explicit 707 padding if required to ensure that the AH header is a multiple of 32 708 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is 709 determined by two factors: 711 - the length of the ICV 712 - the IP protocol version (v4 or v6) 714 For example, if the output of the selected algorithm is 96-bits, no 715 padding is required for either IPv4 or for IPv6. However, if a 716 different length ICV is generated, due to use of a different 717 algorithm, then padding may be required depending on the length and 718 IP protocol version. The content of the padding field is arbitrarily 719 selected by the sender. (The padding is arbitrary, but need not be 720 random to achieve security.) These padding bytes are included in the 721 ICV calculation, counted as part of the Payload Length, and 722 transmitted at the end of the ICV field to enable the receiver to 723 perform the ICV calculation. 725 3.3.3.2.2 Implicit Packet Padding & ESN 727 If the ESN option is elected for an SA, then the high order 32 bits 728 of the ESN must be included in the ICV computation. For purposes of 729 ICV computation, these bits are appended (implicitly) immediately 730 after the end of the payload, and before any implicit packet padding. 732 For some integrity algorithms, the byte string over which the ICV 733 computation is performed must be a multiple of a blocksize specified 734 by the algorithm. If the IP packet length (including AH and the 32 735 high order bits of the ESN, if enabled) does not match the blocksize 736 requirements for the algorithm, implicit padding MUST be appended to 737 the end of the packet, prior to ICV computation. The padding octets 738 MUST have a value of zero. The blocksize (and hence the length of 739 the padding) is specified by the algorithm specification. This 740 padding is not transmitted with the packet. The document that defines 741 an integrity algorithm MUST be consulted to determine if implicit 742 padding is required as described above. If the document does not 743 specify an answer to this, then the default is to assume that 744 implicit padding is required (as needed to match the packet length to 745 the algorithm's blocksize.) If padding bytes are needed but the 746 algorithm does not specify the padding contents, then the padding 747 octets MUST have a value of zero. 749 3.3.4 Fragmentation 751 If required, IP fragmentation occurs after AH processing within an 752 IPsec implementation. Thus, transport mode AH is applied only to 753 whole IP datagrams (not to IP fragments). An IPv4 packet to which AH 754 has been applied may itself be fragmented by routers en route, and 755 such fragments must be reassembled prior to AH processing at a 756 receiver. (This does not apply to IPv6, where there is no router- 757 initiated fragmentation.) In tunnel mode, AH is applied to an IP 758 packet, the payload of which may be a fragmented IP packet. For 759 example, a security gateway or a "bump-in-the-stack" or "bump-in-the- 760 wire" IPsec implementation (see the Security Architecture document 761 for details) may apply tunnel mode AH to such fragments. 763 NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, 764 bump-in-the-stack and bump-in-the-wire implementations may have to 765 first reassemble a packet fragmented by the local IP layer, then 766 apply IPsec, and then fragment the resulting packet. 768 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 769 implementations, it will be necessary to examine all the extension 770 headers to determine if there is a fragmentation header and hence 771 that the packet needs reassembling prior to IPsec processing. 773 Fragmentation, whether performed by an IPsec implementation or by 774 routers along the path between IPsec peers, significantly reduces 775 performance. Moreover, the requirement for an AH receiver to accept 776 fragments for reassembly creates denial of service vulnerabilities. 777 Thus an AH implementation MAY choose to not support fragmentation and 778 may mark transmitted packets with the DF bit, to facilitate PMTU 779 discovery. In any case, an AH implementation MUST support generation 780 of ICMP PMTU messages (or equivalent internal signaling for native 781 host implementations) to minimize the likelihood of fragmentation. 782 Details of the support required for MTU management are contained in 783 the Security Architecture document. 785 3.4 Inbound Packet Processing 787 If there is more than one IPsec header/extension present, the 788 processing for each one ignores (does not zero, does not use) any 789 IPsec headers applied subsequent to the header being processed. 791 3.4.1 Reassembly 793 If required, reassembly is performed prior to AH processing. If a 794 packet offered to AH for processing appears to be an IP fragment, 795 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 796 the receiver MUST discard the packet; this is an auditable event. The 797 audit log entry for this event SHOULD include the SPI value, 798 date/time, Source Address, Destination Address, and (in IPv6) the 799 Flow ID. 801 NOTE: For packet reassembly, the current IPv4 spec does NOT require 802 either the zeroing of the OFFSET field or the clearing of the MORE 803 FRAGMENTS flag. In order for a reassembled packet to be processed by 804 IPsec (as opposed to discarded as an apparent fragment), the IP code 805 must do these two things after it reassembles a packet. 807 3.4.2 Security Association Lookup 809 Upon receipt of a packet containing an IP Authentication Header, the 810 receiver determines the appropriate (unidirectional) SA via lookup in 811 the SAD. For a unicast SA, this determination is based on the SPI or 812 the SPI plus protocol field, as described in Section 2.4. If an 813 implementation supports multicast traffic, the destination address is 814 also employed in the lookup (in addition to the SPI), and the sender 815 address also may be employed, as described in Section 2.4. (This 816 process is described in more detail in the Security Architecture 817 document.) The SAD entry for the SA also indicates whether the 818 Sequence Number field will be checked, whether 32 or 64-bit Sequence 819 Numbers are employed for the SA, specifies the algorithm(s) employed 820 for ICV computation, and indicates the key required to validate the 821 ICV. 823 If no valid Security Association exists for this packet the receiver 824 MUST discard the packet; this is an auditable event. The audit log 825 entry for this event SHOULD include the SPI value, date/time, Source 826 Address, Destination Address, and (in IPv6) the Flow ID. 828 (Note that SA management traffic, e.g., IKE packets, does not need to 829 be processed based on SPI, i.e., one can demultiplex this traffic 830 separately, e.g., based on Next Protocol and Port fields.) 832 3.4.3 Sequence Number Verification 834 All AH implementations MUST support the anti-replay service, though 835 its use may be enabled or disabled by the receiver on a per-SA basis. 836 Anti-replay is applicable to unicast as well as multicast SAs. 837 However, this standard specifies no mechanisms for providing anti- 838 replay for a multi-sender SA (unicast or multicast). In the absence 839 of negotiation (or manual configuration) of an anti-replay mechanism 840 for such an SA, it is recommended that sender and receiver checking 841 of the sequence number for the SA be disabled (via negotiation or 842 manual configuration), as noted below. 844 If the receiver does not enable anti-replay for an SA, no inbound 845 checks are performed on the Sequence Number. However, from the 846 perspective of the sender, the default is to assume that anti-replay 847 is enabled at the receiver. To avoid having the sender do 848 unnecessary sequence number monitoring and SA setup (see section 849 3.3.2 "Sequence Number Generation"), if an SA establishment protocol 850 such as IKE is employed, the receiver SHOULD notify the sender, 851 during SA establishment, if the receiver will not provide anti- 852 replay protection. 854 If the receiver has enabled the anti-replay service for this SA, the 855 receive packet counter for the SA MUST be initialized to zero when 856 the SA is established. For each received packet, the receiver MUST 857 verify that the packet contains a Sequence Number that does not 858 duplicate the Sequence Number of any other packets received during 859 the life of this SA. This SHOULD be the first AH check applied to a 860 packet after it has been matched to an SA, to speed rejection of 861 duplicate packets. 863 Duplicates are rejected through the use of a sliding receive window. 864 How the window is implemented is a local matter, but the following 865 text describes the functionality that the implementation must 866 exhibit. 868 The "right" edge of the window represents the highest, validated 869 Sequence Number value received on this SA. Packets that contain 870 Sequence Numbers lower than the "left" edge of the window are 871 rejected. Packets falling within the window are checked against a 872 list of received packets within the window. 874 If the ESN option is selected for an SA, only the low-order 32 bits 875 of the sequence number are explicitly transmitted; but the receiver 876 employs the full sequence number computed using the high-order 32 877 bits for the indicated SA (from his local counter) when checking the 878 received Sequence Number against the receive window. In constructing 879 the full Sequence Number, if the low order 32 bits carried in the 880 packet are lower in value than the low order 32 bits of the 881 receiver's Sequence Number, the receiver assumes that the high order 882 32 bits have been incremented, moving to a new sequence number 883 subspace. (This algorithm accommodates gaps in reception for a single 884 SA as large as 2**32-1 packets. If a larger gap occurs, additional, 885 heuristic checks for resynchronization of the receiver's Sequence 886 Number counter MAY be employed, as described in Appendix B.) 888 If the received packet falls within the window and is not a 889 duplicate, or if the packet is to the right of the window, then the 890 receiver proceeds to ICV verification. If the ICV validation fails, 891 the receiver MUST discard the received IP datagram as invalid. This 892 is an auditable event. The audit log entry for this event SHOULD 893 include the SPI value, date/time, Source Address, Destination 894 Address, the Sequence Number, and (in IPv6) the Flow ID. The receive 895 window is updated only if the ICV verification succeeds. 897 A MINIMUM window size of 32 packets MUST be supported; but a window 898 size of 64 is preferred and SHOULD be employed as the default. 899 Another window size (larger than the MINIMUM) MAY be chosen by the 900 receiver. (The receiver does NOT notify the sender of the window 901 size.) The receive window size should be increased for higher speed 902 environments, irrespective of assurance issues. Values for minimum 903 and recommended receive window sizes for very high speed (e.g., 904 multi-gigabit/second) devices are not specified by this standard. 906 3.4.4 Integrity Check Value Verification 908 The receiver computes the ICV over the appropriate fields of the 909 packet, using the specified integrity algorithm, and verifies that it 910 is the same as the ICV included in the ICV field of the packet. 911 Details of the computation are provided below. 913 If the computed and received ICV's match, then the datagram is valid, 914 and it is accepted. If the test fails, then the receiver MUST 915 discard the received IP datagram as invalid. This is an auditable 916 event. The audit log entry SHOULD include the SPI value, date/time 917 received, Source Address, Destination Address, and (in IPv6) the Flow 918 ID. 920 Implementation Note: 922 Implementations can use any set of steps that results in the same 923 result as the following set of steps. Begin by saving the ICV 924 value and replacing it (but not any ICV field padding) with zero. 925 Zero all other fields that may have been modified during transit. 926 (See section 3.3.3.1, "Handling Mutable Fields", for a discussion 927 of which fields are zeroed before performing the ICV calculation.) 928 If the ESN option is elected for this SA, append the high order 32 929 bits of the ESN after the end of the packet. Check the overall 930 length of the packet (as described above), and if it requires 931 implicit padding based on the requirements of the integrity 932 algorithm, append zero-filled bytes to the end of the packet 933 (after the ESN if present) as required. Perform the ICV 934 computation and compare the result with the saved value, using the 935 comparison rules defined by the algorithm specification. (For 936 example, if a digital signature and one-way hash are used for the 937 ICV computation, the matching process is more complex.) 939 4. Auditing 941 Not all systems that implement AH will implement auditing. However, 942 if AH is incorporated into a system that supports auditing, then the 943 AH implementation MUST also support auditing and MUST allow a system 944 administrator to enable or disable auditing for AH. For the most 945 part, the granularity of auditing is a local matter. However, 946 several auditable events are identified in this specification and for 947 each of these events a minimum set of information that SHOULD be 948 included in an audit log is defined. Additional information also MAY 949 be included in the audit log for each of these events, and additional 950 events, not explicitly called out in this specification, also MAY 951 result in audit log entries. There is no requirement for the 952 receiver to transmit any message to the purported sender in response 953 to the detection of an auditable event, because of the potential to 954 induce denial of service via such action. 956 5. Conformance Requirements 958 Implementations that claim conformance or compliance with this 959 specification MUST fully implement the AH syntax and processing 960 described here for unicast traffic, and MUST comply with all 961 requirements of the Security Architecture document [Ken-Arch]. 962 Additionally, if an implementation claims to support multicast 963 traffic, it MUST comply with the additional requirements specified 964 for support of such traffic. If the key used to compute an ICV is 965 manually distributed, correct provision of the anti-replay service 966 would require correct maintenance of the counter state at the sender, 967 until the key is replaced, and there likely would be no automated 968 recovery provision if counter overflow were imminent. Thus a 969 compliant implementation SHOULD NOT provide this service in 970 conjunction with SAs that are manually keyed. 972 The mandatory-to-implement algorithms for use with AH are described 973 in a separate RFC [Eas04], to facilitate updating the algorithm 974 requirements independently from the protocol per se. Additional 975 algorithms, beyond those mandated for AH, MAY be supported. 977 6. Security Considerations 979 Security is central to the design of this protocol, and these 980 security considerations permeate the specification. Additional 981 security-relevant aspects of using the IPsec protocol are discussed 982 in the Security Architecture document. 984 7. Differences from RFC 2402 986 This document differs from RFC 2402 in the following ways. 988 o SPI -- modified to specify a uniform algorithm for SAD lookup 989 for unicast and multicast SAs, covering a wider range of 990 multicast technologies. For unicast, the SPI may be used alone 991 to select an SA, or may be combined with the protocol, at the 992 option of the receiver. For multicast SAs, the SPI is 993 combined with the destination address, and optionally the 994 source address, to select an SA. 995 o Sequence number -- added a new option for a 64-bit sequence 996 number for very high-speed communications. Clarified sender 997 and receiver processing requirements for multicast SAs and 998 multi-sender SAs. 999 o Moved references to mandatory algorithms to a separate 1000 document [Eas04]. 1002 Acknowledgements 1004 The author would like to acknowledge the contributions of Ran 1005 Atkinson, who played a critical role in initial IPsec activities, and 1006 who authored the first series of IPsec standards: RFCs 1825-1827. 1007 Karen Seo deserves special thanks for providing help in the editing 1008 of this and the previous version of this specification. The author 1009 also would like to thank the members of the IPsec and MSEC working 1010 groups who have contributed to the development of this protocol 1011 specification. 1013 References 1015 Normative 1017 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 1018 Requirement Level", BCP 14, RFC 2119, March 1997. 1020 [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 1021 (IPv6) Specification", RFC 2460, December 1998. 1023 [Eas04] Eastlake, D., "Cryptographic Algorithm Implementation 1024 Requirements For ESP And AH", RFC ???, ??? 200? 1026 [Ken-Arch]Kent, S., and Seo, K., "Security Architecture for the 1027 Internet Protocol", RFC ???, ??? 200?. 1029 [Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1030 1981 1032 Informative 1034 [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for 1035 IP", Internet-Draft, draft-ietf-ssm-arch-01.txt, November 1036 3, 2002. 1038 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange 1039 (IKE)", RFC 2409, November 1998. 1041 [Ken-AH] Kent, S., "IP Authentication Header (AH)", RFC ???, ??? 1042 200?. 1044 [Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1045 ???, ???? 200?. 1047 [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1048 of the Differentiated Services Field (DS Field) in the IPv4 1049 and IPv6 Headers", RFC 2474, December 1998. 1051 [RFB01] Ramakrishnan, K., Floyd S., Black D., "The Addition of 1052 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1053 September 2001. 1055 [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group 1056 Domain of Interpretation", RFC 3547, July 2003. 1058 [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security 1059 Architecture", RFC 3740, March 2004. 1061 Author Information 1063 Stephen Kent 1064 BBN Technologies 1065 10 Moulton Street 1066 Cambridge, MA 02138 1067 USA 1068 Phone: +1 (617) 873-3988 1069 EMail: kent@bbn.com 1071 Appendix A -- Mutability of IP Options/Extension Headers 1073 A1. IPv4 Options 1075 This table shows how the IPv4 options are classified with regard to 1076 "mutability". Where two references are provided, the second one 1077 supercedes the first. This table is based in part on information 1078 provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). 1080 Opt. 1081 Copy Class # Name Reference 1082 ---- ----- --- ------------------------- -------- 1083 IMMUTABLE -- included in ICV calculation 1084 0 0 0 End of Options List [RFC791] 1085 0 0 1 No Operation [RFC791] 1086 1 0 2 Security [RFC1108(historic but 1087 in use)] 1088 1 0 5 Extended Security [RFC1108(historic but 1089 in use)] 1090 1 0 6 Commercial Security [expired I-D, now US MIL 1091 STD] 1092 1 0 20 Router Alert [RFC2113] 1093 1 0 21 Sender Directed Multi- [RFC1770] 1094 Destination Delivery 1095 MUTABLE -- zeroed 1096 1 0 3 Loose Source Route [RFC791] 1097 0 2 4 Time Stamp [RFC791] 1098 0 0 7 Record Route [RFC791] 1099 1 0 9 Strict Source Route [RFC791] 1100 0 2 18 Traceroute [RFC1393] 1102 EXPERIMENTAL, SUPERCEDED -- zeroed 1103 1 0 8 Stream ID [RFC791, RFC1122 (Host 1104 Req)] 1105 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 1106 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1107 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 1108 0 0 10 Experimental Measurement [ZSu] 1109 1 2 13 Experimental Flow Control [Finn] 1110 1 0 14 Experimental Access Ctl [Estrin] 1111 0 0 15 ??? [VerSteeg] 1112 1 0 16 IMI Traffic Descriptor [Lee] 1113 1 0 19 Address Extension [Ullmann IPv7] 1115 NOTE: Use of the Router Alert option is potentially incompatible with 1116 use of IPsec. Although the option is immutable, its use implies that 1117 each router along a packet's path will "process" the packet and 1118 consequently might change the packet. This would happen on a hop by 1119 hop basis as the packet goes from router to router. Prior to being 1120 processed by the application to which the option contents are 1121 directed, e.g., RSVP/IGMP, the packet should encounter AH processing. 1122 However, AH processing would require that each router along the path 1123 is a member of a multicast-SA defined by the SPI. This might pose 1124 problems for packets that are not strictly source routed, and it 1125 requires multicast support techniques not currently available. 1127 NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by 1128 systems along a packet's path conflicts with the classification of 1129 these IP Options as immutable and is incompatible with the use of 1130 IPsec. 1132 NOTE: End of Options List options SHOULD be repeated as necessary to 1133 ensure that the IP header ends on a 4 byte boundary in order to 1134 ensure that there are no unspecified bytes which could be used for a 1135 covert channel. 1137 A2. IPv6 Extension Headers 1139 This table shows how the IPv6 Extension Headers are classified with 1140 regard to "mutability". 1142 Option/Extension Name Reference 1143 ----------------------------------- --------- 1144 MUTABLE BUT PREDICTABLE -- included in ICV calculation 1145 Routing (Type 0) [DH98] 1147 BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING 1148 TRANSIT) 1149 Hop by Hop options [DH98] 1150 Destination options [DH98] 1152 NOT APPLICABLE 1153 Fragmentation [DH98] 1155 Options -- IPv6 options in the Hop-by-Hop and Destination 1156 Extension Headers contain a bit that indicates whether the option 1157 might change (unpredictably) during transit. For any option for 1158 which contents may change en-route, the entire "Option Data" field 1159 must be treated as zero-valued octets when computing or verifying 1160 the ICV. The Option Type and Opt Data Len are included in the ICV 1161 calculation. All options for which the bit indicates immutability 1162 are included in the ICV calculation. See the IPv6 specification 1163 [DH98] for more information. 1165 Routing (Type 0) -- The IPv6 Routing Header "Type 0" will 1166 rearrange the address fields within the packet during transit from 1167 source to destination. However, the contents of the packet as it 1168 will appear at the receiver are known to the sender and to all 1169 intermediate hops. Hence, the IPv6 Routing Header "Type 0" is 1170 included in the Integrity Check Value calculation as mutable but 1171 predictable. The sender must order the field so that it appears as 1172 it will at the receiver, prior to performing the ICV computation. 1174 Fragmentation -- Fragmentation occurs after outbound IPsec 1175 processing (section 3.3) and reassembly occurs before inbound IPsec 1176 processing (section 3.4). So the Fragmentation Extension Header, if 1177 it exists, is not seen by IPsec. 1179 Note that on the receive side, the IP implementation could 1180 leave a Fragmentation Extension Header in place when it does re- 1181 assembly. If this happens, then when AH receives the packet, before 1182 doing ICV processing, AH MUST "remove" (or skip over) this header 1183 and change the previous header's "Next Header" field to be the "Next 1184 Header" field in the Fragmentation Extension Header. 1186 Note that on the send side, the IP implementation could give 1187 the IPsec code a packet with a Fragmentation Extension Header with 1188 Offset of 0 (first fragment) and a More Fragments Flag of 0 (last 1189 fragment). If this happens, then before doing ICV processing, AH 1190 MUST first "remove" (or skip over) this header and change the 1191 previous header's "Next Header" field to be the "Next Header" field 1192 in the Fragmentation Extension Header. 1194 Appendix B -- Extended (64-bit) Sequence Numbers 1196 B1. Overview 1198 This appendix describes an extended sequence number (ESN) scheme for 1199 use with IPsec (ESP and AH) that employs a 64-bit sequence number, 1200 but in which only the low order 32 bits are transmitted as part of 1201 each packet. It covers both the window scheme used to detect 1202 replayed packets and the determination of the high order bits of the 1203 sequence number that are used both for replay rejection and for 1204 computation of the ICV. It also discusses a mechanism for handling 1205 loss of synchronization relative to the (not transmitted) high order 1206 bits. 1208 B2. Anti-Replay Window 1210 The receiver will maintain an anti-replay window of size W. This 1211 window will limit how far out of order a packet can be, relative to 1212 the packet with the highest sequence number that has been 1213 authenticated so far. (No requirement is established for minimum or 1214 recommended sizes for this window, beyond the 32 and 64-packet values 1215 already established for 32-bit sequence number windows. However, it 1216 is suggested that an implementer scale these values consistent with 1217 the interface speed supported by an implementation that makes use of 1218 the ESN option. Also, the algorithm described below assumes that the 1219 window is no greater than 2^31 packets in width.) All 2^32 sequence 1220 numbers associated with any fixed value for the high order 32 bits 1221 (Seqh) will hereafter be called a sequence number subspace. The 1222 following table lists pertinent variables and their definitions. 1224 Var. Size 1225 Name (bits) Meaning 1226 ---- ------ --------------------------- 1227 W 32 Size of window 1228 T 64 Highest sequence number authenticated so far, 1229 upper bound of window 1230 Tl 32 Lower 32 bits of T 1231 Th 32 Upper 32 bits of T 1232 B 64 Lower bound of window 1233 Bl 32 Lower 32 bits of B 1234 Bh 32 Upper 32 bits of B 1235 Seq 64 Sequence number of received packet 1236 Seql 32 Lower 32 bits of Seq 1237 Seqh 32 Upper 32 bits of Seq 1239 When performing the anti-replay check, or when determining which high 1240 order bits to use to authenticate an incoming packet, there are two 1241 cases: 1243 + Case A: Tl >= (W - 1). In this case, the window is within one 1244 sequence number subspace. (See Figure 1) 1245 + Case B: Tl < (W - 1). In this case, the window spans two 1246 sequence number subspaces. (See Figure 2) 1248 In the figures below, the bottom line ("----") shows two consecutive 1249 sequence number subspaces, with zero's indicating the beginning of 1250 each subspace. The two shorter lines above it show the higher order 1251 bits that apply. The "====" represents the window. The "****" 1252 represents future sequence numbers, i.e., those beyond the current 1253 highest sequence number authenticated (ThTl). 1255 Th+1 ********* 1257 Th =======***** 1259 --0--------+-----+-----0--------+-----------0-- 1260 Bl Tl Bl 1261 (Bl+2^32) mod 2^32 1263 Figure 1 -- Case A 1265 Th ====************** 1267 Th-1 === 1269 --0-----------------+--0--+--------------+--0-- 1270 Bl Tl Bl 1271 (Bl+2^32) mod 2^32 1273 Figure 2 -- Case B 1275 B2.1. Managing and Using the Anti-Replay Window 1277 The anti-replay window can be thought of as a string of bits where 1278 `W' defines the length of the string. W = T - B + 1 and cannot 1279 exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and 1280 the top-most bit corresponds to T and each sequence number from Bl 1281 through Tl is represented by a corresponding bit. The value of the 1282 bit indicates whether or not a packet with that sequence number has 1283 been received and authenticated, so that replays can be detected and 1284 rejected. 1286 When a packet with a 64-bit sequence number (Seq) greater than T is 1287 received and validated, 1288 + B is increased by (Seq - T) 1289 + (Seq - T) bits are dropped from the low end of the window 1290 + (Seq - T) bits are added to the high end of the window 1291 + The top bit is set to indicate that a packet with that sequence 1292 number has been received and authenticated 1293 + The new bits between T and the top bit are set to indicate that 1294 no packets with those sequence numbers have been received yet. 1295 + T is set to the new sequence number 1297 In checking for replayed packets, 1299 + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND 1300 Seql <= Tl, then check the corresponding bit in the window to see 1301 if this Seql has already been seen. If yes, reject the packet. 1302 If no, perform integrity check (see Section 2.2. below for 1303 determination of SeqH). 1305 + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR 1306 Seql <= Tl, then check the corresponding bit in the window to see 1307 if this Seql has already been seen. If yes, reject the packet. 1308 If no, perform integrity check (see Section 2.2. below for 1309 determination of Seqh). 1311 B2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number 1313 Since only `Seql' will be transmitted with the packet, the receiver 1314 must deduce and track the sequence number subspace into which each 1315 packet falls, i.e., determine the value of Seqh. The following 1316 equations define how to select Seqh under "normal" conditions; see 1317 Section 3 for a discussion of how to recover from extreme packet 1318 loss. 1320 + Under Case A (Figure 1): 1321 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th 1322 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1 1324 + Under Case B (Figure 2): 1325 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 1326 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th 1328 B2.3. Pseudo-code Example 1330 The following pseudo-code illustrates the above algorithms for anti- 1331 replay and integrity checks. The values for `Seql', `Tl', `Th' and 1332 `W', are 32-bit unsigned integers. Arithmetic is mod 2^32. 1334 If (Tl >= W - 1) Case A 1335 If (Seql >= Tl - W + 1) 1336 Seqh = Th 1337 If (Seql <= Tl) 1338 If (pass replay check) 1339 If (pass integrity check) 1340 Set bit corresponding to Seql 1341 Pass the packet on 1342 Else reject packet 1343 Else reject packet 1344 Else 1345 If (pass integrity check) 1346 Tl = Seql (shift bits) 1347 Set bit corresponding to Seql 1348 Pass the packet on 1349 Else reject packet 1350 Else 1351 Seqh = Th + 1 1352 If (pass integrity check) 1353 Tl = Seql (shift bits) 1354 Th = Th + 1 1355 Set bit corresponding to Seql 1356 Pass the packet on 1357 Else reject packet 1358 Else Case B 1359 If (Seql >= Tl - W + 1) 1360 Seqh = Th - 1 1361 If (pass replay check) 1362 If (pass integrity check) 1363 Set the bit corresponding to Seql 1364 Pass packet on 1365 Else reject packet 1366 Else reject packet 1367 Else 1368 Seqh = Th 1369 If (Seql <= Tl) 1370 If (pass replay check) 1371 If (pass integrity check) 1372 Set the bit corresponding to Seql 1373 Pass packet on 1374 Else reject packet 1375 Else reject packet 1376 Else 1377 If (pass integrity check) 1378 Tl = Seql (shift bits) 1379 Set the bit corresponding to Seql 1380 Pass packet on 1381 Else reject packet 1383 B3. Handling Loss of Synchronization due to Significant Packet Loss 1385 If there is an undetected packet loss of 2^32 or more consecutive 1386 packets on a single SA, then the transmitter and receiver will lose 1387 synchronization of the high order bits, i.e., the equations in 1388 Section 2.2. will fail to yield the correct value. Unless this 1389 problem is detected and addressed, subsequent packets on this SA will 1390 fail authentication checks and be discarded. The following procedure 1391 SHOULD be implemented by any IPsec (ESP or AH) implementation that 1392 supports the ESN option. 1394 Note that this sort of extended traffic loss seems unlikely to occur 1395 if any significant fraction of the traffic on the SA in question is 1396 TCP, because the source would fail to receive ACKs and would stop 1397 sending long before 2^32 packets had been lost. Also, for any bi- 1398 directional application, even ones operating above UDP, such an 1399 extended outage would likely result in triggering some form of 1400 timeout. However, a unidirectional application, operating over UDP 1401 might lack feedback that would cause automatic detection of a loss of 1402 this magnitude, hence the motivation to develop a recovery method for 1403 this case. 1405 The solution we've chosen was selected to: 1407 + minimize the impact on normal traffic processing 1409 + avoid creating an opportunity for a new denial of service attack 1410 such as might occur by allowing an attacker to force diversion of 1411 resources to a resynchronization process. 1413 + limit the recovery mechanism to the receiver -- since anti-replay 1414 is a service only for the receiver, and the transmitter generally 1415 is not aware of whether the receiver is using sequence numbers in 1416 support of this optional service, it is preferable for recovery 1417 mechanisms to be local to the receiver. This also allows for 1418 backwards compatibility. 1420 B3.1. Triggering Resynchronization 1422 For each SA, the receiver records the number of consecutive packets 1423 that fail authentication. This count is used to trigger the 1424 resynchronization process which should be performed in the background 1425 or using a separate processor. Receipt of a valid packet on the SA 1426 resets the counter to zero. The value used to trigger the 1427 resynchronization process is a local parameter. There is no 1428 requirement to support distinct trigger values for different SAs, 1429 although an implementer may choose to do so. 1431 B3.2. Resynchronization Process 1433 When the above trigger point is reached, a "bad" packet is selected 1434 for which authentication is retried using successively larger values 1436 for the upper half of the sequence number (Seqh). These values are 1437 generated by incrementing by one for each retry. The number of 1438 retries should be limited, in case this is a packet from the "past" 1439 or a bogus packet. The limit value is a local parameter. (Because 1440 the Seqh value is implicitly placed after the AH (or ESP) payload, it 1441 may be possible to optimize this procedure by executing the integrity 1442 algorithm over the packet up to the end point of the payload, then 1443 compute different candidate ICV's by varying the value of Seqh.) 1444 Successful authentication of a packet via this procedure resets the 1445 consecutive failure count and sets the value of T to that of the 1446 received packet. 1448 This solution requires support only on the part of the receiver, 1449 thereby allowing for backwards compatibility. Also, because 1450 resynchronization efforts would either occur in the background or 1451 utilize an additional processor, this solution does not impact 1452 traffic processing and a denial of service attack cannot divert 1453 resources away from traffic processing. 1455 Notices 1457 The IETF takes no position regarding the validity or scope of any 1458 intellectual property or other rights that might be claimed to 1459 pertain to the implementation or use of the technology described in 1460 this document or the extent to which any license under such rights 1461 might or might not be available; neither does it represent that it 1462 has made any effort to identify any such rights. Information on the 1463 IETF's procedures with respect to rights in standards-track and 1464 standards- related documentation can be found in BCP-11. Copies of 1465 claims of rights made available for publication and any assurances of 1466 licenses to be made available, or the result of an attempt made to 1467 obtain a general license or permission for the use of such 1468 proprietary rights by implementers or users of this specification can 1469 be obtained from the IETF Secretariat. 1471 The IETF invites any interested party to bring to its attention any 1472 copyrights, patents or patent applications, or other proprietary 1473 rights which may cover technology that may be required to practice 1474 this standard. Please address the information to the IETF Executive 1475 Director. 1477 Copyright (C) The Internet Society (2004). This document is subject 1478 to the rights, licenses and restrictions contained in BCP 78, and 1479 except as set forth therein, the authors retain all their rights. 1481 This document is subject to the rights, licenses and restrictions 1482 contained in BCP 78, and except as set forth therein, the authors 1483 retain all their rights. 1485 This document and translations of it may be copied and furnished to 1486 others, and derivative works that comment on or otherwise explain it 1487 or assist in its implementation may be prepared, copied, published 1488 and distributed, in whole or in part, without restriction of any 1489 kind, provided that the above copyright notice and this paragraph are 1490 included on all such copies and derivative works. However, this 1491 document itself may not be modified in any way, such as by removing 1492 the copyright notice or references to the Internet Society or other 1493 Internet organizations, except as needed for the purpose of 1494 developing Internet standards in which case the procedures for 1495 copyrights defined in the Internet Standards process must be 1496 followed, or as required to translate it into languages other than 1497 English. 1499 The limited permissions granted above are perpetual and will not be 1500 revoked by the Internet Society or its successors or assigns. 1502 This document and the information contained herein are provided on an 1503 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1504 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1505 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1506 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1507 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1508 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1510 Expires April 2005