idnits 2.17.1 draft-ietf-ipsec-esp-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 66 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 183: '...ounter and the receiver's counter MUST...' RFC 2119 keyword, line 191: '...vironment, this field MUST be present....' RFC 2119 keyword, line 194: '...i.e., the sender MUST always transmit ...' RFC 2119 keyword, line 204: '..., then this data MAY be carried explic...' RFC 2119 keyword, line 208: '...hronization data MUST indicate the len...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 82 has weird spacing: '... before an en...' -- 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 (21 July 1997) is 9773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Bel89' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'CERT95' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'DH95' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'IB93' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'ISO92' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'Ken91' is defined on line 799, but no explicit reference was found in the text == Unused Reference: 'NIST81' is defined on line 813, but no explicit reference was found in the text == Unused Reference: 'NIST88' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'Sch94' is defined on line 832, but no explicit reference was found in the text == Unused Reference: 'SDNS89' is defined on line 835, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1827 (ref. 'ATK95') (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CERT95' ** Obsolete normative reference: RFC 1883 (ref. 'DH95') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO92' -- Possible downref: Non-RFC (?) normative reference: ref. 'KA97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'KA97b' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'KBC97') ** Downref: Normative reference to an Historic RFC: RFC 1108 (ref. 'Ken91') -- Possible downref: Non-RFC (?) normative reference: ref. 'MS97' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST77' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST80' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST81' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST88' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'Riv92') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS89' Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Stephen Kent, BBN Corp 2 Internet Draft Randall Atkinson, @Home Network 3 draft-ietf-ipsec-esp-v2-00.txt 21 July 1997 5 IP Encapsulating Security Payload (ESP) 7 Status of This Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of 6 months. 15 Internet Drafts may be updated, replaced, or obsoleted by other 16 documents at any time. It is not appropriate to use Internet Drafts 17 as reference material or to cite them other than as "work in 18 progress". 20 This particular Internet Draft is a product of the IETF's IPsec 21 working group. It is intended that a future version of this draft be 22 submitted to the IPng Area Directors and the IESG for possible 23 publication as a standards-track protocol. 25 Security Payload (ESP) 27 Table of Contents 29 1. Introduction......................................................3 30 2. Encapsulating Security Payload Packet Format......................4 31 2.1 Security Parameters Index....................................5 32 2.2 Sequence Number .............................................5 33 2.3 Payload Data.................................................5 34 2.4 Padding (for Encryption).....................................6 35 2.5 Pad Length...................................................7 36 2.6 Next Header..................................................7 37 2.7 Authentication Data..........................................7 38 3. Encapsulating Security Protocol Processing........................7 39 3.1 ESP Header Location..........................................7 40 3.2 Outbound Packet Processing..................................10 41 3.2.1 Security Association Lookup............................10 42 3.2.2 Sequence Number Generation.............................10 43 3.2.3 Packet Encryption......................................10 44 3.2.3.1 Scope of Encryption................................10 45 3.2.3.2 Encryption Algorithms..............................11 46 3.2.4 Integrity Check Value Calculation......................11 47 3.2.4.1 Scope of Authentication Protection................11 48 3.2.4.2 Authentication Padding............................11 49 3.2.4.3 Authentication Algorithms.........................12 50 3.2.5 Fragmentation..........................................12 51 3.3 Inbound Packet Processing...................................12 52 3.3.1 Pre-ESP Processing Overview............................12 53 3.3.2 Security Association Lookup............................12 54 3.3.3 Sequence Number Verification...........................13 55 3.3.4 Integrity Check Value Verification.....................14 56 3.3.5 Packet Decryption......................................15 57 4. Auditing.........................................................15 58 5. Conformance Requirements.........................................16 59 6. Security Considerations..........................................16 60 7. Differences from RFC 1827........................................16 61 Acknowledgements....................................................17 62 References..........................................................17 63 Disclaimer..........................................................19 64 Author Information..................................................19 65 Security Payload (ESP) 67 1. Introduction 69 The Encapsulating Security Payload (ESP) header is designed to 70 provide a mix of security services in IPv4 and IPv6. ESP may be 71 applied alone, in combination with the IP Authentication Header (AH) 72 [KA97b], or in a nested fashion, e.g., through the use of tunnel mode 73 (see "Security Architecture for the Internet Protocol" [KA97a], 74 hereafter referred to as the Security Architecture document). 75 Security services can be provided between a pair of communicating 76 hosts, between a pair of communicating security gateways, or between 77 a security gateway and a host. For more details on how to use ESP 78 and AH in various network environments, see the Security Architecture 79 document [KA97a]. 81 The ESP header is inserted after the IP header and before the upper 82 layer protocol header (transport mode) or before an encapsulated IP 83 header (tunnel mode). These modes are described in more detail 84 below. 86 ESP is used to provide confidentiality, data origin authentication, 87 connectionless integrity, an anti-replay service (a form of partial 88 sequence integrity), and limited traffic flow confidentiality. The 89 set of services provided depends on options selected at the time of 90 Security Association establishment and on the placement of the 91 implementation. Confidentiality may be selected independent of all 92 other services. However, use of confidentiality without 93 integrity/authentication (either in ESP or separately in AH) may 94 subject traffic to certain forms of active attacks that could 95 undermine the confidentiality service (see [Bel96]. Data origin 96 authentication and connectionless integrity are joint services 97 (hereafter referred to jointly as "authentication) and are offered as 98 an option in conjunction with confidentiality. The anti-replay 99 service may be selected only if data origin authentication is 100 selected, and its election is solely at the discretion of the 101 receiver. Traffic flow confidentiality requires selection of tunnel 102 mode, and is most effective if implemented at a security gateway, 103 where traffic aggregation may be able to mask true source-destination 104 patterns. 106 It is assumed that the reader is familiar with the terms and concepts 107 described in the Security Architecture document. In particular, the 108 reader should be familiar with the definitions of security services 109 offered by ESP and AH, the concept of Security Associations, the ways 110 in which ESP can be used in conjunction with the Authentication 111 Header (AH), and the different key management options available for 112 ESP and AH. (With regard to the last topic, the current key 113 management options required for both AH and ESP are manual keying and 114 Security Payload (ESP) 116 automated keying via Oakley/ISAKMP.) 118 2. Encapsulating Security Payload Packet Format 120 The protocol header (IPv4, IPv6, or Extension) immediately preceding the 121 ESP header will contain the value 50 in its Protocol (IPv4) or Next 122 Header (IPv6, Extension) field [STD-2]. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 127 | Security Parameters Index (SPI) | ^ 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. 129 | Sequence Number | |Coverage 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- 131 | Payload Data* (variable) | | ^ 132 ~ ~ | | 133 | | | | 134 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. 135 | | Padding (0-255 bytes) | |Coverage* 136 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 137 | | Pad Length | Next Header | v v 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- 139 | Authentication Data (variable) | 140 ~ ~ 141 | | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 * If included in the Payload field, cryptographic synchronization 145 data, e.g., an IV, usually is not encrypted per se, although it 146 often is referred to as being part of the ciphertext. 148 The following subsections define the fields in the header format. 149 "Optional" means that the field is omitted if the option is not 150 selected, i.e., it is present in neither the packet as transmitted 151 nor as formatted for computation of an ICV. Whether or not an option 152 is selected is defined as part of Security Association (SA) 153 establishment. Thus the format of ESP packets for a given SA is 154 fixed, for the duration of the SA. In contrast, "mandatory" fields 155 are always present in the ESP packet format, for all SAs. 157 Security Payload (ESP) 159 2.1 Security Parameters Index 161 The SPI is an arbitrary 32-bit value that uniquely identifies the 162 Security Association for this datagram, relative to the destination 163 IP address contained in the IP header (with which this security 164 header is associated) and relative to the security protocol employed. 165 The set of SPI values in the range 1 through 255 are reserved by the 166 Internet Assigned Numbers Authority (IANA) for future use; a reserved 167 SPI value will not normally be assigned by IANA unless the use of the 168 assigned SPI value is specified in an RFC. It is ordinarily selected 169 by the destination system upon establishment of an SA (see the 170 Security Architecture document for more details). (A zero value may 171 be used within an ESP implementation for local debugging purposes, 172 but no ESP packets should be transmitted with a zero SPI value.) The 173 SPI field is mandatory. 175 2.2 Sequence Number 177 This unsigned 32-bit field contains a monotonically increasing 178 counter value (sequence number). The sender's counter and the 179 receiver's counter are initialized to 0 when an SA is established. 180 (The first packet sent using a given SA will have a Sequence Number 181 of 1; see Section 3.2.2 for more details on how the Sequence Number 182 is generated.) The transmitted Sequence Number must never be allowed 183 to cycle. Thus, the sender's counter and the receiver's counter MUST 184 be reset (by establishing a new SA and thus a new key) prior to the 185 transmission of 2^32nd packet on an SA. 187 The Sequence Number is mandatory. It is always included in an ESP 188 packet, to ensure alignment of the Payload field on an 8-byte 189 boundary (in support of IPv6). Even if authentication is not 190 selected as a security service for the SA, or if ESP is employed in 191 an IPv4 environment, this field MUST be present. 193 Processing of the Sequence Number field is at the discretion of the 194 receiver, i.e., the sender MUST always transmit this field, but the 195 receiver need not act upon it (see the discussion of Sequence Number 196 Verification in the "Inbound Processing" section below). 198 2.3 Payload Data 200 Payload Data is a variable-length field containing data described by 201 the Next Header field. The Payload Data field is mandatory and is an 202 integral number of bytes in length. If the algorithm used to encrypt 203 the payload requires cryptographic synchronization data, e.g., an 204 Initialization Vector (IV), then this data MAY be carried explicitly 205 Security Payload (ESP) 207 in the Payload field. Any encryption algorithm that requires such 208 explicit, per-packet synchronization data MUST indicate the length, 209 any structure for such data, and the location of this data as part of 210 an RFC specifying how the algorithm is used with ESP. If such 211 synchronization data is implicit, the algorithm for deriving the data 212 MUST be part of the RFC. 214 2.4 Padding (for Encryption) 216 Several factors require or motivate use of the Padding field. 218 If an encryption algorithm is employed that requires the 219 plaintext to be a multiple of some number of bytes, e.g., the 220 block size of a block cipher, the Padding field is used to fill 221 the plaintext (consisting of the Payload Data, Pad Length and 222 Next Header fields, as well as the Padding) to the size required 223 by the algorithm. 225 Padding also may be required, irrespective of encryption 226 algorithm requirements, to ensure that the resulting ciphertext 227 terminates on a 4-byte boundary. Specifically, the Pad Length 228 and Next Header fields must be right aligned within a 4-byte 229 word, as illustrated in the ESP packet format figure above. 231 Padding beyond that required for the algorithm or alignment 232 reasons cited above, may be used to conceal the actual length of 233 the payload, in support of (partial) traffic flow 234 confidentiality. However, inclusion of such additional padding 235 has adverse bandwidth implications and thus its use should be 236 undertaken with care. 238 The transmitter MAY add 0-255 bytes of padding. Inclusion of the 239 Padding field in an ESP packet is optional, but all implementations 240 MUST support generation and consumption of padding. 242 As a default, the Padding bytes are initialized with a series of 243 (unsigned, 1-byte) integer values. The first padding byte appended 244 to the plaintext is numbered 1, with subsequent padding bytes making 245 up a monotonically increasing sequence: 1, 2, 3, ... When this 246 padding scheme is employed, the receiver SHOULD inspect the Padding 247 field. (This scheme was selected because of its relative simplicity, 248 ease of implementation in hardware, and because it offers limited 249 protection against certain forms of "cut and paste" attacks in the 250 absence of other integrity measures, if the receiver checks the 251 padding values upon decryption.) 252 Security Payload (ESP) 254 Any encryption algorithm that requires Padding other than the default 255 described above, MUST define the Padding contents (e.g., zeros or 256 random data) and any required receiver processing of these Padding 257 bytes in an RFC specifying how the algorithm is used with ESP. In 258 such circumstances, the content of the Padding field will be 259 determined by the encryption algorithm and mode selected and defined 260 in the corresponding algorithm RFC. The relevant algorithm RFC MAY 261 specify that a receiver MUST inspect the Padding field or that a 262 receiver MUST inform senders of how the receiver will handle the 263 Padding field. 265 2.5 Pad Length 267 The Pad Length field indicates the number of pad bytes immediately 268 preceding it. The range of valid values is 0-255, where a value of 269 zero indicates that no Padding bytes are present. The Pad Length 270 field is mandatory. 272 2.6 Next Header 274 The Next Header is an 8-bit field that identifies the type of data 275 contained in the Payload Data field, e.g., an extension header in 276 IPv6 or an upper layer protocol identifier. The value of this field 277 is chosen from the set of IP Protocol Numbers defined in the most 278 recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned 279 Numbers Authority (IANA). The Next Header field is mandatory. 281 2.7 Authentication Data 283 The Authentication Data is a variable-length field containing an 284 Integrity Check Value (ICV) computed over the ESP packet minus the 285 Authentication Data. The length of the field depends upon the 286 authentication function selected. The mandatory-to-implement 287 authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit 288 ICV's because of the truncation convention (see Section 3.2.4.3) 289 adopted for use in IPsec. The Authentication Data field is optional, 290 and is included only if the authentication service has been selected 291 for the SA in question. 293 3. Encapsulating Security Protocol Processing 295 3.1 ESP Header Location 297 Like AH, ESP may be employed in two ways: transport mode or tunnel 298 mode. The former mode is applicable only to host implementations and 299 provides protection for upper layer protocols, but not the IP header. 300 (In this mode, note that for "bump-in-the-stack" or "bump-in-the- 301 Security Payload (ESP) 303 wire" implementations, as defined in the Security Architecture 304 document, inbound and outbound IP fragments may require an IPsec 305 implementation to perform extra IP reassembly/fragmentation in order 306 to both conform to this specification and provide transparent IPsec 307 support. Special care is required to perform such operations within 308 these implementations when multiple interfaces are in use.) 310 In transport mode, ESP is inserted after the IP header and before an 311 upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other 312 IPsec headers that have already been inserted, e.g., AH. In the 313 context of IPv4, this translates to placing ESP after the IP header 314 (and any options that it contains), but before the upper layer 315 protocol. (Note that the term "transport" mode should not be 316 misconstrued as restricting its use to TCP and UDP. For example, an 317 ICMP message MAY be sent using either "transport" mode or "tunnel" 318 mode.) The following diagram illustrates ESP transport mode 319 positioning for a typical IPv4 packet, on a "before and after" basis. 320 (The "ESP trailer" encompasses any Padding, plus the Pad Length, and 321 Next Header fields.) 323 BEFORE APPLYING ESP 324 ---------------------------- 325 IPv4 |orig IP hdr | | | 326 |(any options)| TCP | Data | 327 ---------------------------- 329 AFTER APPLYING ESP 330 ------------------------------------------------- 331 IPv4 |orig IP hdr | ESP | | | ESP | ESP| 332 |(any options)| Hdr | TCP | Data | Trailer |Auth| 333 ------------------------------------------------- 334 |<----- encrypted ---->| 335 |<------ authenticated ----->| 337 In the IPv6 context, ESP is viewed as an end-to-end payload, and thus 338 should appear after hop-by-hop, routing, and fragmentation extension 339 headers. The destination options extension header(s) could appear 340 either before or after the ESP header depending on the semantics 341 desired. However, since ESP protects only fields after the ESP 342 header, it generally may be desirable to place the destination 343 options header(s) after the ESP header. The following diagram 344 illustrates ESP transport mode positioning for a typical IPv6 packet. 346 Security Payload (ESP) 348 BEFORE APPLYING ESP 349 --------------------------------------- 350 IPv6 | | ext hdrs | | | 351 | orig IP hdr |if present| TCP | Data | 352 --------------------------------------- 354 AFTER APPLYING ESP 355 --------------------------------------------------------- 356 IPv6 | orig |hxh,rtg,frag|dest|ESP|dest| | | ESP | ESP| 357 |IP hdr|if present**|opt*|Hdr|opt*|TCP|Data|Trailer|Auth| 358 --------------------------------------------------------- 359 |<---- encrypted ---->| 360 |<---- authenticated ---->| 362 * = if present, could be before ESP, after ESP, or both 363 ** = hop by hop, routing, fragmentation headers 365 Tunnel mode ESP may be employed in either hosts or security gateways. 366 When ESP is implemented in a security gateway (to protect subscriber 367 transit traffic), tunnel mode must be used. In tunnel mode, the 368 "inner" IP header carries the ultimate source and destination 369 addresses, while an "outer" IP header may contain distinct IP 370 addresses, e.g., addresses of security gateways. In tunnel mode, ESP 371 protects the entire inner IP packet, including the entire inner IP 372 header. The position of ESP in tunnel mode, relative to the outer IP 373 header, is the same as for ESP in transport mode. The following 374 diagram illustrates ESP tunnel mode positioning for typical IPv4 and 375 IPv6 packets. 377 ----------------------------------------------------------- 378 IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| 379 |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| 380 ----------------------------------------------------------- 381 |<--------- encrypted ---------->| 382 |<----------- authenticated ---------->| 384 --------------------------------------------------------------- 385 IPv6 | new* | ext hdrs*| | orig*| ext hdrs*| | | ESP | ESP| 386 |IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth| 387 --------------------------------------------------------------- 388 |<---------- encrypted ----------->| 389 |<----------- authenticated ---------->| 391 * = construction of outer IP hdr/extensions and modification 392 of inner IP hdr/extensions is discussed below. 394 Security Payload (ESP) 396 3.2 Outbound Packet Processing 398 In transport mode, the transmitter encapsulates the upper layer 399 protocol information in the ESP header/trailer, and retains the 400 specified IP header (and any IP extension headers in the IPv6 401 context). In tunnel mode, the outer and inner IP header/extensions 402 can be inter-related in a variety of ways. The construction of the 403 outer IP header/extensions during the encapsulation process is 404 described in the Security Architecture document. 406 3.2.1 Security Association Lookup 408 ESP is applied to an outbound packet only after an IPsec 409 implementation determines that the packet is associated with an SA 410 that calls for ESP processing. The process of determining what, if 411 any, IPsec processing is applied to outbound traffic is described in 412 the Security Architecture document. 414 3.2.2 Sequence Number Generation 416 As noted in Section 2.2, the Sequence Number field is always included 417 in ESP packets, even if the anti-replay service, or the 418 authentication service, have not been enabled for the SA. The 419 sender's counter is initialized to 0 when an SA is established. The 420 transmitter increments the Sequence Number for this SA, checks to 421 ensure that the counter has not cycled, and inserts the new value 422 into the Sequence Number field. Thus the first packet sent using a 423 given SA will have a Sequence Number of 1. A transmitter MUST NOT 424 send a packet on an SA if doing so would cause the Sequence Number to 425 cycle. An attempt to transmit a packet that would result in sequence 426 number overflow is an auditable event. (Note that this approach to 427 Sequence Number management does not require use of modular 428 arithmetic.) 430 3.2.3 Packet Encryption 432 3.2.3.1 Scope of Encryption 434 In transport mode, the transmitter encapsulates the original upper 435 layer protocol information into the ESP payload field, adds any 436 necessary padding, and encrypts the result (Payload Data, Padding, 437 Pad Length, and Next Header) using the key, encryption algorithm, and 438 algorithm mode indicated by the SA. In tunnel mode, the transmitter 439 encapsulates and encrypts the entire original IP datagram (plus the 440 Padding, Pad Length, and Next Header). 442 If authentication is selected, encryption is performed first, before 443 Security Payload (ESP) 445 the authentication, and the encryption does not encompass the 446 Authentication Data field. This order of processing facilitates 447 rapid detection and rejection of replayed or bogus packets by the 448 receiver, prior to decrypting the packet, hence potentially reducing 449 the impact of denial of service attacks. It also allows for the 450 possibility of parallel processing of packets at the receiver, i.e., 451 decryption can take place in parallel with authentication. Note that 452 since the Authentication Data is not protected by encryption, a keyed 453 authentication algorithm must be employed to compute the ICV. 455 3.2.3.2 Encryption Algorithms 457 The encryption algorithm employed is specified by the SA. ESP is 458 designed for use with symmetric encryption algorithms. Because IP 459 packets may arrive out of order, each packet must carry any data 460 required to allow the receiver to establish cryptographic 461 synchronization for decryption. This data may be carried explicitly in 462 the payload field, e.g., as an IV (as described above), or the data may 463 be derived from the packet header. Since ESP makes provision for 464 padding of the plaintext, encryption algorithms employed with ESP may 465 exhibit either block or stream mode characteristics. 467 At the time of writing, one mandatory-to-implement encryption algorithm 468 and mode has been defined for ESP. It is based on the Data Encryption 469 Standard (DES) [NIST77] in Cipher Block Chaining Mode [NIST80]. Details 470 of use of this mode are contained in [MS97]. 472 3.2.4 Integrity Check Value Calculation 474 3.2.4.1 Scope of Authentication Protection 476 If authentication is selected for the SA, the transmitter computes 477 the ICV over the ESP packet minus the Authentication Data. Thus the 478 SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, 479 and Next Header are all encompassed by the ICV computation. Note 480 that the last 4 fields will be in ciphertext form, since encryption 481 is performed prior to authentication. 483 3.2.4.2 Authentication Padding 485 For some authentication algorithms, the byte string over which the 486 ICV computation is performed must be a multiple of a blocksize 487 specified by the algorithm. If the length of this byte string does 488 not match the blocksize requirements for the algorithm, implicit 489 padding MUST be appended to the end of the ESP packet, prior to ICV 490 computation. The padding octets MUST have a value of zero. The 491 Security Payload (ESP) 493 blocksize (and hence the length of the padding) is specified by the 494 algorithm specification. This padding is not transmitted with the 495 packet. 497 3.2.4.3 Authentication Algorithms 499 The authentication algorithm employed for the ICV computation is 500 specified by the SA. For point-to-point communication, suitable 501 authentication algorithms include keyed Message Authentication Codes 502 (MACs) based on symmetric encryption algorithms (e.g., DES) or on 503 one-way hash functions (e.g., MD5 or SHA-1). For multicast 504 communication, one-way hash algorithms combined with asymmetric 505 signature algorithms are suitable. As of this writing, the 506 mandatory-to-implement authentication algorithms are based on the 507 former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 508 [Riv92]. The output of the HMAC computation is truncated to the 509 leftmost 96 bits. Other algorithms, possibly with different ICV 510 lengths, MAY be supported. 512 3.2.5 Fragmentation 514 If necessary, fragmentation is performed after ESP processing within 515 an IPsec implementation. Thus, transport mode ESP is applied only to 516 whole IP datagrams (not to IP fragments). An IP packet to which ESP 517 has been applied may itself be fragmented by routers en route, and 518 such fragments must be reassembled prior to ESP processing at a 519 receiver. In tunnel mode, ESP is applied to an IP packet, the 520 payload of which may be a fragmented IP packet. For example, a 521 security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec 522 implementation (as defined in the Security Architecture document) may 523 apply tunnel mode ESP to such fragments. 525 3.3 Inbound Packet Processing 527 3.3.1 Pre-ESP Processing Overview 529 If required, reassembly is performed prior to ESP processing. 531 3.3.2 Security Association Lookup 533 Upon receipt of a (reassembled) packet containing an ESP Header, the 534 receiver determines the appropriate (unidirectional) SA, based on the 535 destination IP address and the SPI. (This process is described in 536 more detail in the Security Architecture document.) The SA indicates 537 whether the Authentication Data field should be present, and it will 538 specify the algorithms and keys to be employed for decryption and ICV 539 computations (if applicable). 541 Security Payload (ESP) 543 If no valid Security Association exists for this session (for 544 example, the receiver has no key), the receiver MUST discard the 545 packet; this is an auditable event. The audit log entry for this 546 event SHOULD include the SPI value, date/time, Source Address, 547 Destination Address, and (in IPv6) the cleartext Flow ID. 549 3.3.3 Sequence Number Verification 551 All ESP implementations MUST support the anti-replay service, though 552 its use may be enabled or disabled on a per-SA basis. This service 553 MUST NOT be enabled unless the authentication service also is enabled 554 for the SA, since otherwise the Sequence Number field has not been 555 integrity protected. (Note that there are no provisions for managing 556 transmitted Sequence Number values among multiple senders directing 557 traffic to a single, multicast SA. Thus the anti-replay service 558 SHOULD NOT be used in a multi-sender multicast environment that 559 employs a single, multicast SA.) If an SA establishment protocol 560 such as Oakley/ISAKMP is employed, then the receiver SHOULD notify 561 the transmitter, during SA establishment, if the receiver will 562 provide anti-replay protection and SHOULD inform the transmitter of 563 the window size. 565 If the receiver enables the anti-replay service for this SA, the 566 receive packet counter for the SA MUST be initialized to zero when 567 the SA is established. For each received packet, the receiver MUST 568 verify that the packet contains a Sequence Number that does not 569 duplicate the Sequence Number of any other packets received during 570 the life of this SA. This SHOULD be the first ESP check applied to a 571 packet after it has been matched to an SA, to speed rejection of 572 duplicate packets. 574 Duplicates are rejected through the use of a sliding receive window. 575 (How the window is implemented is a local matter, but the following 576 text describes the functionality that the implementation must 577 exhibit.) A MINIMUM window size of 32 MUST be supported; but a 578 window size of 64 is preferred and SHOULD be employed as the default. 579 A window size of 64 or larger MAY be chosen by the receiver. If a 580 larger window size is chosen, it MUST be a multiple of 32. If any 581 window size other than the default of 64 is employed by the receiver, 582 it MUST be reported to the transmitter during SA negotiation. 584 The "right" edge of the window represents the highest, validated 585 Sequence Number value received on this SA. Packets that contain 586 Sequence Numbers lower than the "left" edge of the window are 587 rejected. Packets falling within the window are checked against a 588 list of received packets within the window. An efficient means for 589 performing this check, based on the use of a bit mask, is described 590 Security Payload (ESP) 592 in the Security Architecture document. 594 If the received packet falls within the window and is new, or if the 595 packet is to the right of the window, then the receiver proceeds to 596 ICV verification. If the ICV validation fails, the receiver MUST 597 discard the received IP datagram as invalid; this is an auditable 598 event. The audit log entry for this event SHOULD include the SPI 599 value, date/time, Source Address, Destination Address, the Sequence 600 Number, and (in IPv6) the Flow ID. The receive window is updated 601 only if the ICV verification succeeds. 603 DISCUSSION: 605 Note that if the packet is either inside the window and new, or is 606 outside the window on the "right" side, the receiver MUST 607 authenticate the packet before updating the Sequence Number window 608 data. 610 3.3.4 Integrity Check Value Verification 612 If authentication has been selected, the receiver computes the ICV 613 over the ESP packet minus the Authentication Data using the specified 614 authentication algorithm and verifies that it is the same as the ICV 615 included in the Authentication Data field of the packet. Details of 616 the computation are provided below. 618 If the computed and received ICV's match, then the datagram is valid, 619 and it is accepted. If the test fails, then the receiver MUST 620 discard the received IP datagram as invalid; this is an auditable 621 event. The log data SHOULD include the SPI value, date/time 622 received, Source Address, Destination Address, and (in IPv6) the 623 cleartext Flow ID. 625 DISCUSSION: 627 Begin by removing and saving the ICV value (Authentication Data 628 field). Next check the overall length of the ESP packet minus the 629 Authentication Data. If implicit padding is required, based on 630 the blocksize of the authentication algorithm, append zero-filled 631 bytes to the end of the ESP packet directly after the Next Header 632 field. Perform the ICV computation and compare the result with 633 the saved value. (For the mandatory-to-implement authentication 634 algorithms, HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 635 [Riv92], the output of the HMAC computation is truncated to the 636 leftmost 96 bits. Other algorithms may have different ICV 637 lengths.) (If a digital signature and one-way hash are used for 638 the ICV computation, the matching process is more complex and will 639 Security Payload (ESP) 641 be described in the algorithm specification.) 643 3.3.5 Packet Decryption 645 The receiver decrypts the ESP Payload Data, Padding, Pad Length, and 646 Next Header using the session key that has been established for this 647 traffic. If an explicit IV is present in the Payload Field, it is 648 input to the decryption algorithm as per the algorithm specification. 649 If an implicit IV is employed, a local version of the IV is 650 constructed and input to the decryption algorithm as per the 651 algorithm specification. (Decryption may take place in parallel with 652 authentication, but care must be taken to avoid possible race 653 conditions with regard to packet access and reconstruction of the 654 decrypted packet.) 656 After decryption, the original IP datagram is reconstructed and 657 processed per the normal IP protocol specification. The exact steps 658 for reconstructing the original datagram depend on the mode (tunnel 659 vs transport) and are described in the Security Architecture 660 document. At a minimum, in an IPv6 context, the receiver SHOULD 661 ensure that the decrypted data is 8-byte aligned, to facilitate 662 processing by the protocol identified in the Next Header field. 664 Note that there are two ways in which the decryption can "fail". The 665 selected SA may not be correct or the encrypted ESP packet could be 666 corrupted. (The latter case would be detected if authentication is 667 selected for the SA, as would tampering with the SPI. However, an SA 668 mismatch might still occur due to tampering with the IP Destination 669 Address.) In either case, the erroneous result of the decryption 670 operation (an invalid IP datagram or transport-layer frame) will not 671 necessarily be detected by IPsec, and is the responsibility of later 672 protocol processing. 674 4. Auditing 676 Not all systems that implement ESP will implement auditing. However, 677 if ESP is incorporated into a system that supports auditing, then the 678 ESP implementation MUST also support auditing and MUST allow a system 679 administrator to enable or disable auditing for ESP. For the most 680 part, the granularity of auditing is a local matter. However, 681 several auditable events are identified in this specification and for 682 each of these events a minimum set of information that SHOULD be 683 included in an audit log is defined. Additional information also MAY 684 be included in the audit log for each of these events, and additional 685 events, not explicitly called out in this specification, also MAY 686 Security Payload (ESP) 688 result in audit log entries. There is no requirement for the 689 receiver to transmit any message to the purported transmitter in 690 response to the detection of an auditable event, because of the 691 potential to induce denial of service via such action. 693 5. Conformance Requirements 695 Implementations that claim conformance or compliance with this 696 specification MUST implement the ESP syntax and processing described 697 here and MUST comply with all requirements of the Security 698 Architecture document. If the key used to compute an ICV is manually 699 distributed, correct provision of the anti-replay service would 700 require correct maintenance of the counter state at the transmitter, 701 until the key is replaced, and there likely would be no automated 702 recovery provision if counter overflow were imminent. Thus a 703 compliant implementation SHOULD NOT provide this service in 704 conjunction with SAs that are manually keyed. A compliant ESP 705 implementation MUST support the following mandatory-to-implement 706 algorithms (specified in [KBC97] and in [MS97]. 708 - DES in CBC mode 709 - HMAC with MD5 710 - HMAC with SHA-1 712 6. Security Considerations 714 Security is central to the design of this protocol, and this security 715 considerations permeate the specification. Additional security- 716 relevant aspects of using IPsec protocol are discussed in the 717 Security Architecture document. 719 7. Differences from RFC 1827 721 This document differs from RFC 1827 [ATK95] in several significant 722 ways. The major difference is that, this document attempts to 723 specify a complete framework and context for ESP, whereas RFC 1827 724 provided a "shell" that was completed through the definition of 725 transforms. The combinatorial growth of transforms motivated the 726 reformulation of the ESP specification as a more complete document, 727 with options for security services that may be offered in the context 728 of ESP. Thus, fields previously defined in transform documents are 729 now part of this base ESP specification. For example, the fields 730 necessary to support authentication (and anti-replay) are now defined 731 here, even though the provision of this service is an option. The 732 Security Payload (ESP) 734 fields used to support padding for encryption, and for next protocol 735 identification, are now defined here as well. Packet processing 736 consistent with the definition of these fields also is included in 737 the document. 739 Acknowledgements 741 Many of the concepts embodied in this specification were derived from 742 or influenced by the US Government's SP3 security protocol, ISO/IEC's 743 NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92 744 IB93]. 746 For over 2 years, this document has evolved through multiple versions 747 and iterations. During this time, many people have contributed 748 significant ideas and energy to the process and the documents 749 themselves. The authors would like to thank Karen Seo for providing 750 extensive help in the review, editing, background research, and 751 coordination for this version of the specification. The authors 752 would also like to thank the members of the IPSEC and IPng working 753 groups, with special mention of the efforts of (in alphabetic order): 754 Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David 755 Mihelcic, Hilarie Orman, William Simpson and Nina Yuan. 757 References 759 [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 760 1827, August 1997. 762 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP 763 Protocol Suite", ACM Computer Communications Review, Vol. 764 19, No. 2, March 1989. 766 [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security 767 Protocols", Proceedings of the Sixth Usenix Unix Security 768 Symposium, July, 1996. 770 [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing 771 Attacks and Hijacked Terminal Connections", CA-95:01, 772 January 1995. Available via anonymous ftp from 773 info.cert.org. 775 [DH95] Steve Deering & Robert Hinden, Internet Protocol Version 6 776 (Ipv6) Specification, RFC 1883, December 1995. 778 [IB93] John Ioannidis & Matt Blaze, "Architecture and 779 Security Payload (ESP) 781 Implementation of Network-layer Security Under Unix", 782 Proceedings of the USENIX Security Symposium, Santa Clara, 783 CA, October 1993. 785 [ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 786 DIS 11577, International Standards Organisation, Geneva, 787 Switzerland, 29 November 1992. 789 [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for 790 the Internet Protocol", Internet Draft, ?? 1997. 792 [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", 793 Internet Draft, ?? 1997. 795 [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: 796 Keyed-Hashing for Message Authentication", RFC-2104, 797 February 1997. 799 [Ken91] Steve Kent, "US DoD Security Options for the Internet 800 Protocol (IPSO)", RFC-1108, November 1991. 802 [MS97] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", 803 RFC-xxxx, August 1997. 805 [NIST77] US National Bureau of Standards, "Data Encryption 806 Standard", Federal Information Processing Standard (FIPS) 807 Publication 46, January 1977. 809 [NIST80] US National Bureau of Standards, "DES Modes of Operation" 810 Federal Information Processing Standard (FIPS) Publication 811 81, December 1980. 813 [NIST81] US National Bureau of Standards, "Guidelines for 814 Implementing and Using the Data Encryption Standard", 815 Federal Information Processing Standard (FIPS) Publication 816 74, April 1981. 818 [NIST88] US National Bureau of Standards, "Data Encryption 819 Standard", Federal Information Processing Standard (FIPS) 820 Publication 46-1, January 1988. 822 [Riv92] Ronald Rivest, "The MD5 Message Digest Algorithm," RFC- 823 1321, April 1992. 825 [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 827 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 828 Security Payload (ESP) 830 October 1994. 832 [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, 833 New York, NY, 1994. ISBN 0-471-59756-2 835 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, 836 Document SDN.301, Revision 1.5, 15 May 1989, as published 837 in NIST Publication NIST-IR-90-4250, February 1990. 839 Disclaimer 841 The views and specification here are those of the authors and are not 842 necessarily those of their employers. The authors and their 843 employers specifically disclaim responsibility for any problems 844 arising from correct or incorrect implementation or use of this 845 specification. 847 Author Information 849 Stephen Kent 850 BBN Corporation 851 70 Fawcett Street 852 Cambridge, MA 02140 853 USA 854 E-mail: kent@bbn.com 855 Telephone: +1 (617) 873-3988 857 Randall Atkinson 858 @Home Network 859 385 Ravendale Drive 860 Mountain View, CA 94043 861 USA 862 E-mail: rja@inet.org