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