idnits 2.17.1 draft-ietf-ipsec-esp-v3-01.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. == There are 2 instances of lines with non-ascii characters in the document. == 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 70 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 197 has weird spacing: '...et. The packe...' == Line 330 has weird spacing: '...t Integ is...' == Line 359 has weird spacing: '...t Integ is...' == Line 363 has weird spacing: '... plain p...' == Line 369 has weird spacing: '... cipher d...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 8016 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 172, but not defined -- Looks like a reference, but probably isn't: '1' on line 376 -- Looks like a reference, but probably isn't: '2' on line 377 -- Looks like a reference, but probably isn't: '3' on line 379 -- Looks like a reference, but probably isn't: '4' on line 380 -- Looks like a reference, but probably isn't: '5' on line 381 -- Looks like a reference, but probably isn't: '6' on line 353 == Unused Reference: 'HC98' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: 'MD98' is defined on line 1515, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel96' ** Obsolete normative reference: RFC 2409 (ref. 'HC98') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. 'KA98a') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'KA98b') (Obsoleted by RFC 4302, RFC 4305) Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kent 3 Internet Draft BBN Technologies 4 draft-ietf-ipsec-esp-v3-01.txt November 2001 5 Expires May 2002 7 IP Encapsulating Security Payload (ESP) 9 Status of This Memo 11 This document is an Internet Draft and is subject to all provisions 12 of Section 10 of RFC2026. Internet Drafts are working documents of 13 the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working 15 documents as Internet Drafts 17 Internet Drafts are draft documents valid for a maximum of 6 months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet Drafts as reference 20 material or to cite them other than as a "work in progress". 22 The list of current Internet Drafts can be accessed at 23 http://www.ietf.org/lid-abstracts.html 25 The list of Internet Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Copyright (C) The Internet Society (2001). All Rights Reserved. 30 Abstract 32 This memo describes an updated version of the Encapsulating Security 33 Payload (ESP) protocol, which is designed to provide a mix of 34 security services in IPv4 and Ipv6. ESP is used to provide 35 confidentiality, data origin authentication, connectionless 36 integrity, an anti-replay service (a form of partial sequence 37 integrity), and limited traffic flow confidentiality. This document 38 is based upon RFC 2406 (November 1998). Section 7 provides a brief 39 review of the differences between this document and RFC 2406. 41 Comments should be sent to Stephen Kent (kent@bbn.com). 43 Security Payload (ESP) 45 Table of Contents 47 1. Introduction..................................................4 48 2. Encapsulating Security Payload Packet Format..................6 49 2.1 Security Parameters Index...............................10 50 2.2 Sequence Number ........................................11 51 2.2.1 Extended Sequence Number...........................12 52 2.3 Payload Data............................................12 53 2.4 Padding (for Encryption)................................13 54 2.5 Pad Length..............................................14 55 2.6 Next Header.............................................14 56 2.7 Traffic Flow Confidentiality (TFC) Padding..............15 57 2.8 Integrity Check Value (ICV).............................16 58 3. Encapsulating Security Protocol Processing...................16 59 3.1 ESP Header Location.....................................16 60 3.1.1 Transport Mode Processing..........................16 61 3.1.2 Tunnel Mode Processing.............................18 62 3.2 Algorithms..............................................19 63 3.2.1 Encryption Algorithms..............................19 64 3.2.2 Integrity Algorithms................................20 65 3.2.3 Combined Mode Algorithms............................20 66 3.3 Outbound Packet Processing..............................21 67 3.3.1 Security Association Lookup........................21 68 3.3.2 Packet Encryption and Integrity Check Value (ICV) 69 Calculation.........................................21 70 3.3.2.1 Separate Confidentiality and Integrity 71 Algorithms....................................22 72 3.3.2.2 Combined Mode Algorithms......................23 73 3.3.3 Sequence Number Generation..........................24 74 3.3.4 Fragmentation......................................25 75 3.4 Inbound Packet Processing...............................25 76 3.4.1 Reassembly.........................................25 77 3.4.2 Security Association Lookup........................26 78 3.4.3 Sequence Number Verification.......................26 79 3.4.4 Integrity Check Value Verification and Packet 80 Decryption..........................................28 81 3.4.4.1 Separate Confidentiality and Integrity 82 Algorithms....................................28 83 3.4.4.2 Combined Mode Algorithms .....................30 84 4. Auditing.....................................................31 85 5. Conformance Requirements.....................................32 86 6. Security Considerations......................................33 87 7. Differences from RFC 2406....................................33 88 Acknowledgements................................................34 89 References......................................................34 90 Disclaimer......................................................34 91 Author Information..............................................35 92 Security Payload (ESP) 94 Appendix -- Extended Sequence Number............................36 95 Full Copyright Statement........................................37 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, e.g., through the use of tunnel mode 104 (see "Security Architecture for the Internet Protocol" [KA98a], 105 hereafter referred to as the Security Architecture document). 106 Security services can be provided between a pair of communicating 107 hosts, between a pair of communicating security gateways, or between 108 a security gateway and a host. For more details on how to use ESP 109 and AH in various network environments, see the Security Architecture 110 document [KA98a]. 112 The ESP header is inserted after the IP header and before the upper 113 layer protocol header (transport mode) or before an encapsulated IP 114 header (tunnel mode). These modes are described in more detail below. 116 ESP can be used to provide confidentiality, data origin 117 authentication, connectionless integrity, an anti-replay service (a 118 form of partial sequence integrity), and (limited) traffic flow 119 confidentiality. The set of services provided depends on options 120 selected at the time of Security Association (SA) establishment and 121 on the location of the implementation in a network topology. 123 An implementation MAY offer confidentiality independent of all other 124 services. Use of confidentiality without integrity (either in ESP or 125 separately in AH) may subject traffic to certain forms of active 126 attacks that could undermine the confidentiality service (see 127 [Bel96]). ESP allows confidentiality-only SAs because this may offer 128 considerably better performance and still provide adequate security, 129 e.g., when higher layer authentication/integrity protection is 130 offered independently. However, this standard does not require all 131 ESP implementations to offer this service separately. 133 Data origin authentication and connectionless integrity are joint 134 services, hereafter referred to jointly as "integrity." (This term is 135 employed because, on a per-packet basis, the computation being 136 performed provides connectionless integrity directly; data origin 137 authentication is provided indirectly as a result of binding the key 138 used to verify the integrity to the identity of the IPsec peer. 139 Typically this binding is effected through the use of a shared, 140 symmetric key, but an asymmetric cryptographic algorithm also may be 141 employed, e.g, to sign a hash.) Integrity-only ESP MUST be offered as 142 a service selection option, e.g., it must be negotiable in SA 143 management protocols and MUST be configurable via management 144 interfaces. Integrity-only ESP is an attractive alternative to AH in 145 Security Payload (ESP) 147 many contexts, e.g., because it is faster to process and more 148 amenable to pipelining in many implementations. 150 Although confidentiality and integrity can be offered independently, 151 most ESP use typically will employ both services, i.e., packets will 152 be protected with regard to confidentiality and integrity. Thus there 153 are three possible ESP security service combinations involving these 154 services: 155 - confidentiality-only (SHOULD be supported) 156 - integrity-only (MUST be supported) 157 - confidentiality and integrity (MUST be supported) 159 The anti-replay service may be selected for an SA only if the 160 integrity service is selected for that SA. The selection of this 161 service is solely at the discretion of the receiver and thus need not 162 be negotiated. However, to make use of a new, extended sequence 163 number feature in an interoperable fashion, ESP does impose a 164 requirement on SA management protocols to be able to negotiate this 165 new feature (see Section 2.2.1 below). 167 The traffic flow confidentiality (TFC) service generally is effective 168 only if ESP is employed in tunnel mode between security gateways, and 169 only if sufficient traffic flows between these gateways to conceal 170 the characteristics of specific, individual subscriber traffic flows. 171 (ESP may be employed as part of a higher layer TFC system, e.g., 172 Onion Routing [Syverson], but such systems are outside the scope of 173 this standard.) New TFC features present in ESP facilitate efficient 174 generation and discarding of dummy traffic and better padding of real 175 traffic, in a backwards compatible fashion. 177 It is assumed that the reader is familiar with the terms and concepts 178 described in the Security Architecture document. In particular, the 179 reader should be familiar with the definitions of security services 180 offered by ESP and AH, the concept of Security Associations, the ways 181 in which ESP can be used in conjunction with the Authentication 182 Header (AH), and the different key management options available for 183 ESP and AH. 185 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 186 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 187 document, are to be interpreted as described in RFC 2119 [Bra97]. 189 Security Payload (ESP) 191 2. Encapsulating Security Payload Packet Format 193 The (outer) protocol header (IPv4, IPv6, or Extension) that 194 immediately precedes the ESP header SHALL contain the value 50 in its 195 Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web 196 page at http://www.iana.org/assignments/protocol-numbers). Figure 1 197 illustrates the top level format of an ESP packet. The packet begins 198 with two 4-byte fields (SPI and Sequence Number). Following these 199 fields is the Payload Data, which has substructure that depends on 200 the choice of encryption algorithm and mode, and on the use of TFC 201 padding, which is examined in more detail later. Following the 202 Payload Data are Padding and Pad Length fields, and the Next Header 203 field. The optional Integrity Check Value (ICV) field completes the 204 packet. 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 209 | Security Parameters Index (SPI) | ^Integ. 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 211 | Sequence Number | |erage 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 213 | Payload Data* (variable) | | ^ 214 ~ ~ | | 215 | | |Conf. 216 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 217 | | Padding (0-255 bytes) | |erage* 218 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 219 | | Pad Length | Next Header | v v 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 221 | Integrity Check Value-ICV (variable) | 222 ~ ~ 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 1. Top Level Format of an ESP Packet 228 * If included in the Payload field, cryptographic synchronization 229 data, e.g., an Initialization Vector (IV, see Section 2.3), 230 usually is not encrypted per se, although it often is referred 231 to as being part of the ciphertext. 233 The (transmitted) ESP Trailer consists of the Padding, Pad Length, 234 and Next Header fields. Additional, implicit ESP Trailer data (which 235 is not transmitted) is included in the integrity computation, as 236 described below. 238 Security Payload (ESP) 240 If the integrity service is selected, the integrity computation 241 encompasses the SPI, Sequence Number, Payload Data, and the ESP 242 Trailer (explicit and implicit). 244 If the confidentiality service is selected, the ciphertext consists 245 of the Payload Data (except for any cryptographic synchronization 246 data that may be included) and the (explicit) ESP Trailer. 248 As noted above, the Payload Data may have substructure. An encryption 249 algorithm that requires an explicit Initialization Vector (IV), e.g., 250 CBC mode, often prefixes the Payload Data to be protected with that 251 value. Some algorithm modes combine encryption and integrity into a 252 single operation; this document refers to such algorithm modes as 253 "combined mode algorithms." Accommodation of combined mode algorithms 254 requires changes to ESP processing sequences and thus is not as 255 simple as adding a new encryption or integrity algorithm. 257 Some combined mode algorithms provide integrity only for data that is 258 encrypted, while others can provide integrity for some additional 259 data, data that is not encrypted for transmission. Since the SPI and 260 Sequence Number fields require integrity as part of the integrity 261 service, and they are not encrypted, it is necessary to ensure that 262 they are afforded integrity whenever the service is selected, 263 regardless of the style of combined algorithm mode employed. 265 When any combined mode algorithm is employed, the algorithm itself is 266 expected to return both decrypted plaintext and a pass/fail 267 indication for the integrity check. For combined mode algorithms, the 268 ICV that would normally appear at the end of the ESP packet (when 269 integrity is selected) is omitted. It is the responsibility of the 270 combined mode algorithm to encode within the payload data an ICV- 271 equivalent means of verifying the integrity of the packet. 273 If a combined mode algorithm offers integrity only to data that is 274 encrypted, it will be necessary to replicate the SPI and Sequence 275 Number as part of the Payload Data. 277 Finally, a new provision is made to insert padding for traffic flow 278 confidentiality after the Payload Data and before the ESP trailer. 279 Figure 2 illustrates this substructure for Payload Data. 281 Security Payload (ESP) 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Security Parameters Index (SPI) | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Sequence Number | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 290 | IV (optional] | ^ p 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a 292 | Rest of Payload Data (variable) | | y 293 ~ ~ | l 294 | | | o 295 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a 296 | | TFC Padding * (optional, variable) | v d 297 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- 298 | | Padding (0-255 bytes) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | | Pad Length | Next Header | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Integrity Check Value-ICV (variable) | 303 ~ ~ 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 2. Substructure of Payload Data 309 * If tunnel mode is being used, then the IPsec implementation 310 can add Traffic Flow Confidentiality (TFC) padding (see 311 Section 2.4) after the Payload Data and before the Padding 312 (0-255 bytes) field. 314 If a combined algorithm mode is employed, the explicit ICV shown in 315 Figures 1 and 2 is omitted (see Section ?? below). Since algorithms 316 and modes are fixed when an SA is established, the detailed format of 317 ESP packets for a given SA (including the Payload Data substructure) 318 is fixed, for all traffic on the SA. 320 The tables below refer to the fields in the preceding Figures and 321 illustrate how several categories of algorithmic options, each with a 322 different processing model, affect the fields noted above. The 323 processing details are described in later sections. 325 Security Payload (ESP) 327 Table 1. Separate Encryption and Integrity Algorithms 329 What What What 330 # of Requ'd Encrypt Integ is 331 bytes [1] Covers Covers Xmtd 332 ------ ------ ------ ------ ------ 333 SPI 4 M Y plain 334 Seq# (low order bits) 4 M Y plain p 335 ------ a 336 IV variable O Y plain | y 337 IP datagram [2] variable M or D Y Y cipher[3] |-l 338 TFC padding [4] variable O Y Y cipher[3] | o 339 ------ a 340 Padding 0-255 M Y Y cipher[3] d 341 Pad Length 1 M Y Y cipher[3] 342 Next Header 1 M Y Y cipher[3] 343 Seq# (high order bits) 4 if ESN [5] Y not xmtd 344 ICV Padding variable if need Y not xmtd 345 ICV variable M [6] plain 347 [1] M = mandatory; O = optional; D = dummy 348 [2] If tunnel mode -> IP datagram 349 If transport mode -> next header and data 350 [3] ciphertext if encryption has been selected 351 [4] Can be used only if payload specifies its "real" length 352 [5] See section 2.2.1 353 [6] mandatory if a separate integrity algorithm is used 354 Security Payload (ESP) 356 Table 2. Combined Mode Algorithms 358 What What What 359 # of Requ'd Encrypt Integ is 360 bytes [1] Covers Covers Xmtd 361 ------ ------ ------ ------ ------ 362 SPI 4 M plain 363 Seq# (low order bits) 4 M plain p 364 --- a 365 IV variable O Y plain | y 366 IP datagram [2] variable M or D Y Y cipher |-l 367 TFC padding [3] variable O Y Y cipher | o 368 --- a 369 Padding 0-255 M Y Y cipher d 370 Pad Length 1 M Y Y cipher 371 Next Header 1 M Y Y cipher 372 Seq# (high order bits) 4 if ESN [4] Y [5] 373 ICV Padding variable if need Y [5] 374 ICV omitted when this mode is employed 376 [1] M = mandatory; O = optional; D = dummy 377 [2] If tunnel mode -> IP datagram 378 If transport mode ->next header and data 379 [3] Can be used only if payload specifies its "real" length 380 [4] See section 2.2.1 381 [5] The algorithm choices determines whether these are 382 transmitted, but in either case, the result is invisible 383 to ESP 385 The following subsections describe the fields in the header format. 386 "Optional" means that the field is omitted if the option is not 387 selected, i.e., it is present in neither the packet as transmitted 388 nor as formatted for computation of an Integrity Check Value (ICV, 389 see Section 2.7). Whether or not an option is selected is determined 390 as part of Security Association (SA) establishment. Thus the format 391 of ESP packets for a given SA is fixed, for the duration of the SA. 392 In contrast, "mandatory" fields are always present in the ESP packet 393 format, for all SAs. 395 2.1 Security Parameters Index 397 The SPI is an arbitrary 32-bit value that is used by a receiver to 398 identify the SA to which an incoming packet is bound. The SPI field 399 is mandatory. 401 For a unicast SA, the SPI can be used by itself to specify an SA, or 402 it may be used in conjunction with the IPsec protocol type (in this 403 Security Payload (ESP) 405 case ESP). Since the SPI value is generated by the receiver, whether 406 the value is sufficient to identify an SA by itself, or whether it 407 must be used in conjunction with the IPsec protocol value is a local 408 matter. 410 For multicast SAs, the SPI (and optionally the protocol ID) in 411 combination with the destination address is used to select an SA. 412 This is because multicast SAs are defined by a multicast controller, 413 not by each IPsec receiver. (See the Security Architecture document 414 for more details.) 416 The set of SPI values in the range 1 through 255 are reserved by the 417 Internet Assigned Numbers Authority (IANA) for future use; a reserved 418 SPI value will not normally be assigned by IANA unless the use of the 419 assigned SPI value is specified in an RFC. The SPI value of zero (0) 420 is reserved for local, implementation-specific use and MUST NOT be 421 sent on the wire. (For example, a key management implementation might 422 use the zero SPI value to mean "No Security Association Exists" 423 during the period when the IPsec implementation has requested that 424 its key management entity establish a new SA, but the SA has not yet 425 been established.) 427 2.2 Sequence Number 429 This unsigned 32-bit field contains a counter value that increases by 430 one for each packet sent, i.e., a per-SA packet sequence number. For 431 a unicast SA or a single-sender multicast SA, the sender MUST 432 increment this field for every transmitted packet. Sharing an SA 433 among multiple senders is deprecated, since there is no general means 434 of synchronizing packet counters among the senders or meaningfully 435 managing a receiver packet counter and window in the context of 436 multiple senders. 438 The field is mandatory and MUST always be present even if the 439 receiver does not elect to enable the anti-replay service for a 440 specific SA. Processing of the Sequence Number field is at the 441 discretion of the receiver, but all ESP implementations MUST be 442 capable of performing the Sequence Number processing described in 443 Sections 3.3.3 and 3.4.3. Thus the sender MUST always transmit this 444 field, but the receiver need not act upon it (see the discussion of 445 Sequence Number Verification in the "Inbound Packet Processing" 446 section (3.4.3) below). 448 The sender's counter and the receiver's counter are initialized to 0 449 when an SA is established. (The first packet sent using a given SA 450 will have a Sequence Number of 1; see Section 3.3.3 for more details 451 Security Payload (ESP) 453 on how the Sequence Number is generated.) If anti-replay is enabled 454 (the default), the transmitted Sequence Number must never be allowed 455 to cycle. Thus, the sender's counter and the receiver's counter MUST 456 be reset (by establishing a new SA and thus a new key) prior to the 457 transmission of the 2^32nd packet on an SA. 459 2.2.1 Extended Sequence Number 461 To support high-speed IPsec implementations, a new option for 462 sequence numbers SHOULD be offered, as an extension to the current, 463 32-bit sequence number field. Use of an Extended Sequence Number 464 (ESN) SHOULD be negotiated by an SA management protocol, although it 465 could also be part of the configuration data for a manually 466 configured SA. 468 The ESN facility allows use of a 64-bit sequence number for an SA. 469 (See "Managing 64-bit Sequence Numbers" (See Appendix for details.) 470 Only the low order 32 bits of the sequence number are transmitted in 471 the plaintext ESP header of each packet, thus minimizing packet 472 overhead. The high order 32 bits are maintained as part of the 473 sequence number counter by both transmitter and receiver and are 474 included in the computation of the ICV (if the integrity service is 475 selected). If a separate integrity algorithm is employed, the high 476 order bits are included in the implicit ESP trailer, but are not 477 transmitted, analogous to integrity algorithm padding bits. If a 478 combined mode algorithm is employed, the algorithm choice determines 479 whether the high order ESN bits are transmitted, or are included 480 implicitly in the computation. See Section ?? for processing details. 482 2.3 Payload Data 484 Payload Data is a variable-length field containing data (from the 485 original IP packet) described by the Next Header field. The Payload 486 Data field is mandatory and is an integral number of bytes in length. 487 If the algorithm used to encrypt the payload requires cryptographic 488 synchronization data, e.g., an Initialization Vector (IV), then this 489 data is carried explicitly in the Payload field, but it is not called 490 out as a separate field in ESP, i.e., the transmission of an explicit 491 IV is invisible to ESP. (See Figure 2.) Any encryption algorithm 492 that requires such explicit, per-packet synchronization data MUST 493 indicate the length, any structure for such data, and the location of 494 this data as part of an RFC specifying how the algorithm is used with 495 ESP. (Typically the IV immediately precedes the ciphertext. See 496 Figure 2.) If such synchronization data is implicit, the algorithm 497 for deriving the data MUST be part of the algorithm definition RFC. 498 (If included in the Payload field, cryptographic synchronization 499 Security Payload (ESP) 501 data, e.g., an Initialization Vector (IV), usually is not encrypted 502 per se (see Tables 1 and 2), although it sometimes is referred to as 503 being part of the ciphertext.) 505 Note that the beginning of the transport header (transport mode) or 506 the beginning of the encapsulated IP datagram (tunnel mode) MUST be 507 aligned relative to the beginning of the ESP header as follows. For 508 IPv4, this alignment is a multiple of 4 bytes. For IPv6, the 509 alignment is a multiple of 8 bytes. 511 With regard to ensuring the alignment of the (real) ciphertext in the 512 presence of an IV, note the following: 513 o For some IV-based modes of operation, the receiver treats 514 the IV as the start of the ciphertext, feeding it into the 515 algorithm directly. In these modes, alignment of the start 516 of the (real) ciphertext is not an issue at the receiver. 518 o In some cases, the receiver reads the IV in separately from 519 the ciphertext. In these cases, the algorithm specification 520 MUST address how alignment of the (real) ciphertext is to be 521 achieved. 523 2.4 Padding (for Encryption) 525 Three factors require or motivate use of the Padding field. 526 o If an encryption algorithm is employed that requires the 527 plaintext to be a multiple of some number of bytes, e.g., 528 the block size of a block cipher, the Padding field is used 529 to fill the plaintext (consisting of the Payload Data, 530 Padding, Pad Length and Next Header fields) to the size 531 required by the algorithm. 533 o Padding also may be required, irrespective of encryption 534 algorithm requirements, to ensure that the resulting 535 ciphertext terminates on a 4-byte boundary. Specifically, 536 the Pad Length and Next Header fields must be right aligned 537 within a 4-byte word, as illustrated in the ESP packet 538 format figures above, to ensure that the ICV field (if 539 present) is aligned on a 4-byte boundary. 541 o Padding beyond that required for the algorithm or alignment 542 reasons cited above, may be used to conceal the actual 543 length of the payload, in support of TFC. The padding field 544 described here offers limited opportunity for concealing the 545 length of the plaintext and thus a new, separate mechanism 546 is described below for use when TFC is required (see Section 547 2.7). 549 Security Payload (ESP) 551 The sender MAY add 0 to 255 bytes of padding. Inclusion of the 552 Padding field in an ESP packet is optional, subject to the 553 requirements noted above, but all implementations MUST support 554 generation and consumption of padding. 556 o For the purpose of ensuring that the bits to be encrypted 557 are a multiple of the algorithm's blocksize (first bullet 558 above), the padding computation applies to the Payload Data 559 exclusive of any IV, but including the ESP trailer 560 fields. If a combined algorithm mode requires transmission 561 of the SPI and Sequence Number to effect integrity, then 562 these data items, and any associated, ICV-equivalent data, 563 are included in the computation of the pad length. (If the 564 ESN option is selected, the high order 32 bits of the ESN 565 also would enter into the computation, if the combined mode 566 algorithm requires their transmission for integrity.) 568 o For the purposes of ensuring that the ICV is aligned on a 569 4-byte boundary (second bullet above), the padding 570 computation applies to the Payload Data inclusive of the IV, 571 the Pad Length, and Next Header fields. If a combined mode 572 algorithm is used, any replicated data and ICV-equivalent 573 data are included in the Payload Data covered by the padding 574 computation. 576 If an encryption or combined mode algorithm imposes constraints on 577 the values of the bytes used for padding they MUST be specified by 578 the RFC defining how the algorithm is employed with ESP. If the 579 algorithm requires checking of the values of the bytes used for 580 padding, this too MUST be specified in that RFC. 582 2.5 Pad Length 584 The Pad Length field indicates the number of pad bytes immediately 585 preceding it in the Padding field. The range of valid values is 0 to 586 255, where a value of zero indicates that no Padding bytes are 587 present. As noted above, this does not include any TFC padding bytes. 588 The Pad Length field is mandatory. 590 2.6 Next Header 592 The Next Header is a mandatory, 8-bit field that identifies the type 593 of data contained in the Payload Data field, e.g., an IPv4 or IPv6 594 packet, or an upper layer header and data. The value of this field 595 is chosen from the set of IP Protocol Numbers defined on the web page 596 of the IANA, e.g., a value of 4 indicates IPv4, a value of 41 597 Security Payload (ESP) 599 indicates IPv6 and a value of 6 indicates TCP. 601 To facilitate the rapid generation and discarding of the padding 602 traffic in support of traffic flow confidentiality (see 2.4), the 603 protocol value 59 (which means "no next header") MUST be used to 604 designate a "dummy" packet. A transmitter MUST be capable of 605 generating dummy packets marked with this value in the next protocol 606 field, and a receiver MUST be prepared to discard such packets, 607 without indicating an error. All other ESP header and trailer fields 608 (SPI, Sequence number, Padding, Pad Length, Next Header, and ICV) 609 MUST be present in dummy packets, but the plaintext portion of the 610 payload, other than this Next Header field, need not be well-formed, 611 e.g., the rest of the Payload Data may consist of only random bytes. 612 Dummy packets are discarded without prejudice. 614 2.7 Traffic Flow Confidentiality (TFC) Padding 616 As noted above, the Padding field is limited to 255 bytes in length. 617 This generally will not be adequate to hide traffic characteristics 618 relative to traffic flow confidentiality requirements. A new field, 619 within the payload data, has been added specifically to address the 620 TFC requirement. 622 An IPsec implementation SHOULD be capable of padding traffic by 623 adding bytes after the end of the Payload Data, prior to the 624 beginning of the Padding field. However, this padding (hereafter 625 referred to as TFC padding) can be added only if the "Payload Data" 626 field contains a specification of the length of the IP datagram, 627 e.g., if tunnel mode is employed. This information will enable the 628 receiver to discard the TFC padding, because the true length of the 629 Payload Data will be known. (ESP trailer fields are located by 630 counting back from the end of the ESP packet.) Accordingly, if TFC 631 padding is added, the field containing the specification of the 632 length of the IP datagram MUST NOT be modified to reflect this 633 padding. No requirements for the value of this padding are 634 established by this standard. 636 TFC padding takes advantage of an intrinsic feature of IP, i.e., 637 other data may be present in a buffer delivered to an IP interface, 638 beyond the packet length indicated by the IP total length field. 639 Thus, in tunnel mode, a compliant IP stack at a receiver should 640 ignore this padding. In this sense, existing IPsec implementations 641 could have made use of this capability previously, in a transparent 642 fashion. However, because receivers may not have been prepared to 643 deal with this padding, the SA management protocol MUST negotiate 644 this service prior to a transmitter employing it, to ensure backward 645 compatibility. Combined with the convention described in section 2.6 646 Security Payload (ESP) 648 above, about the use of protocol ID 59, an ESP implementation is 649 capable of generating dummy and real packets that exhibit much 650 greater length variability, in support of TFC. 652 In transport mode, this facility generally will not be available, 653 consistent with the earlier admonition that effective TFC service in 654 IPsec generally requires use of tunnel mode between security 655 gateways. 657 2.8 Integrity Check Value (ICV) 659 The Integrity Check Value is a variable-length field computed over 660 the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer 661 fields (integrity padding and high order ESN bits, if applicable) are 662 included in the ICV computation. The ICV field is optional; it is 663 present only if the integrity service is selected and a separate (not 664 combined mode) integrity algorithm is employed. The length of the 665 field is specified by the integrity algorithm selected and associated 666 with the SA. The integrity algorithm specification MUST specify the 667 length of the ICV and the comparison rules and processing steps for 668 validation. 670 3. Encapsulating Security Protocol Processing 672 3.1 ESP Header Location 674 ESP may be employed in two ways: transport mode or tunnel mode. The 675 former mode is applicable to host implementations and provides 676 protection for upper layer protocols, but not the IP header. (In this 677 mode, note that for "bump-in- the-stack" or "bump-in-the-wire" 678 implementations, as defined in the Security Architecture document, 679 inbound and outbound IP fragments may require an IPsec implementation 680 to perform extra IP reassembly/fragmentation in order to both conform 681 to this specification and provide transparent IPsec support. Special 682 care is required to perform such operations within these 683 implementations when multiple interfaces are in use.) 685 3.1.1 Transport Mode Processing 687 In transport mode, ESP is inserted after the IP header and before an 688 upper layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of 689 IPv4, this translates to placing ESP after the IP header (and any 690 options that it contains), but before the upper layer protocol. (If 691 AH is also applied to a packet, it is applied to the ESP header, 692 Payload, ESP Trailer and ICV, if present.) (Note that the term 693 "transport" mode should not be misconstrued as restricting its use to 694 Security Payload (ESP) 696 TCP and UDP. For example, an ICMP message MAY be sent using either 697 "transport" mode or "tunnel" mode.) The following diagram 698 illustrates ESP transport mode positioning for a typical IPv4 packet, 699 on a "before and after" basis. (This and subsequent diagrams in this 700 section show the ICV field, the presence of which is a function of 701 the security services and the algorithm/mode selected.) 703 BEFORE APPLYING ESP 704 ---------------------------- 705 IPv4 |orig IP hdr | | | 706 |(any options)| TCP | Data | 707 ---------------------------- 709 AFTER APPLYING ESP 710 ------------------------------------------------- 711 IPv4 |orig IP hdr | ESP | | | ESP | ESP| 712 |(any options)| Hdr | TCP | Data | Trailer | ICV| 713 ------------------------------------------------- 714 |<---- encryption ---->| 715 |<-------- integrity ------->| 717 In the IPv6 context, ESP is viewed as an end-to-end payload, and thus 718 should appear after hop-by-hop, routing, and fragmentation extension 719 headers. Destination options extension header(s) could appear 720 before, after, or both before and after the ESP header depending on 721 the semantics desired. However, since ESP protects only fields after 722 the ESP header, it generally will be desirable to place the 723 destination options header(s) after the ESP header. The following 724 diagram illustrates ESP transport mode positioning for a typical IPv6 725 packet. 727 BEFORE APPLYING ESP 728 --------------------------------------- 729 IPv6 | | ext hdrs | | | 730 | orig IP hdr |if present| TCP | Data | 731 --------------------------------------- 733 AFTER APPLYING ESP 734 --------------------------------------------------------- 735 IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| 736 |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 737 --------------------------------------------------------- 738 |<--- encryption ---->| 739 |<------ integrity ------>| 741 * = if present, could be before ESP, after ESP, or both 742 Security Payload (ESP) 744 3.1.2 Tunnel Mode Processing 746 Tunnel mode ESP may be employed in either hosts or security gateways. 747 When ESP is implemented in a security gateway to protect subscriber 748 transit traffic, tunnel mode MUST be used. (Transport mode MAY be 749 used to protect management or similar traffic terminating at a 750 security gateway.) In tunnel mode, the "inner" IP header carries the 751 ultimate source and destination addresses, while an "outer" IP header 752 contains the addresses of the IPsec peers. In tunnel mode, ESP 753 protects the entire inner IP packet, including the entire inner IP 754 header. The position of ESP in tunnel mode, relative to the outer IP 755 header, is the same as for ESP in transport mode. The following 756 diagram illustrates ESP tunnel mode positioning for typical IPv4 and 757 IPv6 packets. 759 Security Payload (ESP) 761 BEFORE APPLYING ESP 762 ---------------------------- 763 IPv4 |orig IP hdr | | | 764 |(any options)| TCP | Data | 765 ---------------------------- 767 AFTER APPLYING ESP 769 ----------------------------------------------------------- 770 IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| 771 |(any options)| ESP | (any options) |TCP|Data|Trailer| ICV| 772 ----------------------------------------------------------- 773 |<--------- encryption --------->| 774 |<------------- integrity ------------>| 776 BEFORE APPLYING ESP 777 --------------------------------------- 778 IPv6 | | ext hdrs | | | 779 | orig IP hdr |if present| TCP | Data | 780 --------------------------------------- 782 AFTER APPLYING ESP 784 ------------------------------------------------------------ 785 IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| 786 |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| 787 ------------------------------------------------------------ 788 |<--------- encryption ---------->| 789 |<------------ integrity ------------>| 791 * = if present, construction of outer IP hdr/extensions and 792 modification of inner IP hdr/extensions is discussed in 793 the Security Architecture document. 795 3.2 Algorithms 797 The mandatory-to-implement algorithms are described in Section 5, 798 "Conformance Requirements." Other algorithms MAY be supported. Note 799 that although both confidentiality and integrity are optional, at 800 least one of these services MUST be selected hence both algorithms 801 MUST NOT be simultaneously NULL. 803 3.2.1 Encryption Algorithms 805 The (symmetric) encryption algorithm employed to protect an ESP 806 packet is specified by the SA via which the packet is 807 Security Payload (ESP) 809 transmitted/received. Because IP packets may arrive out of order, and 810 not all packets may arrive (packet loss) each packet must carry any 811 data required to allow the receiver to establish cryptographic 812 synchronization for decryption. This data may be carried explicitly 813 in the payload field, e.g., as an IV (as described above), or the 814 data may be derived from the plaintext portions of the (outer IP or 815 ESP) packet header. (Note that if plaintext header information is 816 used to derive an IV, that information may become security critical 817 and thus the protection boundary associated with the encryption 818 process may grow. For example, if one were to use the ESP Sequence 819 Number to derive an IV, the Sequence Number generation logic 820 (hardware or software) would have to be evaluated as part of the 821 encryption algorithm implementation. In the case of FIPS 140-x, this 822 could significantly extend the scope of a cryptographic module 823 evaluation.) Since ESP makes provision for padding of the plaintext, 824 encryption algorithms employed with ESP may exhibit either block or 825 stream mode characteristics. Note that since encryption 826 (confidentiality) is an optional service (e.g., integrity-only ESP), 827 this algorithm may be "NULL" [KA98a] 829 To allow an ESP implementation to compute the encryption padding 830 required by a block mode encryption algorithm, and to determine the 831 MTU impact of the algorithm, the RFC for each encryption algorithm 832 used with ESP must specify the padding modulus for the algorithm. 834 3.2.2 Integrity Algorithms 836 The integrity algorithm employed for the ICV computation is specified 837 by the SA via which the packet is transmitted/received. As was the 838 case for encryption algorithms, any integrity algorithm employed with 839 ESP must make provisions to permit processing of packets that arrive 840 out of order and to accommodate packet loss. The same admonition 841 noted above applies to use of any plaintext data to facilitate 842 receiver synchronization of integrity algorithms. Note that since the 843 integrity service MAY be optional, this algorithm may be "NULL". 845 To allow an ESP implementation to compute any implicit integrity 846 algorithm padding required, the RFC for each algorithm used with ESP 847 must specify the padding modulus for the algorithm. 849 3.2.3 Combined Mode Algorithms 851 If a combined mode algorithm is employed, both confidentiality and 852 integrity services are provided. As was the case for encryption 853 algorithms, a combined mode algorithm must make provisions for per- 854 packet cryptographic synchronization, to permit decryption of packets 855 that arrive out of order and to accommodate packet loss. The means by 856 Security Payload (ESP) 858 which a combined mode algorithm provides integrity for the payload, 859 and for the SPI and (Extended) Sequence Number fields, may vary for 860 different algorithm choices. In order to provide a uniform, algorithm 861 independent approach to invocation of combined mode algorithms, no 862 payload substructure is defined. For example, the SPI and Sequence 863 Number fields might be replicated within the ciphertext envelope and 864 an ICV may be appended to the ESP Trailer. None of these details 865 should be observable externally. 867 To allow an ESP implementation to determine the MTU impact of a 868 combined mode algorithm, the RFC for each algorithm used with ESP 869 must specify a (simple) formula that yields encrypted payload size, 870 as a function of the plaintext payload and sequence number sizes. 872 3.3 Outbound Packet Processing 874 In transport mode, the sender encapsulates the upper layer protocol 875 information between the ESP header and the ESP trailer fields, and 876 retains the specified IP header (and any IP extension headers in the 877 IPv6 context). In tunnel mode, the outer and inner IP 878 header/extensions can be inter-related in a variety of ways. The 879 construction of the outer IP header/extensions during the 880 encapsulation process is described in the Security Architecture 881 document. If more than one IPsec header/extension is required by 882 security policy, the order of the application of the security headers 883 MUST be defined by security policy. 885 3.3.1 Security Association Lookup 887 ESP is applied to an outbound packet only after an IPsec 888 implementation determines that the packet is associated with an SA 889 that calls for ESP processing. The process of determining what, if 890 any, IPsec processing is applied to outbound traffic is described in 891 the Security Architecture document. 893 3.3.2 Packet Encryption and Integrity Check Value (ICV) Calculation 895 In this section, we speak in terms of encryption always being applied 896 because of the formatting implications. This is done with the 897 understanding that "no confidentiality" is offered by using the NULL 898 encryption algorithm (RFC 2410). There are several algorithmic 899 options. 901 Security Payload (ESP) 903 3.3.2.1 Separate Confidentiality and Integrity Algorithms 905 If separate confidentiality and integrity algorithms are employed, 906 the sender: 907 1. encapsulates (into the ESP Payload field): 908 - for transport mode -- just the original upper layer 909 protocol information. 910 - for tunnel mode -- the entire original IP datagram. 912 2. adds any necessary padding � Optional TFC padding and 913 (encryption) Padding 915 3. encrypts the result using the key, encryption algorithm, 916 and algorithm mode specified for the SA and using any 917 required cryptographic synchronization data. 918 - If explicit cryptographic synchronization data, 919 e.g., an IV, is indicated, it is input to the 920 encryption algorithm per the algorithm specification 921 and placed in the Payload field. 922 - If implicit cryptographic synchronization data is 923 employed, it is constructed and input to the 924 encryption algorithm as per the algorithm 925 specification. 926 - If integrity is selected, encryption is performed 927 first, before the integrity algorithm is applied, 928 and the encryption does not encompass the ICV 929 field. This order of processing facilitates rapid 930 detection and rejection of replayed or bogus packets 931 by the receiver, prior to decrypting the packet, 932 hence potentially reducing the impact of denial of 933 service attacks. It also allows for the possibility 934 of parallel processing of packets at the receiver, 935 i.e., decryption can take place in parallel with 936 integrity checking. Note that since the ICV is not 937 protected by encryption, a keyed integrity algorithm 938 must be employed to compute the ICV. 940 4. computes the ICV over the ESP packet minus the ICV field. 941 Thus the ICV computation encompasses the SPI, Sequence 942 Number, Payload Data, Padding (if present), Pad Length, and 943 Next Header. (Note that the last 4 fields will be in 944 ciphertext form, since encryption is performed first.) If 945 the ESN option is enabled for the SA, it the high-order 32 946 bits of the Sequence Number are appended after the Next 947 Header field for purposes of this computation, but are not 948 transmitted. 950 Security Payload (ESP) 952 For some integrity algorithms, the byte string over which the ICV 953 computation is performed must be a multiple of a block size specified 954 by the algorithm. If the length of ESP packet (as described above) 955 does not match the block size requirements for the algorithm, 956 implicit padding MUST be appended to the end of the ESP packet. (This 957 padding is added after the Next Header field, or after the high-order 958 32 bits of the Sequence Number, if ESN is selected.) The padding 959 octets MUST have a value of zero. The block size (and hence the 960 length of the padding) is specified by the integrity algorithm 961 specification. This padding is not transmitted with the packet. Note 962 that MD5 and SHA-1 are viewed as having a 1-byte block size because 963 of their internal padding conventions. 965 3.3.2.2 Combined Confidentiality and Integrity Algorithms 967 If a combined confidentiality/integrity algorithm is employed, the 968 sender: 970 1. encapsulates into the ESP Payload Data field: 971 - for transport mode -- just the original upper layer 972 protocol information. 973 - for tunnel mode -- the entire original IP datagram. 975 2. adds any necessary padding�includes optional TFC padding 976 and Padding. 978 3. encrypts and integrity protects the result using the key 979 and combined mode algorithm specified for the SA and using 980 any required cryptographic synchronization data. 981 - If explicit cryptographic synchronization data, 982 e.g., an IV, is indicated, it is input to the 983 combined mode algorithm per the algorithm 984 specification and placed in the Payload field. 985 - If implicit cryptographic synchronization data is 986 employed, it is constructed and input to the 987 encryption algorithm as per the algorithm 988 specification. 989 - The Sequence Number (or Extended Sequence Number, as 990 appropriate) and the SPI are inputs to the 991 algorithm, as they must be included in the integrity 992 check computation. The means by which these values 993 are included in this computation are a function of 994 the combined mode algorithm employed and thus not 995 specified in this standard. 996 - The (explicit) ICV field is NOT part of the ESP packet 997 format when a combined mode algorithm is employed, 998 although an analogous field usually will a part of 999 Security Payload (ESP) 1001 the ciphertext payload. The location of any 1002 integrity fields, and the means by which the 1003 Sequence Number and SPI are included in the 1004 integrity computation MUST be defined in an RFC that 1005 defines the use of the combined mode algorithm with 1006 ESP. 1008 3.3.3 Sequence Number Generation 1010 The sender's counter is initialized to 0 when an SA is established. 1011 The sender increments the Sequence Number (or ESN) for this SA and 1012 inserts the low-order 32 bits of the value into the Sequence Number 1013 field. Thus the first packet sent using a given SA will contain a 1014 Sequence Number of 1. 1016 If anti-replay is enabled (the default), the sender checks to ensure 1017 that the counter has not cycled before inserting the new value in the 1018 Sequence Number field. In other words, the sender MUST NOT send a 1019 packet on an SA if doing so would cause the Sequence Number to cycle. 1020 An attempt to transmit a packet that would result in Sequence Number 1021 overflow is an auditable event. The audit log entry for this event 1022 SHOULD include the SPI value, current date/time, Source Address, 1023 Destination Address, and (in IPv6) the cleartext Flow ID. 1025 The sender assumes anti-replay is enabled as a default, unless 1026 otherwise notified by the receiver (see 3.4.3) or if the SA was 1027 configured using manual key management. Thus typical behavior of an 1028 ESP implementation calls for the sender to establish a new SA when 1029 the Sequence Number (or ESN) cycles, or in anticipation of this value 1030 cycling. 1032 If anti-replay is disabled (as noted above), the sender does not need 1033 to monitor or reset the counter, e.g., in the case of manual key 1034 management (see Section 5). However, the sender still increments the 1035 counter and when it reaches the maximum value, the counter rolls over 1036 back to zero. 1038 If ESN (see Appendix) is selected, only the low order 32 bits of the 1039 sequence number are transmitted in the Sequence Number field, 1040 although both sender and receiver maintain full 64-bit ESN counters. 1041 The high order 32 bits are included in the integrity check in an 1042 algorithm/mode-specific fashion, e.g., the high order 32 bits may be 1043 appended after the Next Header field when a separate integrity 1044 algorithm is employed. 1046 Security Payload (ESP) 1048 3.3.4 Fragmentation 1050 If necessary, fragmentation is performed after ESP processing within 1051 an IPsec implementation. Thus, transport mode ESP is applied only to 1052 whole IP datagrams (not to IP fragments). An IP packet to which ESP 1053 has been applied may itself be fragmented by routers en route, and 1054 such fragments must be reassembled prior to ESP processing at a 1055 receiver. In tunnel mode, ESP is applied to an IP packet, which may 1056 be a fragment of an IP datagram. For example, a security gateway or 1057 a "bump-in-the-stack" or "bump-in-the-wire" IPsec implementation (as 1058 defined in the Security Architecture document) may apply tunnel mode 1059 ESP to such fragments. 1061 NOTE: For transport mode -- As mentioned at the beginning of Section 1062 3.1, bump- in-the-stack and bump-in-the-wire implementations may have 1063 to first reassemble a packet fragmented by the local IP layer, then 1064 apply IPsec, and then fragment the resulting packet. 1066 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 1067 implementations, it will be necessary to examine all the extension 1068 headers to determine if there is a fragmentation header and hence 1069 that the packet needs reassembling prior to IPsec processing. 1071 Fragmentation, whether performed by an IPsec implementation or by 1072 routers along the path between IPsec peers, significantly reduces 1073 performance. Moreover, the requirement for an ESP receiver to accept 1074 fragments for reassembly creates denial of service vulnerabilities. 1075 Thus an ESP implementation MAY choose to not support fragmentation 1076 and may mark transmitted packets with the DF bit, to facilitate PMTU 1077 discovery. In any case, an ESP implementation MUST support generation 1078 of ICMP PMTU messages (or equivalent internal signaling for native 1079 host implementations) to minimize the likelihood of fragmentation. 1080 Details of the support required for MTU management are contained in 1081 the Security Architecture document. 1083 3.4 Inbound Packet Processing 1085 3.4.1 Reassembly 1087 If required, reassembly is performed prior to ESP processing. If a 1088 packet offered to ESP for processing appears to be an IP fragment, 1089 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 1090 the receiver MUST discard the packet; this is an auditable event. The 1091 audit log entry for this event SHOULD include the SPI value, 1092 date/time received, Source Address, Destination Address, Sequence 1093 Number, and (in IPv6) the Flow ID. 1095 Security Payload (ESP) 1097 NOTE: For packet reassembly, the current IPv4 spec does NOT require 1098 either the zeroing of the OFFSET field or the clearing of the MORE 1099 FRAGMENTS flag. In order for a reassembled packet to be processed by 1100 IPsec (as opposed to discarded as an apparent fragment), the IP code 1101 must do these two things after it reassembles a packet. 1103 3.4.2 Security Association Lookup 1105 Upon receipt of a packet containing an ESP Header, the receiver 1106 determines the appropriate (unidirectional) SA, based on the SPI 1107 alone (unicast) or SPI combined with destination IP address 1108 (multicast). (This process is described in more detail in the 1109 Security Architecture document.) The SA indicates whether the 1110 Sequence Number field will be checked and whether 32 or 64-bit 1111 Sequence Numbers are employed for the SA, whether the (explicit) ICV 1112 field should be present (and if so, its size), and it will specify 1113 the algorithms and keys to be employed for decryption and ICV 1114 computations (if applicable). 1116 If no valid Security Association exists for this session (for 1117 example, the receiver has no key), the receiver MUST discard the 1118 packet; this is an auditable event. The audit log entry for this 1119 event SHOULD include the SPI value, date/time received, Source 1120 Address, Destination Address, Sequence Number, and (in IPv6) the 1121 cleartext Flow ID. 1123 Note that SA management traffic does not need to be processed based 1124 on SPI, i.e., one can demultiplex this traffic separately, e.g., 1125 based on Next Protocol and Port fields. 1127 3.4.3 Sequence Number Verification 1129 All ESP implementations MUST support the anti-replay service, though 1130 its use may be enabled or disabled by the receiver on a per-SA basis. 1131 This service MUST NOT be enabled unless the ESP integrity service 1132 also is enabled for the SA, since otherwise the Sequence Number field 1133 has not been integrity protected. (Note that there are no provisions 1134 for managing transmitted Sequence Number values among multiple 1135 senders directing traffic to a single SA, irrespective of whether the 1136 destination address is unicast, broadcast, or multicast. Thus the 1137 anti-replay service SHOULD NOT be used in a multi-sender environment 1138 that employs a single SA.) 1140 If the receiver does not enable anti-replay for an SA, no inbound 1141 checks are performed on the Sequence Number. However, from the 1142 perspective of the sender, the default is to assume that anti-replay 1143 is enabled at the receiver. To avoid having the sender do unnecessary 1144 Security Payload (ESP) 1146 sequence number monitoring and SA setup (see section 3.3.3), if an SA 1147 establishment protocol is employed, the receiver SHOULD notify the 1148 sender, during SA establishment, if the receiver will not provide 1149 anti-replay protection. 1151 If the receiver has enabled the anti-replay service for this SA, the 1152 receive packet counter for the SA MUST be initialized to zero when 1153 the SA is established. For each received packet, the receiver MUST 1154 verify that the packet contains a Sequence Number that does not 1155 duplicate the Sequence Number of any other packets received during 1156 the life of this SA. This SHOULD be the first ESP check applied to a 1157 packet after it has been matched to an SA, to speed rejection of 1158 duplicate packets. 1160 ESP permits two-stage verification of packet sequence numbers. This 1161 capability is important whenever an ESP implementation (typically the 1162 cryptographic module portion thereof) is not capable of performing 1163 decryption and/or integrity checking at the same rate as the 1164 interface(s) to unprotected networks. If the implementation is 1165 capable of such "line rate" operation, then it is not necessary to 1166 perform the preliminary verification stage described below. 1168 The preliminary Sequence Number check is effected utilizing the 1169 Sequence Number value in the ESP Header and is performed prior to 1170 integrity checking and decryption. If this preliminary check fails, 1171 the packet is discarded, thus avoiding the need for any cryptographic 1172 operations by the receiver. If the preliminary check is successful, 1173 the receiver cannot yet modify it's local counter, since the 1174 integrity of the Sequence Number has not been verified at this point. 1176 Duplicates are rejected through the use of a sliding receive window. 1177 How the window is implemented is a local matter, but the following 1178 text describes the functionality that the implementation must 1179 exhibit. 1181 The "right" edge of the window represents the highest, validated 1182 Sequence Number value received on this SA. Packets that contain 1183 Sequence Numbers lower than the "left" edge of the window are 1184 rejected. Packets falling within the window are checked against a 1185 list of received packets within the window. If the ESN option is 1186 selected for an SA, only the low-order 32 bits of the sequence number 1187 are explicitly transmitted, but the receiver employs the full 1188 sequence number computed using the high-order 32 bits for the 1189 indicated SA (from his local counter) when checking the received 1190 Sequence Number against the receive window. In constructing the full 1191 sequence number, if the low order 32 bits carried in the packet are 1192 lower in value than the low order 32 bits of the receiver's sequence 1193 Security Payload (ESP) 1195 number, the receiver assumes that the high order 32 bits have been 1196 incremented, moving to a new sequence number subspace. (This 1197 algorithm accommodates gaps in reception for a single SA as large as 1198 2**32-1 packets. If a larger gap occurs, additional, heuristic checks 1199 for resynchronization of the receiver sequence number counter MAY be 1200 employed, as described in the Appendix.) 1202 If the received packet falls within the window and is not a 1203 duplicate, or if the packet is to the right of the window, and if a 1204 separate integrity algorithm is employed, then the receiver proceeds 1205 to integrity verification. If a combined mode algorithm is employed, 1206 the integrity check is performed along with decryption. In either 1207 case, if the integrity check fails, the receiver MUST discard the 1208 received IP datagram as invalid; this is an auditable event. The 1209 audit log entry for this event SHOULD include the SPI value, 1210 date/time received, Source Address, Destination Address, the Sequence 1211 Number, and (in IPv6) the Flow ID. The receive window is updated 1212 only if the integrity verification succeeds. (If a combined mode 1213 algorithm is being used, then the integrity protected Sequence Number 1214 must also match the Sequence Number used for anti-replay protection.) 1216 A minimum window size of 32 packets MUST be supported when 32-bit 1217 sequence numbers are employed; a window size of 64 is preferred and 1218 SHOULD be employed as the default. Another window size (larger than 1219 the minimum) MAY be chosen by the receiver. (The receiver does NOT 1220 notify the sender of the window size.) The receive window size 1221 should be increased for higher speed environments, irrespective of 1222 assurance issues. Values for minimum and recommended receive window 1223 sizes for very high speed (e.g., multi-gigabit/second) devices are 1224 not specified by this standard. 1226 3.4.4 Integrity Check Value Verification 1228 As with outbound processing, there are several options for inbound 1229 processing, based on features of the algorithms employed. 1231 3.4.4.1 Separate Confidentiality and Integrity Algorithms 1233 If separate confidentiality and integrity algorithms are employed, 1234 1. if integrity has been selected, the receiver computes the 1235 ICV over the ESP packet minus the ICV, using the specified 1236 integrity algorithm and verifies that it is the same as the 1237 ICV carried in the packet. Details of the computation are 1238 provided below. 1240 If the computed and received ICV's match, then the datagram 1241 is valid, and it is accepted. If the test fails, then the 1242 Security Payload (ESP) 1244 receiver MUST discard the received IP datagram as invalid; 1245 this is an auditable event. The log data SHOULD include 1246 the SPI value, date/time received, Source Address, 1247 Destination Address, the Sequence Number, and (for IPv6) 1248 the cleartext Flow ID. 1250 DISCUSSION: 1252 Begin by removing and saving the ICV field. Next check the 1253 overall length of the ESP packet minus the ICV field. If 1254 implicit padding is required, based on the blocksize of the 1255 integrity algorithm, append zero-filled bytes to the end of 1256 the ESP packet directly after the Next Header 1257 field. Perform the ICV computation and compare the result 1258 with the saved value, using the comparison rules defined by 1259 the algorithm specification. 1261 2. the receiver decrypts the ESP Payload Data, Padding, Pad 1262 Length, and Next Header using the key, encryption 1263 algorithm, algorithm mode, and cryptographic 1264 synchronization data (if any), indicated by the SA. As in 1265 section 3.3.2, we speak here in terms of encryption always 1266 being applied because of the formatting implications. This 1267 is done with the understanding that "no confidentiality" is 1268 offered by using the NULL encryption algorithm (RFC 2410). 1270 - If explicit cryptographic synchronization data, 1271 e.g., an IV, is indicated, it is taken from the 1272 Payload field and input to the decryption algorithm 1273 as per the algorithm specification. 1275 - If implicit cryptographic synchronization data is 1276 indicated, a local version of the IV is constructed 1277 and input to the decryption algorithm as per the 1278 algorithm specification. 1280 3. the receiver processes any Padding as specified in the 1281 encryption algorithm specification. If the default padding 1282 scheme (see Section 2.4) has been employed, the receiver 1283 SHOULD inspect the Padding field before removing the 1284 padding prior to passing the decrypted data to the next 1285 layer. 1287 4. the receiver checks the Next Header field. If the value is 1288 "59" (no next header), the (dummy) packet is discarded 1289 without further processing. 1291 Security Payload (ESP) 1293 5. the receiver reconstructs the original IP datagram from: 1294 - for transport mode -- original IP header plus the 1295 original upper layer protocol information in the ESP 1296 Payload field 1297 - for tunnel mode -- tunnel IP header + the entire IP 1298 datagram in the ESP Payload field. 1300 The exact steps for reconstructing the original datagram 1301 depend on the mode (transport or tunnel) and are described 1302 in the Security Architecture document. At a minimum, in an 1303 IPv6 context, the receiver SHOULD ensure that the decrypted 1304 data is 8-byte aligned, to facilitate processing by the 1305 protocol identified in the Next Header field. This 1306 processing "discards" any (optional) TFC padding that has 1307 been added for traffic flow confidentiality. (If present, 1308 this will have been inserted after the IP datagram (or 1309 transport-layer frame) and before the Padding field (see 1310 section 2.4).) 1312 If integrity checking and encryption are performed in parallel, 1313 integrity checking MUST be completed before the decrypted packet is 1314 passed on for further processing. This order of processing 1315 facilitates rapid detection and rejection of replayed or bogus 1316 packets by the receiver, prior to decrypting the packet, hence 1317 potentially reducing the impact of denial of service attacks. 1319 Note: If the receiver performs decryption in parallel with integrity 1320 checking, care must be taken to avoid possible race conditions with 1321 regard to packet access and extraction of the decrypted packet. 1323 3.4.4.2 Combined Mode Algorithms 1325 If a combined confidentiality and integrity algorithm is employed, 1326 then the receiver: 1328 1. decrypts and integrity checks the ESP Payload Data, 1329 Padding, Pad Length, and Next Header, using the key, 1330 algorithm, algorithm mode, and cryptographic 1331 synchronization data (if any), indicated by the SA. The SPI 1332 from the ESP header, and the (receiver) packet counter 1333 value (adjusted as required from the processing described 1334 in Section 3.4.3) are inputs to this algorithm, as they are 1335 required for the integrity check. 1337 - If explicit cryptographic synchronization data, 1338 e.g., an IV, is indicated, it is taken from the 1339 Security Payload (ESP) 1341 Payload field and input to the decryption algorithm 1342 as per the algorithm specification. 1344 - If implicit cryptographic synchronization data, 1345 e.g., an IV, is indicated, a local version of the IV 1346 is constructed and input to the decryption algorithm 1347 as per the algorithm specification. 1349 2. if the integrity check performed by the combined mode 1350 algorithm fails, the receiver MUST discard the received IP 1351 datagram as invalid; this is an auditable event. The log 1352 data SHOULD include the SPI value, date/time received, 1353 Source Address, Destination Address, the Sequence Number, 1354 and (in IPv6) the cleartext Flow ID. 1356 3. processes any Padding as specified in the encryption 1357 algorithm specification, if the algorithm has not already 1358 done so. 1360 4. the receiver checks the Next Header field. If the value is 1361 "59" (no next header), the (dummy) packet is discarded 1362 without further processing. 1364 5. extracts the original IP datagram (tunnel mode) or 1365 transport-layer frame (transport mode) from the ESP Payload 1366 Data field. This implicitly discards any (optional) 1367 padding that has been added for traffic flow 1368 confidentiality. (If present, the TFC padding will have 1369 been inserted after the IP payload and before the Padding 1370 field (see section 2.4).) 1372 4. Auditing 1374 Not all systems that implement ESP will implement auditing. However, 1375 if ESP is incorporated into a system that supports auditing, then the 1376 ESP implementation MUST also support auditing and MUST allow a system 1377 administrator to enable or disable auditing for ESP. For the most 1378 part, the granularity of auditing is a local matter. However, 1379 several auditable events are identified in this specification and for 1380 each of these events a minimum set of information that SHOULD be 1381 included in an audit log is defined. 1383 - No valid Security Association exists for a session. The 1384 audit log entry for this event SHOULD include the SPI value, 1385 date/time received, Source Address, Destination Address, 1386 Sequence Number, and (for IPv6) the cleartext Flow ID. 1388 Security Payload (ESP) 1390 - A packet offered to ESP for processing appears to be an IP 1391 fragment, i.e., the OFFSET field is non-zero or the MORE 1392 FRAGMENTS flag is set. The audit log entry for this event 1393 SHOULD include the SPI value, date/time received, Source 1394 Address, Destination Address, Sequence Number, and (in IPv6) 1395 the Flow ID. 1397 - Attempt to transmit a packet that would result in Sequence 1398 Number overflow. The audit log entry for this event SHOULD 1399 include the SPI value, current date/time, Source Address, 1400 Destination Address, Sequence Number, and (for IPv6) the 1401 cleartext Flow ID. 1403 - The received packet fails the anti-replay checks. The audit 1404 log entry for this event SHOULD include the SPI value, 1405 date/time received, Source Address, Destination Address, the 1406 Sequence Number, and (in IPv6) the Flow ID. 1408 - The integrity check fails. The audit log entry for this 1409 event SHOULD include the SPI value, date/time received, 1410 Source Address, Destination Address, the Sequence Number, 1411 and (for IPv6) the Flow ID. 1413 Additional information also MAY be included in the audit log for each 1414 of these events, and additional events, not explicitly called out in 1415 this specification, also MAY result in audit log entries. There is 1416 no requirement for the receiver to transmit any message to the 1417 purported sender in response to the detection of an auditable event, 1418 because of the potential to induce denial of service via such action. 1420 5. Conformance Requirements 1422 Implementations that claim conformance or compliance with this 1423 specification MUST implement the ESP syntax and processing described 1424 here and MUST comply with all additional packet processing 1425 requirements levied by the Security Architecture document [KA98a]. 1426 If the key used to compute an ICV is manually distributed, correct 1427 provision of the anti-replay service would require correct 1428 maintenance of the counter state at the sender, until the key is 1429 replaced, and there likely would be no automated recovery provision 1430 if counter overflow were imminent. Thus a compliant implementation 1431 SHOULD NOT provide anti-replay service in conjunction with SAs that 1432 are manually keyed. A compliant ESP implementation MUST support the 1433 following mandatory-to-implement algorithms: 1435 - AES in CBC mode 1436 - HMAC with MD5 [MG98a] 1437 Security Payload (ESP) 1439 - HMAC with SHA-1 [MG98b] 1440 - NULL Encryption algorithm (RFC 2410) 1442 Since use of encryption in ESP is optional, support for the "NULL" 1443 encryption algorithm is required to maintain consistency with the way 1444 ESP services are negotiated. Support for the confidentiality-only 1445 service version of ESP is optional. If an implementation offers this 1446 service, it MUST also support the negotiation of the NULL integrity 1447 algorithm. NOTE that while integrity and encryption may each be 1448 "NULL" under the circumstances noted above, they MUST NOT both be 1449 "NULL". 1451 6. Security Considerations 1453 Security is central to the design of this protocol, and thus security 1454 considerations permeate the specification. Additional security- 1455 relevant aspects of using the IPsec protocol are discussed in the 1456 Security Architecture document. 1458 7. Differences from RFC 2406 1460 This document differs from RFC 2406 in a number of significant ways. 1462 o Confidentiality-only service -- now a SHOULD, not a MUST. 1463 o SPI -- modified to better reflect the differences between 1464 unicast and multicast SA lookups. For unicast, the SPI may 1465 be used alone to select an SA; for multicast, the SPI is 1466 combined with destination address to select an SA. 1467 o Sequence number -- added a new option for a 64-bit sequence 1468 number for very high-speed communications. 1469 o Payload data -- broadened model to accommodate combined mode 1470 algorithms. 1471 o Padding for improved traffic flow confidentiality -- added 1472 requirement to be able to add bytes after the end of the IP 1473 Payload, prior to the beginning of the Padding field. 1474 o Next Header -- added requirement to be able to generate and 1475 discard dummy padding packets (Next Header = 59) 1476 o ICV -- broadened model to accommodate combined mode algorithms. 1477 o Algorithms -- Added combined confidentiality mode algorithms. 1478 o Inbound and Outbound packet processing -- there are now two 1479 paths -- (1) separate confidentiality and integrity 1480 algorithms, (2) combined confidentiality mode 1481 algorithms. Because of the addition of combined mode 1482 algorithms, the encryption/decryption and integrity sections 1483 have been combined for both inbound and outbound packet 1484 processing. 1486 Security Payload (ESP) 1488 Acknowledgements 1490 The author would like to acknowledge the contributions of Ran 1491 Atkinson, who played a critical role in initial IPsec activities, and 1492 who authored the first series of IPsec standards: RFCs 1825-1827. 1493 Karen Seo deserves special thanks for providing help in the editing 1494 of this and the previous version of this specification. The author 1495 also would like to thank the members of the IPsec working group. 1497 References 1499 [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security 1500 Protocols", Proceedings of the Sixth Usenix Unix Security 1501 Symposium, July, 1996. 1503 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 1504 Requirement Level", BCP 14, RFC 2119, March 1997. 1506 [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange 1507 (IKE)", RFC 2409, November 1998. 1509 [KA98a] Kent, S., and R. Atkinson, "Security Architecture for the 1510 Internet Protocol", RFC 2401, November 1998. 1512 [KA98b] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 1513 2402, November 1998. 1515 [MD98] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher 1516 Algorithm With Explicit IV", RFC 2405, November 1998. 1518 [MG98a] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within 1519 ESP and AH", RFC 2403, November 1998. 1521 [MG98b] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within 1522 ESP and AH", RFC 2404, November 1998. 1524 Disclaimer 1526 The views and specification here are those of the authors and are not 1527 necessarily those of their employers. The authors and their 1528 employers specifically disclaim responsibility for any problems 1529 arising from correct or incorrect implementation or use of this 1530 specification. 1532 Security Payload (ESP) 1534 Author Information 1536 Stephen Kent 1537 BBN Technologies 1538 10 Moulton Street 1539 Cambridge, MA 02138 1540 USA 1542 Phone: +1 (617) 873-3988 1543 EMail: kent@bbn.com 1544 Security Payload (ESP) 1546 Appendix -- Extended Sequence Numbers 1548 TO BE ADDED -- This appendix describes a sequence number scheme which 1549 uses a 64-bit sequence number, but transmits only the low order 32 1550 bits. 1552 Security Payload (ESP) 1554 Full Copyright Statement 1556 Copyright (C) The Internet Society (2001). All Rights Reserved. 1558 This document and translations of it may be copied and furnished to 1559 others, and derivative works that comment on or otherwise explain it 1560 or assist in its implementation may be prepared, copied, published 1561 and distributed, in whole or in part, without restriction of any 1562 kind, provided that the above copyright notice and this paragraph are 1563 included on all such copies and derivative works. However, this 1564 document itself may not be modified in any way, such as by removing 1565 the copyright notice or references to the Internet Society or other 1566 Internet organizations, except as needed for the purpose of 1567 developing Internet standards in which case the procedures for 1568 copyrights defined in the Internet Standards process must be 1569 followed, or as required to translate it into languages other than 1570 English. 1572 The limited permissions granted above are perpetual and will not be 1573 revoked by the Internet Society or its successors or assigns. 1575 This document and the information contained herein is provided on an 1576 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1577 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1578 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1579 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1580 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1582 Expires May 2002