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