idnits 2.17.1 draft-ietf-ipsec-rfc2402bis-11.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 1530. ** 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 833 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 (September 2005) is 6791 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 1044, 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 499, but not defined == Missing Reference: 'RFC791' is mentioned on line 1121, but not defined == Missing Reference: 'RFC2113' is mentioned on line 1114, but not defined == Missing Reference: 'RFC1770' is mentioned on line 1115, but not defined ** Obsolete undefined reference: RFC 1770 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1393' is mentioned on line 1122, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'ZSu' is mentioned on line 1130, but not defined == Missing Reference: 'Finn' is mentioned on line 1131, but not defined == Missing Reference: 'Estrin' is mentioned on line 1132, but not defined == Missing Reference: 'VerSteeg' is mentioned on line 1133, but not defined == Missing Reference: 'Lee' is mentioned on line 1134, but not defined == Unused Reference: 'Pos81' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'HC98' is defined on line 1058, 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-11.txt March 2005 4 Obsoletes: RFC 2402 5 Expires September 2005 7 IP Authentication Header 8 draft-ietf-ipsec-rfc2402bis-11.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 (2005). 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......................................................5 49 2.4 Security Parameters Index (SPI)...............................6 50 2.5 Sequence Number...............................................7 51 2.5.1 Extended (64-bit) Sequence Number........................8 52 2.6 Integrity Check Value (ICV) ..................................8 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......................13 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.....................15 67 3.3.3.1.2.1 Base Header Fields.......................15 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...............16 71 3.3.3.2.1 ICV Padding..................................16 72 3.3.3.2.2 Implicit Packet Padding & ESN................16 73 3.3.4 Fragmentation..........................................17 74 3.4 Inbound Packet Processing...................................17 75 3.4.1 Reassembly.............................................18 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..........................................................21 80 5. Conformance Requirements..........................................21 81 6. Security Considerations...........................................21 82 7. Differences from RFC 2402.........................................22 83 Acknowledgements.....................................................22 84 References...........................................................22 85 Author Information...................................................24 86 Appendix A -- Mutability of IP Options/Extension Headers.............25 87 A1. IPv4 Options.................................................25 88 A2. IPv6 Extension Headers.......................................26 89 Appendix B -- Extended (64-bit) Sequence Numbers.....................28 90 Notices..............................................................34 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), the concept of Security Associations, the 101 ways in which ESP can be used in conjunction with the Authentication 102 Header (AH), and the different key management options available for 103 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 and MUST 389 insert only enough padding to satisfy the IPv4/IPv6 alignment 390 requirements. Details of how to compute the required padding length 391 are provided below in Section 3.3.3.2 "Padding". The integrity 392 algorithm specification MUST specify the length of the ICV and the 393 comparison rules and 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 Note: If a receiver chooses to not enable anti-replay for an SA, then 559 the receiver SHOULD NOT negotiate ESN in an SA management protocol. 560 Use of ESN creates a need for the receiver to manage the anti-replay 561 window (in order to determine the correct value for the high order 562 bits of the ESN, which are employed in the ICV computation), which is 563 generally contrary to the notion of disabling anti-replay for an SA. 565 3.3.3 Integrity Check Value Calculation 567 The AH ICV is computed over: 568 o IP or extension header fields before the AH header that are 569 either immutable in transit or that are predictable in value 570 upon arrival at the endpoint for the AH SA 571 o the AH header (Next Header, Payload Len, Reserved, SPI, 572 Sequence Number (low order 32 bits), and the Integrity Check 573 Value (which is set to zero for this computation), and 574 explicit padding bytes (if any)) 575 o everything after AH is assumed to be immutable in transit 576 o the high order bits of the ESN (if employed), and any implicit 577 padding required by the integrity algorithm 579 3.3.3.1 Handling Mutable Fields 581 If a field may be modified during transit, the value of the field is 582 set to zero for purposes of the ICV computation. If a field is 583 mutable, but its value at the (IPsec) receiver is predictable, then 584 that value is inserted into the field for purposes of the ICV 585 calculation. The Integrity Check Value field is also set to zero in 586 preparation for this computation. Note that by replacing each 587 field's value with zero, rather than omitting the field, alignment is 588 preserved for the ICV calculation. Also, the zero-fill approach 589 ensures that the length of the fields that are so handled cannot be 590 changed during transit, even though their contents are not explicitly 591 covered by the ICV. 593 As a new extension header or IPv4 option is created, it will be 594 defined in its own RFC and SHOULD include (in the Security 595 Considerations section) directions for how it should be handled when 596 calculating the AH ICV. If the IP (v4 or v6) implementation 597 encounters an extension header that it does not recognize, it will 598 discard the packet and send an ICMP message. IPsec will never see 599 the packet. If the IPsec implementation encounters an IPv4 option 600 that it does not recognize, it should zero the whole option, using 601 the second byte of the option as the length. IPv6 options (in 602 Destination extension headers or the Hop by Hop extension header) 603 contain a flag indicating mutability, which determines appropriate 604 processing for such options. 606 3.3.3.1.1 ICV Computation for IPv4 608 3.3.3.1.1.1 Base Header Fields 610 The IPv4 base header fields are classified as follows: 612 Immutable 613 Version 614 Internet Header Length 615 Total Length 616 Identification 617 Protocol (This should be the value for AH.) 618 Source Address 619 Destination Address (without loose or strict source routing) 621 Mutable but predictable 622 Destination Address (with loose or strict source routing) 624 Mutable (zeroed prior to ICV calculation) 625 DSCP (6 bits, see RFC2474 [NBBB98]) 626 ECN (2 bits, see RFC3168 [RFB01]) 627 Flags 628 Fragment Offset 629 Time to Live (TTL) 630 Header Checksum 632 DSCP - Routers may rewrite the DS field as needed to provide a 633 desired local or end-to-end service, thus its value upon reception 634 cannot be predicted by the sender. 636 ECN - This will change if a router along the route experiences 637 congestion, and thus its value upon reception cannot be predicted by 638 the sender. 640 Flags -- This field is excluded since an intermediate router might 641 set the DF bit, even if the source did not select it. 643 Fragment Offset -- Since AH is applied only to non-fragmented IP 644 packets, the Offset Field must always be zero, and thus it is 645 excluded (even though it is predictable). 647 TTL -- This is changed en-route as a normal course of processing by 648 routers, and thus its value at the receiver is not predictable by the 649 sender. 651 Header Checksum -- This will change if any of these other fields 652 changes, and thus its value upon reception cannot be predicted by the 653 sender. 655 3.3.3.1.1.2 Options 657 For IPv4 (unlike IPv6), there is no mechanism for tagging options as 658 mutable in transit. Hence the IPv4 options are explicitly listed in 659 Appendix A and classified as immutable, mutable but predictable, or 660 mutable. For IPv4, the entire option is viewed as a unit; so even 661 though the type and length fields within most options are immutable 662 in transit, if an option is classified as mutable, the entire option 663 is zeroed for ICV computation purposes. 665 3.3.3.1.2 ICV Computation for IPv6 667 3.3.3.1.2.1 Base Header Fields 669 The IPv6 base header fields are classified as follows: 671 Immutable 672 Version 673 Payload Length 674 Next Header 675 Source Address 676 Destination Address (without Routing Extension Header) 678 Mutable but predictable 679 Destination Address (with Routing Extension Header) 681 Mutable (zeroed prior to ICV calculation) 682 DSCP (6 bits, see RFC2474 [NBBB98]) 683 ECN (2 bits, see RFC3168 [RFB01]) 684 Flow Label (*) 685 Hop Limit 687 (*) The flow label described in AHv1 was mutable, and in 688 RFC 2460 [DH98] was potentially mutable. To retain 689 compatibility with existing AH implementations, the 690 flow label is not included in the ICV in AHv2. 692 3.3.3.1.2.2 Extension Headers Containing Options 694 IPv6 options in the Hop-by-Hop and Destination Extension Headers 695 contain a bit that indicates whether the option might change 696 (unpredictably) during transit. For any option for which contents 697 may change en-route, the entire "Option Data" field must be treated 698 as zero-valued octets when computing or verifying the ICV. The 699 Option Type and Opt Data Len are included in the ICV calculation. 700 All options for which the bit indicates immutability are included in 701 the ICV calculation. See the IPv6 specification [DH98] for more 702 information. 704 3.3.3.1.2.3 Extension Headers Not Containing Options 706 The IPv6 extension headers that do not contain options are explicitly 707 listed in Appendix A and classified as immutable, mutable but 708 predictable, or mutable. 710 3.3.3.2 Padding & Extended Sequence Numbers 712 3.3.3.2.1 ICV Padding 714 As mentioned in section 2.6, the ICV field may include explicit 715 padding if required to ensure that the AH header is a multiple of 32 716 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is 717 determined by two factors: 719 - the length of the ICV 720 - the IP protocol version (v4 or v6) 722 For example, if the output of the selected algorithm is 96-bits, no 723 padding is required for either IPv4 or for IPv6. However, if a 724 different length ICV is generated, due to use of a different 725 algorithm, then padding may be required depending on the length and 726 IP protocol version. The content of the padding field is arbitrarily 727 selected by the sender. (The padding is arbitrary, but need not be 728 random to achieve security.) These padding bytes are included in the 729 ICV calculation, counted as part of the Payload Length, and 730 transmitted at the end of the ICV field to enable the receiver to 731 perform the ICV calculation. Inclusion of padding in excess of the 732 minimum amount required to satisfy IPv4/IPv6 alignment requirements 733 is prohibited. 735 3.3.3.2.2 Implicit Packet Padding & ESN 737 If the ESN option is elected for an SA, then the high order 32 bits 738 of the ESN must be included in the ICV computation. For purposes of 739 ICV computation, these bits are appended (implicitly) immediately 740 after the end of the payload, and before any implicit packet padding. 742 For some integrity algorithms, the byte string over which the ICV 743 computation is performed must be a multiple of a blocksize specified 744 by the algorithm. If the IP packet length (including AH and the 32 745 high order bits of the ESN, if enabled) does not match the blocksize 746 requirements for the algorithm, implicit padding MUST be appended to 747 the end of the packet, prior to ICV computation. The padding octets 748 MUST have a value of zero. The blocksize (and hence the length of 749 the padding) is specified by the algorithm specification. This 750 padding is not transmitted with the packet. The document that defines 751 an integrity algorithm MUST be consulted to determine if implicit 752 padding is required as described above. If the document does not 753 specify an answer to this, then the default is to assume that 754 implicit padding is required (as needed to match the packet length to 755 the algorithm's blocksize.) If padding bytes are needed but the 756 algorithm does not specify the padding contents, then the padding 757 octets MUST have a value of zero. 759 3.3.4 Fragmentation 761 If required, IP fragmentation occurs after AH processing within an 762 IPsec implementation. Thus, transport mode AH is applied only to 763 whole IP datagrams (not to IP fragments). An IPv4 packet to which AH 764 has been applied may itself be fragmented by routers en route, and 765 such fragments must be reassembled prior to AH processing at a 766 receiver. (This does not apply to IPv6, where there is no router- 767 initiated fragmentation.) In tunnel mode, AH is applied to an IP 768 packet, the payload of which may be a fragmented IP packet. For 769 example, a security gateway or a "bump-in-the-stack" or "bump-in-the- 770 wire" IPsec implementation (see the Security Architecture document 771 for details) may apply tunnel mode AH to such fragments. 773 NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, 774 bump-in-the-stack and bump-in-the-wire implementations may have to 775 first reassemble a packet fragmented by the local IP layer, then 776 apply IPsec, and then fragment the resulting packet. 778 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 779 implementations, it will be necessary to examine all the extension 780 headers to determine if there is a fragmentation header and hence 781 that the packet needs reassembling prior to IPsec processing. 783 Fragmentation, whether performed by an IPsec implementation or by 784 routers along the path between IPsec peers, significantly reduces 785 performance. Moreover, the requirement for an AH receiver to accept 786 fragments for reassembly creates denial of service vulnerabilities. 787 Thus an AH implementation MAY choose to not support fragmentation and 788 may mark transmitted packets with the DF bit, to facilitate PMTU 789 discovery. In any case, an AH implementation MUST support generation 790 of ICMP PMTU messages (or equivalent internal signaling for native 791 host implementations) to minimize the likelihood of fragmentation. 792 Details of the support required for MTU management are contained in 793 the Security Architecture document. 795 3.4 Inbound Packet Processing 797 If there is more than one IPsec header/extension present, the 798 processing for each one ignores (does not zero, does not use) any 799 IPsec headers applied subsequent to the header being processed. 801 3.4.1 Reassembly 803 If required, reassembly is performed prior to AH processing. If a 804 packet offered to AH for processing appears to be an IP fragment, 805 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 806 the receiver MUST discard the packet; this is an auditable event. The 807 audit log entry for this event SHOULD include the SPI value, 808 date/time, Source Address, Destination Address, and (in IPv6) the 809 Flow ID. 811 NOTE: For packet reassembly, the current IPv4 spec does NOT require 812 either the zeroing of the OFFSET field or the clearing of the MORE 813 FRAGMENTS flag. In order for a reassembled packet to be processed by 814 IPsec (as opposed to discarded as an apparent fragment), the IP code 815 must do these two things after it reassembles a packet. 817 3.4.2 Security Association Lookup 819 Upon receipt of a packet containing an IP Authentication Header, the 820 receiver determines the appropriate (unidirectional) SA via lookup in 821 the SAD. For a unicast SA, this determination is based on the SPI or 822 the SPI plus protocol field, as described in Section 2.4. If an 823 implementation supports multicast traffic, the destination address is 824 also employed in the lookup (in addition to the SPI), and the sender 825 address also may be employed, as described in Section 2.4. (This 826 process is described in more detail in the Security Architecture 827 document.) The SAD entry for the SA also indicates whether the 828 Sequence Number field will be checked, whether 32 or 64-bit Sequence 829 Numbers are employed for the SA, specifies the algorithm(s) employed 830 for ICV computation, and indicates the key required to validate the 831 ICV. 833 If no valid Security Association exists for this packet the receiver 834 MUST discard the packet; this is an auditable event. The audit log 835 entry for this event SHOULD include the SPI value, date/time, Source 836 Address, Destination Address, and (in IPv6) the Flow ID. 838 (Note that SA management traffic, e.g., IKE packets, does not need to 839 be processed based on SPI, i.e., one can demultiplex this traffic 840 separately, e.g., based on Next Protocol and Port fields.) 842 3.4.3 Sequence Number Verification 844 All AH implementations MUST support the anti-replay service, though 845 its use may be enabled or disabled by the receiver on a per-SA basis. 846 Anti-replay is applicable to unicast as well as multicast SAs. 847 However, this standard specifies no mechanisms for providing anti- 848 replay for a multi-sender SA (unicast or multicast). In the absence 849 of negotiation (or manual configuration) of an anti-replay mechanism 850 for such an SA, it is recommended that sender and receiver checking 851 of the sequence number for the SA be disabled (via negotiation or 852 manual configuration), as noted below. 854 If the receiver does not enable anti-replay for an SA, no inbound 855 checks are performed on the Sequence Number. However, from the 856 perspective of the sender, the default is to assume that anti-replay 857 is enabled at the receiver. To avoid having the sender do 858 unnecessary sequence number monitoring and SA setup (see section 859 3.3.2 "Sequence Number Generation"), if an SA establishment protocol 860 such as IKE is employed, the receiver SHOULD notify the sender, 861 during SA establishment, if the receiver will not provide anti- 862 replay protection. 864 If the receiver has enabled the anti-replay service for this SA, the 865 receive packet counter for the SA MUST be initialized to zero when 866 the SA is established. For each received packet, the receiver MUST 867 verify that the packet contains a Sequence Number that does not 868 duplicate the Sequence Number of any other packets received during 869 the life of this SA. This SHOULD be the first AH check applied to a 870 packet after it has been matched to an SA, to speed rejection of 871 duplicate packets. 873 Duplicates are rejected through the use of a sliding receive window. 874 How the window is implemented is a local matter, but the following 875 text describes the functionality that the implementation must 876 exhibit. 878 The "right" edge of the window represents the highest, validated 879 Sequence Number value received on this SA. Packets that contain 880 Sequence Numbers lower than the "left" edge of the window are 881 rejected. Packets falling within the window are checked against a 882 list of received packets within the window. 884 If the ESN option is selected for an SA, only the low-order 32 bits 885 of the sequence number are explicitly transmitted; but the receiver 886 employs the full sequence number computed using the high-order 32 887 bits for the indicated SA (from his local counter) when checking the 888 received Sequence Number against the receive window. In constructing 889 the full Sequence Number, if the low order 32 bits carried in the 890 packet are lower in value than the low order 32 bits of the 891 receiver's Sequence Number, the receiver assumes that the high order 892 32 bits have been incremented, moving to a new sequence number 893 subspace. (This algorithm accommodates gaps in reception for a single 894 SA as large as 2**32-1 packets. If a larger gap occurs, additional, 895 heuristic checks for resynchronization of the receiver's Sequence 896 Number counter MAY be employed, as described in Appendix B.) 898 If the received packet falls within the window and is not a 899 duplicate, or if the packet is to the right of the window, then the 900 receiver proceeds to ICV verification. If the ICV validation fails, 901 the receiver MUST discard the received IP datagram as invalid. This 902 is an auditable event. The audit log entry for this event SHOULD 903 include the SPI value, date/time, Source Address, Destination 904 Address, the Sequence Number, and (in IPv6) the Flow ID. The receive 905 window is updated only if the ICV verification succeeds. 907 A MINIMUM window size of 32 packets MUST be supported; but a window 908 size of 64 is preferred and SHOULD be employed as the default. 909 Another window size (larger than the MINIMUM) MAY be chosen by the 910 receiver. (The receiver does NOT notify the sender of the window 911 size.) The receive window size should be increased for higher speed 912 environments, irrespective of assurance issues. Values for minimum 913 and recommended receive window sizes for very high speed (e.g., 914 multi-gigabit/second) devices are not specified by this standard. 916 3.4.4 Integrity Check Value Verification 918 The receiver computes the ICV over the appropriate fields of the 919 packet, using the specified integrity algorithm, and verifies that it 920 is the same as the ICV included in the ICV field of the packet. 921 Details of the computation are provided below. 923 If the computed and received ICV's match, then the datagram is valid, 924 and it is accepted. If the test fails, then the receiver MUST 925 discard the received IP datagram as invalid. This is an auditable 926 event. The audit log entry SHOULD include the SPI value, date/time 927 received, Source Address, Destination Address, and (in IPv6) the Flow 928 ID. 930 Implementation Note: 932 Implementations can use any set of steps that results in the same 933 result as the following set of steps. Begin by saving the ICV 934 value and replacing it (but not any ICV field padding) with zero. 935 Zero all other fields that may have been modified during transit. 936 (See section 3.3.3.1, "Handling Mutable Fields", for a discussion 937 of which fields are zeroed before performing the ICV calculation.) 938 If the ESN option is elected for this SA, append the high order 32 939 bits of the ESN after the end of the packet. Check the overall 940 length of the packet (as described above), and if it requires 941 implicit padding based on the requirements of the integrity 942 algorithm, append zero-filled bytes to the end of the packet 943 (after the ESN if present) as required. Perform the ICV 944 computation and compare the result with the saved value, using the 945 comparison rules defined by the algorithm specification. (For 946 example, if a digital signature and one-way hash are used for the 947 ICV computation, the matching process is more complex.) 949 4. Auditing 951 Not all systems that implement AH will implement auditing. However, 952 if AH is incorporated into a system that supports auditing, then the 953 AH implementation MUST also support auditing and MUST allow a system 954 administrator to enable or disable auditing for AH. For the most 955 part, the granularity of auditing is a local matter. However, 956 several auditable events are identified in this specification and for 957 each of these events a minimum set of information that SHOULD be 958 included in an audit log is defined. Additional information also MAY 959 be included in the audit log for each of these events, and additional 960 events, not explicitly called out in this specification, also MAY 961 result in audit log entries. There is no requirement for the 962 receiver to transmit any message to the purported sender in response 963 to the detection of an auditable event, because of the potential to 964 induce denial of service via such action. 966 5. Conformance Requirements 968 Implementations that claim conformance or compliance with this 969 specification MUST fully implement the AH syntax and processing 970 described here for unicast traffic, and MUST comply with all 971 requirements of the Security Architecture document [Ken-Arch]. 972 Additionally, if an implementation claims to support multicast 973 traffic, it MUST comply with the additional requirements specified 974 for support of such traffic. If the key used to compute an ICV is 975 manually distributed, correct provision of the anti-replay service 976 would require correct maintenance of the counter state at the sender, 977 until the key is replaced, and there likely would be no automated 978 recovery provision if counter overflow were imminent. Thus a 979 compliant implementation SHOULD NOT provide this service in 980 conjunction with SAs that are manually keyed. 982 The mandatory-to-implement algorithms for use with AH are described 983 in a separate RFC [Eas04], to facilitate updating the algorithm 984 requirements independently from the protocol per se. Additional 985 algorithms, beyond those mandated for AH, MAY be supported. 987 6. Security Considerations 989 Security is central to the design of this protocol, and these 990 security considerations permeate the specification. Additional 991 security-relevant aspects of using the IPsec protocol are discussed 992 in the Security Architecture document. 994 7. Differences from RFC 2402 996 This document differs from RFC 2402 in the following ways. 998 o SPI -- modified to specify a uniform algorithm for SAD lookup 999 for unicast and multicast SAs, covering a wider range of 1000 multicast technologies. For unicast, the SPI may be used alone 1001 to select an SA, or may be combined with the protocol, at the 1002 option of the receiver. For multicast SAs, the SPI is 1003 combined with the destination address, and optionally the 1004 source address, to select an SA. 1005 o Sequence number -- added a new option for a 64-bit sequence 1006 number for very high-speed communications. Clarified sender 1007 and receiver processing requirements for multicast SAs and 1008 multi-sender SAs. 1009 o Moved references to mandatory algorithms to a separate 1010 document [Eas04]. 1012 Acknowledgements 1014 The author would like to acknowledge the contributions of Ran 1015 Atkinson, who played a critical role in initial IPsec activities, and 1016 who authored the first series of IPsec standards: RFCs 1825-1827. 1017 Karen Seo deserves special thanks for providing help in the editing 1018 of this and the previous version of this specification. The author 1019 also would like to thank the members of the IPsec and MSEC working 1020 groups who have contributed to the development of this protocol 1021 specification. 1023 References 1025 Normative 1027 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 1028 Requirement Level", BCP 14, RFC 2119, March 1997. 1030 [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 1031 (IPv6) Specification", RFC 2460, December 1998. 1033 [Eas04] Eastlake, D., "Cryptographic Algorithm Implementation 1034 Requirements For ESP And AH", RFC ???, ??? 200? 1036 [RFC Editor: Please update reference [Eas04] "Cryptographic 1037 Algorithm Implementation Requirements For ESP And AH" 1038 (draft-ietf-ipsec-esp-ah-algorithms-02.txt) with the RFC 1039 number and month when it is issued.] 1041 [Ken-Arch]Kent, S., and Seo, K., "Security Architecture for the 1042 Internet Protocol", RFC ???, ??? 200?. 1044 [RFC Editor: Please update reference [Ken-Arch] "Security 1045 Architecture for the Internet Protocol" (draft-ietf-ipsec- 1046 rfc2401bis-05.txt) with the RFC number and month when it is 1047 issued.] 1049 [Pos81] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1050 1981 1052 Informative 1054 [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for 1055 IP", Internet-Draft, draft-ietf-ssm-arch-01.txt, November 1056 3, 2002. 1058 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange 1059 (IKE)", RFC 2409, November 1998. 1061 [Ken-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1062 ???, ???? 200?. 1064 [RFC Editor: Please update the reference [Ken-ESP] "IP 1065 Encapsulating Security Payload (ESP)" (draft-ietf-ipsec- 1066 esp-v3-09.txt) with the RFC number and month when it is 1067 issued.] 1069 [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1070 of the Differentiated Services Field (DS Field) in the IPv4 1071 and IPv6 Headers", RFC 2474, December 1998. 1073 [RFB01] Ramakrishnan, K., Floyd S., Black D., "The Addition of 1074 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1075 September 2001. 1077 [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group 1078 Domain of Interpretation", RFC 3547, July 2003. 1080 [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security 1081 Architecture", RFC 3740, March 2004. 1083 Author Information 1085 Stephen Kent 1086 BBN Technologies 1087 10 Moulton Street 1088 Cambridge, MA 02138 1089 USA 1090 Phone: +1 (617) 873-3988 1091 EMail: kent@bbn.com 1093 Appendix A -- Mutability of IP Options/Extension Headers 1095 A1. IPv4 Options 1097 This table shows how the IPv4 options are classified with regard to 1098 "mutability". Where two references are provided, the second one 1099 supercedes the first. This table is based in part on information 1100 provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). 1102 Opt. 1103 Copy Class # Name Reference 1104 ---- ----- --- ------------------------- -------- 1105 IMMUTABLE -- included in ICV calculation 1106 0 0 0 End of Options List [RFC791] 1107 0 0 1 No Operation [RFC791] 1108 1 0 2 Security [RFC1108(historic but 1109 in use)] 1110 1 0 5 Extended Security [RFC1108(historic but 1111 in use)] 1112 1 0 6 Commercial Security [expired I-D, now US MIL 1113 STD] 1114 1 0 20 Router Alert [RFC2113] 1115 1 0 21 Sender Directed Multi- [RFC1770] 1116 Destination Delivery 1117 MUTABLE -- zeroed 1118 1 0 3 Loose Source Route [RFC791] 1119 0 2 4 Time Stamp [RFC791] 1120 0 0 7 Record Route [RFC791] 1121 1 0 9 Strict Source Route [RFC791] 1122 0 2 18 Traceroute [RFC1393] 1124 EXPERIMENTAL, SUPERCEDED -- zeroed 1125 1 0 8 Stream ID [RFC791, RFC1122 (Host 1126 Req)] 1127 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 1128 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1129 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 1130 0 0 10 Experimental Measurement [ZSu] 1131 1 2 13 Experimental Flow Control [Finn] 1132 1 0 14 Experimental Access Ctl [Estrin] 1133 0 0 15 ??? [VerSteeg] 1134 1 0 16 IMI Traffic Descriptor [Lee] 1135 1 0 19 Address Extension [Ullmann IPv7] 1137 NOTE: Use of the Router Alert option is potentially incompatible with 1138 use of IPsec. Although the option is immutable, its use implies that 1139 each router along a packet's path will "process" the packet and 1140 consequently might change the packet. This would happen on a hop by 1141 hop basis as the packet goes from router to router. Prior to being 1142 processed by the application to which the option contents are 1143 directed, e.g., RSVP/IGMP, the packet should encounter AH processing. 1144 However, AH processing would require that each router along the path 1145 is a member of a multicast-SA defined by the SPI. This might pose 1146 problems for packets that are not strictly source routed, and it 1147 requires multicast support techniques not currently available. 1149 NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by 1150 systems along a packet's path conflicts with the classification of 1151 these IP Options as immutable and is incompatible with the use of 1152 IPsec. 1154 NOTE: End of Options List options SHOULD be repeated as necessary to 1155 ensure that the IP header ends on a 4 byte boundary in order to 1156 ensure that there are no unspecified bytes which could be used for a 1157 covert channel. 1159 A2. IPv6 Extension Headers 1161 This table shows how the IPv6 Extension Headers are classified with 1162 regard to "mutability". 1164 Option/Extension Name Reference 1165 ----------------------------------- --------- 1166 MUTABLE BUT PREDICTABLE -- included in ICV calculation 1167 Routing (Type 0) [DH98] 1169 BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING 1170 TRANSIT) 1171 Hop by Hop options [DH98] 1172 Destination options [DH98] 1174 NOT APPLICABLE 1175 Fragmentation [DH98] 1177 Options -- IPv6 options in the Hop-by-Hop and Destination 1178 Extension Headers contain a bit that indicates whether the option 1179 might change (unpredictably) during transit. For any option for 1180 which contents may change en-route, the entire "Option Data" field 1181 must be treated as zero-valued octets when computing or verifying 1182 the ICV. The Option Type and Opt Data Len are included in the ICV 1183 calculation. All options for which the bit indicates immutability 1184 are included in the ICV calculation. See the IPv6 specification 1185 [DH98] for more information. 1187 Routing (Type 0) -- The IPv6 Routing Header "Type 0" will 1188 rearrange the address fields within the packet during transit from 1189 source to destination. However, the contents of the packet as it 1190 will appear at the receiver are known to the sender and to all 1191 intermediate hops. Hence, the IPv6 Routing Header "Type 0" is 1192 included in the Integrity Check Value calculation as mutable but 1193 predictable. The sender must order the field so that it appears as 1194 it will at the receiver, prior to performing the ICV computation. 1196 Fragmentation -- Fragmentation occurs after outbound IPsec 1197 processing (section 3.3) and reassembly occurs before inbound IPsec 1198 processing (section 3.4). So the Fragmentation Extension Header, if 1199 it exists, is not seen by IPsec. 1201 Note that on the receive side, the IP implementation could 1202 leave a Fragmentation Extension Header in place when it does re- 1203 assembly. If this happens, then when AH receives the packet, before 1204 doing ICV processing, AH MUST "remove" (or skip over) this header 1205 and change the previous header's "Next Header" field to be the "Next 1206 Header" field in the Fragmentation Extension Header. 1208 Note that on the send side, the IP implementation could give 1209 the IPsec code a packet with a Fragmentation Extension Header with 1210 Offset of 0 (first fragment) and a More Fragments Flag of 0 (last 1211 fragment). If this happens, then before doing ICV processing, AH 1212 MUST first "remove" (or skip over) this header and change the 1213 previous header's "Next Header" field to be the "Next Header" field 1214 in the Fragmentation Extension Header. 1216 Appendix B -- Extended (64-bit) Sequence Numbers 1218 B1. Overview 1220 This appendix describes an extended sequence number (ESN) scheme for 1221 use with IPsec (ESP and AH) that employs a 64-bit sequence number, 1222 but in which only the low order 32 bits are transmitted as part of 1223 each packet. It covers both the window scheme used to detect 1224 replayed packets and the determination of the high order bits of the 1225 sequence number that are used both for replay rejection and for 1226 computation of the ICV. It also discusses a mechanism for handling 1227 loss of synchronization relative to the (not transmitted) high order 1228 bits. 1230 B2. Anti-Replay Window 1232 The receiver will maintain an anti-replay window of size W. This 1233 window will limit how far out of order a packet can be, relative to 1234 the packet with the highest sequence number that has been 1235 authenticated so far. (No requirement is established for minimum or 1236 recommended sizes for this window, beyond the 32 and 64-packet values 1237 already established for 32-bit sequence number windows. However, it 1238 is suggested that an implementer scale these values consistent with 1239 the interface speed supported by an implementation that makes use of 1240 the ESN option. Also, the algorithm described below assumes that the 1241 window is no greater than 2^31 packets in width.) All 2^32 sequence 1242 numbers associated with any fixed value for the high order 32 bits 1243 (Seqh) will hereafter be called a sequence number subspace. The 1244 following table lists pertinent variables and their definitions. 1246 Var. Size 1247 Name (bits) Meaning 1248 ---- ------ --------------------------- 1249 W 32 Size of window 1250 T 64 Highest sequence number authenticated so far, 1251 upper bound of window 1252 Tl 32 Lower 32 bits of T 1253 Th 32 Upper 32 bits of T 1254 B 64 Lower bound of window 1255 Bl 32 Lower 32 bits of B 1256 Bh 32 Upper 32 bits of B 1257 Seq 64 Sequence number of received packet 1258 Seql 32 Lower 32 bits of Seq 1259 Seqh 32 Upper 32 bits of Seq 1261 When performing the anti-replay check, or when determining which high 1262 order bits to use to authenticate an incoming packet, there are two 1263 cases: 1265 + Case A: Tl >= (W - 1). In this case, the window is within one 1266 sequence number subspace. (See Figure 1) 1267 + Case B: Tl < (W - 1). In this case, the window spans two 1268 sequence number subspaces. (See Figure 2) 1270 In the figures below, the bottom line ("----") shows two consecutive 1271 sequence number subspaces, with zero's indicating the beginning of 1272 each subspace. The two shorter lines above it show the higher order 1273 bits that apply. The "====" represents the window. The "****" 1274 represents future sequence numbers, i.e., those beyond the current 1275 highest sequence number authenticated (ThTl). 1277 Th+1 ********* 1279 Th =======***** 1281 --0--------+-----+-----0--------+-----------0-- 1282 Bl Tl Bl 1283 (Bl+2^32) mod 2^32 1285 Figure 1 -- Case A 1287 Th ====************** 1289 Th-1 === 1291 --0-----------------+--0--+--------------+--0-- 1292 Bl Tl Bl 1293 (Bl+2^32) mod 2^32 1295 Figure 2 -- Case B 1297 B2.1. Managing and Using the Anti-Replay Window 1299 The anti-replay window can be thought of as a string of bits where 1300 `W' defines the length of the string. W = T - B + 1 and cannot 1301 exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and 1302 the top-most bit corresponds to T and each sequence number from Bl 1303 through Tl is represented by a corresponding bit. The value of the 1304 bit indicates whether or not a packet with that sequence number has 1305 been received and authenticated, so that replays can be detected and 1306 rejected. 1308 When a packet with a 64-bit sequence number (Seq) greater than T is 1309 received and validated, 1310 + B is increased by (Seq - T) 1311 + (Seq - T) bits are dropped from the low end of the window 1312 + (Seq - T) bits are added to the high end of the window 1313 + The top bit is set to indicate that a packet with that sequence 1314 number has been received and authenticated 1315 + The new bits between T and the top bit are set to indicate that 1316 no packets with those sequence numbers have been received yet. 1317 + T is set to the new sequence number 1319 In checking for replayed packets, 1321 + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND 1322 Seql <= Tl, then check the corresponding bit in the window to see 1323 if this Seql has already been seen. If yes, reject the packet. 1324 If no, perform integrity check (see Section 2.2. below for 1325 determination of SeqH). 1327 + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR 1328 Seql <= Tl, then check the corresponding bit in the window to see 1329 if this Seql has already been seen. If yes, reject the packet. 1330 If no, perform integrity check (see Section 2.2. below for 1331 determination of Seqh). 1333 B2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number 1335 Since only `Seql' will be transmitted with the packet, the receiver 1336 must deduce and track the sequence number subspace into which each 1337 packet falls, i.e., determine the value of Seqh. The following 1338 equations define how to select Seqh under "normal" conditions; see 1339 Section 3 for a discussion of how to recover from extreme packet 1340 loss. 1342 + Under Case A (Figure 1): 1343 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th 1344 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1 1346 + Under Case B (Figure 2): 1347 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 1348 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th 1350 B2.3. Pseudo-code Example 1352 The following pseudo-code illustrates the above algorithms for anti- 1353 replay and integrity checks. The values for `Seql', `Tl', `Th' and 1354 `W', are 32-bit unsigned integers. Arithmetic is mod 2^32. 1356 If (Tl >= W - 1) Case A 1357 If (Seql >= Tl - W + 1) 1358 Seqh = Th 1359 If (Seql <= Tl) 1360 If (pass replay check) 1361 If (pass integrity check) 1362 Set bit corresponding to Seql 1363 Pass the packet on 1364 Else reject packet 1365 Else reject packet 1366 Else 1367 If (pass integrity check) 1368 Tl = Seql (shift bits) 1369 Set bit corresponding to Seql 1370 Pass the packet on 1371 Else reject packet 1372 Else 1373 Seqh = Th + 1 1374 If (pass integrity check) 1375 Tl = Seql (shift bits) 1376 Th = Th + 1 1377 Set bit corresponding to Seql 1378 Pass the packet on 1379 Else reject packet 1380 Else Case B 1381 If (Seql >= Tl - W + 1) 1382 Seqh = Th - 1 1383 If (pass replay check) 1384 If (pass integrity check) 1385 Set the bit corresponding to Seql 1386 Pass packet on 1387 Else reject packet 1388 Else reject packet 1389 Else 1390 Seqh = Th 1391 If (Seql <= Tl) 1392 If (pass replay check) 1393 If (pass integrity check) 1394 Set the bit corresponding to Seql 1395 Pass packet on 1396 Else reject packet 1397 Else reject packet 1398 Else 1399 If (pass integrity check) 1400 Tl = Seql (shift bits) 1401 Set the bit corresponding to Seql 1402 Pass packet on 1403 Else reject packet 1405 B3. Handling Loss of Synchronization due to Significant Packet Loss 1407 If there is an undetected packet loss of 2^32 or more consecutive 1408 packets on a single SA, then the transmitter and receiver will lose 1409 synchronization of the high order bits, i.e., the equations in 1410 Section 2.2. will fail to yield the correct value. Unless this 1411 problem is detected and addressed, subsequent packets on this SA will 1412 fail authentication checks and be discarded. The following procedure 1413 SHOULD be implemented by any IPsec (ESP or AH) implementation that 1414 supports the ESN option. 1416 Note that this sort of extended traffic loss seems unlikely to occur 1417 if any significant fraction of the traffic on the SA in question is 1418 TCP, because the source would fail to receive ACKs and would stop 1419 sending long before 2^32 packets had been lost. Also, for any bi- 1420 directional application, even ones operating above UDP, such an 1421 extended outage would likely result in triggering some form of 1422 timeout. However, a unidirectional application, operating over UDP 1423 might lack feedback that would cause automatic detection of a loss of 1424 this magnitude, hence the motivation to develop a recovery method for 1425 this case. 1427 The solution we've chosen was selected to: 1429 + minimize the impact on normal traffic processing 1431 + avoid creating an opportunity for a new denial of service attack 1432 such as might occur by allowing an attacker to force diversion of 1433 resources to a resynchronization process. 1435 + limit the recovery mechanism to the receiver -- since anti-replay 1436 is a service only for the receiver, and the transmitter generally 1437 is not aware of whether the receiver is using sequence numbers in 1438 support of this optional service, it is preferable for recovery 1439 mechanisms to be local to the receiver. This also allows for 1440 backwards compatibility. 1442 B3.1. Triggering Resynchronization 1444 For each SA, the receiver records the number of consecutive packets 1445 that fail authentication. This count is used to trigger the 1446 resynchronization process which should be performed in the background 1447 or using a separate processor. Receipt of a valid packet on the SA 1448 resets the counter to zero. The value used to trigger the 1449 resynchronization process is a local parameter. There is no 1450 requirement to support distinct trigger values for different SAs, 1451 although an implementer may choose to do so. 1453 B3.2. Resynchronization Process 1455 When the above trigger point is reached, a "bad" packet is selected 1456 for which authentication is retried using successively larger values 1458 for the upper half of the sequence number (Seqh). These values are 1459 generated by incrementing by one for each retry. The number of 1460 retries should be limited, in case this is a packet from the "past" 1461 or a bogus packet. The limit value is a local parameter. (Because 1462 the Seqh value is implicitly placed after the AH (or ESP) payload, it 1463 may be possible to optimize this procedure by executing the integrity 1464 algorithm over the packet up to the end point of the payload, then 1465 compute different candidate ICV's by varying the value of Seqh.) 1466 Successful authentication of a packet via this procedure resets the 1467 consecutive failure count and sets the value of T to that of the 1468 received packet. 1470 This solution requires support only on the part of the receiver, 1471 thereby allowing for backwards compatibility. Also, because 1472 resynchronization efforts would either occur in the background or 1473 utilize an additional processor, this solution does not impact 1474 traffic processing and a denial of service attack cannot divert 1475 resources away from traffic processing. 1477 Notices 1479 The IETF takes no position regarding the validity or scope of any 1480 intellectual property or other rights that might be claimed to 1481 pertain to the implementation or use of the technology described in 1482 this document or the extent to which any license under such rights 1483 might or might not be available; neither does it represent that it 1484 has made any effort to identify any such rights. Information on the 1485 IETF's procedures with respect to rights in standards-track and 1486 standards- related documentation can be found in BCP-11. Copies of 1487 claims of rights made available for publication and any assurances of 1488 licenses to be made available, or the result of an attempt made to 1489 obtain a general license or permission for the use of such 1490 proprietary rights by implementers or users of this specification can 1491 be obtained from the IETF Secretariat. 1493 The IETF invites any interested party to bring to its attention any 1494 copyrights, patents or patent applications, or other proprietary 1495 rights which may cover technology that may be required to practice 1496 this standard. Please address the information to the IETF Executive 1497 Director. 1499 Copyright (C) The Internet Society (2005). This document is subject 1500 to the rights, licenses and restrictions contained in BCP 78, and 1501 except as set forth therein, the authors retain all their rights. 1503 This document is subject to the rights, licenses and restrictions 1504 contained in BCP 78, and except as set forth therein, the authors 1505 retain all their rights. 1507 This document and translations of it may be copied and furnished to 1508 others, and derivative works that comment on or otherwise explain it 1509 or assist in its implementation may be prepared, copied, published 1510 and distributed, in whole or in part, without restriction of any 1511 kind, provided that the above copyright notice and this paragraph are 1512 included on all such copies and derivative works. However, this 1513 document itself may not be modified in any way, such as by removing 1514 the copyright notice or references to the Internet Society or other 1515 Internet organizations, except as needed for the purpose of 1516 developing Internet standards in which case the procedures for 1517 copyrights defined in the Internet Standards process must be 1518 followed, or as required to translate it into languages other than 1519 English. 1521 The limited permissions granted above are perpetual and will not be 1522 revoked by the Internet Society or its successors or assigns. 1524 This document and the information contained herein are provided on an 1525 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1526 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1527 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1528 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1529 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1530 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1532 Expires September 2005