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