idnits 2.17.1 draft-ietf-ipsec-esp-v3-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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 122 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 340 has weird spacing: '...t Integ is...' == Line 369 has weird spacing: '...t Integ is...' == Line 373 has weird spacing: '... plain p...' == Line 379 has weird spacing: '... cipher d...' == 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 (October 2003) is 7499 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: 'Syverson' is mentioned on line 178, but not defined -- Looks like a reference, but probably isn't: '1' on line 386 -- Looks like a reference, but probably isn't: '2' on line 387 -- Looks like a reference, but probably isn't: '3' on line 389 -- Looks like a reference, but probably isn't: '4' on line 390 -- Looks like a reference, but probably isn't: '5' on line 391 -- Looks like a reference, but probably isn't: '6' on line 363 == Unused Reference: 'HC98' is defined on line 1550, but no explicit reference was found in the text == Unused Reference: 'MD98' is defined on line 1566, but no explicit reference was found in the text == Unused Reference: 'MG98a' is defined on line 1569, but no explicit reference was found in the text == Unused Reference: 'MG98b' is defined on line 1572, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel96' ** 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. 'KA98') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken03' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kra01' Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsec Working Group S. Kent 3 Internet Draft BBN Technologies 4 draft-ietf-ipsec-esp-v3-05.txt April 2003 5 Expires October 2003 7 IP Encapsulating Security Payload (ESP) 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 Encapsulating 33 Security Payload (ESP) protocol, which is designed to provide a mix 34 of security services in IPv4 and IPv6. ESP is used to provide 35 confidentiality, data origin authentication, connectionless 36 integrity, an anti-replay service (a form of partial sequence 37 integrity), and limited traffic flow confidentiality. This document 38 is based upon RFC 2406 (November 1998). Section 7 provides a brief 39 review of the differences between this document and RFC 2406. 41 Comments should be sent to Stephen Kent (kent@bbn.com). 43 Security Payload (ESP) 45 Table of Contents 47 1. Introduction...................................................4 48 2. Encapsulating Security Payload Packet Format...................6 49 2.1 Security Parameters Index (SPI).........................10 50 2.2 Sequence Number.........................................12 51 2.2.1 Extended (64-bit) Sequence Number..................12 52 2.3 Payload Data............................................13 53 2.4 Padding (for Encryption)................................14 54 2.5 Pad Length..............................................15 55 2.6 Next Header.............................................15 56 2.7 Traffic Flow Confidentiality (TFC) Padding..............15 57 2.8 Integrity Check Value (ICV).............................16 58 3. Encapsulating Security Protocol Processing....................16 59 3.1 ESP Header Location.....................................16 60 3.1.1 Transport Mode Processing..........................17 61 3.1.2 Tunnel Mode Processing.............................18 62 3.2 Algorithms..............................................19 63 3.2.1 Encryption Algorithms..............................20 64 3.2.2 Integrity Algorithms...............................20 65 3.2.3 Combined Mode Algorithms...........................21 66 3.3 Outbound Packet Processing..............................21 67 3.3.1 Security Association Lookup........................21 68 3.3.2 Packet Encryption and Integrity Check Value (ICV) 69 Calculation........................................21 70 3.3.2.1 Separate Confidentiality and Integrity 71 Algorithms....................................22 72 3.3.2.2 Combined Confidentiality and Integrity 73 Algorithms....................................23 74 3.3.3 Sequence Number Generation.........................24 75 3.3.4 Fragmentation......................................25 76 3.4 Inbound Packet Processing...............................25 77 3.4.1 Reassembly.........................................25 78 3.4.2 Security Association Lookup........................26 79 3.4.3 Sequence Number Verification.......................26 80 3.4.4 Integrity Check Value Verification.................28 81 3.4.4.1 Separate Confidentiality and Integrity 82 Algorithms....................................28 83 3.4.4.2 Combined Confidentiality and Integrity 84 Algorithms....................................30 85 4. Auditing......................................................31 86 5. Conformance Requirements......................................32 87 6. Security Considerations.......................................33 88 7. Differences from RFC 2406.....................................33 89 Acknowledgements.................................................34 90 References.......................................................34 91 Disclaimer.......................................................35 92 Author Information...............................................35 93 Security Payload (ESP) 95 Appendix -- Extended Sequence Number.............................36 96 Full Copyright Statement.........................................42 97 Security Payload (ESP) 99 1. Introduction 101 The Encapsulating Security Payload (ESP) header is designed to 102 provide a mix of security services in IPv4 and IPv6. ESP may be 103 applied alone, in combination with the IP Authentication Header (AH) 104 [Ken03], or in a nested fashion, (see "Security Architecture for the 105 Internet Protocol" [KA98], hereafter referred to as the Security 106 Architecture document). Security services can be provided between a 107 pair of communicating hosts, between a pair of communicating security 108 gateways, or between a security gateway and a host. For more details 109 on how to use ESP and AH in various network environments, see the 110 Security Architecture document [KA98]. 112 The ESP header is inserted after the IP header and before the next 113 layer protocol header (transport mode) or before an encapsulated IP 114 header (tunnel mode). These modes are described in more detail below. 116 ESP can be used to provide confidentiality, data origin 117 authentication, connectionless integrity, an anti-replay service (a 118 form of partial sequence integrity), and (limited) traffic flow 119 confidentiality. The set of services provided depends on options 120 selected at the time of Security Association (SA) establishment and 121 on the location of the implementation in a network topology. 123 Using encryption-only for confidentiality is allowed by ESP. 124 However, it should be noted that in general, this will provide 125 defense only against passive attackers. Using encryption without a 126 strong integrity mechanism on top of it (either in ESP or separately 127 via AH) may render the confidentiality service insecure against some 128 forms of active attacks [Bel96, Kra01]. Moreover, an underlying 129 integrity service, such as AH, applied before encryption does not 130 necessarily protect the encryption-only confidentiality against 131 active attackers [Kra01]. ESP allows encryption-only SAs because 132 this may offer considerably better performance and still provide 133 adequate security, e.g., when higher layer authentication/integrity 134 protection is offered independently. However, this standard does not 135 require ESP implementations to offer an encryption-only service. 137 Data origin authentication and connectionless integrity are joint 138 services, hereafter referred to jointly as "integrity." (This term is 139 employed because, on a per-packet basis, the computation being 140 performed provides connectionless integrity directly; data origin 141 authentication is provided indirectly as a result of binding the key 142 used to verify the integrity to the identity of the IPsec peer. 143 Typically this binding is effected through the use of a shared, 144 symmetric key, but an asymmetric cryptographic algorithm also may be 145 employed, e.g., to sign a hash.) Integrity-only ESP MUST be offered 146 as a service selection option, e.g., it must be negotiable in SA 147 Security Payload (ESP) 149 management protocols and MUST be configurable via management 150 interfaces. Integrity-only ESP is an attractive alternative to AH in 151 many contexts, e.g., because it is faster to process and more 152 amenable to pipelining in many implementations. 154 Although confidentiality and integrity can be offered independently, 155 most ESP use typically will employ both services, i.e., packets will 156 be protected with regard to confidentiality and integrity. Thus there 157 are three possible ESP security service combinations involving these 158 services: 159 - confidentiality-only (MAY be supported) 160 - integrity-only (MUST be supported) 161 - confidentiality and integrity (MUST be supported) 163 The anti-replay service may be selected for an SA only if the 164 integrity service is selected for that SA. The selection of this 165 service is solely at the discretion of the receiver and thus need not 166 be negotiated. However, to make use of the extended sequence number 167 feature in an interoperable fashion, ESP does impose a requirement on 168 SA management protocols to be able to negotiate this feature (see 169 Section 2.2.1 below). 171 The traffic flow confidentiality (TFC) service generally is effective 172 only if ESP is employed in a fashion that conceals the ultimate 173 source and destination addresses of correspondents, e.g., in tunnel 174 mode between security gateways, and only if sufficient traffic flows 175 between IPsec peers (either naturally or as a result of generation of 176 masking traffic) to conceal the characteristics of specific, 177 individual subscriber traffic flows. (ESP may be employed as part of 178 a higher layer TFC system, e.g., Onion Routing [Syverson], but such 179 systems are outside the scope of this standard.) New TFC features 180 present in ESP facilitate efficient generation and discarding of 181 dummy traffic and better padding of real traffic, in a backwards 182 compatible fashion. 184 It is assumed that the reader is familiar with the terms and concepts 185 described in the Security Architecture document. In particular, the 186 reader should be familiar with the definitions of security services 187 offered by ESP and AH, the concept of Security Associations, the ways 188 in which ESP can be used in conjunction with the Authentication 189 Header (AH), and the different key management options available for 190 ESP and AH. 192 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 193 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 194 document, are to be interpreted as described in RFC 2119 [Bra97]. 196 Security Payload (ESP) 198 2. Encapsulating Security Payload Packet Format 200 The (outer) protocol header (IPv4, IPv6, or Extension) that 201 immediately precedes the ESP header SHALL contain the value 50 in its 202 Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web 203 page at http://www.iana.org/assignments/protocol-numbers). Figure 1 204 illustrates the top level format of an ESP packet. The packet begins 205 with two 4-byte fields (SPI and Sequence Number). Following these 206 fields is the Payload Data, which has substructure that depends on 207 the choice of encryption algorithm and mode, and on the use of TFC 208 padding, which is examined in more detail later. Following the 209 Payload Data are Padding and Pad Length fields, and the Next Header 210 field. The optional Integrity Check Value (ICV) field completes the 211 packet. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 216 | Security Parameters Index (SPI) | ^Integ. 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 218 | Sequence Number | |erage 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 220 | Payload Data* (variable) | | ^ 221 ~ ~ | | 222 | | |Conf. 223 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 224 | | Padding (0-255 bytes) | |erage* 225 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 226 | | Pad Length | Next Header | v v 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 228 | Integrity Check Value-ICV (variable) | 229 ~ ~ 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 1. Top Level Format of an ESP Packet 235 * If included in the Payload field, cryptographic synchronization 236 data, e.g., an Initialization Vector (IV, see Section 2.3), 237 usually is not encrypted per se, although it often is referred 238 to as being part of the ciphertext. 240 The (transmitted) ESP Trailer consists of the Padding, Pad Length, 241 and Next Header fields. Additional, implicit ESP Trailer data (which 242 is not transmitted) is included in the integrity computation, as 243 described below. 245 Security Payload (ESP) 247 If the integrity service is selected, the integrity computation 248 encompasses the SPI, Sequence Number, Payload Data, and the ESP 249 Trailer (explicit and implicit). 251 If the confidentiality service is selected, the ciphertext consists 252 of the Payload Data (except for any cryptographic synchronization 253 data that may be included) and the (explicit) ESP Trailer. 255 As noted above, the Payload Data may have substructure. An encryption 256 algorithm that requires an explicit Initialization Vector (IV), e.g., 257 CBC mode, often prefixes the Payload Data to be protected with that 258 value. Some algorithm modes combine encryption and integrity into a 259 single operation; this document refers to such algorithm modes as 260 "combined mode algorithms." Accommodation of combined mode algorithms 261 requires that the algorithm explicitly describe the payload 262 substructure used to convey the integrity data. 264 Some combined mode algorithms provide integrity only for data that is 265 encrypted, while others can provide integrity for some additional 266 data, data that is not encrypted for transmission. Since the SPI and 267 Sequence Number fields require integrity as part of the integrity 268 service, and they are not encrypted, it is necessary to ensure that 269 they are afforded integrity whenever the service is selected, 270 regardless of the style of combined algorithm mode employed. 272 When any combined mode algorithm is employed, the algorithm itself is 273 expected to return both decrypted plaintext and a pass/fail 274 indication for the integrity check. For combined mode algorithms, the 275 ICV that would normally appear at the end of the ESP packet (when 276 integrity is selected) is omitted. It is the responsibility of the 277 combined mode algorithm to encode within the payload data an ICV- 278 equivalent means of verifying the integrity of the packet. 280 If a combined mode algorithm offers integrity only to data that is 281 encrypted, it will be necessary to replicate the SPI and Sequence 282 Number as part of the Payload Data. 284 Finally, a new provision is made to insert padding for traffic flow 285 confidentiality after the Payload Data and before the ESP trailer. 286 Figure 2 illustrates this substructure for Payload Data. (Note: This 287 diagram shows bits-on-the-wire. So even if extended sequence numbers 288 are being used, only 32 bits of the Sequence Number will be 289 transmitted (see Section 2.2.1). 291 Security Payload (ESP) 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Security Parameters Index (SPI) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Sequence Number | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 300 | IV (optional] | ^ p 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a 302 | Rest of Payload Data (variable) | | y 303 ~ ~ | l 304 | | | o 305 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a 306 | | TFC Padding * (optional, variable) | v d 307 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 308 | | Padding (0-255 bytes) | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | Pad Length | Next Header | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Integrity Check Value-ICV (variable) | 313 ~ ~ 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 2. Substructure of Payload Data 319 * If tunnel mode is being used, then the IPsec implementation 320 can add Traffic Flow Confidentiality (TFC) padding (see 321 Section 2.4) after the Payload Data and before the Padding 322 (0-255 bytes) field. 324 If a combined algorithm mode is employed, the explicit ICV shown in 325 Figures 1 and 2 is omitted (see Section 3.3.2.2 below). Since 326 algorithms and modes are fixed when an SA is established, the 327 detailed format of ESP packets for a given SA (including the Payload 328 Data substructure) is fixed, for all traffic on the SA. 330 The tables below refer to the fields in the preceding Figures and 331 illustrate how several categories of algorithmic options, each with a 332 different processing model, affect the fields noted above. The 333 processing details are described in later sections. 335 Security Payload (ESP) 337 Table 1. Separate Encryption and Integrity Algorithms 339 What What What 340 # of Requ'd Encrypt Integ is 341 bytes [1] Covers Covers Xmtd 342 ------ ------ ------ ------ ------ 343 SPI 4 M Y plain 344 Seq# (low order bits) 4 M Y plain p 345 ------ a 346 IV variable O Y plain | y 347 IP datagram [2] variable M or D Y Y cipher[3] |-l 348 TFC padding [4] variable O Y Y cipher[3] | o 349 ------ a 350 Padding 0-255 M Y Y cipher[3] d 351 Pad Length 1 M Y Y cipher[3] 352 Next Header 1 M Y Y cipher[3] 353 Seq# (high order bits) 4 if ESN [5] Y not xmtd 354 ICV Padding variable if need Y not xmtd 355 ICV variable M [6] plain 357 [1] M = mandatory; O = optional; D = dummy 358 [2] If tunnel mode -> IP datagram 359 If transport mode -> next header and data 360 [3] ciphertext if encryption has been selected 361 [4] Can be used only if payload specifies its "real" length 362 [5] See section 2.2.1 363 [6] mandatory if a separate integrity algorithm is used 364 Security Payload (ESP) 366 Table 2. Combined Mode Algorithms 368 What What What 369 # of Requ'd Encrypt Integ is 370 bytes [1] Covers Covers Xmtd 371 ------ ------ ------ ------ ------ 372 SPI 4 M plain 373 Seq# (low order bits) 4 M plain p 374 --- a 375 IV variable O Y plain | y 376 IP datagram [2] variable M or D Y Y cipher |-l 377 TFC padding [3] variable O Y Y cipher | o 378 --- a 379 Padding 0-255 M Y Y cipher d 380 Pad Length 1 M Y Y cipher 381 Next Header 1 M Y Y cipher 382 Seq# (high order bits) 4 if ESN [4] Y [5] 383 ICV Padding variable if need Y [5] 384 ICV omitted when this mode is employed 386 [1] M = mandatory; O = optional; D = dummy 387 [2] If tunnel mode -> IP datagram 388 If transport mode ->next header and data 389 [3] Can be used only if payload specifies its "real" length 390 [4] See section 2.2.1 391 [5] The algorithm choices determines whether these are 392 transmitted, but in either case, the result is invisible 393 to ESP 395 The following subsections describe the fields in the header format. 396 "Optional" means that the field is omitted if the option is not 397 selected, i.e., it is present in neither the packet as transmitted 398 nor as formatted for computation of an Integrity Check Value (ICV, 399 see Section 2.7). Whether or not an option is selected is determined 400 as part of Security Association (SA) establishment. Thus the format 401 of ESP packets for a given SA is fixed, for the duration of the SA. 402 In contrast, "mandatory" fields are always present in the ESP packet 403 format, for all SAs. 405 Note: All of the cryptographic algorithms used in IPsec expect their 406 input in canonical network byte order (see Appendix in RFC 791) and 407 generate their output in canonical network byte order. IP packets 408 are also transmitted in network byte order. 410 2.1 Security Parameters Index (SPI) 412 The SPI is an arbitrary 32-bit value that is used by a receiver to 413 identify the SA to which an incoming packet is bound. The SPI field 414 Security Payload (ESP) 416 is mandatory. 418 For a unicast SA, the SPI can be used by itself to specify an SA, or 419 it may be used in conjunction with the IPsec protocol type (in this 420 case ESP). Since the SPI value is generated by the receiver for a 421 unicast SA, whether the value is sufficient to identify an SA by 422 itself, or whether it must be used in conjunction with the IPsec 423 protocol value is a local matter. This mechanism for mapping inbound 424 traffic to unicast SAs MUST be supported by all ESP implementations. 426 If an IPsec implementation supports multicast, then it MUST support 427 multicast SAs using the following algorithm for mapping inbound IPsec 428 datagrams to SAs. (Implementations that support only unicast traffic 429 need not implement this demultiplexing algorithm.) Each entry in the 430 Security Association Database (SAD) [KA98] must indicate whether the 431 SA lookup makes use of the source and destination IP addresses, in 432 addition to the SPI. (For multicast SAs, the protocol field is not 433 employed for SA lookups.) Nominally, this indication can be 434 represented by two bits, one associated with the source IP address 435 and the other for the destination IP address. A "1" value for each 436 bit indicates the need to match against the corresponding address 437 field as part of the SA lookup process. Thus, for example, unicast 438 SAs would have both bits set to zero, since neither the source nor 439 destination IP address is used for SA matching. (Only the SPI, and, 440 optionally, the protocol field are employed.) For multicast methods 441 that rely only on the destination address to specify a multicast 442 group, only the second bit would be set to "1," implying the need to 443 use the destination address plus the SPI to determine the appropriate 444 SA. For multicast methods (e.g., SSM [HC03]) that also require the 445 source address to identify a multicast group, both bits would be set 446 to "1." (There is no current requirement to support SA mapping based 447 on the source address but not the destination address, thus one of 448 the possible four values is not meaningful.) The indication whether 449 source and destination address matching is required to map inbound 450 IPsec traffic to SAs MUST be set either as a side effect of manual SA 451 configuration or via negotiation using an SA management protocol, 452 e.g., IKE. 454 The set of SPI values in the range 1 through 255 are reserved by the 455 Internet Assigned Numbers Authority (IANA) for future use; a reserved 456 SPI value will not normally be assigned by IANA unless the use of the 457 assigned SPI value is specified in an RFC. The SPI value of zero (0) 458 is reserved for local, implementation-specific use and MUST NOT be 459 sent on the wire. (For example, a key management implementation might 460 use the zero SPI value to mean "No Security Association Exists" 461 during the period when the IPsec implementation has requested that 462 its key management entity establish a new SA, but the SA has not yet 463 been established.) 464 Security Payload (ESP) 466 2.2 Sequence Number 468 This unsigned 32-bit field contains a counter value that increases by 469 one for each packet sent, i.e., a per-SA packet sequence number. For 470 a unicast SA or a single-sender multicast SA, the sender MUST 471 increment this field for every transmitted packet. Sharing an SA 472 among multiple senders is permitted, though generally not 473 recommended. ESP provides no means of synchronizing packet counters 474 among multiple senders or meaningfully managing a receiver packet 475 counter and window in the context of multiple senders. Thus, for a 476 multi-sender SA, the anti-replay features of ESP are not available 477 (see Sections 3.3.3 and 3.4.3.) 479 The field is mandatory and MUST always be present even if the 480 receiver does not elect to enable the anti-replay service for a 481 specific SA. Processing of the Sequence Number field is at the 482 discretion of the receiver, but all ESP implementations MUST be 483 capable of performing the Sequence Number processing described in 484 Sections 3.3.3 and 3.4.3. Thus the sender MUST always transmit this 485 field, but the receiver need not act upon it (see the discussion of 486 Sequence Number Verification in the "Inbound Packet Processing" 487 section (3.4.3) below). 489 The sender's counter and the receiver's counter are initialized to 0 490 when an SA is established. (The first packet sent using a given SA 491 will have a Sequence Number of 1; see Section 3.3.3 for more details 492 on how the Sequence Number is generated.) If anti-replay is enabled 493 (the default), the transmitted Sequence Number must never be allowed 494 to cycle. Thus, the sender's counter and the receiver's counter MUST 495 be reset (by establishing a new SA and thus a new key) prior to the 496 transmission of the 2^32nd packet on an SA. 498 2.2.1 Extended (64-bit) Sequence Number 500 To support high-speed IPsec implementations, a new option for 501 sequence numbers SHOULD be offered, as an extension to the current, 502 32-bit sequence number field. Use of an Extended Sequence Number 503 (ESN) MUST be negotiated by an SA management protocol. (The ESN 504 feature is applicable to multicast as well as unicast SAs.) 506 The ESN facility allows use of a 64-bit sequence number for an SA. 507 (See Appendix on "Extended (64-bit) Sequence Numbers" for details.) 508 Only the low order 32 bits of the sequence number are transmitted in 509 the plaintext ESP header of each packet, thus minimizing packet 510 overhead. The high order 32 bits are maintained as part of the 511 sequence number counter by both transmitter and receiver and are 512 included in the computation of the ICV (if the integrity service is 513 Security Payload (ESP) 515 selected). If a separate integrity algorithm is employed, the high 516 order bits are included in the implicit ESP trailer, but are not 517 transmitted, analogous to integrity algorithm padding bits. If a 518 combined mode algorithm is employed, the algorithm choice determines 519 whether the high order ESN bits are transmitted, or are included 520 implicitly in the computation. See Section 3.3.2.2 for processing 521 details. 523 2.3 Payload Data 525 Payload Data is a variable-length field containing data (from the 526 original IP packet) described by the Next Header field. The Payload 527 Data field is mandatory and is an integral number of bytes in length. 528 If the algorithm used to encrypt the payload requires cryptographic 529 synchronization data, e.g., an Initialization Vector (IV), then this 530 data is carried explicitly in the Payload field, but it is not called 531 out as a separate field in ESP, i.e., the transmission of an explicit 532 IV is invisible to ESP. (See Figure 2.) Any encryption algorithm 533 that requires such explicit, per-packet synchronization data MUST 534 indicate the length, any structure for such data, and the location of 535 this data as part of an RFC specifying how the algorithm is used with 536 ESP. (Typically the IV immediately precedes the ciphertext. See 537 Figure 2.) If such synchronization data is implicit, the algorithm 538 for deriving the data MUST be part of the algorithm definition RFC. 539 (If included in the Payload field, cryptographic synchronization 540 data, e.g., an Initialization Vector (IV), usually is not encrypted 541 per se (see Tables 1 and 2), although it sometimes is referred to as 542 being part of the ciphertext.) 544 Note that the beginning of the next layer protocol header MUST be 545 aligned relative to the beginning of the ESP header as follows. For 546 IPv4, this alignment is a multiple of 4 bytes. For IPv6, the 547 alignment is a multiple of 8 bytes. 549 With regard to ensuring the alignment of the (real) ciphertext in the 550 presence of an IV, note the following: 551 o For some IV-based modes of operation, the receiver treats 552 the IV as the start of the ciphertext, feeding it into the 553 algorithm directly. In these modes, alignment of the start 554 of the (real) ciphertext is not an issue at the receiver. 556 o In some cases, the receiver reads the IV in separately from 557 the ciphertext. In these cases, the algorithm specification 558 MUST address how alignment of the (real) ciphertext is to be 559 achieved. 561 Security Payload (ESP) 563 2.4 Padding (for Encryption) 565 Three factors require or motivate use of the Padding field. 566 o If an encryption algorithm is employed that requires the 567 plaintext to be a multiple of some number of bytes, e.g., 568 the block size of a block cipher, the Padding field is used 569 to fill the plaintext (consisting of the Payload Data, 570 Padding, Pad Length and Next Header fields) to the size 571 required by the algorithm. 573 o Padding also may be required, irrespective of encryption 574 algorithm requirements, to ensure that the resulting 575 ciphertext terminates on a 4-byte boundary. Specifically, 576 the Pad Length and Next Header fields must be right aligned 577 within a 4-byte word, as illustrated in the ESP packet 578 format figures above, to ensure that the ICV field (if 579 present) is aligned on a 4-byte boundary. 581 Padding beyond that required for the algorithm or alignment reasons 582 cited above, could be used to conceal the actual length of the 583 payload, in support of TFC. However, the Padding field described is 584 too limited to be effective for TFC and thus should not be used for 585 that purpose. Instead, the separate mechanism described below (see 586 Section 2.7) should be used when TFC is required. 588 The sender MAY add 0 to 255 bytes of padding. Inclusion of the 589 Padding field in an ESP packet is optional, subject to the 590 requirements noted above, but all implementations MUST support 591 generation and consumption of padding. 593 o For the purpose of ensuring that the bits to be encrypted 594 are a multiple of the algorithm's blocksize (first bullet 595 above), the padding computation applies to the Payload Data 596 exclusive of any IV, but including the ESP trailer 597 fields. If a combined algorithm mode requires transmission 598 of the SPI and Sequence Number to effect integrity, e.g., 599 replication of the SPI and Sequence Number in the Payload 600 Data, then the replicated versions of these data items, and 601 any associated, ICV-equivalent data, are included in the 602 computation of the pad length. (If the ESN option is 603 selected, the high order 32 bits of the ESN also would enter 604 into the computation, if the combined mode algorithm 605 requires their transmission for integrity.) 607 o For the purposes of ensuring that the ICV is aligned on a 608 4-byte boundary (second bullet above), the padding 609 computation applies to the Payload Data inclusive of the IV, 610 Security Payload (ESP) 612 the Pad Length, and Next Header fields. If a combined mode 613 algorithm is used, any replicated data and ICV-equivalent 614 data are included in the Payload Data covered by the padding 615 computation. 617 If an encryption or combined mode algorithm imposes constraints on 618 the values of the bytes used for padding they MUST be specified by 619 the RFC defining how the algorithm is employed with ESP. If the 620 algorithm requires checking of the values of the bytes used for 621 padding, this too MUST be specified in that RFC. 623 2.5 Pad Length 625 The Pad Length field indicates the number of pad bytes immediately 626 preceding it in the Padding field. The range of valid values is 0 to 627 255, where a value of zero indicates that no Padding bytes are 628 present. As noted above, this does not include any TFC padding bytes. 629 The Pad Length field is mandatory. 631 2.6 Next Header 633 The Next Header is a mandatory, 8-bit field that identifies the type 634 of data contained in the Payload Data field, e.g., an IPv4 or IPv6 635 packet, or a next layer header and data. The value of this field is 636 chosen from the set of IP Protocol Numbers defined on the web page of 637 the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates 638 IPv6 and a value of 6 indicates TCP. 640 To facilitate the rapid generation and discarding of the padding 641 traffic in support of traffic flow confidentiality (see 2.4), the 642 protocol value 59 (which means "no next header") MUST be used to 643 designate a "dummy" packet. A transmitter MUST be capable of 644 generating dummy packets marked with this value in the next protocol 645 field, and a receiver MUST be prepared to discard such packets, 646 without indicating an error. All other ESP header and trailer fields 647 (SPI, Sequence number, Padding, Pad Length, Next Header, and ICV) 648 MUST be present in dummy packets, but the plaintext portion of the 649 payload, other than this Next Header field, need not be well-formed, 650 e.g., the rest of the Payload Data may consist of only random bytes. 651 Dummy packets are discarded without prejudice. 653 2.7 Traffic Flow Confidentiality (TFC) Padding 655 As noted above, the Padding field is limited to 255 bytes in length. 656 This generally will not be adequate to hide traffic characteristics 657 relative to traffic flow confidentiality requirements. An optional 658 field, within the payload data, is provided specifically to address 659 the TFC requirement. 661 Security Payload (ESP) 663 An IPsec implementation SHOULD be capable of padding traffic by 664 adding bytes after the end of the Payload Data, prior to the 665 beginning of the Padding field. However, this padding (hereafter 666 referred to as TFC padding) can be added only if the "Payload Data" 667 field contains a specification of the length of the IP datagram, 668 e.g., if tunnel mode is employed. This information will enable the 669 receiver to discard the TFC padding, because the true length of the 670 Payload Data will be known. (ESP trailer fields are located by 671 counting back from the end of the ESP packet.) Accordingly, if TFC 672 padding is added, the field containing the specification of the 673 length of the IP datagram MUST NOT be modified to reflect this 674 padding. No requirements for the value of this padding are 675 established by this standard. 677 TFC padding takes advantage of an intrinsic feature of IP, i.e., 678 other data may be present in a buffer delivered to an IP interface, 679 beyond the packet length indicated by the IP total length field. 680 Thus, in tunnel mode, a compliant IP stack at a receiver should 681 ignore this padding. In this sense, existing IPsec implementations 682 could have made use of this capability previously, in a transparent 683 fashion. However, because receivers may not have been prepared to 684 deal with this padding, the SA management protocol MUST negotiate 685 this service prior to a transmitter employing it, to ensure backward 686 compatibility. Combined with the convention described in section 2.6 687 above, about the use of protocol ID 59, an ESP implementation is 688 capable of generating dummy and real packets that exhibit much 689 greater length variability, in support of TFC. 691 2.8 Integrity Check Value (ICV) 693 The Integrity Check Value is a variable-length field computed over 694 the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer 695 fields (integrity padding and high order ESN bits, if applicable) are 696 included in the ICV computation. The ICV field is optional; it is 697 present only if the integrity service is selected and a separate (not 698 combined mode) integrity algorithm is employed. The length of the 699 field is specified by the integrity algorithm selected and associated 700 with the SA. The integrity algorithm specification MUST specify the 701 length of the ICV and the comparison rules and processing steps for 702 validation. 704 3. Encapsulating Security Protocol Processing 706 3.1 ESP Header Location 708 ESP may be employed in two ways: transport mode or tunnel mode. 710 Security Payload (ESP) 712 3.1.1 Transport Mode Processing 714 In transport mode, ESP is inserted after the IP header and before a 715 next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of 716 IPv4, this translates to placing ESP after the IP header (and any 717 options that it contains), but before the next layer protocol. (If 718 AH is also applied to a packet, it is applied to the ESP header, 719 Payload, ESP Trailer and ICV, if present.) (Note that the term 720 "transport" mode should not be misconstrued as restricting its use to 721 TCP and UDP.) The following diagram illustrates ESP transport mode 722 positioning for a typical IPv4 packet, on a "before and after" basis. 723 (This and subsequent diagrams in this section show the ICV field, the 724 presence of which is a function of the security services and the 725 algorithm/mode selected.) 727 BEFORE APPLYING ESP 728 ---------------------------- 729 IPv4 |orig IP hdr | | | 730 |(any options)| TCP | Data | 731 ---------------------------- 733 AFTER APPLYING ESP 734 ------------------------------------------------- 735 IPv4 |orig IP hdr | ESP | | | ESP | ESP| 736 |(any options)| Hdr | TCP | Data | Trailer | ICV| 737 ------------------------------------------------- 738 |<---- encryption ---->| 739 |<-------- integrity ------->| 741 In the IPv6 context, ESP is viewed as an end-to-end payload, and thus 742 should appear after hop-by-hop, routing, and fragmentation extension 743 headers. Destination options extension header(s) could appear 744 before, after, or both before and after the ESP header depending on 745 the semantics desired. However, since ESP protects only fields after 746 the ESP header, it generally will be desirable to place the 747 destination options header(s) after the ESP header. The following 748 diagram illustrates ESP transport mode positioning for a typical IPv6 749 packet. 751 Security Payload (ESP) 753 BEFORE APPLYING ESP 754 --------------------------------------- 755 IPv6 | | ext hdrs | | | 756 | orig IP hdr |if present| TCP | Data | 757 --------------------------------------- 759 AFTER APPLYING ESP 760 --------------------------------------------------------- 761 IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| 762 |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 763 --------------------------------------------------------- 764 |<--- encryption ---->| 765 |<------ integrity ------>| 767 * = if present, could be before ESP, after ESP, or both 769 Note that in transport mode, for "bump-in- the-stack" or "bump-in- 770 the-wire" implementations, as defined in the Security Architecture 771 document, inbound and outbound IP fragments may require an IPsec 772 implementation to perform extra IP reassembly/fragmentation in order 773 to both conform to this specification and provide transparent IPsec 774 support. Special care is required to perform such operations within 775 these implementations when multiple interfaces are in use. 777 3.1.2 Tunnel Mode Processing 779 In tunnel mode, the "inner" IP header carries the ultimate (IP) 780 source and destination addresses, while an "outer" IP header contains 781 the addresses of the IPsec "peers", e.g., addresses of security 782 gateways. In tunnel mode, ESP protects the entire inner IP packet, 783 including the entire inner IP header. The position of ESP in tunnel 784 mode, relative to the outer IP header, is the same as for ESP in 785 transport mode. The following diagram illustrates ESP tunnel mode 786 positioning for typical IPv4 and IPv6 packets. 788 Security Payload (ESP) 790 BEFORE APPLYING ESP 791 ---------------------------- 792 IPv4 |orig IP hdr | | | 793 |(any options)| TCP | Data | 794 ---------------------------- 796 AFTER APPLYING ESP 798 ----------------------------------------------------------- 799 IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| 800 |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| 801 ----------------------------------------------------------- 802 |<--------- encryption --------->| 803 |<------------- integrity ------------>| 805 BEFORE APPLYING ESP 806 --------------------------------------- 807 IPv6 | | ext hdrs | | | 808 | orig IP hdr |if present| TCP | Data | 809 --------------------------------------- 811 AFTER APPLYING ESP 813 ------------------------------------------------------------ 814 IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| 815 |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 816 ------------------------------------------------------------ 817 |<--------- encryption ---------->| 818 |<------------ integrity ------------>| 820 * = if present, construction of outer IP hdr/extensions and 821 modification of inner IP hdr/extensions is discussed in 822 the Security Architecture document. 824 3.2 Algorithms 826 The mandatory-to-implement algorithms for use with ESP are described 827 in a separate RFC, to facilitate updating the algorithm requirements 828 independently from the protocol per se. Additional algorithms, beyond 829 those mandated for ESP, MAY be supported. Note that although both 830 confidentiality and integrity are optional, at least one of these 831 services MUST be selected hence both algorithms MUST NOT be 832 simultaneously NULL. 834 Security Payload (ESP) 836 3.2.1 Encryption Algorithms 838 The encryption algorithm employed to protect an ESP packet is 839 specified by the SA via which the packet is transmitted/received. 840 Because IP packets may arrive out of order, and not all packets may 841 arrive (packet loss) each packet must carry any data required to 842 allow the receiver to establish cryptographic synchronization for 843 decryption. This data may be carried explicitly in the payload 844 field, e.g., as an IV (as described above), or the data may be 845 derived from the plaintext portions of the (outer IP or ESP) packet 846 header. (Note that if plaintext header information is used to derive 847 an IV, that information may become security critical and thus the 848 protection boundary associated with the encryption process may grow. 849 For example, if one were to use the ESP Sequence Number to derive an 850 IV, the Sequence Number generation logic (hardware or software) would 851 have to be evaluated as part of the encryption algorithm 852 implementation. In the case of FIPS 140-2, this could significantly 853 extend the scope of a cryptographic module evaluation.) Since ESP 854 makes provision for padding of the plaintext, encryption algorithms 855 employed with ESP may exhibit either block or stream mode 856 characteristics. Note that since encryption (confidentiality) MAY be 857 an optional service (e.g., integrity-only ESP), this algorithm MAY be 858 "NULL" [KA98] 860 To allow an ESP implementation to compute the encryption padding 861 required by a block mode encryption algorithm, and to determine the 862 MTU impact of the algorithm, the RFC for each encryption algorithm 863 used with ESP must specify the padding modulus for the algorithm. 865 3.2.2 Integrity Algorithms 867 The integrity algorithm employed for the ICV computation is specified 868 by the SA via which the packet is transmitted/received. As was the 869 case for encryption algorithms, any integrity algorithm employed with 870 ESP must make provisions to permit processing of packets that arrive 871 out of order and to accommodate packet loss. The same admonition 872 noted above applies to use of any plaintext data to facilitate 873 receiver synchronization of integrity algorithms. Note that since the 874 integrity service MAY be optional, this algorithm may be "NULL". 876 To allow an ESP implementation to compute any implicit integrity 877 algorithm padding required, the RFC for each algorithm used with ESP 878 must specify the padding modulus for the algorithm. 880 Security Payload (ESP) 882 3.2.3 Combined Mode Algorithms 884 If a combined mode algorithm is employed, both confidentiality and 885 integrity services are provided. As was the case for encryption 886 algorithms, a combined mode algorithm must make provisions for per- 887 packet cryptographic synchronization, to permit decryption of packets 888 that arrive out of order and to accommodate packet loss. The means by 889 which a combined mode algorithm provides integrity for the payload, 890 and for the SPI and (Extended) Sequence Number fields, may vary for 891 different algorithm choices. In order to provide a uniform, algorithm 892 independent approach to invocation of combined mode algorithms, no 893 payload substructure is defined. For example, the SPI and Sequence 894 Number fields might be replicated within the ciphertext envelope and 895 an ICV may be appended to the ESP Trailer. None of these details 896 should be observable externally. 898 To allow an ESP implementation to determine the MTU impact of a 899 combined mode algorithm, the RFC for each algorithm used with ESP 900 must specify a (simple) formula that yields encrypted payload size, 901 as a function of the plaintext payload and sequence number sizes. 903 3.3 Outbound Packet Processing 905 In transport mode, the sender encapsulates the next layer protocol 906 information between the ESP header and the ESP trailer fields, and 907 retains the specified IP header (and any IP extension headers in the 908 IPv6 context). In tunnel mode, the outer and inner IP 909 header/extensions can be inter-related in a variety of ways. The 910 construction of the outer IP header/extensions during the 911 encapsulation process is described in the Security Architecture 912 document. 914 3.3.1 Security Association Lookup 916 ESP is applied to an outbound packet only after an IPsec 917 implementation determines that the packet is associated with an SA 918 that calls for ESP processing. The process of determining what, if 919 any, IPsec processing is applied to outbound traffic is described in 920 the Security Architecture document. 922 3.3.2 Packet Encryption and Integrity Check Value (ICV) Calculation 924 In this section, we speak in terms of encryption always being applied 925 because of the formatting implications. This is done with the 926 understanding that "no confidentiality" is offered by using the NULL 927 encryption algorithm (RFC 2410). There are several algorithmic 928 options. 930 Security Payload (ESP) 932 3.3.2.1 Separate Confidentiality and Integrity Algorithms 934 If separate confidentiality and integrity algorithms are employed, 935 the Sender proceeds as follows: 936 1. Encapsulate (into the ESP Payload field): 937 - for transport mode -- just the original next layer 938 protocol information. 939 - for tunnel mode -- the entire original IP datagram. 941 2. Add any necessary padding -- Optional TFC padding and 942 (encryption) Padding 944 3. Encrypt the result using the key, encryption algorithm, 945 and algorithm mode specified for the SA and using any 946 required cryptographic synchronization data. 947 - If explicit cryptographic synchronization data, 948 e.g., an IV, is indicated, it is input to the 949 encryption algorithm per the algorithm specification 950 and placed in the Payload field. 951 - If implicit cryptographic synchronization data is 952 employed, it is constructed and input to the 953 encryption algorithm as per the algorithm 954 specification. 955 - If integrity is selected, encryption is performed 956 first, before the integrity algorithm is applied, 957 and the encryption does not encompass the ICV 958 field. This order of processing facilitates rapid 959 detection and rejection of replayed or bogus packets 960 by the receiver, prior to decrypting the packet, 961 hence potentially reducing the impact of denial of 962 service attacks. It also allows for the possibility 963 of parallel processing of packets at the receiver, 964 i.e., decryption can take place in parallel with 965 integrity checking. Note that since the ICV is not 966 protected by encryption, a keyed integrity algorithm 967 must be employed to compute the ICV. 969 4. Compute the ICV over the ESP packet minus the ICV field. 970 Thus the ICV computation encompasses the SPI, Sequence 971 Number, Payload Data, Padding (if present), Pad Length, and 972 Next Header. (Note that the last 4 fields will be in 973 ciphertext form, since encryption is performed first.) If 974 the ESN option is enabled for the SA, it the high-order 32 975 bits of the Sequence Number are appended after the Next 976 Header field for purposes of this computation, but are not 977 transmitted. 979 For some integrity algorithms, the byte string over which the ICV 980 Security Payload (ESP) 982 computation is performed must be a multiple of a block size specified 983 by the algorithm. If the length of ESP packet (as described above) 984 does not match the block size requirements for the algorithm, 985 implicit padding MUST be appended to the end of the ESP packet. (This 986 padding is added after the Next Header field, or after the high-order 987 32 bits of the Sequence Number, if ESN is selected.) The padding 988 octets MUST have a value of zero. The block size (and hence the 989 length of the padding) is specified by the integrity algorithm 990 specification. This padding is not transmitted with the packet. Note 991 that MD5 and SHA-1 are viewed as having a 1-byte block size because 992 of their internal padding conventions. 994 3.3.2.2 Combined Confidentiality and Integrity Algorithms 996 If a combined confidentiality/integrity algorithm is employed, the 997 Sender proceeds as follows: 998 1. Encapsulate into the ESP Payload Data field: 999 - for transport mode -- just the original next layer 1000 protocol information. 1001 - for tunnel mode -- the entire original IP datagram. 1003 2. Add any necessary padding -- includes optional TFC padding 1004 and (encryption) Padding. 1006 3. Encrypt and integrity protect the result using the key 1007 and combined mode algorithm specified for the SA and using 1008 any required cryptographic synchronization data. 1009 - If explicit cryptographic synchronization data, 1010 e.g., an IV, is indicated, it is input to the 1011 combined mode algorithm per the algorithm 1012 specification and placed in the Payload field. 1013 - If implicit cryptographic synchronization data is 1014 employed, it is constructed and input to the 1015 encryption algorithm as per the algorithm 1016 specification. 1017 - The Sequence Number (or Extended Sequence Number, as 1018 appropriate) and the SPI are inputs to the 1019 algorithm, as they must be included in the integrity 1020 check computation. The means by which these values 1021 are included in this computation are a function of 1022 the combined mode algorithm employed and thus not 1023 specified in this standard. 1024 - The (explicit) ICV field is NOT part of the ESP packet 1025 format when a combined mode algorithm is employed, 1026 although an analogous field usually will a part of 1027 the ciphertext payload. The location of any 1028 integrity fields, and the means by which the 1029 Security Payload (ESP) 1031 Sequence Number and SPI are included in the 1032 integrity computation MUST be defined in an RFC that 1033 defines the use of the combined mode algorithm with 1034 ESP. 1036 3.3.3 Sequence Number Generation 1038 The sender's counter is initialized to 0 when an SA is established. 1039 The sender increments the Sequence Number (or ESN) for this SA and 1040 inserts the low-order 32 bits of the value into the Sequence Number 1041 field. Thus the first packet sent using a given SA will contain a 1042 Sequence Number of 1. 1044 If anti-replay is enabled (the default), the sender checks to ensure 1045 that the counter has not cycled before inserting the new value in the 1046 Sequence Number field. In other words, the sender MUST NOT send a 1047 packet on an SA if doing so would cause the Sequence Number to cycle. 1048 An attempt to transmit a packet that would result in Sequence Number 1049 overflow is an auditable event. The audit log entry for this event 1050 SHOULD include the SPI value, current date/time, Source Address, 1051 Destination Address, and (in IPv6) the cleartext Flow ID. 1053 The sender assumes anti-replay is enabled as a default, unless 1054 otherwise notified by the receiver (see 3.4.3) or if the SA was 1055 configured using manual key management. Thus typical behavior of an 1056 ESP implementation calls for the sender to establish a new SA when 1057 the Sequence Number (or ESN) cycles, or in anticipation of this value 1058 cycling. 1060 If anti-replay is disabled (as noted above), the sender does not need 1061 to monitor or reset the counter, e.g., in the case of manual key 1062 management (see Section 5). However, the sender still increments the 1063 counter and when it reaches the maximum value, the counter rolls over 1064 back to zero. (This behavior is recommended for multi-sender, 1065 multicast SAs, unless anti-replay mechanisms outside the scope of 1066 this standard are negotiated between the sender and receiver.) 1068 If ESN (see Appendix) is selected, only the low order 32 bits of the 1069 sequence number are transmitted in the Sequence Number field, 1070 although both sender and receiver maintain full 64-bit ESN counters. 1071 The high order 32 bits are included in the integrity check in an 1072 algorithm/mode-specific fashion, e.g., the high order 32 bits may be 1073 appended after the Next Header field when a separate integrity 1074 algorithm is employed. 1076 Security Payload (ESP) 1078 3.3.4 Fragmentation 1080 If necessary, fragmentation is performed after ESP processing within 1081 an IPsec implementation. Thus, transport mode ESP is applied only to 1082 whole IP datagrams (not to IP fragments). An IP packet to which ESP 1083 has been applied may itself be fragmented by routers en route, and 1084 such fragments must be reassembled prior to ESP processing at a 1085 receiver. In tunnel mode, ESP is applied to an IP packet, which may 1086 be a fragment of an IP datagram. For example, a security gateway or 1087 a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as 1088 defined in the Security Architecture document) may apply tunnel mode 1089 ESP to such fragments. 1091 NOTE: For transport mode -- As mentioned at the end of Section 3.1.1, 1092 bump- in-the-stack and bump-in-the-wire implementations may have to 1093 first reassemble a packet fragmented by the local IP layer, then 1094 apply IPsec, and then fragment the resulting packet. 1096 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 1097 implementations, it will be necessary to examine all the extension 1098 headers to determine if there is a fragmentation header and hence 1099 that the packet needs reassembling prior to IPsec processing. 1101 Fragmentation, whether performed by an IPsec implementation or by 1102 routers along the path between IPsec peers, significantly reduces 1103 performance. Moreover, the requirement for an ESP receiver to accept 1104 fragments for reassembly creates denial of service vulnerabilities. 1105 Thus an ESP implementation MAY choose to not support fragmentation 1106 and may mark transmitted packets with the DF bit, to facilitate PMTU 1107 discovery. In any case, an ESP implementation MUST support generation 1108 of ICMP PMTU messages (or equivalent internal signaling for native 1109 host implementations) to minimize the likelihood of fragmentation. 1110 Details of the support required for MTU management are contained in 1111 the Security Architecture document. 1113 3.4 Inbound Packet Processing 1115 3.4.1 Reassembly 1117 If required, reassembly is performed prior to ESP processing. If a 1118 packet offered to ESP for processing appears to be an IP fragment, 1119 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 1120 the receiver MUST discard the packet; this is an auditable event. The 1121 audit log entry for this event SHOULD include the SPI value, 1122 date/time received, Source Address, Destination Address, Sequence 1123 Number, and (in IPv6) the Flow ID. 1125 NOTE: For packet reassembly, the current IPv4 spec does NOT require 1126 Security Payload (ESP) 1128 either the zeroing of the OFFSET field or the clearing of the MORE 1129 FRAGMENTS flag. In order for a reassembled packet to be processed by 1130 IPsec (as opposed to discarded as an apparent fragment), the IP code 1131 must do these two things after it reassembles a packet. 1133 3.4.2 Security Association Lookup 1135 Upon receipt of a packet containing an ESP Header, the receiver 1136 determines the appropriate (unidirectional) SA via lookup in the SAD. 1137 For a unicast SA, this determination is based on the SPI or the SPI 1138 plus protocol field, as described in Section 2.1. If an 1139 implementation supports multicast traffic, the destination address is 1140 also employed in the lookup (in addition to the SPI), and the sender 1141 address also may be employed, as described in Section 2.1. (This 1142 process is described in more detail in the Security Architecture 1143 document.) The SAD entry for the SA also indicates whether the 1144 Sequence Number field will be checked, whether 32 or 64-bit Sequence 1145 Numbers are employed for the SA, whether the (explicit) ICV field 1146 should be present (and if so, its size), and it will specify the 1147 algorithms and keys to be employed for decryption and ICV computation 1148 (if applicable). 1150 If no valid Security Association exists for this packet, the receiver 1151 MUST discard the packet; this is an auditable event. The audit log 1152 entry for this event SHOULD include the SPI value, date/time 1153 received, Source Address, Destination Address, Sequence Number, and 1154 (in IPv6) the cleartext Flow ID. 1156 (Note that SA management traffic, e.g., IKE packets, does not need to 1157 be processed based on SPI, i.e., one can demultiplex this traffic 1158 separately, e.g., based on Next Protocol and Port fields.) 1160 3.4.3 Sequence Number Verification 1162 All ESP implementations MUST support the anti-replay service, though 1163 its use may be enabled or disabled by the receiver on a per-SA basis. 1164 This service MUST NOT be enabled unless the ESP integrity service 1165 also is enabled for the SA, since otherwise the Sequence Number field 1166 has not been integrity protected. Anti-replay is applicable to 1167 unicast as well as multicast SAs. However, this standard specifies no 1168 mechanisms for providing anti-replay for a multi-sender SA (unicast 1169 or multicast). In the absence of negotiation (or manual 1170 configuration) of an anti-replay mechanism for such an SA, it is 1171 recommended that sender and receiver checking of the sequence number 1172 for the SA be disabled (via negotiation or manual configuration), as 1173 noted below. 1175 If the receiver does not enable anti-replay for an SA, no inbound 1176 Security Payload (ESP) 1178 checks are performed on the Sequence Number. However, from the 1179 perspective of the sender, the default is to assume that anti-replay 1180 is enabled at the receiver. To avoid having the sender do unnecessary 1181 sequence number monitoring and SA setup (see section 3.3.3), if an SA 1182 establishment protocol is employed, the receiver SHOULD notify the 1183 sender, during SA establishment, if the receiver will not provide 1184 anti-replay protection. 1186 If the receiver has enabled the anti-replay service for this SA, the 1187 receive packet counter for the SA MUST be initialized to zero when 1188 the SA is established. For each received packet, the receiver MUST 1189 verify that the packet contains a Sequence Number that does not 1190 duplicate the Sequence Number of any other packets received during 1191 the life of this SA. This SHOULD be the first ESP check applied to a 1192 packet after it has been matched to an SA, to speed rejection of 1193 duplicate packets. 1195 ESP permits two-stage verification of packet sequence numbers. This 1196 capability is important whenever an ESP implementation (typically the 1197 cryptographic module portion thereof) is not capable of performing 1198 decryption and/or integrity checking at the same rate as the 1199 interface(s) to unprotected networks. If the implementation is 1200 capable of such "line rate" operation, then it is not necessary to 1201 perform the preliminary verification stage described below. 1203 The preliminary Sequence Number check is effected utilizing the 1204 Sequence Number value in the ESP Header and is performed prior to 1205 integrity checking and decryption. If this preliminary check fails, 1206 the packet is discarded, thus avoiding the need for any cryptographic 1207 operations by the receiver. If the preliminary check is successful, 1208 the receiver cannot yet modify it's local counter, since the 1209 integrity of the Sequence Number has not been verified at this point. 1211 Duplicates are rejected through the use of a sliding receive window. 1212 How the window is implemented is a local matter, but the following 1213 text describes the functionality that the implementation must 1214 exhibit. 1216 The "right" edge of the window represents the highest, validated 1217 Sequence Number value received on this SA. Packets that contain 1218 Sequence Numbers lower than the "left" edge of the window are 1219 rejected. Packets falling within the window are checked against a 1220 list of received packets within the window. If the ESN option is 1221 selected for an SA, only the low-order 32 bits of the sequence number 1222 are explicitly transmitted, but the receiver employs the full 1223 sequence number computed using the high-order 32 bits for the 1224 indicated SA (from his local counter) when checking the received 1225 Sequence Number against the receive window. In constructing the full 1226 Security Payload (ESP) 1228 sequence number, if the low order 32 bits carried in the packet are 1229 lower in value than the low order 32 bits of the receiver's sequence 1230 number, the receiver assumes that the high order 32 bits have been 1231 incremented, moving to a new sequence number subspace. (This 1232 algorithm accommodates gaps in reception for a single SA as large as 1233 2**32-1 packets. If a larger gap occurs, additional, heuristic checks 1234 for resynchronization of the receiver sequence number counter MAY be 1235 employed, as described in the Appendix.) 1237 If the received packet falls within the window and is not a 1238 duplicate, or if the packet is to the right of the window, and if a 1239 separate integrity algorithm is employed, then the receiver proceeds 1240 to integrity verification. If a combined mode algorithm is employed, 1241 the integrity check is performed along with decryption. In either 1242 case, if the integrity check fails, the receiver MUST discard the 1243 received IP datagram as invalid; this is an auditable event. The 1244 audit log entry for this event SHOULD include the SPI value, 1245 date/time received, Source Address, Destination Address, the Sequence 1246 Number, and (in IPv6) the Flow ID. The receive window is updated 1247 only if the integrity verification succeeds. (If a combined mode 1248 algorithm is being used, then the integrity protected Sequence Number 1249 must also match the Sequence Number used for anti-replay protection.) 1251 A minimum window size of 32 packets MUST be supported when 32-bit 1252 sequence numbers are employed; a window size of 64 is preferred and 1253 SHOULD be employed as the default. Another window size (larger than 1254 the minimum) MAY be chosen by the receiver. (The receiver does NOT 1255 notify the sender of the window size.) The receive window size 1256 should be increased for higher speed environments, irrespective of 1257 assurance issues. Values for minimum and recommended receive window 1258 sizes for very high speed (e.g., multi-gigabit/second) devices are 1259 not specified by this standard. 1261 3.4.4 Integrity Check Value Verification 1263 As with outbound processing, there are several options for inbound 1264 processing, based on features of the algorithms employed. 1266 3.4.4.1 Separate Confidentiality and Integrity Algorithms 1268 If separate confidentiality and integrity algorithms are employed 1269 processing proceeds as follows:, 1270 1. If integrity has been selected, the receiver computes the 1271 ICV over the ESP packet minus the ICV, using the specified 1272 integrity algorithm and verifies that it is the same as the 1273 ICV carried in the packet. Details of the computation are 1274 provided below. 1276 Security Payload (ESP) 1278 If the computed and received ICV's match, then the datagram 1279 is valid, and it is accepted. If the test fails, then the 1280 receiver MUST discard the received IP datagram as invalid; 1281 this is an auditable event. The log data SHOULD include 1282 the SPI value, date/time received, Source Address, 1283 Destination Address, the Sequence Number, and (for IPv6) 1284 the cleartext Flow ID. 1286 DISCUSSION: 1288 Begin by removing and saving the ICV field. Next check the 1289 overall length of the ESP packet minus the ICV field. If 1290 implicit padding is required, based on the blocksize of the 1291 integrity algorithm, append zero-filled bytes to the end of 1292 the ESP packet directly after the Next Header 1293 field. Perform the ICV computation and compare the result 1294 with the saved value, using the comparison rules defined by 1295 the algorithm specification. 1297 2. The receiver decrypts the ESP Payload Data, Padding, Pad 1298 Length, and Next Header using the key, encryption 1299 algorithm, algorithm mode, and cryptographic 1300 synchronization data (if any), indicated by the SA. As in 1301 section 3.3.2, we speak here in terms of encryption always 1302 being applied because of the formatting implications. This 1303 is done with the understanding that "no confidentiality" is 1304 offered by using the NULL encryption algorithm (RFC 2410). 1306 - If explicit cryptographic synchronization data, 1307 e.g., an IV, is indicated, it is taken from the 1308 Payload field and input to the decryption algorithm 1309 as per the algorithm specification. 1311 - If implicit cryptographic synchronization data is 1312 indicated, a local version of the IV is constructed 1313 and input to the decryption algorithm as per the 1314 algorithm specification. 1316 3. The receiver processes any Padding as specified in the 1317 encryption algorithm specification. If the default padding 1318 scheme (see Section 2.4) has been employed, the receiver 1319 SHOULD inspect the Padding field before removing the 1320 padding prior to passing the decrypted data to the next 1321 layer. 1323 4. The receiver checks the Next Header field. If the value is 1324 "59" (no next header), the (dummy) packet is discarded 1325 without further processing. 1327 Security Payload (ESP) 1329 5. The receiver reconstructs the original IP datagram from: 1330 - for transport mode -- outer IP header plus the 1331 original next layer protocol information in the ESP 1332 Payload field 1333 - for tunnel mode -- the entire IP datagram in the ESP 1334 Payload field. 1336 The exact steps for reconstructing the original datagram 1337 depend on the mode (transport or tunnel) and are described 1338 in the Security Architecture document. At a minimum, in an 1339 IPv6 context, the receiver SHOULD ensure that the decrypted 1340 data is 8-byte aligned, to facilitate processing by the 1341 protocol identified in the Next Header field. This 1342 processing "discards" any (optional) TFC padding that has 1343 been added for traffic flow confidentiality. (If present, 1344 this will have been inserted after the IP datagram (or 1345 transport-layer frame) and before the Padding field (see 1346 section 2.4).) 1348 If integrity checking and encryption are performed in parallel, 1349 integrity checking MUST be completed before the decrypted packet is 1350 passed on for further processing. This order of processing 1351 facilitates rapid detection and rejection of replayed or bogus 1352 packets by the receiver, prior to decrypting the packet, hence 1353 potentially reducing the impact of denial of service attacks. 1355 Note: If the receiver performs decryption in parallel with integrity 1356 checking, care must be taken to avoid possible race conditions with 1357 regard to packet access and extraction of the decrypted packet. 1359 3.4.4.2 Combined Confidentiality and Integrity Algorithms 1361 If a combined confidentiality and integrity algorithm is employed, 1362 then the receiver proceeds as follows: 1364 1. Decryps and integrity check the ESP Payload Data, 1365 Padding, Pad Length, and Next Header, using the key, 1366 algorithm, algorithm mode, and cryptographic 1367 synchronization data (if any), indicated by the SA. The SPI 1368 from the ESP header, and the (receiver) packet counter 1369 value (adjusted as required from the processing described 1370 in Section 3.4.3) are inputs to this algorithm, as they are 1371 required for the integrity check. 1373 - If explicit cryptographic synchronization data, 1374 e.g., an IV, is indicated, it is taken from the 1375 Security Payload (ESP) 1377 Payload field and input to the decryption algorithm 1378 as per the algorithm specification. 1380 - If implicit cryptographic synchronization data, 1381 e.g., an IV, is indicated, a local version of the IV 1382 is constructed and input to the decryption algorithm 1383 as per the algorithm specification. 1385 2. If the integrity check performed by the combined mode 1386 algorithm fails, the receiver MUST discard the received IP 1387 datagram as invalid; this is an auditable event. The log 1388 data SHOULD include the SPI value, date/time received, 1389 Source Address, Destination Address, the Sequence Number, 1390 and (in IPv6) the cleartext Flow ID. 1392 3. Process any Padding as specified in the encryption 1393 algorithm specification, if the algorithm has not already 1394 done so. 1396 4. The receiver checks the Next Header field. If the value is 1397 "59" (no next header), the (dummy) packet is discarded 1398 without further processing. 1400 5. Extract the original IP datagram (tunnel mode) or 1401 transport-layer frame (transport mode) from the ESP Payload 1402 Data field. This implicitly discards any (optional) 1403 padding that has been added for traffic flow 1404 confidentiality. (If present, the TFC padding will have 1405 been inserted after the IP payload and before the Padding 1406 field (see section 2.4).) 1408 4. Auditing 1410 Not all systems that implement ESP will implement auditing. However, 1411 if ESP is incorporated into a system that supports auditing, then the 1412 ESP implementation MUST also support auditing and MUST allow a system 1413 administrator to enable or disable auditing for ESP. For the most 1414 part, the granularity of auditing is a local matter. However, 1415 several auditable events are identified in this specification and for 1416 each of these events a minimum set of information that SHOULD be 1417 included in an audit log is defined. 1419 - No valid Security Association exists for a session. The 1420 audit log entry for this event SHOULD include the SPI value, 1421 date/time received, Source Address, Destination Address, 1422 Sequence Number, and (for IPv6) the cleartext Flow ID. 1424 - A packet offered to ESP for processing appears to be an IP 1425 Security Payload (ESP) 1427 fragment, i.e., the OFFSET field is non-zero or the MORE 1428 FRAGMENTS flag is set. The audit log entry for this event 1429 SHOULD include the SPI value, date/time received, Source 1430 Address, Destination Address, Sequence Number, and (in IPv6) 1431 the Flow ID. 1433 - Attempt to transmit a packet that would result in Sequence 1434 Number overflow. The audit log entry for this event SHOULD 1435 include the SPI value, current date/time, Source Address, 1436 Destination Address, Sequence Number, and (for IPv6) the 1437 cleartext Flow ID. 1439 - The received packet fails the anti-replay checks. The audit 1440 log entry for this event SHOULD include the SPI value, 1441 date/time received, Source Address, Destination Address, the 1442 Sequence Number, and (in IPv6) the Flow ID. 1444 - The integrity check fails. The audit log entry for this 1445 event SHOULD include the SPI value, date/time received, 1446 Source Address, Destination Address, the Sequence Number, 1447 and (for IPv6) the Flow ID. 1449 Additional information also MAY be included in the audit log for each 1450 of these events, and additional events, not explicitly called out in 1451 this specification, also MAY result in audit log entries. There is 1452 no requirement for the receiver to transmit any message to the 1453 purported sender in response to the detection of an auditable event, 1454 because of the potential to induce denial of service via such action. 1456 5. Conformance Requirements 1458 Implementations that claim conformance or compliance with this 1459 specification MUST implement the ESP syntax and processing described 1460 here for unicast traffic, and MUST comply with all additional packet 1461 processing requirements levied by the Security Architecture document 1462 [KA98]. Additionally, if an implementation claims to support 1463 multicast traffic, it MUST comply with the additional requirements 1464 specified for support of such traffic. If the key used to compute an 1465 ICV is manually distributed, correct provision of the anti-replay 1466 service would require correct maintenance of the counter state at the 1467 sender, until the key is replaced, and there likely would be no 1468 automated recovery provision if counter overflow were imminent. Thus 1469 a compliant implementation SHOULD NOT provide anti-replay service in 1470 conjunction with SAs that are manually keyed. 1472 The mandatory-to-implement algorithms for use with ESP are described 1473 in a separate document, to facilitate updating the algorithm 1474 requirements independently from the protocol per se. Additional 1475 Security Payload (ESP) 1477 algorithms, beyond those mandated for ESP, MAY be supported. 1479 Since use of encryption in ESP is optional, support for the "NULL" 1480 encryption algorithm also is required to maintain consistency with 1481 the way ESP services are negotiated. Support for the confidentiality- 1482 only service version of ESP is optional. If an implementation offers 1483 this service, it MUST also support the negotiation of the NULL 1484 integrity algorithm. NOTE that while integrity and encryption may 1485 each be "NULL" under the circumstances noted above, they MUST NOT 1486 both be "NULL". 1488 6. Security Considerations 1490 Security is central to the design of this protocol, and thus security 1491 considerations permeate the specification. Additional security- 1492 relevant aspects of using the IPsec protocol are discussed in the 1493 Security Architecture document. 1495 7. Differences from RFC 2406 1497 This document differs from RFC 2406 in a number of significant ways. 1499 o Confidentiality-only service -- now a MAY, not a MUST. 1500 o SPI -- modified to specify a uniform algorithm for SAD lookup for 1501 unicast and multicast SAs, covering a wider range of multicast 1502 technologies. For unicast, the SPI may be used alone to select an SA, 1503 or may be combined with the protocol, at the option of the receiver. 1504 For multicast SAs, the SPI is combined with the destination address, 1505 and optionally the source address, to select an SA. 1506 o Sequence number -- added a new option for a 64-bit sequence 1507 number for very high-speed communications. Clarified sender 1508 and receiver processing requirements for multicast SAs and 1509 multi-sender SAs. 1510 o Payload data -- broadened model to accommodate combined mode 1511 algorithms. 1512 o Padding for improved traffic flow confidentiality -- added 1513 requirement to be able to add bytes after the end of the IP 1514 Payload, prior to the beginning of the Padding field. 1515 o Next Header -- added requirement to be able to generate and 1516 discard dummy padding packets (Next Header = 59) 1517 o ICV -- broadened model to accommodate combined mode algorithms. 1518 o Algorithms -- Added combined confidentiality mode algorithms. 1519 o Moved references to mandatory algorithms to a separate document. 1520 o Inbound and Outbound packet processing -- there are now two 1521 paths -- (1) separate confidentiality and integrity 1522 algorithms, (2) combined confidentiality mode 1523 algorithms. Because of the addition of combined mode 1524 algorithms, the encryption/decryption and integrity sections 1525 Security Payload (ESP) 1527 have been combined for both inbound and outbound packet 1528 processing. 1530 Acknowledgements 1532 The author would like to acknowledge the contributions of Ran 1533 Atkinson, who played a critical role in initial IPsec activities, and 1534 who authored the first series of IPsec standards: RFCs 1825-1827. 1535 Karen Seo deserves special thanks for providing help in the editing 1536 of this and the previous version of this specification. The author 1537 also would like to thank the members of the IPSEC and MSEC working 1538 groups who have contributed to the development of this protocol 1539 specification. 1541 References 1543 [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security 1544 Protocols", Proceedings of the Sixth Usenix Unix Security 1545 Symposium, July, 1996. 1547 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 1548 Requirement Level", BCP 14, RFC 2119, March 1997. 1550 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange 1551 (IKE)", RFC 2409, November 1998. 1553 [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for 1554 IP", Internet Draft, draft-ietf-ssm-arch-01.txt, November 1555 3, 2002. 1557 [KA98] Kent, S., and R. Atkinson, "Security Architecture for the 1558 Internet Protocol", RFC 2401, November 1998. 1560 [Ken03] Kent, S., "IP Authentication Header", RFC ???, ??? 2003. 1562 [Kra01] Krawczyk, H., "The Order of Encryption and Authentication 1563 for Protecting Communications (Or: How Secure Is SSL?)", 1564 CRYPTO' 2001. 1566 [MD98] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher 1567 Algorithm With Explicit IV", RFC 2405, November 1998. 1569 [MG98a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within 1570 ESP and AH", RFC 2403, November 1998. 1572 [MG98b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within 1573 ESP and AH", RFC 2404, November 1998. 1575 Security Payload (ESP) 1577 Disclaimer 1579 The views and specification here are those of the authors and are not 1580 necessarily those of their employers. The authors and their 1581 employers specifically disclaim responsibility for any problems 1582 arising from correct or incorrect implementation or use of this 1583 specification. 1585 Author Information 1587 Stephen Kent 1588 BBN Technologies 1589 10 Moulton Street 1590 Cambridge, MA 02138 1591 USA 1593 Phone: +1 (617) 873-3988 1594 EMail: kent@bbn.com 1595 Security Payload (ESP) 1597 Appendix -- Extended (64-bit) Sequence Numbers 1599 A1. Overview 1601 This appendix describes an extended sequence number (ESN) scheme for 1602 use with IPsec (ESP and AH) that employs a 64-bit sequence number, 1603 but in which only the low order 32 bits are transmitted as part of 1604 each packet. It covers both the window scheme used to detect 1605 replayed packets and the determination of the high order bits of the 1606 sequence number that are used both for replay rejection and for 1607 computation of the ICV. It also discusses a mechanism for handling 1608 loss of synchronization relative to the (not transmitted) high order 1609 bits. 1611 A2. Anti-Replay Window 1613 The receiver will maintain an anti-replay window of size W. This 1614 window will limit how far out of order a packet can be, relative to 1615 the packet with the highest sequence number that has been 1616 authenticated so far. (No requirement is established for minimum or 1617 recommended sizes for this window, beyond the 32 and 64-packet values 1618 already established for 32-bit sequence number windows. However, it 1619 is suggested that an implementer scale these values consistent with 1620 the interface speed supported by an implementation that makes use of 1621 the ESN option. Also, the algorithm described below assumes that the 1622 window is no greater than 2^31 packets in width.) All 2^32 sequence 1623 numbers associated with any fixed value for the high order 32 bits 1624 (Seqh) will hereafter be called a sequence number subspace. The 1625 following table lists pertinent variables and their definitions. 1627 Var. Size 1628 Name (bits) Meaning 1629 ---- ------ --------------------------- 1630 W 32 Size of window 1631 T 64 Highest sequence number authenticated so far, 1632 upper bound of window 1633 Tl 32 Lower 32 bits of T 1634 Th 32 Upper 32 bits of T 1635 B 64 Lower bound of window 1636 Bl 32 Lower 32 bits of B 1637 Bh 32 Upper 32 bits of B 1638 Seq 64 Sequence number of received packet 1639 Seql 32 Lower 32 bits of Seq 1640 Seqh 32 Upper 32 bits of Seq 1642 When performing the anti-replay check, or when determining which high 1643 order bits to use to authenticate an incoming packet, there are two 1644 cases: 1646 Security Payload (ESP) 1648 + Case A: Tl >= (W - 1). In this case, the window is within one 1649 sequence number subspace. (See Figure 1) 1650 + Case B: Tl < (W - 1). In this case, the window spans two 1651 sequence number subspaces. (See Figure 2) 1653 In the figures below, the bottom line ("----") shows two consecutive 1654 sequence number subspaces, with zero's indicating the beginning of 1655 each subspace. The two shorter lines above it show the higher order 1656 bits that apply. The "====" represents the window. The "****" 1657 represents future sequence numbers, i.e., those beyond the current 1658 highest sequence number authenticated (ThTl). 1660 Th+1 ********* 1662 Th =======***** 1664 --0--------+-----+-----0--------+-----------0-- 1665 Bl Tl Bl 1666 (Bl+2^32) mod 2^32 1668 Figure 1 -- Case A 1670 Th ====************** 1672 Th-1 === 1674 --0-----------------+--0--+--------------+--0-- 1675 Bl Tl Bl 1676 (Bl+2^32) mod 2^32 1678 Figure 2 -- Case B 1680 A2.1. Managing and Using the Anti-Replay Window 1682 The anti-replay window can be thought of as a string of bits where 1683 `W' defines the length of the string. W = T - B + 1 and cannot 1684 exceed 2^32 - 1 in value. The bottom-most bit corresponds to B and 1685 the top-most bit corresponds to T and each sequence number from Bl 1686 through Tl is represented by a corresponding bit. The value of the 1687 bit indicates whether or not a packet with that sequence number has 1688 been received and authenticated, so that replays can be detected and 1689 rejected. 1691 When a packet with a 64-bit sequence number (Seq) greater than T is 1692 received and validated, 1693 Security Payload (ESP) 1695 + B is increased by (Seq - T) 1696 + (Seq - T) bits are dropped from the low end of the window 1697 + (Seq - T) bits are added to the high end of the window 1698 + The top bit is set to indicate that a packet with that sequence 1699 number has been received and authenticated 1700 + The new bits between T and the top bit are set to indicate that 1701 no packets with those sequence numbers have been received yet. 1702 + T is set to the new sequence number 1704 In checking for replayed packets, 1706 + Under Case A: If Seql >= Bl (where Bl = Tl - W + 1) AND 1707 Seql <= Tl, then check the corresponding bit in the window to see 1708 if this Seql has already been seen. If yes, reject the packet. 1709 If no, perform integrity check (see Section 2.2. below for 1710 determination of SeqH). 1712 + Under Case B: If Seql >= Bl (where Bl = Tl - W + 1) OR 1713 Seql <= Tl, then check the corresponding bit in the window to see 1714 if this Seql has already been seen. If yes, reject the packet. 1715 If no, perform integrity check (see Section 2.2. below for 1716 determination of Seqh). 1718 A2.2. Determining the Higher Order Bits (Seqh) of the Sequence Number 1720 Since only `Seql' will be transmitted with the packet, the receiver 1721 must deduce and track the sequence number subspace into which each 1722 packet falls, i.e., determine the value of Seqh. The following 1723 equations define how to select Seqh under "normal" conditions; see 1724 Section 3 for a discussion of how to recover from extreme packet 1725 loss. 1727 + Under Case A (Figure 1): 1728 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th 1729 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th + 1 1731 + Under Case B (Figure 2): 1732 If Seql >= Bl (where Bl = Tl - W + 1), then Seqh = Th - 1 1733 If Seql < Bl (where Bl = Tl - W + 1), then Seqh = Th 1735 A2.3. Pseudo-code Example 1737 The following pseudo-code illustrates the above algorithms for anti- 1738 replay and integrity checks. The values for `Seql', `Tl', `Th' and 1739 `W', are 32-bit unsigned integers. Arithmetic is mod 2^32. 1741 Security Payload (ESP) 1743 If (Tl >= W - 1) Case A 1744 If (Seql >= Tl - W + 1) 1745 Seqh = Th 1746 If (Seql <= Tl) 1747 If (pass replay check) 1748 If (pass integrity check) 1749 Set bit corresponding to Seql 1750 Pass the packet on 1751 Else reject packet 1752 Else reject packet 1753 Else 1754 If (pass integrity check) 1755 Tl = Seql (shift bits) 1756 Set bit corresponding to Seql 1757 Pass the packet on 1758 Else reject packet 1759 Else 1760 Seqh = Th + 1 1761 If (pass integrity check) 1762 Tl = Seql (shift bits) 1763 Th = Th + 1 1764 Set bit corresponding to Seql 1765 Pass the packet on 1766 Else reject packet 1767 Else Case B 1768 If (Seql >= Tl - W + 1) 1769 Seqh = Th - 1 1770 If (pass replay check) 1771 If (pass integrity check) 1772 Set the bit corresponding to Seql 1773 Pass packet on 1774 Else reject packet 1775 Else reject packet 1776 Else 1777 If (Seql <= Tl) 1778 If (pass replay check) 1779 If (pass integrity check) 1780 Set the bit corresponding to Seql 1781 Pass packet on 1782 Else reject packet 1783 Else reject packet 1784 Else 1785 If (pass integrity check) 1786 Tl = Seql (shift bits) 1787 Set the bit corresponding to Seql 1788 Pass packet on 1789 Else reject packet 1790 Security Payload (ESP) 1792 A3. Handling Loss of Synchronization due to Significant Packet Loss 1794 If there is an undetected packet loss of 2^32 or more consecutive 1795 packets on a single SA, then the transmitter and receiver will lose 1796 synchronization of the high order bits, i.e., the equations in 1797 Section 2.2. will fail to yield the correct value. Unless this 1798 problem is detected and addressed, subsequent packets on this SA will 1799 fail authentication checks and be discarded. The following procedure 1800 SHOULD be implemented by any IPsec (ESP or AH) implementation that 1801 supports the ESN option. 1803 Note that this sort of extended traffic loss seems unlikely to occur 1804 if any significant fraction of the traffic on the SA in question is 1805 TCP, because the source would fail to receive ACKs and would stop 1806 sending long before 2^32 packets had been lost. Also, for any bi- 1807 directional application, even ones operating above UDP, such an 1808 extended outage would likely result in triggering some form of 1809 timeout. However, a unidirectional application, operating over UDP 1810 might lack feedback that would cause automatic detection of a loss of 1811 this magnitude, hence the motivation to develop a recovery method for 1812 this case. 1814 The solution we've chosen was selected to: 1816 + minimize the impact on normal traffic processing 1818 + avoid creating an opportunity for a new denial of service attack 1819 such as might occur by allowing an attacker to force diversion of 1820 resources to a resynchronization process. 1822 + limit the recovery mechanism to the receiver -- since anti-replay 1823 is a service only for the receiver, and the transmitter generally 1824 is not aware of whether the receiver is using sequence numbers in 1825 support of this optional service, it is preferable for recovery 1826 mechanisms to be local to the receiver. This also allows for 1827 backwards compatibility. 1829 A3.1. Triggering Resynchronization 1831 For each SA, the receiver records the number of consecutive packets 1832 that fail authentication. This count is used to trigger the 1833 resynchronization process which should be performed in the background 1834 or using a separate processor. Receipt of a valid packet on the SA 1835 resets the counter to zero. The value used to trigger the 1836 resynchronization process is a local parameter. There is no 1837 requirement to support distinct trigger values for different SAs, 1838 although an implementer may choose to do so. 1840 Security Payload (ESP) 1842 A3.2. Resynchronization Process 1844 When the above trigger point is reached, a "bad" packet is selected 1845 for which authentication is retried using successively larger values 1846 for the upper half of the sequence number (Seqh). These values are 1847 generated by incrementing by one for each retry. The number of 1848 retries should be limited, in case this is a packet from the "past" 1849 or a bogus packet. The limit value is a local parameter. (Because 1850 the Seqh value is implicitly placed after the ESP (or AH) payload, it 1851 may be possible to optimize this procedure by executing the integrity 1852 algorithm over the packet up to the end point of the payload, then 1853 compute different candidate ICV's by varying the value of Seqh.) 1854 Successful authentication of a packet via this procedure resets the 1855 consecutive failure count and sets the value of T to that of the 1856 received packet. 1858 This solution requires support only on the part of the receiver, 1859 thereby allowing for backwards compatibility. Also, because 1860 resynchronization efforts would either occur in the background or 1861 utilize an additional processor, this solution does not impact 1862 traffic processing and a denial of service attack cannot divert 1863 resources away from traffic processing. 1865 Security Payload (ESP) 1867 Full Copyright Statement 1869 Copyright (C) The Internet Society (2003). All Rights Reserved. 1871 This document and translations of it may be copied and furnished to 1872 others, and derivative works that comment on or otherwise explain it 1873 or assist in its implementation may be prepared, copied, published 1874 and distributed, in whole or in part, without restriction of any 1875 kind, provided that the above copyright notice and this paragraph are 1876 included on all such copies and derivative works. However, this 1877 document itself may not be modified in any way, such as by removing 1878 the copyright notice or references to the Internet Society or other 1879 Internet organizations, except as needed for the purpose of 1880 developing Internet standards in which case the procedures for 1881 copyrights defined in the Internet Standards process must be 1882 followed, or as required to translate it into languages other than 1883 English. 1885 The limited permissions granted above are perpetual and will not be 1886 revoked by the Internet Society or its successors or assigns. 1888 This document and the information contained herein is provided on an 1889 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1890 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1891 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1892 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1893 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1895 Expires October 2003