idnits 2.17.1 draft-ietf-ipsec-rfc2402bis-01.txt: -(779): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 60 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([KA98c]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 164 has weird spacing: '... Integ is...' == Line 176 has weird spacing: '...ariable if ne...' == 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 (July 2002) is 7956 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: 'KA97b' is mentioned on line 112, but not defined == Missing Reference: 'KA97a' is mentioned on line 124, but not defined == Missing Reference: 'STD-2' is mentioned on line 143, but not defined -- Looks like a reference, but probably isn't: '1' on line 178 -- Looks like a reference, but probably isn't: '2' on line 179 -- Looks like a reference, but probably isn't: '3' on line 181 -- Looks like a reference, but probably isn't: '4' on line 183 == Missing Reference: 'AES' is mentioned on line 411, but not defined == Missing Reference: 'RFC791' is mentioned on line 972, but not defined == Missing Reference: 'RFC2113' is mentioned on line 965, but not defined == Missing Reference: 'RFC1770' is mentioned on line 966, but not defined ** Obsolete undefined reference: RFC 1770 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1393' is mentioned on line 973, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'ZSu' is mentioned on line 981, but not defined == Missing Reference: 'Finn' is mentioned on line 982, but not defined == Missing Reference: 'Estrin' is mentioned on line 983, but not defined == Missing Reference: 'VerSteeg' is mentioned on line 984, but not defined == Missing Reference: 'Lee' is mentioned on line 985, but not defined == Missing Reference: 'RFC1883' is mentioned on line 1026, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Unused Reference: 'ATK95' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'KA98a' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'KA98b' is defined on line 914, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1826 (ref. 'ATK95') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1883 (ref. 'DH95') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. 'KA98a') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2406 (ref. 'KA98b') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2402 (ref. 'KA98c') (Obsoleted by RFC 4302, RFC 4305) Summary: 18 errors (**), 0 flaws (~~), 23 warnings (==), 7 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 Expires January 2003 July 2002 5 IP Authentication Header 6 draft-ietf-ipsec-rfc2402bis-01.txt 8 Status of This Memo 10 This document is an Internet Draft and is subject to all provisions 11 of Section 10 of RFC2026. Internet Drafts are working documents of 12 the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet Drafts 16 Internet Drafts are draft documents valid for a maximum of 6 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as a "work in progress". 21 The list of current Internet Drafts can be accessed at 22 http://www.ietf.org/lid-abstracts.html 24 The list of Internet Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html 27 Copyright (C) The Internet Society (2002). All Rights Reserved. 29 Abstract 31 This document describes an updated version of the IP Authentication 32 Header (AH), which is designed to provide authentication services in 33 IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) 34 [KA98c]. Section 7 provides a brief review of the differences 35 between this document and RFC 2402. 37 Comments should be sent to Stephen Kent (kent@bbn.com). 39 Table of Contents 40 1. Introduction......................................................3 41 2. Authentication Header Format......................................4 42 2.1 Next Header...................................................5 43 2.2 Payload Length................................................5 44 2.3 Reserved......................................................5 45 2.4 Security Parameters Index (SPI)...............................5 46 2.5 Sequence Number...............................................6 47 2.5.1 Extended Sequence Number.................................6 48 2.6 Integrity Check Value (ICV) ..................................7 49 3. Authentication Header Processing..................................7 50 3.1 Authentication Header Location...............................7 51 3.1.1 Transport Mode..........................................7 52 3.1.2 Tunnel Mode.............................................8 53 3.2 Authentication Algorithms....................................9 54 3.3 Outbound Packet Processing...................................9 55 3.3.1 Security Association Lookup............................10 56 3.3.2 Sequence Number Generation.............................10 57 3.3.3 Integrity Check Value Calculation......................11 58 3.3.3.1 Handling Mutable Fields...........................11 59 3.3.3.1.1 ICV Computation for IPv4.....................12 60 3.3.3.1.1.1 Base Header Fields.......................12 61 3.3.3.1.1.2 Options..................................12 62 3.3.3.1.2 ICV Computation for IPv6.....................13 63 3.3.3.1.2.1 Base Header Fields.......................13 64 3.3.3.1.2.2 Extension Headers Containing Options.....13 65 3.3.3.1.2.3 Extension Headers Not Containing Options.13 66 3.3.3.2 Padding & Extended Sequence Numbers...............14 67 3.3.3.2.1 ICV Padding..................................14 68 3.3.3.2.2 Implicit Packet Padding & ESN................14 69 3.3.4 Fragmentation..........................................14 70 3.4 Inbound Packet Processing...................................15 71 3.4.1 Reassembly.............................................15 72 3.4.2 Security Association Lookup............................16 73 3.4.3 Sequence Number Verification...........................16 74 3.4.4 Integrity Check Value Verification.....................17 75 4. Auditing.........................................................18 76 5. Conformance Requirements.........................................19 77 6. Security Considerations..........................................19 78 7. Differences from RFC 1826........................................19 79 Acknowledgements....................................................19 80 References..........................................................20 81 Disclaimer..........................................................20 82 Author Information..................................................20 83 Appendix A -- Mutability of IP Options/Extension Headers............21 84 A1. IPv4 Options.................................................21 85 A2. IPv6 Extension Headers.......................................22 86 Appendix B -- Extended (64-bit) Sequence Numbers....................24 87 Full Copyright Statement............................................30 89 1. Introduction 91 The IP Authentication Header (AH) is used to provide connectionless 92 integrity and data origin authentication for IP datagrams (hereafter 93 referred to as just "authentication"), and to provide protection 94 against replays. This latter, optional service may be selected, by 95 the receiver, when a Security Association is established. (Although 96 the default calls for the sender to increment the Sequence Number 97 used for anti-replay, the service is effective only if the receiver 98 checks the Sequence Number.) However, to make use of a new, extended 99 sequence number feature in an interoperable fashion, AH does impose a 100 requirement on SA management protocols to be able to negotiate this 101 new feature (see Section 2.5.1 below). 103 AH provides authentication for as much of the IP header as possible, 104 as well as for upper level protocol data. However, some IP header 105 fields may change in transit and the value of these fields, when the 106 packet arrives at the receiver, may not be predictable by the sender. 107 The values of such fields cannot be protected by AH. Thus the 108 protection provided to the IP header by AH is somewhat piecemeal. 109 (See Appendix A.) 111 AH may be applied alone, in combination with the IP Encapsulating 112 Security Payload (ESP) [KA97b], or in a nested fashion through the 113 use of tunnel mode (see "Security Architecture for the Internet 114 Protocol" [KA97a], hereafter referred to as the Security Architecture 115 document). Security services can be provided between a pair of 116 communicating hosts, between a pair of communicating security 117 gateways, or between a security gateway and a host. ESP may be used 118 to provide the same anti-replay and similar authentication services, 119 and it also provides a confidentiality (encryption) service. The 120 primary difference between the authentication provided by ESP and AH 121 is the extent of the coverage. Specifically, ESP does not protect 122 any IP header fields unless those fields are encapsulated by ESP 123 (tunnel mode). For more details on how to use AH and ESP in various 124 network environments, see the Security Architecture document [KA97a]. 126 It is assumed that the reader is familiar with the terms and concepts 127 described in the Security Architecture document. In particular, the 128 reader should be familiar with the definitions of security services 129 offered by AH and ESP, the concept of Security Associations, the ways 130 in which AH can be used in conjunction with ESP, and the different 131 key management options available for AH and ESP. (With regard to the 132 last topic, the current key management options required for both AH 133 and ESP are manual keying and automated keying via IKE [HC98].) 135 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 136 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 137 document, are to be interpreted as described in RFC 2119 [Bra97]. 139 2. Authentication Header Format 141 The protocol header (IPv4, IPv6, or IPv6 Extension) immediately 142 preceding the AH header will contain the value 51 in its Protocol 143 (IPv4) or Next Header (IPv6, Extension) field [STD-2]. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Next Header | Payload Len | RESERVED | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Security Parameters Index (SPI) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Sequence Number Field | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + Integrity Check Value-ICV (variable) | 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 The following table refers to the fields in the preceding figure and 160 illustrates which fields are covered by the ICV and what is 161 transmitted. 163 What What 164 # of Requ'd Integ is 165 bytes [1] Covers Xmtd 166 ------ ------ ------ ------ 167 IP Header variable M [2] plain 168 Next Header 1 M Y plain 169 Payload Len 1 M Y plain 170 RESERVED 2 M Y plain 171 SPI 4 M Y plain 172 Seq# (low order 32-bits) 4 M Y plain 173 ICV variable M Y[3] plain 174 IP datagram [4] variable M or D Y plain 175 Seq# (high order 32-bits) 4 if ESN Y not xmtd 176 ICV Padding variable if need Y not xmtd 178 [1] - M = mandatory; D = dummy 179 [2] - See section 3.3.3 "Integrity Check Value Calculation" for 180 details of which IP header fields are covered. 181 [3] - Zero'd before ICV calculation (resulting ICV placed here 182 after calculation) 183 [4] - If tunnel mode -> IP datagram 184 If transport mode -> next header and data 186 The following subsections define the fields that comprise the AH 187 format. All the fields described here are mandatory, i.e., they are 188 always present in the AH format and are included in the Integrity 189 Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 191 2.1 Next Header 193 The Next Header is an 8-bit field that identifies the type of the 194 next payload after the Authentication Header. The value of this 195 field is chosen from the set of IP Protocol Numbers defined on the 196 web page of Internet Assigned Numbers Authority (IANA), e.g., a value 197 of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 198 indicates TCP. 200 2.2 Payload Length 202 This 8-bit field specifies the length of AH in 32-bit words (4-byte 203 units), minus "2". (This means of expressing the length of AH was 204 selected to allow its use as an IPv6 extension header. Thus the 205 length computation is consistent with the algorithm described in RFC 206 1883.) In the case of the "default" integrity algorithm, a 96-bit 207 authentication value plus the 3 32-bit word fixed portion, this 208 length field will be "4". See Section 2.6, "Integrity Check Value 209 (ICV)", for comments on padding of this field, and Section 3.3.3.2.1 210 "ICV Padding". 212 2.3 Reserved 214 This 16-bit field is reserved for future use. It MUST be set to 215 "zero." (Note that the value is included in the ICV calculation, but 216 is otherwise ignored by the recipient.) 218 2.4 Security Parameters Index (SPI) 220 The SPI is an arbitrary 32-bit value that is used by a receiver to 221 identify the SA to which an incoming packet is bound. For a unicast 222 SA, the SPI can be used by itself to specify an SA, or it may be used 223 in conjunction with the IPsec protocol type (in this case ESP). 224 Since the SPI value is generated by the receiver, whether the value 225 is sufficient to identify an SA by itself, or whether it must be used 226 in conjunction with the IPsec protocol value is a local matter. The 227 SPI field is mandatory. 229 For multicast SAs, the SPI (and optionally the protocol ID) in 230 combination with the destination address is used to select an SA. 231 This is because multicast SAs are defined by a multicast controller, 232 not by each IPsec receiver. (See the Security Architecture document 233 for more details.) 234 The set of SPI values in the range 1 through 255 are reserved by the 235 Internet Assigned Numbers Authority (IANA) for future use; a reserved 236 SPI value will not normally be assigned by IANA unless the use of the 237 assigned SPI value is specified in an RFC. The SPI value of zero (0) 238 is reserved for local, implementation- specific use and MUST NOT be 239 sent on the wire. (For example, a key management implementation might 240 use the zero SPI value to mean "No Security Association Exists" 241 during the period when the IPsec implementation has requested that 242 its key management entity establish a new SA, but the SA has not yet 243 been established.) 245 2.5 Sequence Number 247 This unsigned 32-bit field contains a counter value that increases by 248 one for each packet sent, i.e., a per-SA packet sequence number. For 249 a unicast SA or a single-sender multicast SA, the sender MUST 250 increment this field for every transmitted packet. Sharing an SA 251 among multiple senders is deprecated, since there is no general means 252 of synchronizing packet counters among the senders or meaningfully 253 managing a receiver packet counter and window in the context of 254 multiple senders. 256 The field is mandatory and MUST always be present even if the 257 receiver does not elect to enable the anti-replay service for a 258 specific SA. Processing of the Sequence Number field is at the 259 discretion of the receiver, but all AH implementations MUST be 260 capable of performing the Sequence Number processing described in 261 Section 3.3.2 "Sequence Number Generation" and Section 3.4.3 262 "Sequence Number Verification." Thus the sender MUST always transmit 263 this field, but the receiver need not act upon it. 265 The sender's counter and the receiver's counter are initialized to 0 266 when an SA is established. (The first packet sent using a given SA 267 will have a Sequence Number of 1; see Section 3.3.2 for more details 268 on how the Sequence Number is generated.) If anti-replay is enabled 269 (the default), the transmitted Sequence Number must never be allowed 270 to cycle. Thus, the sender's counter and the receiver's counter MUST 271 be reset (by establishing a new SA and thus a new key) prior to the 272 transmission of the 2^32nd packet on an SA. 274 2.5.1 Extended (64-bit) Sequence Number 276 To support high-speed IPsec implementations, a new option for 277 sequence numbers SHOULD be offered, as an extension to the current, 278 32-bit sequence number field. Use of an Extended Sequence Number 279 (ESN) MUST be negotiated by an SA management protocol. 281 The ESN facility allows use of a 64-bit sequence number for an SA. 283 (See Appendix B, "Managing 64-bit Sequence Numbers", for details.) 284 Only the low order 32 bits of the sequence number are transmitted in 285 the AH header of each packet, thus minimizing packet overhead. The 286 high order 32 bits are maintained as part of the sequence number 287 counter by both transmitter and receiver and are included in the 288 computation of the ICV, but are not transmitted. 290 2.6 Integrity Check Value (ICV) 292 This is a variable-length field that contains the Integrity Check 293 Value (ICV) for this packet. The field must be an integral multiple 294 of 32 bits (IPv4) or 64 bits (IPv6) in length. The details of ICV 295 processing are described in Section 3.3.3 "Integrity Check Value 296 Calculation" and Section 3.4.4 "Integrity Check Value Verification." 297 This field may include explicit padding, if required to ensure that 298 the length of the AH header is an integral multiple of 32 bits (IPv4) 299 or 64 bits (IPv6). All implementations MUST support such padding. 300 Details of how to compute the required padding length are provided 301 below in Section 3.3.3.2 "Padding". The authentication algorithm 302 specification MUST specify the length of the ICV and the comparison 303 rules and processing steps for validation. 305 3. Authentication Header Processing 307 3.1 Authentication Header Location 309 Like ESP, AH may be employed in two ways: transport mode or tunnel 310 mode. The former mode is applicable only to host implementations and 311 provides protection for upper layer protocols, in addition to 312 selected IP header fields. (In this mode, note that for "bump-in- 313 the-stack" or "bump-in-the-wire" implementations, as defined in the 314 Security Architecture document, inbound and outbound IP fragments may 315 require an IPsec implementation to perform extra IP 316 reassembly/fragmentation in order to both conform to this 317 specification and provide transparent IPsec support. Special care is 318 required to perform such operations within these implementations when 319 multiple interfaces are in use.) 321 3.1.1 Transport Mode 323 In transport mode, AH is inserted after the IP header and before an 324 upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other 325 IPsec headers that have already been inserted. In the context of 326 IPv4, this calls for placing AH after the IP header (and any options 327 that it contains), but before the upper layer protocol. (Note that 328 the term "transport" mode should not be misconstrued as restricting 329 its use to TCP and UDP. For example, an ICMP message MAY be sent 330 using either "transport" mode or "tunnel" mode.) The following 331 diagram illustrates AH transport mode positioning for a typical IPv4 332 packet, on a "before and after" basis. 334 BEFORE APPLYING AH 335 ---------------------------- 336 IPv4 |orig IP hdr | | | 337 |(any options)| TCP | Data | 338 ---------------------------- 340 AFTER APPLYING AH 341 --------------------------------- 342 IPv4 |orig IP hdr | | | | 343 |(any options)| AH | TCP | Data | 344 --------------------------------- 345 |<------- authenticated ------->| 346 except for mutable fields 348 In the IPv6 context, AH is viewed as an end-to-end payload, and thus 349 should appear after hop-by-hop, routing, and fragmentation extension 350 headers. The destination options extension header(s) could appear 351 before or after or both before and after the AH header depending on 352 the semantics desired. The following diagram illustrates AH 353 transport mode positioning for a typical IPv6 packet. 355 BEFORE APPLYING AH 356 --------------------------------------- 357 IPv6 | | ext hdrs | | | 358 | orig IP hdr |if present| TCP | Data | 359 --------------------------------------- 361 AFTER APPLYING AH 362 ------------------------------------------------------------ 363 IPv6 | |hop-by-hop, dest*, | | dest | | | 364 |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | 365 ------------------------------------------------------------ 366 |<---- authenticated except for mutable fields ----------->| 368 * = if present, could be before AH, after AH, or both 370 ESP and AH headers can be combined in a variety of modes. The IPsec 371 Architecture document describes the combinations of security 372 associations that must be supported. 374 3.1.2 Tunnel Mode 376 Tunnel mode AH may be employed in either hosts or security gateways 377 (or in so-called "bump-in-the-stack" or "bump-in-the-wire" 378 implementations, as defined in the Security Architecture document). 379 When AH is implemented in a security gateway (to protect transit 380 traffic), tunnel mode MUST be used. In tunnel mode, the "inner" IP 381 header carries the ultimate source and destination addresses, while 382 an "outer" IP header may contain distinct IP addresses, e.g., 383 addresses of security gateways. In tunnel mode, AH protects the 384 entire inner IP packet, including the entire inner IP header. The 385 position of AH in tunnel mode, relative to the outer IP header, is 386 the same as for AH in transport mode. The following diagram 387 illustrates AH tunnel mode positioning for typical IPv4 and IPv6 388 packets. 390 ------------------------------------------------ 391 IPv4 | new IP hdr* | | orig IP hdr* | | | 392 |(any options)| AH | (any options) |TCP | Data | 393 ------------------------------------------------ 394 |<- authenticated except for mutable fields -->| 395 | in the new IP hdr | 397 -------------------------------------------------------------- 398 IPv6 | | ext hdrs*| | | ext hdrs*| | | 399 |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| 400 -------------------------------------------------------------- 401 |<-- authenticated except for mutable fields in new IP hdr ->| 403 * = construction of outer IP hdr/extensions and modification 404 of inner IP hdr/extensions is discussed below. 406 3.2 Authentication Algorithms 408 The authentication algorithm employed for the ICV computation is 409 specified by the SA. For point-to-point communication, suitable 410 integrity algorithms include keyed Message Authentication Codes 411 (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or 412 on one-way hash functions (e.g., MD5 or SHA-1). For multicast 413 communication, one-way hash algorithms combined with asymmetric 414 signature algorithms are appropriate, though performance and space 415 considerations currently preclude use of such algorithms. The 416 mandatory-to-implement integrity algorithms are described in Section 417 5 "Conformance Requirements". Other algorithms MAY be supported. 419 3.3 Outbound Packet Processing 421 In transport mode, the sender inserts the AH header after the IP 422 header and before an upper layer protocol header, as described above. 423 In tunnel mode, the outer and inner IP header/extensions can be 424 inter-related in a variety of ways. The construction of the outer IP 425 header/extensions during the encapsulation process is described in 426 the Security Architecture document. 428 If there is more than one IPsec header/extension required, the order 429 of the application of the security headers MUST be defined by 430 security policy. For simplicity of processing, each IPsec header 431 SHOULD ignore the existence (i.e., not zero the contents or try to 432 predict the contents) of IPsec headers to be applied later. (While a 433 native IP or bump-in-the-stack implementation could predict the 434 contents of later IPsec headers that it applies itself, it won't be 435 possible for it to predict any IPsec headers added by a bump-in-the- 436 wire implementation between the host and the network.) 438 3.3.1 Security Association Lookup 440 AH is applied to an outbound packet only after an IPsec 441 implementation determines that the packet is associated with an SA 442 that calls for AH processing. The process of determining what, if 443 any, IPsec processing is applied to outbound traffic is described in 444 the Security Architecture document. 446 3.3.2 Sequence Number Generation 448 The sender's counter is initialized to 0 when an SA is established. 449 The sender increments the Sequence Number (or ESN) for this SA and 450 inserts the low-order 32 bits of the value into the Sequence Number 451 field. Thus the first packet sent using a given SA will contain a 452 Sequence Number of 1. 454 If anti-replay is enabled (the default), the sender checks to ensure 455 that the counter has not cycled before inserting the new value in the 456 Sequence Number field. In other words, the sender MUST NOT send a 457 packet on an SA if doing so would cause the Sequence Number to cycle. 458 An attempt to transmit a packet that would result in Sequence Number 459 overflow is an auditable event. The audit log entry for this event 460 SHOULD include the SPI value, current date/time, Source Address, 461 Destination Address, and (in IPv6) the cleartext Flow ID. 463 The sender assumes anti-replay is enabled as a default, unless 464 otherwise notified by the receiver (see 3.4.3) or if the SA was 465 configured using manual key management. Thus typical behavior of an 466 ESP implementation calls for the sender to establish a new SA when 467 the Sequence Number (or ESN) cycles, or in anticipation of this value 468 cycling. 470 If anti-replay is disabled (as noted above), the sender does not need 471 to monitor or reset the counter, e.g., in the case of manual key 472 management (see Section 5). However, the sender still increments the 473 counter and when it reaches the maximum value, the counter rolls over 474 back to zero. 476 If ESN (see Appendix B) is selected, only the low order 32 bits of 477 the Sequence Number are transmitted in the Sequence Number field, 478 although both sender and receiver maintain full 64-bit ESN counters. 479 However, the high order 32 bits are included in the ICV calculation. 481 3.3.3 Integrity Check Value Calculation 483 The AH ICV is computed over: 484 o IP header fields that are either immutable in transit or that 485 are predictable in value upon arrival at the endpoint for the AH 486 SA 487 o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence 488 Number (low order 32 bits), and the Authentication Data (which is 489 set to zero for this computation), and explicit padding bytes (if 490 any)) 491 o the upper level protocol data, which is assumed to be immutable 492 in transit 493 o the high order bits of the ESN (if employed), and any implicit 494 padding required by the integrity algorithm 496 3.3.3.1 Handling Mutable Fields 498 If a field may be modified during transit, the value of the field is 499 set to zero for purposes of the ICV computation. If a field is 500 mutable, but its value at the (IPsec) receiver is predictable, then 501 that value is inserted into the field for purposes of the ICV 502 calculation. The Authentication Data field is also set to zero in 503 preparation for this computation. Note that by replacing each 504 field's value with zero, rather than omitting the field, alignment is 505 preserved for the ICV calculation. Also, the zero-fill approach 506 ensures that the length of the fields that are so handled cannot be 507 gchanged during transit, even though their contents are not 508 explicitly covered by the ICV. 510 As a new extension header or IPv4 option is created, it will be 511 defined in its own RFC and SHOULD include (in the Security 512 Considerations section) directions for how it should be handled when 513 calculating the AH ICV. If the IP (v4 or v6) implementation 514 encounters an extension header that it does not recognize, it will 515 discard the packet and send an ICMP message. IPsec will never see 516 the packet. If the IPsec implementation encounters an IPv4 option 517 that it does not recognize, it should zero the whole option, using 518 the second byte of the option as the length. IPv6 options (in 519 Destination extension headers or the Hop by Hop extension header) 520 contain a flag indicating mutability, which determines appropriate 521 processing for such options. 523 3.3.3.1.1 ICV Computation for IPv4 525 3.3.3.1.1.1 Base Header Fields 527 The IPv4 base header fields are classified as follows: 529 Immutable 530 Version 531 Internet Header Length 532 Total Length 533 Identification 534 Protocol (This should be the value for AH.) 535 Source Address 536 Destination Address (without loose or strict source routing) 538 Mutable but predictable 539 Destination Address (with loose or strict source routing) 541 Mutable (zeroed prior to ICV calculation) 542 Type of Service (TOS) 543 Flags 544 Fragment Offset 545 Time to Live (TTL) 546 Header Checksum 548 TOS -- This field is excluded because some routers are known to 549 change the value of this field, even though the IP specification 550 does not consider TOS to be a mutable header field. 552 Flags -- This field is excluded since an intermediate router 553 might set the DF bit, even if the source did not select it. 555 Fragment Offset -- Since AH is applied only to non-fragmented IP 556 packets, the Offset Field must always be zero, and thus it is 557 excluded (even though it is predictable). 559 TTL -- This is changed en-route as a normal course of processing 560 by routers, and thus its value at the receiver is not predictable by 561 the sender. 563 Header Checksum -- This will change if any of these other fields 564 changes, and thus its value upon reception cannot be predicted by 565 the sender. 567 3.3.3.1.1.2 Options 569 For IPv4 (unlike IPv6), there is no mechanism for tagging options as 570 mutable in transit. Hence the IPv4 options are explicitly listed in 571 Appendix A and classified as immutable, mutable but predictable, or 572 mutable. For IPv4, the entire option is viewed as a unit; so even 573 though the type and length fields within most options are immutable 574 in transit, if an option is classified as mutable, the entire option 575 is zeroed for ICV computation purposes. 577 3.3.3.1.2 ICV Computation for IPv6 579 3.3.3.1.2.1 Base Header Fields 581 The IPv6 base header fields are classified as follows: 583 Immutable 584 Version 585 Payload Length 586 Next Header (This should be the value for AH.) 587 Source Address 588 Destination Address (without Routing Extension Header) 590 Mutable but predictable 591 Destination Address (with Routing Extension Header) 593 Mutable (zeroed prior to ICV calculation) 594 Class 595 Flow Label 596 Hop Limit 598 3.3.3.1.2.2 Extension Headers Containing Options 600 IPv6 options in the Hop-by-Hop and Destination Extension Headers 601 contain a bit that indicates whether the option might change 602 (unpredictably) during transit. For any option for which contents 603 may change en-route, the entire "Option Data" field must be treated 604 as zero-valued octets when computing or verifying the ICV. The 605 Option Type and Opt Data Len are included in the ICV calculation. 606 All options for which the bit indicates immutability are included in 607 the ICV calculation. See the IPv6 specification [DH95] for more 608 information. 610 3.3.3.1.2.3 Extension Headers Not Containing Options 612 The IPv6 extension headers that do not contain options are explicitly 613 listed in Appendix A and classified as immutable, mutable but 614 predictable, or mutable. 616 3.3.3.2 Padding & Extended Sequence Numbers 618 3.3.3.2.1 ICV Padding 620 As mentioned in section 2.6, the ICV field may include explicit 621 padding if required to ensure that the AH header is a multiple of 32 622 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is 623 determined by two factors: 625 - the length of the ICV 626 - the IP protocol version (v4 or v6) 628 For example, if the output of the selected algorithm is 96-bits, no 629 padding is required for either IPv4 or for IPv6. However, if a 630 different length ICV is generated, due to use of a different 631 algorithm, then padding may be required depending on the length and 632 IP protocol version. The content of the padding field is arbitrarily 633 selected by the sender. (The padding is arbitrary, but need not be 634 random to achieve security.) These padding bytes are included in the 635 ICV calculation, counted as part of the Payload Length, and 636 transmitted at the end of the ICV field to enable the receiver to 637 perform the ICV calculation. 639 3.3.3.2.2 Implicit Packet Padding & ESN 641 If the ESN option is elected for an SA, then the high order 32 bits 642 of the ESN must be included in the ICV computation. For purposes of 643 ICV computation, these bits are appended (implicitly) immediately 644 after the end of the payload, and before any implicit packet padding. 646 For some integrity algorithms, the byte string over which the ICV 647 computation is performed must be a multiple of a blocksize specified 648 by the algorithm. If the IP packet length (including AH and the 32 649 high order bits of the ESN, if enabled) does not match the blocksize 650 requirements for the algorithm, implicit padding MUST be appended to 651 the end of the packet, prior to ICV computation. The padding octets 652 MUST have a value of zero. The blocksize (and hence the length of 653 the padding) is specified by the algorithm specification. This 654 padding is not transmitted with the packet. Note that MD5 and SHA-1 655 are viewed as having a 1-byte blocksize because of their internal 656 padding conventions and thus no implicit packet padding is required. 658 3.3.4 Fragmentation 660 If required, IP fragmentation occurs after AH processing within an 661 IPsec implementation. Thus, transport mode AH is applied only to 662 whole IP datagrams (not to IP fragments). An IP packet to which AH 663 has been applied may itself be fragmented by routers en route, and 664 such fragments must be reassembled prior to AH processing at a 665 receiver. In tunnel mode, AH is applied to an IP packet, the payload 666 of which may be a fragmented IP packet. For example, a security 667 gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec 668 implementation (see the Security Architecture document for details) 669 may apply tunnel mode AH to such fragments. 671 NOTE: For transport mode -- As mentioned at the beginning of Section 672 3.1, bump-in-the-stack and bump-in-the-wire implementations may have 673 to first reassemble a packet fragmented by the local IP layer, then 674 apply IPsec, and then fragment the resulting packet. 676 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 677 implementations, it will be necessary to examine all the extension 678 headers to determine if there is a fragmentation header and hence 679 that the packet needs reassembling prior to IPsec processing. 681 Fragmentation, whether performed by an IPsec implementation or by 682 routers along the path between IPsec peers, significantly reduces 683 performance. Moreover, the requirement for an ESP receiver to accept 684 fragments for reassembly creates denial of service vulnerabilities. 685 Thus an ESP implementation MAY choose to not support fragmentation 686 and may mark transmitted packets with the DF bit, to facilitate PMTU 687 discovery. In any case, an ESP implementation MUST support generation 688 of ICMP PMTU messages (or equivalent internal signaling for native 689 host implementations) to minimize the likelihood of fragmentation. 690 Details of the support required for MTU management are contained in 691 the Security Architecture document. 693 3.4 Inbound Packet Processing 695 If there is more than one IPsec header/extension present, the 696 processing for each one ignores (does not zero, does not use) any 697 IPsec headers applied subsequent to the header being processed. 699 3.4.1 Reassembly 701 If required, reassembly is performed prior to AH processing. If a 702 packet offered to AH for processing appears to be an IP fragment, 703 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 704 the receiver MUST discard the packet; this is an auditable event. The 705 audit log entry for this event SHOULD include the SPI value, 706 date/time, Source Address, Destination Address, and (in IPv6) the 707 Flow ID. 709 NOTE: For packet reassembly, the current IPv4 spec does NOT require 710 either the zeroing of the OFFSET field or the clearing of the MORE 711 FRAGMENTS flag. In order for a reassembled packet to be processed by 712 IPsec (as opposed to discarded as an apparent fragment), the IP code 713 must do these two things after it reassembles a packet. 715 3.4.2 Security Association Lookup 717 Upon receipt of a packet containing an IP Authentication Header, the 718 receiver determines the appropriate (unidirectional) SA, based on the 719 destination IP address, security protocol (AH), and the SPI. (This 720 process is described in more detail in the Security Architecture 721 document.) The SA indicates whether the Sequence Number field will 722 be checked and whether 32 or 64-bit Sequence Numbers are employed for 723 the SA, specifies the algorithm(s) employed for ICV computation, and 724 indicates the key(s) required to validate the ICV. 726 If no valid Security Association exists for this session (e.g., the 727 receiver has no key to use in the ICV computation) the receiver MUST 728 discard the packet; this is an auditable event. The audit log entry 729 for this event SHOULD include the SPI value, date/time, Source 730 Address, Destination Address, and (in IPv6) the Flow ID. 732 3.4.3 Sequence Number Verification 734 All AH implementations MUST support the anti-replay service, though 735 its use may be enabled or disabled by the receiver on a per-SA basis. 736 (Note that there are no provisions for managing transmitted Sequence 737 Number values among multiple senders directing traffic to a single SA 738 (irrespective of whether the destination address is unicast, 739 broadcast, or multicast). Thus the anti-replay service SHOULD NOT be 740 used in a multi-sender environment that employs a single SA.) 742 If the receiver does not enable anti-replay for an SA, no inbound 743 checks are performed on the Sequence Number. However, from the 744 perspective of the sender, the default is to assume that anti-replay 745 is enabled at the receiver. To avoid having the sender do 746 unnecessary sequence number monitoring and SA setup (see section 747 3.3.2 "Sequence Number Generation"), if an SA establishment protocol 748 such as IKE is employed, the receiver SHOULD notify the sender, 749 during SA establishment, if the receiver will not provide anti- 750 replay protection. 752 If the receiver has enabled the anti-replay service for this SA, the 753 receive packet counter for the SA MUST be initialized to zero when 754 the SA is established. For each received packet, the receiver MUST 755 verify that the packet contains a Sequence Number that does not 756 duplicate the Sequence Number of any other packets received during 757 the life of this SA. This SHOULD be the first AH check applied to a 758 packet after it has been matched to an SA, to speed rejection of 759 duplicate packets. 761 Duplicates are rejected through the use of a sliding receive window. 762 How the window is implemented is a local matter, but the following 763 text describes the functionality that the implementation must 764 exhibit. 766 The "right" edge of the window represents the highest, validated 767 Sequence Number value received on this SA. Packets that contain 768 Sequence Numbers lower than the "left" edge of the window are 769 rejected. Packets falling within the window are checked against a 770 list of received packets within the window. 772 If the ESN option is selected for an SA, only the low-order 32 bits 773 of the sequence number are explicitly transmitted; but the receiver 774 employs the full sequence number computed using the high-order 32 775 bits for the indicated SA (from his local counter) when checking the 776 received Sequence Number against the receive window. In constructing 777 the full Sequence Number, if the low order 32 bits carried in the 778 packet are lower in value than the low order 32 bits of the 779 receiver�s Sequence Number, the receiver assumes that the high order 780 32 bits have been incremented, moving to a new sequence number 781 subspace. (This algorithm accommodates gaps in reception for a single 782 SA as large as 2**32-1 packets. If a larger gap occurs, additional, 783 heuristic checks for resynchronization of the receiver�s Sequence 784 Number counter MAY be employed, as described in Appendix B.) 786 If the received packet falls within the window and is not a 787 duplicate, or if the packet is to the right of the window, then the 788 receiver proceeds to ICV verification. If the ICV validation fails, 789 the receiver MUST discard the received IP datagram as invalid. This 790 is an auditable event. The audit log entry for this event SHOULD 791 include the SPI value, date/time, Source Address, Destination 792 Address, the Sequence Number, and (in IPv6) the Flow ID. The receive 793 window is updated only if the ICV verification succeeds. 795 A MINIMUM window size of 32 packets MUST be supported; but a window 796 size of 64 is preferred and SHOULD be employed as the default. 797 Another window size (larger than the MINIMUM) MAY be chosen by the 798 receiver. (The receiver does NOT notify the sender of the window 799 size.) The receive window size should be increased for higher speed 800 environments, irrespective of assurance issues. Values for minimum 801 and recommended receive window sizes for very high speed (e.g., 802 multi-gigabit/second) devices are not specified by this standard. 804 3.4.4 Integrity Check Value Verification 806 The receiver computes the ICV over the appropriate fields of the 807 packet, using the specified integrity algorithm, and verifies that it 808 is the same as the ICV included in the ICV field of the packet. 810 Details of the computation are provided below. 812 If the computed and received ICV's match, then the datagram is valid, 813 and it is accepted. If the test fails, then the receiver MUST 814 discard the received IP datagram as invalid. This is an auditable 815 event. The audit log entry SHOULD include the SPI value, date/time 816 received, Source Address, Destination Address, and (in IPv6) the Flow 817 ID. 819 DISCUSSION: 821 Begin by saving the ICV value and replacing it (but not any ICV 822 field padding) with zero. Zero all other fields that may have 823 been modified during transit. (See section 3.3.3.1, "Handling 824 Mutable Fields", for a discussion of which fields are zeroed 825 before performing the ICV calculation.) IF the ESN option is 826 elected for this SA, append the high order 32 bits of the ESN 827 after the end of the packet. Check the overall length of the 828 packet (as described above), and if it requires implicit padding 829 based on the requirements of the integrity algorithm, append zero- 830 filled bytes to the end of the packet (after the ESN if present) 831 as required. Perform the ICV computation and compare the result 832 with the saved value, using the comparison rules defined by the 833 algorithm specification. (For example, if a digital signature and 834 one-way hash are used for the ICV computation, the matching 835 process is more complex.) 837 4. Auditing 839 Not all systems that implement AH will implement auditing. However, 840 if AH is incorporated into a system that supports auditing, then the 841 AH implementation MUST also support auditing and MUST allow a system 842 administrator to enable or disable auditing for AH. For the most 843 part, the granularity of auditing is a local matter. However, 844 several auditable events are identified in this specification and for 845 each of these events a minimum set of information that SHOULD be 846 included in an audit log is defined. Additional information also MAY 847 be included in the audit log for each of these events, and additional 848 events, not explicitly called out in this specification, also MAY 849 result in audit log entries. There is no requirement for the 850 receiver to transmit any message to the purported sender in response 851 to the detection of an auditable event, because of the potential to 852 induce denial of service via such action. 854 5. Conformance Requirements 856 Implementations that claim conformance or compliance with this 857 specification MUST fully implement the AH syntax and processing 858 described here and MUST comply with all requirements of the Security 859 Architecture document. If the key used to compute an ICV is manually 860 distributed, correct provision of the anti-replay service would 861 require correct maintenance of the counter state at the sender, until 862 the key is replaced, and there likely would be no automated recovery 863 provision if counter overflow were imminent. Thus a compliant 864 implementation SHOULD NOT provide this service in conjunction with 865 SAs that are manually keyed. A compliant AH implementation MUST 866 support the following mandatory-to-implement algorithms: 868 - HMAC with MD5 [MG97a] 869 - HMAC with SHA-1 [MG97b] 871 6. Security Considerations 873 Security is central to the design of this protocol, and these 874 security considerations permeate the specification. Additional 875 security-relevant aspects of using the IPsec protocol are discussed 876 in the Security Architecture document. 878 7. Differences from RFC 1826 880 This document differs from RFC 2402 in the following ways. 881 o SPI -- modified to better reflect the differences between 882 unicast and multicast SA lookups. For unicast, the SPI may be 883 used alone to select an SA; for multicast, the SPI is combined 884 with destination address to select an SA. 885 o Sequence number -- added a new option for a 64-bit sequence 886 number for very high-speed communications. 888 Acknowledgements 890 The author would like to acknowledge the contributions of Ran 891 Atkinson, who played a critical role in initial IPsec activities, and 892 who authored the first series of IPsec standards: RFCs 1825-1827. 893 Karen Seo deserves special thanks for providing help in the editing 894 of this and the previous version of this specification. The author 895 also would like to thank the members of the IPsec working group. 897 References 899 [ATK95] Atkinson, R., "The IP Authentication Header", RFC 1826, 900 August 1995. 902 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Level", BCP 14, RFC 2119, March 1997. 905 [DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 906 (IPv6) Specification", RFC 1883, December 1995. 908 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", 909 RFC 2409, November 1998. 911 [KA98a] Kent, S., and R. Atkinson, "Security Architecture for the 912 Internet Protocol", RFC 2401, November 1998. 914 [KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload 915 (ESP)", RFC 2406, November 1998. 917 [KA98c] Kent, S., and R. Atkinson, "IP Authentication Header (AH)", 918 RFC 2402, November 1998. 920 [MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP 921 and AH", RFC 2403, November 1998. 923 [MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within 924 ESP and AH", RFC 2404, November 1998. 926 Disclaimer 928 The views and specification here are those of the authors and are not 929 necessarily those of their employers. The authors and their 930 employers specifically disclaim responsibility for any problems 931 arising from correct or incorrect implementation or use of this 932 specification. 934 Author Information 936 Stephen Kent 937 BBN Technologies 938 10 Moulton Street 939 Cambridge, MA 02138 940 USA 941 Phone: +1 (617) 873-3988 942 EMail: kent@bbn.com 944 Appendix A -- Mutability of IP Options/Extension Headers 946 A1. IPv4 Options 948 This table shows how the IPv4 options are classified with regard to 949 "mutability". Where two references are provided, the second one 950 supercedes the first. This table is based in part on information 951 provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). 953 Opt. 954 Copy Class # Name Reference 955 ---- ----- --- ------------------------- -------- 956 IMMUTABLE -- included in ICV calculation 957 0 0 0 End of Options List [RFC791] 958 0 0 1 No Operation [RFC791] 959 1 0 2 Security [RFC1108(historic but 960 in use)] 961 1 0 5 Extended Security [RFC1108(historic but 962 in use)] 963 1 0 6 Commercial Security [expired I-D, now US MIL 964 STD] 965 1 0 20 Router Alert [RFC2113] 966 1 0 21 Sender Directed Multi- [RFC1770] 967 Destination Delivery 968 MUTABLE -- zeroed 969 1 0 3 Loose Source Route [RFC791] 970 0 2 4 Time Stamp [RFC791] 971 0 0 7 Record Route [RFC791] 972 1 0 9 Strict Source Route [RFC791] 973 0 2 18 Traceroute [RFC1393] 975 EXPERIMENTAL, SUPERCEDED -- zeroed 976 1 0 8 Stream ID [RFC791, RFC1122 (Host 977 Req)] 978 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 979 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 980 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 981 0 0 10 Experimental Measurement [ZSu] 982 1 2 13 Experimental Flow Control [Finn] 983 1 0 14 Experimental Access Ctl [Estrin] 984 0 0 15 ??? [VerSteeg] 985 1 0 16 IMI Traffic Descriptor [Lee] 986 1 0 19 Address Extension [Ullmann IPv7] 988 NOTE: Use of the Router Alert option is potentially incompatible with 989 use of IPsec. Although the option is immutable, its use implies that 990 each router along a packet's path will "process" the packet and 991 consequently might change the packet. This would happen on a hop by 992 hop basis as the packet goes from router to router. Prior to being 993 processed by the application to which the option contents are 994 directed, e.g., RSVP/IGMP, the packet should encounter AH processing. 995 However, AH processing would require that each router along the path 996 is a member of a multicast-SA defined by the SPI. This might pose 997 problems for packets that are not strictly source routed, and it 998 requires multicast support techniques not currently available. 1000 NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by 1001 systems along a packet's path conflicts with the classification of 1002 these IP Options as immutable and is incompatible with the use of 1003 IPsec. 1005 NOTE: End of Options List options SHOULD be repeated as necessary to 1006 ensure that the IP header ends on a 4 byte boundary in order to 1007 ensure that there are no unspecified bytes which could be used for a 1008 covert channel. 1010 A2. IPv6 Extension Headers 1012 This table shows how the IPv6 Extension Headers are classified with 1013 regard to "mutability". 1015 Option/Extension Name Reference 1016 ----------------------------------- --------- 1017 MUTABLE BUT PREDICTABLE -- included in ICV calculation 1018 Routing (Type 0) [RFC1883] 1020 BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING 1021 TRANSIT) 1022 Hop by Hop options [RFC1883] 1023 Destination options [RFC1883] 1025 NOT APPLICABLE 1026 Fragmentation [RFC1883] 1028 Options -- IPv6 options in the Hop-by-Hop and Destination 1029 Extension Headers contain a bit that indicates whether the option 1030 might change (unpredictably) during transit. For any option for 1031 which contents may change en-route, the entire "Option Data" field 1032 must be treated as zero-valued octets when computing or verifying 1033 the ICV. The Option Type and Opt Data Len are included in the ICV 1034 calculation. All options for which the bit indicates immutability 1035 are included in the ICV calculation. See the IPv6 specification 1036 [DH95] for more information. 1038 Routing (Type 0) -- The IPv6 Routing Header "Type 0" will 1039 rearrange the address fields within the packet during transit from 1040 source to destination. However, the contents of the packet as it 1041 will appear at the receiver are known to the sender and to all 1042 intermediate hops. Hence, the IPv6 Routing Header "Type 0" is 1043 included in the Authentication Data calculation as mutable but 1044 predictable. The sender must order the field so that it appears as 1045 it will at the receiver, prior to performing the ICV computation. 1047 Fragmentation -- Fragmentation occurs after outbound IPsec 1048 processing (section 3.3) and reassembly occurs before inbound IPsec 1049 processing (section 3.4). So the Fragmentation Extension Header, if 1050 it exists, is not seen by IPsec. 1052 Note that on the receive side, the IP implementation could 1053 leave a Fragmentation Extension Header in place when it does re- 1054 assembly. If this happens, then when AH receives the packet, before 1055 doing ICV processing, AH MUST "remove" (or skip over) this header 1056 and change the previous header's "Next Header" field to be the "Next 1057 Header" field in the Fragmentation Extension Header. 1059 Note that on the send side, the IP implementation could give 1060 the IPsec code a packet with a Fragmentation Extension Header with 1061 Offset of 0 (first fragment) and a More Fragments Flag of 0 (last 1062 fragment). If this happens, then before doing ICV processing, AH 1063 MUST first "remove" (or skip over) this header and change the 1064 previous header's "Next Header" field to be the "Next Header" field 1065 in the Fragmentation Extension Header. 1067 Appendix B -- Extended (64-bit) Sequence Numbers 1069 B1. Overview 1071 This appendix describes an extended sequence number (ESN) scheme for 1072 use with IPsec (ESP and AH) that employs a 64-bit sequence number, 1073 but in which only the low order 32 bits are transmitted as part of 1074 each packet. It covers both the window scheme used to detect 1075 replayed packets and the determination of the high order bits of the 1076 sequence number that are used both for replay rejection and for 1077 computation of the ICV. It also discusses a mechanism for handling 1078 loss of synchronization relative to the (not transmitted) high order 1079 bits. 1081 B2. Anti-Replay Window 1083 The receiver will maintain an anti-replay window of size W. This 1084 window will limit how far out of order a packet can be, relative to 1085 the packet with the highest sequence number that has been 1086 authenticated so far. (No requirement is established for minimum or 1087 recommended sizes for this window, beyond the 32 and 64-packet values 1088 already established for 32-bit sequence number windows. However, it 1089 is suggested that an implementer scale these values consistent with 1090 the interface speed supported by an implementation that makes use of 1091 the ESN option. Also, the algorithm described below assumes that the 1092 window is no greater than 2^31 packets in width.) All 2^32 sequence 1093 numbers associated with any fixed value for the high order 32 bits 1094 (Seqh) will hereafter be called a sequence number subspace. The 1095 following table lists pertinent variables and their definitions. 1097 Var. Size 1098 Name (bits) Meaning 1099 ---- ------ --------------------------- 1100 W 32 Size of window 1101 T 64 Highest sequence number authenticated so far, 1102 upper bound of window 1103 Tl 32 Lower 32 bits of T 1104 Th 32 Upper 32 bits of T 1105 B 64 Lower bound of window 1106 Bl 32 Lower 32 bits of B 1107 Bh 32 Upper 32 bits of B 1108 Seq 64 Sequence number of received packet 1109 Seql 32 Lower 32 bits of Seq 1110 Seqh 32 Upper 32 bits of Seq 1112 When performing the anti-replay check, or when determining which high 1113 order bits to use to authenticate an incoming packet, there are two 1114 cases: 1116 + Case A: Tl >= (W - 1). In this case, the window is within one 1117 sequence number subspace. (See Figure 1) 1118 + Case B: Tl < (W - 1). In this case, the window spans two 1119 sequence number subspaces. (See Figure 2) 1121 In the figures below, the bottom line ("----") shows two consecutive 1122 sequence number subspaces, with zero's indicating the beginning of 1123 each subspace. The two shorter lines above it show the higher order 1124 bits that apply. The "====" represents the window. The "****" 1125 represents future sequence numbers, i.e., those beyond the current 1126 highest sequence number authenticated (ThTl). 1128 Th+1 ********* 1130 Th =======***** 1132 --0--------+-----+-----0--------+-----------0-- 1133 Bl Tl Bl 1134 (Bl+2^32) mod 2^32 1136 Figure 1 -- Case A 1138 Th ====************** 1140 Th-1 === 1142 --0-----------------+--0--+--------------+--0-- 1143 Bl Tl Bl 1144 (Bl+2^32) mod 2^32 1146 Figure 2 -- Case B 1148 B2.1. Managing and Using the Anti-Replay Window 1150 The anti-replay window can be thought of as a string of bits where 1151 `W' defines the length of the string. W = T - B + 1 and cannot 1152 exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and 1153 the top-most bit corresponds to T and each sequence number from Bl 1154 through Tl is represented by a corresponding bit. The value of the 1155 bit indicates whether or not a packet with that sequence number has 1156 been received and authenticated, so that replays can be detected and 1157 rejected. 1159 When a packet with a 64-bit sequence number (Seq) greater than T is 1160 received and validated, 1161 + B is increased by (Seq - T) 1162 + (Seq - T) bits are dropped from the low end of the window 1163 + (Seq - T) bits are added to the high end of the window 1164 + The top bit is set to indicate that a packet with that sequence 1165 number has been received and authenticated 1166 + The new bits between T and the top bit are set to indicate that 1167 no packets with those sequence numbers have been received yet. 1168 + T is set to the new sequence number 1170 In checking for replayed packets, 1172 + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND 1173 Seql <= Tl, then check the corresponding bit in the window to see 1174 if this Seql has already been seen. If yes, reject the packet. 1175 If no, perform integrity check (see Section 2.2. below for 1176 determination of SeqH). 1178 + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR 1179 Seql <= Tl, then check the corresponding bit in the window to see 1180 if this Seql has already been seen. If yes, reject the packet. 1181 If no, perform integrity check (see Section 2.2. below for 1182 determination of Seqh). 1184 B2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number 1186 Since only `Seql' will be transmitted with the packet, the receiver 1187 must deduce and track the sequence number subspace into which each 1188 packet falls, i.e., determine the value of Seqh. The following 1189 equations define how to select Seqh under "normal" conditions; see 1190 Section 3 for a discussion of how to recover from extreme packet 1191 loss. 1193 + Under Case A (Figure 1): 1194 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th 1195 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1 1197 + Under Case B (Figure 2): 1198 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 1199 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th 1201 B2.3. Pseudo-code Example 1203 The following pseudo-code illustrates the above algorithms for anti- 1204 replay and integrity checks. The values for `Seql', `Tl', `Th' and 1205 `W', are 32-bit unsigned integers. Arithmetic is mod 2^32. 1207 If (Tl >= W - 1) Case A 1208 If (Seql >= Tl - W + 1) 1209 Seqh = Th 1210 If (Seql <= Tl) 1211 If (pass replay check) 1212 If (pass integrity check) 1213 Set bit corresponding to Seql 1214 Pass the packet on 1215 Else reject packet 1216 Else reject packet 1217 Else 1218 If (pass integrity check) 1219 Tl = Seql (shift bits) 1220 Set bit corresponding to Seql 1221 Pass the packet on 1222 Else reject packet 1223 Else 1224 Seqh = Th + 1 1225 If (pass integrity check) 1226 Tl = Seql (shift bits) 1227 Th = Th + 1 1228 Set bit corresponding to Seql 1229 Pass the packet on 1230 Else reject packet 1231 Else Case B 1232 If (Seql >= Tl - W + 1) 1233 Seqh = Th - 1 1234 If (pass replay check) 1235 If (pass integrity check) 1236 Set the bit corresponding to Seql 1237 Pass packet on 1238 Else reject packet 1239 Else reject packet 1240 Else 1241 If (Seql <= Tl) 1242 If (pass replay check) 1243 If (pass integrity check) 1244 Set the bit corresponding to Seql 1245 Pass packet on 1246 Else reject packet 1247 Else reject packet 1248 Else 1249 If (pass integrity check) 1250 Tl = Seql (shift bits) 1251 Set the bit corresponding to Seql 1252 Pass packet on 1253 Else reject packet 1255 B3. Handling Loss of Synchronization due to Significant Packet Loss 1257 If there is an undetected packet loss of 2^32 or more consecutive 1258 packets on a single SA, then the transmitter and receiver will lose 1259 synchronization of the high order bits, i.e., the equations in 1260 Section 2.2. will fail to yield the correct value. Unless this 1261 problem is detected and addressed, subsequent packets on this SA will 1262 fail authentication checks and be discarded. The following procedure 1263 SHOULD be implemented by any IPsec (ESP or AH) implementation that 1264 supports the ESN option. 1266 Note that this sort of extended traffic loss seems unlikely to occur 1267 if any significant fraction of the traffic on the SA in question is 1268 TCP, because the source would fail to receive ACKs and would stop 1269 sending long before 2^32 packets had been lost. Also, for any bi- 1270 directional application, even ones operating above UDP, such an 1271 extended outage would likely result in triggering some form of 1272 timeout. However, a unidirectional application, operating over UDP 1273 might lack feedback that would cause automatic detection of a loss of 1274 this magnitude, hence the motivation to develop a recovery method for 1275 this case. 1277 The solution we've chosen was selected to: 1279 + minimize the impact on normal traffic processing 1281 + avoid creating an opportunity for a new denial of service attack 1282 such as might occur by allowing an attacker to force diversion of 1283 resources to a resynchronization process. 1285 + limit the recovery mechanism to the receiver -- since anti-replay 1286 is a service only for the receiver, and the transmitter generally 1287 is not aware of whether the receiver is using sequence numbers in 1288 support of this optional service, it is preferable for recovery 1289 mechanisms to be local to the receiver. This also allows for 1290 backwards compatibility. 1292 B3.1. Triggering Resynchronization 1294 For each SA, the receiver records the number of consecutive packets 1295 that fail authentication. This count is used to trigger the 1296 resynchronization process which should be performed in the background 1297 or using a separate processor. Receipt of a valid packet on the SA 1298 resets the counter to zero. The value used to trigger the 1299 resynchronization process is a local parameter. There is no 1300 requirement to support distinct trigger values for different SAs, 1301 although an implementer may choose to do so. 1303 B3.2. Resynchronization Process 1305 When the above trigger point is reached, a "bad" packet is selected 1306 for which authentication is retried using successively larger values 1307 for the upper half of the sequence number (Seqh). These values are 1308 generated by incrementing by one for each retry. The number of 1309 retries should be limited, in case this is a packet from the "past" 1310 or a bogus packet. The limit value is a local parameter. (Because 1311 the Seqh value is implicitly placed after the ESP (or AH) payload, it 1312 may be possible to optimize this procedure by executing the integrity 1313 algorithm over the packet up to the end point of the payload, then 1314 compute different candidate ICV's by varying the value of Seqh.) 1315 Successful authentication of a packet via this procedure resets the 1316 consecutive failure count and sets the value of T to that of the 1317 received packet. 1319 This solution requires support only on the part of the receiver, 1320 thereby allowing for backwards compatibility. Also, because 1321 resynchronization efforts would either occur in the background or 1322 utilize an additional processor, this solution does not impact 1323 traffic processing and a denial of service attack cannot divert 1324 resources away from traffic processing. 1326 Copyright (C) The Internet Society (2002). All Rights Reserved. 1328 This document and translations of it may be copied and furnished to 1329 others, and derivative works that comment on or otherwise explain it 1330 or assist in its implementation may be prepared, copied, published 1331 and distributed, in whole or in part, without restriction of any 1332 kind, provided that the above copyright notice and this paragraph are 1333 included on all such copies and derivative works. However, this 1334 document itself may not be modified in any way, such as by removing 1335 the copyright notice or references to the Internet Society or other 1336 Internet organizations, except as needed for the purpose of 1337 developing Internet standards in which case the procedures for 1338 copyrights defined in the Internet Standards process must be 1339 followed, or as required to translate it into languages other than 1340 English. 1342 The limited permissions granted above are perpetual and will not be 1343 revoked by the Internet Society or its successors or assigns. 1345 This document and the information contained herein is provided on an 1346 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1347 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1348 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1349 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1350 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1352 Expires January 2003