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