idnits 2.17.1 draft-ietf-ipsec-rfc2402bis-05.txt: 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 52 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([KA98b]), 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 170 has weird spacing: '... Integ is...' == Line 182 has weird spacing: '...ariable if ne...' == Line 763 has weird spacing: '... packet the r...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2004) is 7346 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) -- Looks like a reference, but probably isn't: '1' on line 184 -- Looks like a reference, but probably isn't: '2' on line 185 -- Looks like a reference, but probably isn't: '3' on line 188 -- Looks like a reference, but probably isn't: '4' on line 190 == Missing Reference: 'AES' is mentioned on line 447, but not defined == Missing Reference: 'RFC791' is mentioned on line 1035, but not defined == Missing Reference: 'RFC2113' is mentioned on line 1028, but not defined == Missing Reference: 'RFC1770' is mentioned on line 1029, but not defined ** Obsolete undefined reference: RFC 1770 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1393' is mentioned on line 1036, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'ZSu' is mentioned on line 1044, but not defined == Missing Reference: 'Finn' is mentioned on line 1045, but not defined == Missing Reference: 'Estrin' is mentioned on line 1046, but not defined == Missing Reference: 'VerSteeg' is mentioned on line 1047, but not defined == Missing Reference: 'Lee' is mentioned on line 1048, but not defined ** Obsolete normative reference: RFC 2460 (ref. 'DH98') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2401 (ref. 'KA98a') (Obsoleted by RFC 4301) == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-01 -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'KA98b') (Obsoleted by RFC 4302, RFC 4305) Summary: 12 errors (**), 0 flaws (~~), 17 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPsec Working Group S. Kent 2 Internet Draft BBN Technologies 3 draft-ietf-ipsec-rfc2402bis-05.txt September 2003 4 Expires March 2004 6 IP Authentication Header 7 draft-ietf-ipsec-rfc2402bis-05.txt 9 Status of This Memo 11 This document is an Internet Draft and is subject to all provisions 12 of Section 10 of RFC2026. Internet Drafts are working documents of 13 the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet Drafts 17 Internet Drafts are draft documents valid for a maximum of 6 months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet Drafts as reference 20 material or to cite them other than as a "work in progress". 22 The list of current Internet Drafts can be accessed at 23 http://www.ietf.org/lid-abstracts.html 25 The list of Internet Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Copyright (C) The Internet Society (2003). All Rights Reserved. 30 Abstract 32 This document describes an updated version of the IP Authentication 33 Header (AH), which is designed to provide authentication services in 34 IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) 35 [KA98b]. 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...............................................7 47 2.5.1 Extended Sequence Number.................................7 48 2.6 Integrity Check Value (ICV) ..................................8 49 3. Authentication Header Processing...................................8 50 3.1 Authentication Header Location...............................8 51 3.1.1 Transport Mode..........................................8 52 3.1.2 Tunnel Mode.............................................9 53 3.2 Integrity Algorithms........................................10 54 3.3 Outbound Packet Processing..................................10 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...........................12 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..................................13 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.....14 65 3.3.3.1.2.3 Extension Headers Not Containing Options.14 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................15 69 3.3.4 Fragmentation..........................................15 70 3.4 Inbound Packet Processing...................................16 71 3.4.1 Reassembly.............................................16 72 3.4.2 Security Association Lookup............................16 73 3.4.3 Sequence Number Verification...........................17 74 3.4.4 Integrity Check Value Verification.....................18 75 4. Auditing..........................................................19 76 5. Conformance Requirements..........................................19 77 6. Security Considerations...........................................20 78 7. Differences from RFC 2402.........................................20 79 Acknowledgements.....................................................20 80 References...........................................................21 81 Disclaimer...........................................................21 82 Author Information...................................................22 83 Appendix A -- Mutability of IP Options/Extension Headers.............23 84 A1. IPv4 Options.................................................23 85 A2. IPv6 Extension Headers.......................................24 86 Appendix B -- Extended (64-bit) Sequence Numbers.....................26 87 Full Copyright Statement.............................................32 89 1. Introduction 91 This document assumes that the reader is familiar with the terms and 92 concepts described in the "Security Architecture for the Internet 93 Protocol" [KA98a], hereafter referred to as the Security Architecture 94 document. In particular, the reader should be familiar with the 95 definitions of security services offered by the Encapsulating 96 Security Payload (ESP) and the IP Authentication Header (AH), the 97 concept of Security Associations, the ways in which ESP can be used 98 in conjunction with the Authentication Header (AH), and the different 99 key management options available for ESP and AH. 101 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 102 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 103 document, are to be interpreted as described in RFC 2119 [Bra97]. 105 The IP Authentication Header (AH) is used to provide connectionless 106 integrity and data origin authentication for IP datagrams (hereafter 107 referred to as just "integrity"), and to provide protection against 108 replays. This latter, optional service may be selected, by the 109 receiver, when a Security Association is established. (The protocol 110 default requires the sender to increment the Sequence Number used for 111 anti-replay, but the service is effective only if the receiver checks 112 the Sequence Number.) However, to make use of the extended sequence 113 number feature in an interoperable fashion, AH does impose a 114 requirement on SA management protocols to be able to negotiate this 115 new feature (see Section 2.5.1 below). 117 AH provides authentication for as much of the IP header as possible, 118 as well as for next level protocol data. However, some IP header 119 fields may change in transit and the value of these fields, when the 120 packet arrives at the receiver, may not be predictable by the sender. 121 The values of such fields cannot be protected by AH. Thus the 122 protection provided to the IP header by AH is piecemeal. (See 123 Appendix A.) 125 AH may be applied alone, in combination with the IP Encapsulating 126 Security Payload (ESP) [Ken03], or in a nested fashion (see Security 127 Architecture document [KA98a]). Security services can be provided 128 between a pair of communicating hosts, between a pair of 129 communicating security gateways, or between a security gateway and a 130 host. ESP may be used to provide the same anti-replay and similar 131 integrity services, and it also provides a confidentiality 132 (encryption) service. The primary difference between the integrity 133 provided by ESP and AH is the extent of the coverage. Specifically, 134 ESP does not protect any IP header fields unless those fields are 135 encapsulated by ESP (e.g., via use of tunnel mode). For more details 136 on how to use AH and ESP in various network environments, see the 137 Security Architecture document [KA98a]. 139 Section 7 provides a brief review of the differences between this 140 document and RFC 2402. 142 2. Authentication Header Format 144 The protocol header (IPv4, IPv6, or IPv6 Extension) immediately 145 preceding the AH header SHALL contain the value 51 in its Protocol 146 (IPv4) or Next Header (IPv6, Extension) field [DH98]. Figure 1 147 illustrates the format for AH. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Next Header | Payload Len | RESERVED | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Security Parameters Index (SPI) | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Sequence Number Field | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | | 159 + Integrity Check Value-ICV (variable) | 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1. AH Format 165 The following table refers to the fields that comprise AH, 166 (illustrated in Figure 1), plus other fields included in the 167 integrity computation, and illustrates which fields are covered by 168 the ICV and what is transmitted. 169 What What 170 # of Requ'd Integ is 171 bytes [1] Covers Xmtd 172 ------ ------ ------ ------ 173 IP Header variable M [2] plain 174 Next Header 1 M Y plain 175 Payload Len 1 M Y plain 176 RESERVED 2 M Y plain 177 SPI 4 M Y plain 178 Seq# (low order 32-bits) 4 M Y plain 179 ICV variable M Y[3] plain 180 IP datagram [4] variable M Y plain 181 Seq# (high order 32-bits) 4 if ESN Y not xmtd 182 ICV Padding variable if need Y not xmtd 184 [1] - M = mandatory 185 [2] - See section 3.3.3 "Integrity Check Value Calculation" for 186 details of which IP header fields are covered. 188 [3] - Zero'd before ICV calculation (resulting ICV placed here 189 after calculation) 190 [4] - If tunnel mode -> IP datagram 191 If transport mode -> next header and data 193 The following subsections define the fields that comprise the AH 194 format. All the fields described here are mandatory, i.e., they are 195 always present in the AH format and are included in the Integrity 196 Check Value (ICV) computation (see Sections 2.6 and 3.3.3). 198 Note: All of the cryptographic algorithms used in IPsec expect their 199 input in canonical network byte order (see Appendix in RFC 791) and 200 generate their output in canonical network byte order. IP packets 201 are also transmitted in network byte order. 203 2.1 Next Header 205 The Next Header is an 8-bit field that identifies the type of the 206 next payload after the Authentication Header. The value of this 207 field is chosen from the set of IP Protocol Numbers defined on the 208 web page of Internet Assigned Numbers Authority (IANA), e.g., a value 209 of 4 indicates IPv4, a value of 41 indicates IPv6, and a value of 6 210 indicates TCP. 212 2.2 Payload Length 214 This 8-bit field specifies the length of AH in 32-bit words (4-byte 215 units), minus "2". (This means of expressing the length of AH was 216 selected to allow its use as an IPv6 extension header. Thus the 217 length computation is consistent with the algorithm described in RFC 218 2460 [DH98].) In the case of an integrity algorithm that yields a 219 96-bit authentication value, plus the 3 32-bit word fixed portion, 220 this length field will be "4". For IPv6, the total length of the 221 header must be a multiple of 8-octet units. See Section 2.6, 222 "Integrity Check Value (ICV)", for comments on padding of this field, 223 and Section 3.3.3.2.1 "ICV Padding". 225 2.3 Reserved 227 This 16-bit field is reserved for future use. It MUST be set to 228 "zero" by the sender, and it SHOULD be ignored by the recipient. 229 (Note that the value is included in the ICV calculation, but is 230 otherwise ignored by the recipient.) 232 2.4 Security Parameters Index (SPI) 234 The SPI is an arbitrary 32-bit value that is used by a receiver to 235 identify the SA to which an incoming packet is bound. For a unicast 236 SA, the SPI can be used by itself to specify an SA, or it may be used 237 in conjunction with the IPsec protocol type (in this case AH). 238 Since, for unicast SAs, the SPI value is generated by the receiver, 239 whether the value is sufficient to identify an SA by itself, or 240 whether it must be used in conjunction with the IPsec protocol value 241 is a local matter. The SPI field is mandatory and this mechanism for 242 mapping inbound traffic to unicast SAs described above MUST be 243 supported by all AH implementations. 245 If an IPsec implementation supports multicast, then it MUST support 246 multicast SAs using the following algorithm for mapping inbound IPsec 247 datagrams to SAs. (Implementations that support only unicast traffic 248 need not implement this demultiplexing algorithm.) Each entry in the 249 Security Association Database (SAD) [KA98a] must indicate whether the 250 SA lookup makes use of the source and destination IP addresses, in 251 addition to the SPI. (For multicast SAs, the protocol field is not 252 employed for SA lookups.) Nominally, this indication can be 253 represented by two bits, one associated with the source IP address 254 and the other for the destination IP address. A "1" value for each 255 bit indicates the need to match against the corresponding address 256 field as part of the SA lookup process. Thus, for example, unicast 257 SAs would have both bits set to zero, since neither the source nor 258 destination IP address is used for SA matching. (Only the SPI, and, 259 optionally, the protocol field are employed.) For multicast methods 260 that rely only on the destination address to specify a multicast 261 group, only the second bit would be set to "1," implying the need to 262 use the destination address plus the SPI to determine the appropriate 263 SA. For multicast methods (e.g., SSM [HC03]) that also require the 264 source address to identify a multicast group, both bits would be set 265 to "1." (There is no current requirement to support SA mapping based 266 on the source address but not the destination address, thus one of 267 the possible four values is not meaningful.) The indication whether 268 source and destination address matching is required to map inbound 269 IPsec traffic to SAs MUST be set either as a side effect of manual SA 270 configuration or via negotiation using an SA management protocol, 271 e.g., IKE [HC98]. 273 The set of SPI values in the range 1 through 255 are reserved by the 274 Internet Assigned Numbers Authority (IANA) for future use; a reserved 275 SPI value will not normally be assigned by IANA unless the use of the 276 assigned SPI value is specified in an RFC. The SPI value of zero (0) 277 is reserved for local, implementation- specific use and MUST NOT be 278 sent on the wire. (For example, a key management implementation might 279 use the zero SPI value to mean "No Security Association Exists" 280 during the period when the IPsec implementation has requested that 281 its key management entity establish a new SA, but the SA has not yet 282 been established.) 284 2.5 Sequence Number 286 This unsigned 32-bit field contains a counter value that increases by 287 one for each packet sent, i.e., a per-SA packet sequence number. For 288 a unicast SA or a single-sender multicast SA, the sender MUST 289 increment this field for every transmitted packet. Sharing an SA 290 among multiple senders is permitted, though generally not 291 recommended. AH provides no means of synchronizing packet counters 292 among multiple senders or meaningfully managing a receiver packet 293 counter and window in the context of multiple senders. Thus, for a 294 multi-sender SA, the anti-reply features of AH are not available (see 295 Sections 3.3.2 and 3.4.3.) 297 The field is mandatory and MUST always be present even if the 298 receiver does not elect to enable the anti-replay service for a 299 specific SA. Processing of the Sequence Number field is at the 300 discretion of the receiver, but all AH implementations MUST be 301 capable of performing the Sequence Number processing described in 302 Section 3.3.2 "Sequence Number Generation" and Section 3.4.3 303 "Sequence Number Verification." Thus the sender MUST always transmit 304 this field, but the receiver need not act upon it. 306 The sender's counter and the receiver's counter are initialized to 0 307 when an SA is established. (The first packet sent using a given SA 308 will have a Sequence Number of 1; see Section 3.3.2 for more details 309 on how the Sequence Number is generated.) If anti-replay is enabled 310 (the default), the transmitted Sequence Number must never be allowed 311 to cycle. Thus, the sender's counter and the receiver's counter MUST 312 be reset (by establishing a new SA and thus a new key) prior to the 313 transmission of the 2^32nd packet on an SA. 315 2.5.1 Extended (64-bit) Sequence Number 317 To support high-speed IPsec implementations, a new option for 318 sequence numbers SHOULD be offered, as an extension to the current, 319 32-bit sequence number field. Use of an Extended Sequence Number 320 (ESN) MUST be negotiated by an SA management protocol. (The ESN 321 feature is applicable to multicast as well as unicast SAs.) 323 The ESN facility allows use of a 64-bit sequence number for an SA. 324 (See Appendix B, "Managing 64-bit Sequence Numbers", for details.) 325 Only the low order 32 bits of the sequence number are transmitted in 326 the AH header of each packet, thus minimizing packet overhead. The 327 high order 32 bits are maintained as part of the sequence number 328 counter by both transmitter and receiver and are included in the 329 computation of the ICV, but are not transmitted. 331 2.6 Integrity Check Value (ICV) 333 This is a variable-length field that contains the Integrity Check 334 Value (ICV) for this packet. The field must be an integral multiple 335 of 32 bits (IPv4 or IPv6) in length. The details of ICV processing 336 are described in Section 3.3.3 "Integrity Check Value Calculation" 337 and Section 3.4.4 "Integrity Check Value Verification." This field 338 may include explicit padding, if required to ensure that the length 339 of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits 340 (IPv6). All implementations MUST support such padding. Details of 341 how to compute the required padding length are provided below in 342 Section 3.3.3.2 "Padding". The integrity algorithm specification 343 MUST specify the length of the ICV and the comparison rules and 344 processing steps for validation. 346 3. Authentication Header Processing 348 3.1 Authentication Header Location 350 AH may be employed in two ways: transport mode or tunnel mode. (See 351 the Security Architecture document for a description of when each 352 should be used.) 354 3.1.1 Transport Mode 356 In transport mode, AH is inserted after the IP header and before a 357 next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other 358 IPsec headers that have already been inserted. In the context of 359 IPv4, this calls for placing AH after the IP header (and any options 360 that it contains), but before the next layer protocol. (Note that 361 the term "transport" mode should not be misconstrued as restricting 362 its use to TCP and UDP.) The following diagram illustrates AH 363 transport mode positioning for a typical IPv4 packet, on a "before 364 and after" basis. 366 BEFORE APPLYING AH 367 ---------------------------- 368 IPv4 |orig IP hdr | | | 369 |(any options)| TCP | Data | 370 ---------------------------- 372 AFTER APPLYING AH 373 --------------------------------- 374 IPv4 |orig IP hdr | | | | 375 |(any options)| AH | TCP | Data | 376 --------------------------------- 377 |<------- authenticated ------->| 378 except for mutable fields 380 In the IPv6 context, AH is viewed as an end-to-end payload, and thus 381 should appear after hop-by-hop, routing, and fragmentation extension 382 headers. The destination options extension header(s) could appear 383 before or after or both before and after the AH header depending on 384 the semantics desired. The following diagram illustrates AH 385 transport mode positioning for a typical IPv6 packet. 387 BEFORE APPLYING AH 388 --------------------------------------- 389 IPv6 | | ext hdrs | | | 390 | orig IP hdr |if present| TCP | Data | 391 --------------------------------------- 393 AFTER APPLYING AH 394 ------------------------------------------------------------ 395 IPv6 | |hop-by-hop, dest*, | | dest | | | 396 |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | 397 ------------------------------------------------------------ 398 |<---- authenticated except for mutable fields ----------->| 400 * = if present, could be before AH, after AH, or both 402 ESP and AH headers can be combined in a variety of modes. The IPsec 403 Architecture document describes the combinations of security 404 associations that must be supported. 406 Note that in transport mode, for "bump-in- the-stack" or "bump-in- 407 the-wire" implementations, as defined in the Security Architecture 408 document, inbound and outbound IP fragments may require an IPsec 409 implementation to perform extra IP reassembly/fragmentation in order 410 to both conform to this specification and provide transparent IPsec 411 support. Special care is required to perform such operations within 412 these implementations when multiple interfaces are in use. 414 3.1.2 Tunnel Mode 416 In tunnel mode, the "inner" IP header carries the ultimate (IP) 417 source and destination addresses, while an "outer" IP header contains 418 the addresses of the IPsec "peers," e.g., addresses of security 419 gateways. In tunnel mode, AH protects the entire inner IP packet, 420 including the entire inner IP header. The position of AH in tunnel 421 mode, relative to the outer IP header, is the same as for AH in 422 transport mode. The following diagram illustrates AH tunnel mode 423 positioning for typical IPv4 and IPv6 packets. 425 ------------------------------------------------ 426 IPv4 | new IP hdr* | | orig IP hdr* | | | 427 |(any options)| AH | (any options) |TCP | Data | 428 ------------------------------------------------ 429 |<- authenticated except for mutable fields -->| 430 | in the new IP hdr | 432 -------------------------------------------------------------- 433 IPv6 | | ext hdrs*| | | ext hdrs*| | | 434 |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data| 435 -------------------------------------------------------------- 436 |<-- authenticated except for mutable fields in new IP hdr ->| 438 * = if present, construction of outer IP hdr/extensions and 439 modification of inner IP hdr/extensions is discussed in 440 the Security Architecture document. 442 3.2 Integrity Algorithms 444 The integrity algorithm employed for the ICV computation is specified 445 by the SA. For point-to-point communication, suitable integrity 446 algorithms include keyed Message Authentication Codes (MACs) based on 447 symmetric encryption algorithms (e.g., AES [AES]) or on one-way hash 448 functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast 449 communication, a variety of cryptographic strategies for providing 450 integrity have been developed and research continues in this area. 452 3.3 Outbound Packet Processing 454 In transport mode, the sender inserts the AH header after the IP 455 header and before a next layer protocol header, as described above. 456 In tunnel mode, the outer and inner IP header/extensions can be 457 inter-related in a variety of ways. The construction of the outer IP 458 header/extensions during the encapsulation process is described in 459 the Security Architecture document. 461 3.3.1 Security Association Lookup 463 AH is applied to an outbound packet only after an IPsec 464 implementation determines that the packet is associated with an SA 465 that calls for AH processing. The process of determining what, if 466 any, IPsec processing is applied to outbound traffic is described in 467 the Security Architecture document. 469 3.3.2 Sequence Number Generation 471 The sender's counter is initialized to 0 when an SA is established. 472 The sender increments the Sequence Number (or ESN) for this SA and 473 inserts the low-order 32 bits of the value into the Sequence Number 474 field. Thus the first packet sent using a given SA will contain a 475 Sequence Number of 1. 477 If anti-replay is enabled (the default), the sender checks to ensure 478 that the counter has not cycled before inserting the new value in the 479 Sequence Number field. In other words, the sender MUST NOT send a 480 packet on an SA if doing so would cause the Sequence Number to cycle. 481 An attempt to transmit a packet that would result in Sequence Number 482 overflow is an auditable event. The audit log entry for this event 483 SHOULD include the SPI value, current date/time, Source Address, 484 Destination Address, and (in IPv6) the cleartext Flow ID. 486 The sender assumes anti-replay is enabled as a default, unless 487 otherwise notified by the receiver (see 3.4.3) or if the SA was 488 configured using manual key management. Thus typical behavior of an 489 AH implementation calls for the sender to establish a new SA when the 490 Sequence Number (or ESN) cycles, or in anticipation of this value 491 cycling. 493 If anti-replay is disabled (as noted above), the sender does not need 494 to monitor or reset the counter, e.g., in the case of manual key 495 management (see Section 5). However, the sender still increments the 496 counter and when it reaches the maximum value, the counter rolls over 497 back to zero. (This behavior is recommended for multi-sender, 498 multicast SAs, unless anti-replay mechanisms outside the scope of 499 this standard are negotiated between the sender and receiver.) 501 If ESN (see Appendix B) is selected, only the low order 32 bits of 502 the Sequence Number are transmitted in the Sequence Number field, 503 although both sender and receiver maintain full 64-bit ESN counters. 504 However, the high order 32 bits are included in the ICV calculation. 506 3.3.3 Integrity Check Value Calculation 508 The AH ICV is computed over: 509 o IP header fields that are either immutable in transit or that 510 are predictable in value upon arrival at the endpoint for the 511 AH SA 512 o the AH header (Next Header, Payload Len, Reserved, SPI, 513 Sequence Number (low order 32 bits), and the Integrity Check 514 Value (which is set to zero for this computation), and 515 explicit padding bytes (if any)) 516 o the next level protocol data, which is assumed to be immutable 517 in transit 518 o the high order bits of the ESN (if employed), and any implicit 519 padding required by the integrity algorithm 521 3.3.3.1 Handling Mutable Fields 523 If a field may be modified during transit, the value of the field is 524 set to zero for purposes of the ICV computation. If a field is 525 mutable, but its value at the (IPsec) receiver is predictable, then 526 that value is inserted into the field for purposes of the ICV 527 calculation. The Integrity Check Value field is also set to zero in 528 preparation for this computation. Note that by replacing each 529 field's value with zero, rather than omitting the field, alignment is 530 preserved for the ICV calculation. Also, the zero-fill approach 531 ensures that the length of the fields that are so handled cannot be 532 changed during transit, even though their contents are not explicitly 533 covered by the ICV. 535 As a new extension header or IPv4 option is created, it will be 536 defined in its own RFC and SHOULD include (in the Security 537 Considerations section) directions for how it should be handled when 538 calculating the AH ICV. If the IP (v4 or v6) implementation 539 encounters an extension header that it does not recognize, it will 540 discard the packet and send an ICMP message. IPsec will never see 541 the packet. If the IPsec implementation encounters an IPv4 option 542 that it does not recognize, it should zero the whole option, using 543 the second byte of the option as the length. IPv6 options (in 544 Destination extension headers or the Hop by Hop extension header) 545 contain a flag indicating mutability, which determines appropriate 546 processing for such options. 548 3.3.3.1.1 ICV Computation for IPv4 550 3.3.3.1.1.1 Base Header Fields 552 The IPv4 base header fields are classified as follows: 554 Immutable 555 Version 556 Internet Header Length 557 Total Length 558 Identification 559 Protocol (This should be the value for AH.) 560 Source Address 561 Destination Address (without loose or strict source routing) 563 Mutable but predictable 564 Destination Address (with loose or strict source routing) 566 Mutable (zeroed prior to ICV calculation) 567 DSCP (6 bits, see RFC2474 [NBBB98]) 568 ECN (2 bits, see RFC3168 [RFB01]) 569 Flags 570 Fragment Offset 571 Time to Live (TTL) 572 Header Checksum 574 DSCP - Routers may rewrite the DS field as needed to provide a 575 desired local or end-to-end service, thus its value upon reception 576 cannot be predicted by the sender. 578 ECN - This will change if a router along the route experiences 579 congestion, and thus its value upon reception cannot be predicted by 580 the sender. 582 Flags -- This field is excluded since an intermediate router might 583 set the DF bit, even if the source did not select it. 585 Fragment Offset -- Since AH is applied only to non-fragmented IP 586 packets, the Offset Field must always be zero, and thus it is 587 excluded (even though it is predictable). 589 TTL -- This is changed en-route as a normal course of processing by 590 routers, and thus its value at the receiver is not predictable by the 591 sender. 593 Header Checksum -- This will change if any of these other fields 594 changes, and thus its value upon reception cannot be predicted by the 595 sender. 597 3.3.3.1.1.2 Options 599 For IPv4 (unlike IPv6), there is no mechanism for tagging options as 600 mutable in transit. Hence the IPv4 options are explicitly listed in 601 Appendix A and classified as immutable, mutable but predictable, or 602 mutable. For IPv4, the entire option is viewed as a unit; so even 603 though the type and length fields within most options are immutable 604 in transit, if an option is classified as mutable, the entire option 605 is zeroed for ICV computation purposes. 607 3.3.3.1.2 ICV Computation for IPv6 609 3.3.3.1.2.1 Base Header Fields 611 The IPv6 base header fields are classified as follows: 613 Immutable 614 Version 615 Payload Length 616 Next Header 617 Source Address 618 Destination Address (without Routing Extension Header) 620 Mutable but predictable 621 Destination Address (with Routing Extension Header) 623 Mutable (zeroed prior to ICV calculation) 624 DSCP (6 bits, see RFC2474 [NBBB98]) 625 ECN (2 bits, see RFC3168 [RFB01]) 626 Flow Label 627 Hop Limit 629 3.3.3.1.2.2 Extension Headers Containing Options 631 IPv6 options in the Hop-by-Hop and Destination Extension Headers 632 contain a bit that indicates whether the option might change 633 (unpredictably) during transit. For any option for which contents 634 may change en-route, the entire "Option Data" field must be treated 635 as zero-valued octets when computing or verifying the ICV. The 636 Option Type and Opt Data Len are included in the ICV calculation. 637 All options for which the bit indicates immutability are included in 638 the ICV calculation. See the IPv6 specification [DH98] for more 639 information. 641 3.3.3.1.2.3 Extension Headers Not Containing Options 643 The IPv6 extension headers that do not contain options are explicitly 644 listed in Appendix A and classified as immutable, mutable but 645 predictable, or mutable. 647 3.3.3.2 Padding & Extended Sequence Numbers 649 3.3.3.2.1 ICV Padding 651 As mentioned in section 2.6, the ICV field may include explicit 652 padding if required to ensure that the AH header is a multiple of 32 653 bits (IPv4) or 64 bits (IPv6). If padding is required, its length is 654 determined by two factors: 656 - the length of the ICV 657 - the IP protocol version (v4 or v6) 659 For example, if the output of the selected algorithm is 96-bits, no 660 padding is required for either IPv4 or for IPv6. However, if a 661 different length ICV is generated, due to use of a different 662 algorithm, then padding may be required depending on the length and 663 IP protocol version. The content of the padding field is arbitrarily 664 selected by the sender. (The padding is arbitrary, but need not be 665 random to achieve security.) These padding bytes are included in the 666 ICV calculation, counted as part of the Payload Length, and 667 transmitted at the end of the ICV field to enable the receiver to 668 perform the ICV calculation. 670 3.3.3.2.2 Implicit Packet Padding & ESN 672 If the ESN option is elected for an SA, then the high order 32 bits 673 of the ESN must be included in the ICV computation. For purposes of 674 ICV computation, these bits are appended (implicitly) immediately 675 after the end of the payload, and before any implicit packet padding. 677 For some integrity algorithms, the byte string over which the ICV 678 computation is performed must be a multiple of a blocksize specified 679 by the algorithm. If the IP packet length (including AH and the 32 680 high order bits of the ESN, if enabled) does not match the blocksize 681 requirements for the algorithm, implicit padding MUST be appended to 682 the end of the packet, prior to ICV computation. The padding octets 683 MUST have a value of zero. The blocksize (and hence the length of 684 the padding) is specified by the algorithm specification. This 685 padding is not transmitted with the packet. Note that MD5 and SHA-1 686 are viewed as having a 1-byte blocksize because of their internal 687 padding conventions and thus no implicit packet padding is required. 689 3.3.4 Fragmentation 691 If required, IP fragmentation occurs after AH processing within an 692 IPsec implementation. Thus, transport mode AH is applied only to 693 whole IP datagrams (not to IP fragments). An IPv4 packet to which AH 694 has been applied may itself be fragmented by routers en route, and 695 such fragments must be reassembled prior to AH processing at a 696 receiver. (This does not apply to IPv6, where there is no router- 697 initiated fragmentation.) In tunnel mode, AH is applied to an IP 698 packet, the payload of which may be a fragmented IP packet. For 699 example, a security gateway or a "bump-in-the-stack" or "bump-in-the- 700 wire" IPsec implementation (see the Security Architecture document 701 for details) may apply tunnel mode AH to such fragments. 703 NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, 704 bump-in-the-stack and bump-in-the-wire implementations may have to 705 first reassemble a packet fragmented by the local IP layer, then 706 apply IPsec, and then fragment the resulting packet. 708 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 709 implementations, it will be necessary to examine all the extension 710 headers to determine if there is a fragmentation header and hence 711 that the packet needs reassembling prior to IPsec processing. 713 Fragmentation, whether performed by an IPsec implementation or by 714 routers along the path between IPsec peers, significantly reduces 715 performance. Moreover, the requirement for an AH receiver to accept 716 fragments for reassembly creates denial of service vulnerabilities. 717 Thus an AH implementation MAY choose to not support fragmentation and 718 may mark transmitted packets with the DF bit, to facilitate PMTU 719 discovery. In any case, an AH implementation MUST support generation 720 of ICMP PMTU messages (or equivalent internal signaling for native 721 host implementations) to minimize the likelihood of fragmentation. 722 Details of the support required for MTU management are contained in 723 the Security Architecture document. 725 3.4 Inbound Packet Processing 727 If there is more than one IPsec header/extension present, the 728 processing for each one ignores (does not zero, does not use) any 729 IPsec headers applied subsequent to the header being processed. 731 3.4.1 Reassembly 733 If required, reassembly is performed prior to AH processing. If a 734 packet offered to AH for processing appears to be an IP fragment, 735 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 736 the receiver MUST discard the packet; this is an auditable event. The 737 audit log entry for this event SHOULD include the SPI value, 738 date/time, Source Address, Destination Address, and (in IPv6) the 739 Flow ID. 741 NOTE: For packet reassembly, the current IPv4 spec does NOT require 742 either the zeroing of the OFFSET field or the clearing of the MORE 743 FRAGMENTS flag. In order for a reassembled packet to be processed by 744 IPsec (as opposed to discarded as an apparent fragment), the IP code 745 must do these two things after it reassembles a packet. 747 3.4.2 Security Association Lookup 749 Upon receipt of a packet containing an IP Authentication Header, the 750 receiver determines the appropriate (unidirectional) SA via lookup in 751 the SAD. For a unicast SA, this determination is based on the SPI or 752 the SPI plus protocol field, as described in Section 2.4. If an 753 implementation supports multicast traffic, the destination address is 754 also employed in the lookup (in addition to the SPI), and the sender 755 address also may be employed, as described in Section 2.4. (This 756 process is described in more detail in the Security Architecture 757 document.) The SAD entry for the SA also indicates whether the 758 Sequence Number field will be checked, whether 32 or 64-bit Sequence 759 Numbers are employed for the SA, specifies the algorithm(s) employed 760 for ICV computation, and indicates the key required to validate the 761 ICV. 763 If no valid Security Association exists for this packet the receiver 764 MUST discard the packet; this is an auditable event. The audit log 765 entry for this event SHOULD include the SPI value, date/time, Source 766 Address, Destination Address, and (in IPv6) the Flow ID. 768 (Note that SA management traffic, e.g., IKE packets, does not need to 769 be processed based on SPI, i.e., one can demultiplex this traffic 770 separately, e.g., based on Next Protocol and Port fields.) 772 3.4.3 Sequence Number Verification 774 All AH implementations MUST support the anti-replay service, though 775 its use may be enabled or disabled by the receiver on a per-SA basis. 776 Anti-replay is applicable to unicast as well as multicast SAs. 777 However, this standard specifies no mechanisms for providing anti- 778 replay for a multi-sender SA (unicast or multicast). In the absence 779 of negotiation (or manual configuration) of an anti-replay mechanism 780 for such an SA, it is recommended that sender and receiver checking 781 of the sequence number for the SA be disabled (via negotiation or 782 manual configuration), as noted below. 784 If the receiver does not enable anti-replay for an SA, no inbound 785 checks are performed on the Sequence Number. However, from the 786 perspective of the sender, the default is to assume that anti-replay 787 is enabled at the receiver. To avoid having the sender do 788 unnecessary sequence number monitoring and SA setup (see section 789 3.3.2 "Sequence Number Generation"), if an SA establishment protocol 790 such as IKE is employed, the receiver SHOULD notify the sender, 791 during SA establishment, if the receiver will not provide anti- 792 replay protection. 794 If the receiver has enabled the anti-replay service for this SA, the 795 receive packet counter for the SA MUST be initialized to zero when 796 the SA is established. For each received packet, the receiver MUST 797 verify that the packet contains a Sequence Number that does not 798 duplicate the Sequence Number of any other packets received during 799 the life of this SA. This SHOULD be the first AH check applied to a 800 packet after it has been matched to an SA, to speed rejection of 801 duplicate packets. 803 Duplicates are rejected through the use of a sliding receive window. 804 How the window is implemented is a local matter, but the following 805 text describes the functionality that the implementation must 806 exhibit. 808 The "right" edge of the window represents the highest, validated 809 Sequence Number value received on this SA. Packets that contain 810 Sequence Numbers lower than the "left" edge of the window are 811 rejected. Packets falling within the window are checked against a 812 list of received packets within the window. 814 If the ESN option is selected for an SA, only the low-order 32 bits 815 of the sequence number are explicitly transmitted; but the receiver 816 employs the full sequence number computed using the high-order 32 817 bits for the indicated SA (from his local counter) when checking the 818 received Sequence Number against the receive window. In constructing 819 the full Sequence Number, if the low order 32 bits carried in the 820 packet are lower in value than the low order 32 bits of the 821 receiver's Sequence Number, the receiver assumes that the high order 822 32 bits have been incremented, moving to a new sequence number 823 subspace. (This algorithm accommodates gaps in reception for a single 824 SA as large as 2**32-1 packets. If a larger gap occurs, additional, 825 heuristic checks for resynchronization of the receiver's Sequence 826 Number counter MAY be employed, as described in Appendix B.) 828 If the received packet falls within the window and is not a 829 duplicate, or if the packet is to the right of the window, then the 830 receiver proceeds to ICV verification. If the ICV validation fails, 831 the receiver MUST discard the received IP datagram as invalid. This 832 is an auditable event. The audit log entry for this event SHOULD 833 include the SPI value, date/time, Source Address, Destination 834 Address, the Sequence Number, and (in IPv6) the Flow ID. The receive 835 window is updated only if the ICV verification succeeds. 837 A MINIMUM window size of 32 packets MUST be supported; but a window 838 size of 64 is preferred and SHOULD be employed as the default. 839 Another window size (larger than the MINIMUM) MAY be chosen by the 840 receiver. (The receiver does NOT notify the sender of the window 841 size.) The receive window size should be increased for higher speed 842 environments, irrespective of assurance issues. Values for minimum 843 and recommended receive window sizes for very high speed (e.g., 844 multi-gigabit/second) devices are not specified by this standard. 846 3.4.4 Integrity Check Value Verification 848 The receiver computes the ICV over the appropriate fields of the 849 packet, using the specified integrity algorithm, and verifies that it 850 is the same as the ICV included in the ICV field of the packet. 851 Details of the computation are provided below. 853 If the computed and received ICV's match, then the datagram is valid, 854 and it is accepted. If the test fails, then the receiver MUST 855 discard the received IP datagram as invalid. This is an auditable 856 event. The audit log entry SHOULD include the SPI value, date/time 857 received, Source Address, Destination Address, and (in IPv6) the Flow 858 ID. 860 Implementation Note: 862 Implementations can use any set of steps that results in the same 863 result as the following set of steps. Begin by saving the ICV 864 value and replacing it (but not any ICV field padding) with zero. 865 Zero all other fields that may have been modified during transit. 866 (See section 3.3.3.1, "Handling Mutable Fields", for a discussion 867 of which fields are zeroed before performing the ICV calculation.) 868 If the ESN option is elected for this SA, append the high order 32 869 bits of the ESN after the end of the packet. Check the overall 870 length of the packet (as described above), and if it requires 871 implicit padding based on the requirements of the integrity 872 algorithm, append zero-filled bytes to the end of the packet 873 (after the ESN if present) as required. Perform the ICV 874 computation and compare the result with the saved value, using the 875 comparison rules defined by the algorithm specification. (For 876 example, if a digital signature and one-way hash are used for the 877 ICV computation, the matching process is more complex.) 879 4. Auditing 881 Not all systems that implement AH will implement auditing. However, 882 if AH is incorporated into a system that supports auditing, then the 883 AH implementation MUST also support auditing and MUST allow a system 884 administrator to enable or disable auditing for AH. For the most 885 part, the granularity of auditing is a local matter. However, 886 several auditable events are identified in this specification and for 887 each of these events a minimum set of information that SHOULD be 888 included in an audit log is defined. Additional information also MAY 889 be included in the audit log for each of these events, and additional 890 events, not explicitly called out in this specification, also MAY 891 result in audit log entries. There is no requirement for the 892 receiver to transmit any message to the purported sender in response 893 to the detection of an auditable event, because of the potential to 894 induce denial of service via such action. 896 5. Conformance Requirements 898 Implementations that claim conformance or compliance with this 899 specification MUST fully implement the AH syntax and processing 900 described here for unicast traffic, and MUST comply with all 901 requirements of the Security Architecture document [KA98a]. 902 Additionally, if an implementation claims to support multicast 903 traffic, it MUST comply with the additional requirements specified 904 for support of such traffic. If the key used to compute an ICV is 905 manually distributed, correct provision of the anti-replay service 906 would require correct maintenance of the counter state at the sender, 907 until the key is replaced, and there likely would be no automated 908 recovery provision if counter overflow were imminent. Thus a 909 compliant implementation SHOULD NOT provide this service in 910 conjunction with SAs that are manually keyed. 912 The mandatory-to-implement algorithms for use with AH are described 913 in a separate RFC, to facilitate updating the algorithm requirements 914 independently from the protocol per se. Additional algorithms, beyond 915 those mandated for AH, MAY be supported. 917 6. Security Considerations 919 Security is central to the design of this protocol, and these 920 security considerations permeate the specification. Additional 921 security-relevant aspects of using the IPsec protocol are discussed 922 in the Security Architecture document. 924 7. Differences from RFC 2402 926 This document differs from RFC 2402 in the following ways. 928 o SPI -- modified to specify a uniform algorithm for SAD lookup 929 for unicast and multicast SAs, covering a wider range of 930 multicast technologies. For unicast, the SPI may be used alone 931 to select an SA, or may be combined with the protocol, at the 932 option of the receiver. For multicast SAs, the SPI is 933 combined with the destination address, and optionally the 934 source address, to select an SA. 935 o Sequence number -- added a new option for a 64-bit sequence 936 number for very high-speed communications. Clarified sender 937 and receiver processing requirements for multicast SAs and 938 multi-sender SAs. 939 o Moved references to mandatory algorithms to a separate 940 document. 942 Acknowledgements 944 The author would like to acknowledge the contributions of Ran 945 Atkinson, who played a critical role in initial IPsec activities, and 946 who authored the first series of IPsec standards: RFCs 1825-1827. 947 Karen Seo deserves special thanks for providing help in the editing 948 of this and the previous version of this specification. The author 949 also would like to thank the members of the IPSEC and MSEC working 950 groups who have contributed to the development of this protocol 951 specification. 953 References 955 Normative 957 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 958 Requirement Level", BCP 14, RFC 2119, March 1997. 960 [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 961 (IPv6) Specification", RFC 2460, December 1998. 963 [KA98a] Kent, S., and R. Atkinson, "Security Architecture for the 964 Internet Protocol", RFC 2401, November 1998. 966 Informative 968 [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for 969 IP", Internet Draft, draft-ietf-ssm-arch-01.txt, November 970 3, 2002. 972 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange 973 (IKE)", RFC 2409, November 1998. 975 [KA98b] Kent, S., and R. Atkinson, "IP Authentication Header (AH)", 976 RFC 2402, November 1998. 978 [Ken03] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 979 ???, ???? 2003. 981 [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 982 of the Differentiated Services Field (DS Field) in the IPv4 983 and IPv6 Headers", RFC 2474, December 1998. 985 [RFB01] Ramakrishnan, K., Floyd S., Black D., "The Addition of 986 Explicit Congestion Notification (ECN) to IP", RFC 3168, 987 September 2001. 989 Disclaimer 991 The views and specification here are those of the authors and are not 992 necessarily those of their employers. The authors and their 993 employers specifically disclaim responsibility for any problems 994 arising from correct or incorrect implementation or use of this 995 specification. 997 Author Information 999 Stephen Kent 1000 BBN Technologies 1001 10 Moulton Street 1002 Cambridge, MA 02138 1003 USA 1004 Phone: +1 (617) 873-3988 1005 EMail: kent@bbn.com 1007 Appendix A -- Mutability of IP Options/Extension Headers 1009 A1. IPv4 Options 1011 This table shows how the IPv4 options are classified with regard to 1012 "mutability". Where two references are provided, the second one 1013 supercedes the first. This table is based in part on information 1014 provided in RFC1700, "ASSIGNED NUMBERS", (October 1994). 1016 Opt. 1017 Copy Class # Name Reference 1018 ---- ----- --- ------------------------- -------- 1019 IMMUTABLE -- included in ICV calculation 1020 0 0 0 End of Options List [RFC791] 1021 0 0 1 No Operation [RFC791] 1022 1 0 2 Security [RFC1108(historic but 1023 in use)] 1024 1 0 5 Extended Security [RFC1108(historic but 1025 in use)] 1026 1 0 6 Commercial Security [expired I-D, now US MIL 1027 STD] 1028 1 0 20 Router Alert [RFC2113] 1029 1 0 21 Sender Directed Multi- [RFC1770] 1030 Destination Delivery 1031 MUTABLE -- zeroed 1032 1 0 3 Loose Source Route [RFC791] 1033 0 2 4 Time Stamp [RFC791] 1034 0 0 7 Record Route [RFC791] 1035 1 0 9 Strict Source Route [RFC791] 1036 0 2 18 Traceroute [RFC1393] 1038 EXPERIMENTAL, SUPERCEDED -- zeroed 1039 1 0 8 Stream ID [RFC791, RFC1122 (Host 1040 Req)] 1041 0 0 11 MTU Probe [RFC1063, RFC1191 (PMTU)] 1042 0 0 12 MTU Reply [RFC1063, RFC1191 (PMTU)] 1043 1 0 17 Extended Internet Protocol [RFC1385, RFC1883 (IPv6)] 1044 0 0 10 Experimental Measurement [ZSu] 1045 1 2 13 Experimental Flow Control [Finn] 1046 1 0 14 Experimental Access Ctl [Estrin] 1047 0 0 15 ??? [VerSteeg] 1048 1 0 16 IMI Traffic Descriptor [Lee] 1049 1 0 19 Address Extension [Ullmann IPv7] 1051 NOTE: Use of the Router Alert option is potentially incompatible with 1052 use of IPsec. Although the option is immutable, its use implies that 1053 each router along a packet's path will "process" the packet and 1054 consequently might change the packet. This would happen on a hop by 1055 hop basis as the packet goes from router to router. Prior to being 1056 processed by the application to which the option contents are 1057 directed, e.g., RSVP/IGMP, the packet should encounter AH processing. 1058 However, AH processing would require that each router along the path 1059 is a member of a multicast-SA defined by the SPI. This might pose 1060 problems for packets that are not strictly source routed, and it 1061 requires multicast support techniques not currently available. 1063 NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by 1064 systems along a packet's path conflicts with the classification of 1065 these IP Options as immutable and is incompatible with the use of 1066 IPsec. 1068 NOTE: End of Options List options SHOULD be repeated as necessary to 1069 ensure that the IP header ends on a 4 byte boundary in order to 1070 ensure that there are no unspecified bytes which could be used for a 1071 covert channel. 1073 A2. IPv6 Extension Headers 1075 This table shows how the IPv6 Extension Headers are classified with 1076 regard to "mutability". 1078 Option/Extension Name Reference 1079 ----------------------------------- --------- 1080 MUTABLE BUT PREDICTABLE -- included in ICV calculation 1081 Routing (Type 0) [DH98] 1083 BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING 1084 TRANSIT) 1085 Hop by Hop options [DH98] 1086 Destination options [DH98] 1088 NOT APPLICABLE 1089 Fragmentation [DH98] 1091 Options -- IPv6 options in the Hop-by-Hop and Destination 1092 Extension Headers contain a bit that indicates whether the option 1093 might change (unpredictably) during transit. For any option for 1094 which contents may change en-route, the entire "Option Data" field 1095 must be treated as zero-valued octets when computing or verifying 1096 the ICV. The Option Type and Opt Data Len are included in the ICV 1097 calculation. All options for which the bit indicates immutability 1098 are included in the ICV calculation. See the IPv6 specification 1099 [DH98] for more information. 1101 Routing (Type 0) -- The IPv6 Routing Header "Type 0" will 1102 rearrange the address fields within the packet during transit from 1103 source to destination. However, the contents of the packet as it 1104 will appear at the receiver are known to the sender and to all 1105 intermediate hops. Hence, the IPv6 Routing Header "Type 0" is 1106 included in the Integrity Check Value calculation as mutable but 1107 predictable. The sender must order the field so that it appears as 1108 it will at the receiver, prior to performing the ICV computation. 1110 Fragmentation -- Fragmentation occurs after outbound IPsec 1111 processing (section 3.3) and reassembly occurs before inbound IPsec 1112 processing (section 3.4). So the Fragmentation Extension Header, if 1113 it exists, is not seen by IPsec. 1115 Note that on the receive side, the IP implementation could 1116 leave a Fragmentation Extension Header in place when it does re- 1117 assembly. If this happens, then when AH receives the packet, before 1118 doing ICV processing, AH MUST "remove" (or skip over) this header 1119 and change the previous header's "Next Header" field to be the "Next 1120 Header" field in the Fragmentation Extension Header. 1122 Note that on the send side, the IP implementation could give 1123 the IPsec code a packet with a Fragmentation Extension Header with 1124 Offset of 0 (first fragment) and a More Fragments Flag of 0 (last 1125 fragment). If this happens, then before doing ICV processing, AH 1126 MUST first "remove" (or skip over) this header and change the 1127 previous header's "Next Header" field to be the "Next Header" field 1128 in the Fragmentation Extension Header. 1130 Appendix B -- Extended (64-bit) Sequence Numbers 1132 B1. Overview 1134 This appendix describes an extended sequence number (ESN) scheme for 1135 use with IPsec (ESP and AH) that employs a 64-bit sequence number, 1136 but in which only the low order 32 bits are transmitted as part of 1137 each packet. It covers both the window scheme used to detect 1138 replayed packets and the determination of the high order bits of the 1139 sequence number that are used both for replay rejection and for 1140 computation of the ICV. It also discusses a mechanism for handling 1141 loss of synchronization relative to the (not transmitted) high order 1142 bits. 1144 B2. Anti-Replay Window 1146 The receiver will maintain an anti-replay window of size W. This 1147 window will limit how far out of order a packet can be, relative to 1148 the packet with the highest sequence number that has been 1149 authenticated so far. (No requirement is established for minimum or 1150 recommended sizes for this window, beyond the 32 and 64-packet values 1151 already established for 32-bit sequence number windows. However, it 1152 is suggested that an implementer scale these values consistent with 1153 the interface speed supported by an implementation that makes use of 1154 the ESN option. Also, the algorithm described below assumes that the 1155 window is no greater than 2^31 packets in width.) All 2^32 sequence 1156 numbers associated with any fixed value for the high order 32 bits 1157 (Seqh) will hereafter be called a sequence number subspace. The 1158 following table lists pertinent variables and their definitions. 1160 Var. Size 1161 Name (bits) Meaning 1162 ---- ------ --------------------------- 1163 W 32 Size of window 1164 T 64 Highest sequence number authenticated so far, 1165 upper bound of window 1166 Tl 32 Lower 32 bits of T 1167 Th 32 Upper 32 bits of T 1168 B 64 Lower bound of window 1169 Bl 32 Lower 32 bits of B 1170 Bh 32 Upper 32 bits of B 1171 Seq 64 Sequence number of received packet 1172 Seql 32 Lower 32 bits of Seq 1173 Seqh 32 Upper 32 bits of Seq 1175 When performing the anti-replay check, or when determining which high 1176 order bits to use to authenticate an incoming packet, there are two 1177 cases: 1179 + Case A: Tl >= (W - 1). In this case, the window is within one 1180 sequence number subspace. (See Figure 1) 1181 + Case B: Tl < (W - 1). In this case, the window spans two 1182 sequence number subspaces. (See Figure 2) 1184 In the figures below, the bottom line ("----") shows two consecutive 1185 sequence number subspaces, with zero's indicating the beginning of 1186 each subspace. The two shorter lines above it show the higher order 1187 bits that apply. The "====" represents the window. The "****" 1188 represents future sequence numbers, i.e., those beyond the current 1189 highest sequence number authenticated (ThTl). 1191 Th+1 ********* 1193 Th =======***** 1195 --0--------+-----+-----0--------+-----------0-- 1196 Bl Tl Bl 1197 (Bl+2^32) mod 2^32 1199 Figure 1 -- Case A 1201 Th ====************** 1203 Th-1 === 1205 --0-----------------+--0--+--------------+--0-- 1206 Bl Tl Bl 1207 (Bl+2^32) mod 2^32 1209 Figure 2 -- Case B 1211 B2.1. Managing and Using the Anti-Replay Window 1213 The anti-replay window can be thought of as a string of bits where 1214 `W' defines the length of the string. W = T - B + 1 and cannot 1215 exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and 1216 the top-most bit corresponds to T and each sequence number from Bl 1217 through Tl is represented by a corresponding bit. The value of the 1218 bit indicates whether or not a packet with that sequence number has 1219 been received and authenticated, so that replays can be detected and 1220 rejected. 1222 When a packet with a 64-bit sequence number (Seq) greater than T is 1223 received and validated, 1224 + B is increased by (Seq - T) 1225 + (Seq - T) bits are dropped from the low end of the window 1226 + (Seq - T) bits are added to the high end of the window 1227 + The top bit is set to indicate that a packet with that sequence 1228 number has been received and authenticated 1229 + The new bits between T and the top bit are set to indicate that 1230 no packets with those sequence numbers have been received yet. 1231 + T is set to the new sequence number 1233 In checking for replayed packets, 1235 + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND 1236 Seql <= Tl, then check the corresponding bit in the window to see 1237 if this Seql has already been seen. If yes, reject the packet. 1238 If no, perform integrity check (see Section 2.2. below for 1239 determination of SeqH). 1241 + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR 1242 Seql <= Tl, then check the corresponding bit in the window to see 1243 if this Seql has already been seen. If yes, reject the packet. 1244 If no, perform integrity check (see Section 2.2. below for 1245 determination of Seqh). 1247 B2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number 1249 Since only `Seql' will be transmitted with the packet, the receiver 1250 must deduce and track the sequence number subspace into which each 1251 packet falls, i.e., determine the value of Seqh. The following 1252 equations define how to select Seqh under "normal" conditions; see 1253 Section 3 for a discussion of how to recover from extreme packet 1254 loss. 1256 + Under Case A (Figure 1): 1257 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th 1258 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1 1260 + Under Case B (Figure 2): 1261 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 1262 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th 1264 B2.3. Pseudo-code Example 1266 The following pseudo-code illustrates the above algorithms for anti- 1267 replay and integrity checks. The values for `Seql', `Tl', `Th' and 1268 `W', are 32-bit unsigned integers. Arithmetic is mod 2^32. 1270 If (Tl >= W - 1) Case A 1271 If (Seql >= Tl - W + 1) 1272 Seqh = Th 1273 If (Seql <= Tl) 1274 If (pass replay check) 1275 If (pass integrity check) 1276 Set bit corresponding to Seql 1277 Pass the packet on 1278 Else reject packet 1279 Else reject packet 1280 Else 1281 If (pass integrity check) 1282 Tl = Seql (shift bits) 1283 Set bit corresponding to Seql 1284 Pass the packet on 1285 Else reject packet 1286 Else 1287 Seqh = Th + 1 1288 If (pass integrity check) 1289 Tl = Seql (shift bits) 1290 Th = Th + 1 1291 Set bit corresponding to Seql 1292 Pass the packet on 1293 Else reject packet 1294 Else Case B 1295 If (Seql >= Tl - W + 1) 1296 Seqh = Th - 1 1297 If (pass replay check) 1298 If (pass integrity check) 1299 Set the bit corresponding to Seql 1300 Pass packet on 1301 Else reject packet 1302 Else reject packet 1303 Else 1304 If (Seql <= Tl) 1305 If (pass replay check) 1306 If (pass integrity check) 1307 Set the bit corresponding to Seql 1308 Pass packet on 1309 Else reject packet 1310 Else reject packet 1311 Else 1312 If (pass integrity check) 1313 Tl = Seql (shift bits) 1314 Set the bit corresponding to Seql 1315 Pass packet on 1316 Else reject packet 1318 B3. Handling Loss of Synchronization due to Significant Packet Loss 1320 If there is an undetected packet loss of 2^32 or more consecutive 1321 packets on a single SA, then the transmitter and receiver will lose 1322 synchronization of the high order bits, i.e., the equations in 1323 Section 2.2. will fail to yield the correct value. Unless this 1324 problem is detected and addressed, subsequent packets on this SA will 1325 fail authentication checks and be discarded. The following procedure 1326 SHOULD be implemented by any IPsec (ESP or AH) implementation that 1327 supports the ESN option. 1329 Note that this sort of extended traffic loss seems unlikely to occur 1330 if any significant fraction of the traffic on the SA in question is 1331 TCP, because the source would fail to receive ACKs and would stop 1332 sending long before 2^32 packets had been lost. Also, for any bi- 1333 directional application, even ones operating above UDP, such an 1334 extended outage would likely result in triggering some form of 1335 timeout. However, a unidirectional application, operating over UDP 1336 might lack feedback that would cause automatic detection of a loss of 1337 this magnitude, hence the motivation to develop a recovery method for 1338 this case. 1340 The solution we've chosen was selected to: 1342 + minimize the impact on normal traffic processing 1344 + avoid creating an opportunity for a new denial of service attack 1345 such as might occur by allowing an attacker to force diversion of 1346 resources to a resynchronization process. 1348 + limit the recovery mechanism to the receiver -- since anti-replay 1349 is a service only for the receiver, and the transmitter generally 1350 is not aware of whether the receiver is using sequence numbers in 1351 support of this optional service, it is preferable for recovery 1352 mechanisms to be local to the receiver. This also allows for 1353 backwards compatibility. 1355 B3.1. Triggering Resynchronization 1357 For each SA, the receiver records the number of consecutive packets 1358 that fail authentication. This count is used to trigger the 1359 resynchronization process which should be performed in the background 1360 or using a separate processor. Receipt of a valid packet on the SA 1361 resets the counter to zero. The value used to trigger the 1362 resynchronization process is a local parameter. There is no 1363 requirement to support distinct trigger values for different SAs, 1364 although an implementer may choose to do so. 1366 B3.2. Resynchronization Process 1368 When the above trigger point is reached, a "bad" packet is selected 1369 for which authentication is retried using successively larger values 1371 for the upper half of the sequence number (Seqh). These values are 1372 generated by incrementing by one for each retry. The number of 1373 retries should be limited, in case this is a packet from the "past" 1374 or a bogus packet. The limit value is a local parameter. (Because 1375 the Seqh value is implicitly placed after the ESP (or AH) payload, it 1376 may be possible to optimize this procedure by executing the integrity 1377 algorithm over the packet up to the end point of the payload, then 1378 compute different candidate ICV's by varying the value of Seqh.) 1379 Successful authentication of a packet via this procedure resets the 1380 consecutive failure count and sets the value of T to that of the 1381 received packet. 1383 This solution requires support only on the part of the receiver, 1384 thereby allowing for backwards compatibility. Also, because 1385 resynchronization efforts would either occur in the background or 1386 utilize an additional processor, this solution does not impact 1387 traffic processing and a denial of service attack cannot divert 1388 resources away from traffic processing. 1390 Copyright (C) The Internet Society (2003). All Rights Reserved. 1392 This document and translations of it may be copied and furnished to 1393 others, and derivative works that comment on or otherwise explain it 1394 or assist in its implementation may be prepared, copied, published 1395 and distributed, in whole or in part, without restriction of any 1396 kind, provided that the above copyright notice and this paragraph are 1397 included on all such copies and derivative works. However, this 1398 document itself may not be modified in any way, such as by removing 1399 the copyright notice or references to the Internet Society or other 1400 Internet organizations, except as needed for the purpose of 1401 developing Internet standards in which case the procedures for 1402 copyrights defined in the Internet Standards process must be 1403 followed, or as required to translate it into languages other than 1404 English. 1406 The limited permissions granted above are perpetual and will not be 1407 revoked by the Internet Society or its successors or assigns. 1409 This document and the information contained herein is provided on an 1410 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1411 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1412 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1413 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1414 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1416 Expires March 2004