idnits 2.17.1 draft-ietf-ipsec-rfc2402bis-00.txt: -(781): 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 (March 2002) is 8078 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 413, but not defined == Missing Reference: 'RFC791' is mentioned on line 974, but not defined == Missing Reference: 'RFC2113' is mentioned on line 967, but not defined == Missing Reference: 'RFC1770' is mentioned on line 968, but not defined ** Obsolete undefined reference: RFC 1770 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1393' is mentioned on line 975, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'ZSu' is mentioned on line 983, but not defined == Missing Reference: 'Finn' is mentioned on line 984, but not defined == Missing Reference: 'Estrin' is mentioned on line 985, but not defined == Missing Reference: 'VerSteeg' is mentioned on line 986, but not defined == Missing Reference: 'Lee' is mentioned on line 987, but not defined == Missing Reference: 'RFC1883' is mentioned on line 1028, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Unused Reference: 'ATK95' is defined on line 901, but no explicit reference was found in the text == Unused Reference: 'KA98a' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'KA98b' is defined on line 916, 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 September 2002 March 2002 5 IP Authentication Header 6 draft-ietf-ipsec-rfc2402bis-00.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) SHOULD be negotiated by an SA management protocol, although it 280 could also be part of the configuration data for a manually 281 configured SA. 283 The ESN facility allows use of a 64-bit sequence number for an SA. 284 (See Appendix B, "Managing 64-bit Sequence Numbers", for details.) 285 Only the low order 32 bits of the sequence number are transmitted in 286 the AH header of each packet, thus minimizing packet overhead. The 287 high order 32 bits are maintained as part of the sequence number 288 counter by both transmitter and receiver and are included in the 289 computation of the ICV, but are not transmitted. 291 2.6 Integrity Check Value (ICV) 293 This is a variable-length field that contains the Integrity Check 294 Value (ICV) for this packet. The field must be an integral multiple 295 of 32 bits (IPv4) or 64 bits (IPv6) in length. The details of ICV 296 processing are described in Section 3.3.3 "Integrity Check Value 297 Calculation" and Section 3.4.4 "Integrity Check Value Verification." 298 This field may include explicit padding, if required to ensure that 299 the length of the AH header is an integral multiple of 32 bits (IPv4) 300 or 64 bits (IPv6). All implementations MUST support such padding. 301 Details of how to compute the required padding length are provided 302 below in Section 3.3.3.2 "Padding". The authentication algorithm 303 specification MUST specify the length of the ICV and the comparison 304 rules and processing steps for validation. 306 3. Authentication Header Processing 308 3.1 Authentication Header Location 310 Like ESP, AH may be employed in two ways: transport mode or tunnel 311 mode. The former mode is applicable only to host implementations and 312 provides protection for upper layer protocols, in addition to 313 selected IP header fields. (In this mode, note that for "bump-in- 314 the-stack" or "bump-in-the-wire" implementations, as defined in the 315 Security Architecture document, inbound and outbound IP fragments may 316 require an IPsec implementation to perform extra IP 317 reassembly/fragmentation in order to both conform to this 318 specification and provide transparent IPsec support. Special care is 319 required to perform such operations within these implementations when 320 multiple interfaces are in use.) 322 3.1.1 Transport Mode 324 In transport mode, AH is inserted after the IP header and before an 325 upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other 326 IPsec headers that have already been inserted. In the context of 327 IPv4, this calls for placing AH after the IP header (and any options 328 that it contains), but before the upper layer protocol. (Note that 329 the term "transport" mode should not be misconstrued as restricting 330 its use to TCP and UDP. For example, an ICMP message MAY be sent 331 using either "transport" mode or "tunnel" mode.) The following 332 diagram illustrates AH transport mode positioning for a typical IPv4 333 packet, on a "before and after" basis. 335 BEFORE APPLYING AH 336 ---------------------------- 337 IPv4 |orig IP hdr | | | 338 |(any options)| TCP | Data | 339 ---------------------------- 341 AFTER APPLYING AH 342 --------------------------------- 343 IPv4 |orig IP hdr | | | | 344 |(any options)| AH | TCP | Data | 345 --------------------------------- 346 |<------- authenticated ------->| 347 except for mutable fields 349 In the IPv6 context, AH is viewed as an end-to-end payload, and thus 350 should appear after hop-by-hop, routing, and fragmentation extension 351 headers. The destination options extension header(s) could appear 352 before or after or both before and after the AH header depending on 353 the semantics desired. The following diagram illustrates AH 354 transport mode positioning for a typical IPv6 packet. 356 BEFORE APPLYING AH 357 --------------------------------------- 358 IPv6 | | ext hdrs | | | 359 | orig IP hdr |if present| TCP | Data | 360 --------------------------------------- 362 AFTER APPLYING AH 363 ------------------------------------------------------------ 364 IPv6 | |hop-by-hop, dest*, | | dest | | | 365 |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | 366 ------------------------------------------------------------ 367 |<---- authenticated except for mutable fields ----------->| 369 * = if present, could be before AH, after AH, or both 371 ESP and AH headers can be combined in a variety of modes. The IPsec 372 Architecture document describes the combinations of security 373 associations that must be supported. 375 3.1.2 Tunnel Mode 377 Tunnel mode AH may be employed in either hosts or security gateways 378 (or in so-called "bump-in-the-stack" or "bump-in-the-wire" 379 implementations, as defined in the Security Architecture document). 381 When AH is implemented in a security gateway (to protect transit 382 traffic), tunnel mode MUST be used. In tunnel mode, the "inner" IP 383 header carries the ultimate source and destination addresses, while 384 an "outer" IP header may contain distinct IP addresses, e.g., 385 addresses of security gateways. In tunnel mode, AH protects the 386 entire inner IP packet, including the entire inner IP header. The 387 position of AH in tunnel mode, relative to the outer IP header, is 388 the same as for AH in transport mode. The following diagram 389 illustrates AH tunnel mode positioning for typical IPv4 and IPv6 390 packets. 392 ------------------------------------------------ 393 IPv4 | new IP hdr* | | orig IP hdr* | | | 394 |(any options)| AH | (any options) |TCP | Data | 395 ------------------------------------------------ 396 |<- authenticated except for mutable fields -->| 397 | in the new IP hdr | 399 -------------------------------------------------------------- 400 IPv6 | | ext hdrs*| | | ext hdrs*| | | 401 |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| 402 -------------------------------------------------------------- 403 |<-- authenticated except for mutable fields in new IP hdr ->| 405 * = construction of outer IP hdr/extensions and modification 406 of inner IP hdr/extensions is discussed below. 408 3.2 Authentication Algorithms 410 The authentication algorithm employed for the ICV computation is 411 specified by the SA. For point-to-point communication, suitable 412 integrity algorithms include keyed Message Authentication Codes 413 (MACs) based on symmetric encryption algorithms (e.g., AES [AES] or 414 on one-way hash functions (e.g., MD5 or SHA-1). For multicast 415 communication, one-way hash algorithms combined with asymmetric 416 signature algorithms are appropriate, though performance and space 417 considerations currently preclude use of such algorithms. The 418 mandatory-to-implement integrity algorithms are described in Section 419 5 "Conformance Requirements". Other algorithms MAY be supported. 421 3.3 Outbound Packet Processing 423 In transport mode, the sender inserts the AH header after the IP 424 header and before an upper layer protocol header, as described above. 425 In tunnel mode, the outer and inner IP header/extensions can be 426 inter-related in a variety of ways. The construction of the outer IP 427 header/extensions during the encapsulation process is described in 428 the Security Architecture document. 430 If there is more than one IPsec header/extension required, the order 431 of the application of the security headers MUST be defined by 432 security policy. For simplicity of processing, each IPsec header 433 SHOULD ignore the existence (i.e., not zero the contents or try to 434 predict the contents) of IPsec headers to be applied later. (While a 435 native IP or bump-in-the-stack implementation could predict the 436 contents of later IPsec headers that it applies itself, it won't be 437 possible for it to predict any IPsec headers added by a bump-in-the- 438 wire implementation between the host and the network.) 440 3.3.1 Security Association Lookup 442 AH is applied to an outbound packet only after an IPsec 443 implementation determines that the packet is associated with an SA 444 that calls for AH processing. The process of determining what, if 445 any, IPsec processing is applied to outbound traffic is described in 446 the Security Architecture document. 448 3.3.2 Sequence Number Generation 450 The sender's counter is initialized to 0 when an SA is established. 451 The sender increments the Sequence Number (or ESN) for this SA and 452 inserts the low-order 32 bits of the value into the Sequence Number 453 field. Thus the first packet sent using a given SA will contain a 454 Sequence Number of 1. 456 If anti-replay is enabled (the default), the sender checks to ensure 457 that the counter has not cycled before inserting the new value in the 458 Sequence Number field. In other words, the sender MUST NOT send a 459 packet on an SA if doing so would cause the Sequence Number to cycle. 460 An attempt to transmit a packet that would result in Sequence Number 461 overflow is an auditable event. The audit log entry for this event 462 SHOULD include the SPI value, current date/time, Source Address, 463 Destination Address, and (in IPv6) the cleartext Flow ID. 465 The sender assumes anti-replay is enabled as a default, unless 466 otherwise notified by the receiver (see 3.4.3) or if the SA was 467 configured using manual key management. Thus typical behavior of an 468 ESP implementation calls for the sender to establish a new SA when 469 the Sequence Number (or ESN) cycles, or in anticipation of this value 470 cycling. 472 If anti-replay is disabled (as noted above), the sender does not need 473 to monitor or reset the counter, e.g., in the case of manual key 474 management (see Section 5). However, the sender still increments the 475 counter and when it reaches the maximum value, the counter rolls over 476 back to zero. 478 If ESN (see Appendix B) is selected, only the low order 32 bits of 479 the Sequence Number are transmitted in the Sequence Number field, 480 although both sender and receiver maintain full 64-bit ESN counters. 481 However, the high order 32 bits are included in the ICV calculation. 483 3.3.3 Integrity Check Value Calculation 485 The AH ICV is computed over: 486 o IP header fields that are either immutable in transit or that 487 are predictable in value upon arrival at the endpoint for the AH 488 SA 489 o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence 490 Number (low order 32 bits), and the Authentication Data (which is 491 set to zero for this computation), and explicit padding bytes (if 492 any)) 493 o the upper level protocol data, which is assumed to be immutable 494 in transit 495 o the high order bits of the ESN (if employed), and any implicit 496 padding required by the integrity algorithm 498 3.3.3.1 Handling Mutable Fields 500 If a field may be modified during transit, the value of the field is 501 set to zero for purposes of the ICV computation. If a field is 502 mutable, but its value at the (IPsec) receiver is predictable, then 503 that value is inserted into the field for purposes of the ICV 504 calculation. The Authentication Data field is also set to zero in 505 preparation for this computation. Note that by replacing each 506 field's value with zero, rather than omitting the field, alignment is 507 preserved for the ICV calculation. Also, the zero-fill approach 508 ensures that the length of the fields that are so handled cannot be 509 gchanged during transit, even though their contents are not 510 explicitly covered by the ICV. 512 As a new extension header or IPv4 option is created, it will be 513 defined in its own RFC and SHOULD include (in the Security 514 Considerations section) directions for how it should be handled when 515 calculating the AH ICV. If the IP (v4 or v6) implementation 516 encounters an extension header that it does not recognize, it will 517 discard the packet and send an ICMP message. IPsec will never see 518 the packet. If the IPsec implementation encounters an IPv4 option 519 that it does not recognize, it should zero the whole option, using 520 the second byte of the option as the length. IPv6 options (in 521 Destination extension headers or the Hop by Hop extension header) 522 contain a flag indicating mutability, which determines appropriate 523 processing for such options. 525 3.3.3.1.1 ICV Computation for IPv4 527 3.3.3.1.1.1 Base Header Fields 529 The IPv4 base header fields are classified as follows: 531 Immutable 532 Version 533 Internet Header Length 534 Total Length 535 Identification 536 Protocol (This should be the value for AH.) 537 Source Address 538 Destination Address (without loose or strict source routing) 540 Mutable but predictable 541 Destination Address (with loose or strict source routing) 543 Mutable (zeroed prior to ICV calculation) 544 Type of Service (TOS) 545 Flags 546 Fragment Offset 547 Time to Live (TTL) 548 Header Checksum 550 TOS -- This field is excluded because some routers are known to 551 change the value of this field, even though the IP specification 552 does not consider TOS to be a mutable header field. 554 Flags -- This field is excluded since an intermediate router 555 might set the DF bit, even if the source did not select it. 557 Fragment Offset -- Since AH is applied only to non-fragmented IP 558 packets, the Offset Field must always be zero, and thus it is 559 excluded (even though it is predictable). 561 TTL -- This is changed en-route as a normal course of processing 562 by routers, and thus its value at the receiver is not predictable by 563 the sender. 565 Header Checksum -- This will change if any of these other fields 566 changes, and thus its value upon reception cannot be predicted by 567 the sender. 569 3.3.3.1.1.2 Options 571 For IPv4 (unlike IPv6), there is no mechanism for tagging options as 572 mutable in transit. Hence the IPv4 options are explicitly listed in 573 Appendix A and classified as immutable, mutable but predictable, or 574 mutable. For IPv4, the entire option is viewed as a unit; so even 575 though the type and length fields within most options are immutable 576 in transit, if an option is classified as mutable, the entire option 577 is zeroed for ICV computation purposes. 579 3.3.3.1.2 ICV Computation for IPv6 581 3.3.3.1.2.1 Base Header Fields 583 The IPv6 base header fields are classified as follows: 585 Immutable 586 Version 587 Payload Length 588 Next Header (This should be the value for AH.) 589 Source Address 590 Destination Address (without Routing Extension Header) 592 Mutable but predictable 593 Destination Address (with Routing Extension Header) 595 Mutable (zeroed prior to ICV calculation) 596 Class 597 Flow Label 598 Hop Limit 600 3.3.3.1.2.2 Extension Headers Containing Options 602 IPv6 options in the Hop-by-Hop and Destination Extension Headers 603 contain a bit that indicates whether the option might change 604 (unpredictably) during transit. For any option for which contents 605 may change en-route, the entire "Option Data" field must be treated 606 as zero-valued octets when computing or verifying the ICV. The 607 Option Type and Opt Data Len are included in the ICV calculation. 608 All options for which the bit indicates immutability are included in 609 the ICV calculation. See the IPv6 specification [DH95] for more 610 information. 612 3.3.3.1.2.3 Extension Headers Not Containing Options 614 The IPv6 extension headers that do not contain options are explicitly 615 listed in Appendix A and classified as immutable, mutable but 616 predictable, or mutable. 618 3.3.3.2 Padding & Extended Sequence Numbers 620 3.3.3.2.1 ICV Padding 622 As mentioned in section 2.6, the ICV field may include explicit 623 padding if required to ensure that the AH header is a multiple of 32 624 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is 625 determined by two factors: 627 - the length of the ICV 628 - the IP protocol version (v4 or v6) 630 For example, if the output of the selected algorithm is 96-bits, no 631 padding is required for either IPv4 or for IPv6. However, if a 632 different length ICV is generated, due to use of a different 633 algorithm, then padding may be required depending on the length and 634 IP protocol version. The content of the padding field is arbitrarily 635 selected by the sender. (The padding is arbitrary, but need not be 636 random to achieve security.) These padding bytes are included in the 637 ICV calculation, counted as part of the Payload Length, and 638 transmitted at the end of the ICV field to enable the receiver to 639 perform the ICV calculation. 641 3.3.3.2.2 Implicit Packet Padding & ESN 643 If the ESN option is elected for an SA, then the high order 32 bits 644 of the ESN must be included in the ICV computation. For purposes of 645 ICV computation, these bits are appended (implicitly) immediately 646 after the end of the payload, and before any implicit packet padding. 648 For some integrity algorithms, the byte string over which the ICV 649 computation is performed must be a multiple of a blocksize specified 650 by the algorithm. If the IP packet length (including AH and the 32 651 high order bits of the ESN, if enabled) does not match the blocksize 652 requirements for the algorithm, implicit padding MUST be appended to 653 the end of the packet, prior to ICV computation. The padding octets 654 MUST have a value of zero. The blocksize (and hence the length of 655 the padding) is specified by the algorithm specification. This 656 padding is not transmitted with the packet. Note that MD5 and SHA-1 657 are viewed as having a 1-byte blocksize because of their internal 658 padding conventions and thus no implicit packet padding is required. 660 3.3.4 Fragmentation 662 If required, IP fragmentation occurs after AH processing within an 663 IPsec implementation. Thus, transport mode AH is applied only to 664 whole IP datagrams (not to IP fragments). An IP packet to which AH 665 has been applied may itself be fragmented by routers en route, and 666 such fragments must be reassembled prior to AH processing at a 667 receiver. In tunnel mode, AH is applied to an IP packet, the payload 668 of which may be a fragmented IP packet. For example, a security 669 gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec 670 implementation (see the Security Architecture document for details) 671 may apply tunnel mode AH to such fragments. 673 NOTE: For transport mode -- As mentioned at the beginning of Section 674 3.1, bump-in-the-stack and bump-in-the-wire implementations may have 675 to first reassemble a packet fragmented by the local IP layer, then 676 apply IPsec, and then fragment the resulting packet. 678 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 679 implementations, it will be necessary to examine all the extension 680 headers to determine if there is a fragmentation header and hence 681 that the packet needs reassembling prior to IPsec processing. 683 Fragmentation, whether performed by an IPsec implementation or by 684 routers along the path between IPsec peers, significantly reduces 685 performance. Moreover, the requirement for an ESP receiver to accept 686 fragments for reassembly creates denial of service vulnerabilities. 687 Thus an ESP implementation MAY choose to not support fragmentation 688 and may mark transmitted packets with the DF bit, to facilitate PMTU 689 discovery. In any case, an ESP implementation MUST support generation 690 of ICMP PMTU messages (or equivalent internal signaling for native 691 host implementations) to minimize the likelihood of fragmentation. 692 Details of the support required for MTU management are contained in 693 the Security Architecture document. 695 3.4 Inbound Packet Processing 697 If there is more than one IPsec header/extension present, the 698 processing for each one ignores (does not zero, does not use) any 699 IPsec headers applied subsequent to the header being processed. 701 3.4.1 Reassembly 703 If required, reassembly is performed prior to AH processing. If a 704 packet offered to AH for processing appears to be an IP fragment, 705 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 706 the receiver MUST discard the packet; this is an auditable event. The 707 audit log entry for this event SHOULD include the SPI value, 708 date/time, Source Address, Destination Address, and (in IPv6) the 709 Flow ID. 711 NOTE: For packet reassembly, the current IPv4 spec does NOT require 712 either the zeroing of the OFFSET field or the clearing of the MORE 713 FRAGMENTS flag. In order for a reassembled packet to be processed by 714 IPsec (as opposed to discarded as an apparent fragment), the IP code 715 must do these two things after it reassembles a packet. 717 3.4.2 Security Association Lookup 719 Upon receipt of a packet containing an IP Authentication Header, the 720 receiver determines the appropriate (unidirectional) SA, based on the 721 destination IP address, security protocol (AH), and the SPI. (This 722 process is described in more detail in the Security Architecture 723 document.) The SA indicates whether the Sequence Number field will 724 be checked and whether 32 or 64-bit Sequence Numbers are employed for 725 the SA, specifies the algorithm(s) employed for ICV computation, and 726 indicates the key(s) required to validate the ICV. 728 If no valid Security Association exists for this session (e.g., the 729 receiver has no key to use in the ICV computation) the receiver MUST 730 discard the packet; this is an auditable event. The audit log entry 731 for this event SHOULD include the SPI value, date/time, Source 732 Address, Destination Address, and (in IPv6) the Flow ID. 734 3.4.3 Sequence Number Verification 736 All AH implementations MUST support the anti-replay service, though 737 its use may be enabled or disabled by the receiver on a per-SA basis. 738 (Note that there are no provisions for managing transmitted Sequence 739 Number values among multiple senders directing traffic to a single SA 740 (irrespective of whether the destination address is unicast, 741 broadcast, or multicast). Thus the anti-replay service SHOULD NOT be 742 used in a multi-sender environment that employs a single SA.) 744 If the receiver does not enable anti-replay for an SA, no inbound 745 checks are performed on the Sequence Number. However, from the 746 perspective of the sender, the default is to assume that anti-replay 747 is enabled at the receiver. To avoid having the sender do 748 unnecessary sequence number monitoring and SA setup (see section 749 3.3.2 "Sequence Number Generation"), if an SA establishment protocol 750 such as IKE is employed, the receiver SHOULD notify the sender, 751 during SA establishment, if the receiver will not provide anti- 752 replay protection. 754 If the receiver has enabled the anti-replay service for this SA, the 755 receive packet counter for the SA MUST be initialized to zero when 756 the SA is established. For each received packet, the receiver MUST 757 verify that the packet contains a Sequence Number that does not 758 duplicate the Sequence Number of any other packets received during 759 the life of this SA. This SHOULD be the first AH check applied to a 760 packet after it has been matched to an SA, to speed rejection of 761 duplicate packets. 763 Duplicates are rejected through the use of a sliding receive window. 764 How the window is implemented is a local matter, but the following 765 text describes the functionality that the implementation must 766 exhibit. 768 The "right" edge of the window represents the highest, validated 769 Sequence Number value received on this SA. Packets that contain 770 Sequence Numbers lower than the "left" edge of the window are 771 rejected. Packets falling within the window are checked against a 772 list of received packets within the window. 774 If the ESN option is selected for an SA, only the low-order 32 bits 775 of the sequence number are explicitly transmitted; but the receiver 776 employs the full sequence number computed using the high-order 32 777 bits for the indicated SA (from his local counter) when checking the 778 received Sequence Number against the receive window. In constructing 779 the full Sequence Number, if the low order 32 bits carried in the 780 packet are lower in value than the low order 32 bits of the 781 receiver�s Sequence Number, the receiver assumes that the high order 782 32 bits have been incremented, moving to a new sequence number 783 subspace. (This algorithm accommodates gaps in reception for a single 784 SA as large as 2**32-1 packets. If a larger gap occurs, additional, 785 heuristic checks for resynchronization of the receiver�s Sequence 786 Number counter MAY be employed, as described in Appendix B.) 788 If the received packet falls within the window and is not a 789 duplicate, or if the packet is to the right of the window, then the 790 receiver proceeds to ICV verification. If the ICV validation fails, 791 the receiver MUST discard the received IP datagram as invalid. This 792 is an auditable event. The audit log entry for this event SHOULD 793 include the SPI value, date/time, Source Address, Destination 794 Address, the Sequence Number, and (in IPv6) the Flow ID. The receive 795 window is updated only if the ICV verification succeeds. 797 A MINIMUM window size of 32 packets MUST be supported; but a window 798 size of 64 is preferred and SHOULD be employed as the default. 799 Another window size (larger than the MINIMUM) MAY be chosen by the 800 receiver. (The receiver does NOT notify the sender of the window 801 size.) The receive window size should be increased for higher speed 802 environments, irrespective of assurance issues. Values for minimum 803 and recommended receive window sizes for very high speed (e.g., 804 multi-gigabit/second) devices are not specified by this standard. 806 3.4.4 Integrity Check Value Verification 808 The receiver computes the ICV over the appropriate fields of the 809 packet, using the specified integrity algorithm, and verifies that it 810 is the same as the ICV included in the ICV field of the packet. 812 Details of the computation are provided below. 814 If the computed and received ICV's match, then the datagram is valid, 815 and it is accepted. If the test fails, then the receiver MUST 816 discard the received IP datagram as invalid. This is an auditable 817 event. The audit log entry SHOULD include the SPI value, date/time 818 received, Source Address, Destination Address, and (in IPv6) the Flow 819 ID. 821 DISCUSSION: 823 Begin by saving the ICV value and replacing it (but not any ICV 824 field padding) with zero. Zero all other fields that may have 825 been modified during transit. (See section 3.3.3.1, "Handling 826 Mutable Fields", for a discussion of which fields are zeroed 827 before performing the ICV calculation.) IF the ESN option is 828 elected for this SA, append the high order 32 bits of the ESN 829 after the end of the packet. Check the overall length of the 830 packet (as described above), and if it requires implicit padding 831 based on the requirements of the integrity algorithm, append zero- 832 filled bytes to the end of the packet (after the ESN if present) 833 as required. Perform the ICV computation and compare the result 834 with the saved value, using the comparison rules defined by the 835 algorithm specification. (For example, if a digital signature and 836 one-way hash are used for the ICV computation, the matching 837 process is more complex.) 839 4. Auditing 841 Not all systems that implement AH will implement auditing. However, 842 if AH is incorporated into a system that supports auditing, then the 843 AH implementation MUST also support auditing and MUST allow a system 844 administrator to enable or disable auditing for AH. For the most 845 part, the granularity of auditing is a local matter. However, 846 several auditable events are identified in this specification and for 847 each of these events a minimum set of information that SHOULD be 848 included in an audit log is defined. Additional information also MAY 849 be included in the audit log for each of these events, and additional 850 events, not explicitly called out in this specification, also MAY 851 result in audit log entries. There is no requirement for the 852 receiver to transmit any message to the purported sender in response 853 to the detection of an auditable event, because of the potential to 854 induce denial of service via such action. 856 5. Conformance Requirements 858 Implementations that claim conformance or compliance with this 859 specification MUST fully implement the AH syntax and processing 860 described here and MUST comply with all requirements of the Security 861 Architecture document. If the key used to compute an ICV is manually 862 distributed, correct provision of the anti-replay service would 863 require correct maintenance of the counter state at the sender, until 864 the key is replaced, and there likely would be no automated recovery 865 provision if counter overflow were imminent. Thus a compliant 866 implementation SHOULD NOT provide this service in conjunction with 867 SAs that are manually keyed. A compliant AH implementation MUST 868 support the following mandatory-to-implement algorithms: 870 - HMAC with MD5 [MG97a] 871 - HMAC with SHA-1 [MG97b] 873 6. Security Considerations 875 Security is central to the design of this protocol, and these 876 security considerations permeate the specification. Additional 877 security-relevant aspects of using the IPsec protocol are discussed 878 in the Security Architecture document. 880 7. Differences from RFC 1826 882 This document differs from RFC 2402 in the following ways. 883 o SPI -- modified to better reflect the differences between 884 unicast and multicast SA lookups. For unicast, the SPI may be 885 used alone to select an SA; for multicast, the SPI is combined 886 with destination address to select an SA. 887 o Sequence number -- added a new option for a 64-bit sequence 888 number for very high-speed communications. 890 Acknowledgements 892 The author would like to acknowledge the contributions of Ran 893 Atkinson, who played a critical role in initial IPsec activities, and 894 who authored the first series of IPsec standards: RFCs 1825-1827. 895 Karen Seo deserves special thanks for providing help in the editing 896 of this and the previous version of this specification. The author 897 also would like to thank the members of the IPsec working group. 899 References 901 [ATK95] Atkinson, R., "The IP Authentication Header", RFC 1826, 902 August 1995. 904 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 905 Requirement Level", BCP 14, RFC 2119, March 1997. 907 [DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 908 (IPv6) Specification", RFC 1883, December 1995. 910 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", 911 RFC 2409, November 1998. 913 [KA98a] Kent, S., and R. Atkinson, "Security Architecture for the 914 Internet Protocol", RFC 2401, November 1998. 916 [KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload 917 (ESP)", RFC 2406, November 1998. 919 [KA98c] Kent, S., and R. Atkinson, "IP Authentication Header (AH)", 920 RFC 2402, November 1998. 922 [MG97a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP 923 and AH", RFC 2403, November 1998. 925 [MG97b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within 926 ESP and AH", RFC 2404, November 1998. 928 Disclaimer 930 The views and specification here are those of the authors and are not 931 necessarily those of their employers. The authors and their 932 employers specifically disclaim responsibility for any problems 933 arising from correct or incorrect implementation or use of this 934 specification. 936 Author Information 938 Stephen Kent 939 BBN Technologies 940 10 Moulton Street 941 Cambridge, MA 02138 942 USA 943 Phone: +1 (617) 873-3988 944 EMail: kent@bbn.com 946 Appendix A -- Mutability of IP Options/Extension Headers 948 A1. IPv4 Options 950 This table shows how the IPv4 options are classified with regard to 951 "mutability". Where two references are provided, the second one 952 supercedes the first. This table is based in part on information 953 provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). 955 Opt. 956 Copy Class # Name Reference 957 ---- ----- --- ------------------------- -------- 958 IMMUTABLE -- included in ICV calculation 959 0 0 0 End of Options List [RFC791] 960 0 0 1 No Operation [RFC791] 961 1 0 2 Security [RFC1108(historic but 962 in use)] 963 1 0 5 Extended Security [RFC1108(historic but 964 in use)] 965 1 0 6 Commercial Security [expired I-D, now US MIL 966 STD] 967 1 0 20 Router Alert [RFC2113] 968 1 0 21 Sender Directed Multi- [RFC1770] 969 Destination Delivery 970 MUTABLE -- zeroed 971 1 0 3 Loose Source Route [RFC791] 972 0 2 4 Time Stamp [RFC791] 973 0 0 7 Record Route [RFC791] 974 1 0 9 Strict Source Route [RFC791] 975 0 2 18 Traceroute [RFC1393] 977 EXPERIMENTAL, SUPERCEDED -- zeroed 978 1 0 8 Stream ID [RFC791, RFC1122 (Host 979 Req)] 980 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 981 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 982 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 983 0 0 10 Experimental Measurement [ZSu] 984 1 2 13 Experimental Flow Control [Finn] 985 1 0 14 Experimental Access Ctl [Estrin] 986 0 0 15 ??? [VerSteeg] 987 1 0 16 IMI Traffic Descriptor [Lee] 988 1 0 19 Address Extension [Ullmann IPv7] 990 NOTE: Use of the Router Alert option is potentially incompatible with 991 use of IPsec. Although the option is immutable, its use implies that 992 each router along a packet's path will "process" the packet and 993 consequently might change the packet. This would happen on a hop by 994 hop basis as the packet goes from router to router. Prior to being 995 processed by the application to which the option contents are 996 directed, e.g., RSVP/IGMP, the packet should encounter AH processing. 997 However, AH processing would require that each router along the path 998 is a member of a multicast-SA defined by the SPI. This might pose 999 problems for packets that are not strictly source routed, and it 1000 requires multicast support techniques not currently available. 1002 NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by 1003 systems along a packet's path conflicts with the classification of 1004 these IP Options as immutable and is incompatible with the use of 1005 IPsec. 1007 NOTE: End of Options List options SHOULD be repeated as necessary to 1008 ensure that the IP header ends on a 4 byte boundary in order to 1009 ensure that there are no unspecified bytes which could be used for a 1010 covert channel. 1012 A2. IPv6 Extension Headers 1014 This table shows how the IPv6 Extension Headers are classified with 1015 regard to "mutability". 1017 Option/Extension Name Reference 1018 ----------------------------------- --------- 1019 MUTABLE BUT PREDICTABLE -- included in ICV calculation 1020 Routing (Type 0) [RFC1883] 1022 BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING 1023 TRANSIT) 1024 Hop by Hop options [RFC1883] 1025 Destination options [RFC1883] 1027 NOT APPLICABLE 1028 Fragmentation [RFC1883] 1030 Options -- IPv6 options in the Hop-by-Hop and Destination 1031 Extension Headers contain a bit that indicates whether the option 1032 might change (unpredictably) during transit. For any option for 1033 which contents may change en-route, the entire "Option Data" field 1034 must be treated as zero-valued octets when computing or verifying 1035 the ICV. The Option Type and Opt Data Len are included in the ICV 1036 calculation. All options for which the bit indicates immutability 1037 are included in the ICV calculation. See the IPv6 specification 1038 [DH95] for more information. 1040 Routing (Type 0) -- The IPv6 Routing Header "Type 0" will 1041 rearrange the address fields within the packet during transit from 1042 source to destination. However, the contents of the packet as it 1043 will appear at the receiver are known to the sender and to all 1044 intermediate hops. Hence, the IPv6 Routing Header "Type 0" is 1045 included in the Authentication Data calculation as mutable but 1046 predictable. The sender must order the field so that it appears as 1047 it will at the receiver, prior to performing the ICV computation. 1049 Fragmentation -- Fragmentation occurs after outbound IPsec 1050 processing (section 3.3) and reassembly occurs before inbound IPsec 1051 processing (section 3.4). So the Fragmentation Extension Header, if 1052 it exists, is not seen by IPsec. 1054 Note that on the receive side, the IP implementation could 1055 leave a Fragmentation Extension Header in place when it does re- 1056 assembly. If this happens, then when AH receives the packet, before 1057 doing ICV processing, AH MUST "remove" (or skip over) this header 1058 and change the previous header's "Next Header" field to be the "Next 1059 Header" field in the Fragmentation Extension Header. 1061 Note that on the send side, the IP implementation could give 1062 the IPsec code a packet with a Fragmentation Extension Header with 1063 Offset of 0 (first fragment) and a More Fragments Flag of 0 (last 1064 fragment). If this happens, then before doing ICV processing, AH 1065 MUST first "remove" (or skip over) this header and change the 1066 previous header's "Next Header" field to be the "Next Header" field 1067 in the Fragmentation Extension Header. 1069 Appendix B -- Extended (64-bit) Sequence Numbers 1071 B1. Overview 1073 This appendix describes an extended sequence number (ESN) scheme for 1074 use with IPsec (ESP and AH) that employs a 64-bit sequence number, 1075 but in which only the low order 32 bits are transmitted as part of 1076 each packet. It covers both the window scheme used to detect 1077 replayed packets and the determination of the high order bits of the 1078 sequence number that are used both for replay rejection and for 1079 computation of the ICV. It also discusses a mechanism for handling 1080 loss of synchronization relative to the (not transmitted) high order 1081 bits. 1083 B2. Anti-Replay Window 1085 The receiver will maintain an anti-replay window of size W. This 1086 window will limit how far out of order a packet can be, relative to 1087 the packet with the highest sequence number that has been 1088 authenticated so far. (No requirement is established for minimum or 1089 recommended sizes for this window, beyond the 32 and 64-packet values 1090 already established for 32-bit sequence number windows. However, it 1091 is suggested that an implementer scale these values consistent with 1092 the interface speed supported by an implementation that makes use of 1093 the ESN option. Also, the algorithm described below assumes that the 1094 window is no greater than 2^31 packets in width.) All 2^32 sequence 1095 numbers associated with any fixed value for the high order 32 bits 1096 (Seqh) will hereafter be called a sequence number subspace. The 1097 following table lists pertinent variables and their definitions. 1099 Var. Size 1100 Name (bits) Meaning 1101 ---- ------ --------------------------- 1102 W 32 Size of window 1103 T 64 Highest sequence number authenticated so far, 1104 upper bound of window 1105 Tl 32 Lower 32 bits of T 1106 Th 32 Upper 32 bits of T 1107 B 64 Lower bound of window 1108 Bl 32 Lower 32 bits of B 1109 Bh 32 Upper 32 bits of B 1110 Seq 64 Sequence number of received packet 1111 Seql 32 Lower 32 bits of Seq 1112 Seqh 32 Upper 32 bits of Seq 1114 When performing the anti-replay check, or when determining which high 1115 order bits to use to authenticate an incoming packet, there are two 1116 cases: 1118 + Case A: Tl >= (W - 1). In this case, the window is within one 1119 sequence number subspace. (See Figure 1) 1120 + Case B: Tl < (W - 1). In this case, the window spans two 1121 sequence number subspaces. (See Figure 2) 1123 In the figures below, the bottom line ("----") shows two consecutive 1124 sequence number subspaces, with zero's indicating the beginning of 1125 each subspace. The two shorter lines above it show the higher order 1126 bits that apply. The "====" represents the window. The "****" 1127 represents future sequence numbers, i.e., those beyond the current 1128 highest sequence number authenticated (ThTl). 1130 Th+1 ********* 1132 Th =======***** 1134 --0--------+-----+-----0--------+-----------0-- 1135 Bl Tl Bl 1136 (Bl+2^32) mod 2^32 1138 Figure 1 -- Case A 1140 Th ====************** 1142 Th-1 === 1144 --0-----------------+--0--+--------------+--0-- 1145 Bl Tl Bl 1146 (Bl+2^32) mod 2^32 1148 Figure 2 -- Case B 1150 B2.1. Managing and Using the Anti-Replay Window 1152 The anti-replay window can be thought of as a string of bits where 1153 `W' defines the length of the string. W = T - B + 1 and cannot 1154 exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and 1155 the top-most bit corresponds to T and each sequence number from Bl 1156 through Tl is represented by a corresponding bit. The value of the 1157 bit indicates whether or not a packet with that sequence number has 1158 been received and authenticated, so that replays can be detected and 1159 rejected. 1161 When a packet with a 64-bit sequence number (Seq) greater than T is 1162 received and validated, 1163 + B is increased by (Seq - T) 1164 + (Seq - T) bits are dropped from the low end of the window 1165 + (Seq - T) bits are added to the high end of the window 1166 + The top bit is set to indicate that a packet with that sequence 1167 number has been received and authenticated 1168 + The new bits between T and the top bit are set to indicate that 1169 no packets with those sequence numbers have been received yet. 1170 + T is set to the new sequence number 1172 In checking for replayed packets, 1174 + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND 1175 Seql <= Tl, then check the corresponding bit in the window to see 1176 if this Seql has already been seen. If yes, reject the packet. 1177 If no, perform integrity check (see Section 2.2. below for 1178 determination of SeqH). 1180 + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR 1181 Seql <= Tl, then check the corresponding bit in the window to see 1182 if this Seql has already been seen. If yes, reject the packet. 1183 If no, perform integrity check (see Section 2.2. below for 1184 determination of Seqh). 1186 B2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number 1188 Since only `Seql' will be transmitted with the packet, the receiver 1189 must deduce and track the sequence number subspace into which each 1190 packet falls, i.e., determine the value of Seqh. The following 1191 equations define how to select Seqh under "normal" conditions; see 1192 Section 3 for a discussion of how to recover from extreme packet 1193 loss. 1195 + Under Case A (Figure 1): 1196 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th 1197 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1 1199 + Under Case B (Figure 2): 1200 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 1201 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th 1203 B2.3. Pseudo-code Example 1205 The following pseudo-code illustrates the above algorithms for anti- 1206 replay and integrity checks. The values for `Seql', `Tl', `Th' and 1207 `W', are 32-bit unsigned integers. Arithmetic is mod 2^32. 1209 If (Tl >= W - 1) Case A 1210 If (Seql >= Tl - W + 1) 1211 Seqh = Th 1212 If (Seql <= Tl) 1213 If (pass replay check) 1214 If (pass integrity check) 1215 Set bit corresponding to Seql 1216 Pass the packet on 1217 Else reject packet 1218 Else reject packet 1219 Else 1220 If (pass integrity check) 1221 Tl = Seql (shift bits) 1222 Set bit corresponding to Seql 1223 Pass the packet on 1224 Else reject packet 1225 Else 1226 Seqh = Th + 1 1227 If (pass integrity check) 1228 Tl = Seql (shift bits) 1229 Th = Th + 1 1230 Set bit corresponding to Seql 1231 Pass the packet on 1232 Else reject packet 1233 Else Case B 1234 If (Seql >= Tl - W + 1) 1235 Seqh = Th - 1 1236 If (pass replay check) 1237 If (pass integrity check) 1238 Set the bit corresponding to Seql 1239 Pass packet on 1240 Else reject packet 1241 Else reject packet 1242 Else 1243 If (Seql <= Tl) 1244 If (pass replay check) 1245 If (pass integrity check) 1246 Set the bit corresponding to Seql 1247 Pass packet on 1248 Else reject packet 1249 Else reject packet 1250 Else 1251 If (pass integrity check) 1252 Tl = Seql (shift bits) 1253 Set the bit corresponding to Seql 1254 Pass packet on 1255 Else reject packet 1257 B3. Handling Loss of Synchronization due to Significant Packet Loss 1259 If there is an undetected packet loss of 2^32 or more consecutive 1260 packets on a single SA, then the transmitter and receiver will lose 1261 synchronization of the high order bits, i.e., the equations in 1262 Section 2.2. will fail to yield the correct value. Unless this 1263 problem is detected and addressed, subsequent packets on this SA will 1264 fail authentication checks and be discarded. The following procedure 1265 SHOULD be implemented by any IPsec (ESP or AH) implementation that 1266 supports the ESN option. 1268 Note that this sort of extended traffic loss seems unlikely to occur 1269 if any significant fraction of the traffic on the SA in question is 1270 TCP, because the source would fail to receive ACKs and would stop 1271 sending long before 2^32 packets had been lost. Also, for any bi- 1272 directional application, even ones operating above UDP, such an 1273 extended outage would likely result in triggering some form of 1274 timeout. However, a unidirectional application, operating over UDP 1275 might lack feedback that would cause automatic detection of a loss of 1276 this magnitude, hence the motivation to develop a recovery method for 1277 this case. 1279 The solution we've chosen was selected to: 1281 + minimize the impact on normal traffic processing 1283 + avoid creating an opportunity for a new denial of service attack 1284 such as might occur by allowing an attacker to force diversion of 1285 resources to a resynchronization process. 1287 + limit the recovery mechanism to the receiver -- since anti-replay 1288 is a service only for the receiver, and the transmitter generally 1289 is not aware of whether the receiver is using sequence numbers in 1290 support of this optional service, it is preferable for recovery 1291 mechanisms to be local to the receiver. This also allows for 1292 backwards compatibility. 1294 B3.1. Triggering Resynchronization 1296 For each SA, the receiver records the number of consecutive packets 1297 that fail authentication. This count is used to trigger the 1298 resynchronization process which should be performed in the background 1299 or using a separate processor. Receipt of a valid packet on the SA 1300 resets the counter to zero. The value used to trigger the 1301 resynchronization process is a local parameter. There is no 1302 requirement to support distinct trigger values for different SAs, 1303 although an implementer may choose to do so. 1305 B3.2. Resynchronization Process 1307 When the above trigger point is reached, a "bad" packet is selected 1308 for which authentication is retried using successively larger values 1309 for the upper half of the sequence number (Seqh). These values are 1310 generated by incrementing by one for each retry. The number of 1311 retries should be limited, in case this is a packet from the "past" 1312 or a bogus packet. The limit value is a local parameter. (Because 1313 the Seqh value is implicitly placed after the ESP (or AH) payload, it 1314 may be possible to optimize this procedure by executing the integrity 1315 algorithm over the packet up to the end point of the payload, then 1316 compute different candidate ICV's by varying the value of Seqh.) 1317 Successful authentication of a packet via this procedure resets the 1318 consecutive failure count and sets the value of T to that of the 1319 received packet. 1321 This solution requires support only on the part of the receiver, 1322 thereby allowing for backwards compatibility. Also, because 1323 resynchronization efforts would either occur in the background or 1324 utilize an additional processor, this solution does not impact 1325 traffic processing and a denial of service attack cannot divert 1326 resources away from traffic processing. 1328 Copyright (C) The Internet Society (2002). All Rights Reserved. 1330 This document and translations of it may be copied and furnished to 1331 others, and derivative works that comment on or otherwise explain it 1332 or assist in its implementation may be prepared, copied, published 1333 and distributed, in whole or in part, without restriction of any 1334 kind, provided that the above copyright notice and this paragraph are 1335 included on all such copies and derivative works. However, this 1336 document itself may not be modified in any way, such as by removing 1337 the copyright notice or references to the Internet Society or other 1338 Internet organizations, except as needed for the purpose of 1339 developing Internet standards in which case the procedures for 1340 copyrights defined in the Internet Standards process must be 1341 followed, or as required to translate it into languages other than 1342 English. 1344 The limited permissions granted above are perpetual and will not be 1345 revoked by the Internet Society or its successors or assigns. 1347 This document and the information contained herein is provided on an 1348 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1349 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1350 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1351 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1352 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1354 Expires September 2002