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