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