idnits 2.17.1 draft-ietf-ipsec-new-esp-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-18) 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 57 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 169: '... cycle; thus, it MUST be reset (by est...' RFC 2119 keyword, line 175: '... Sequence Number MUST not be present i...' RFC 2119 keyword, line 222: '...he Padding bytes SHOULD be initialized...' RFC 2119 keyword, line 229: '... implementations MUST support generati...' RFC 2119 keyword, line 272: '...r example, an ICMP message MAY be sent...' (24 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Sequence Number is optional. It is only included if the anti-replay service is selected as a security service for the SA. Since the anti-replay service requires selection of the authentication service as well, the Sequence Number MUST not be present in the absence of the Authentication Data field (described below.) -- 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 (26 March 1997) is 9885 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 654, but no explicit reference was found in the text == Unused Reference: 'CERT95' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'DH95' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'IB93' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'ISO92' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'Ken91' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'MS95' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'NIST81' is defined on line 701, but no explicit reference was found in the text == Unused Reference: 'NIST88' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'Sch94' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'SDNS89' is defined on line 720, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' -- 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' ** 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. 'KA97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'KA97b' -- 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: 15 errors (**), 0 flaws (~~), 13 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Stephen Kent, BBN Corp 3 Internet Draft Randall Atkinson, @Home Network 4 draft-ietf-ipsec-new-esp-00.txt 26 March 1997 5 Expire in six months 7 IP Encapsulating Security Payload (ESP) 9 Status of This Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of 6 months. 17 Internet Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet Drafts 19 as reference material or to cite them other than as "work in 20 progress". 22 This particular Internet Draft is a product of the IETF's IPng and 23 IPsec working groups. It is intended that a future version of this 24 draft be submitted to the IPng Area Directors and the IESG for 25 possible publication as a standards-track protocol. 27 Security Payload (ESP) 29 Table of Contents 31 1. Introduction......................................................3 32 2. Encapsulating Security Payload Packet Format......................4 33 2.1 Security Parameters Index....................................4 34 2.2 Sequence Number .............................................5 35 2.3 Initialization Vector........................................5 36 2.4 Payload Data.................................................5 37 2.5 Padding (for encryption).....................................6 38 2.6 Pad Length...................................................6 39 2.7 Next Header..................................................6 40 2.8 Authentication Data..........................................6 41 3. Encapsulating Security Protocol Processing........................7 42 3.1 ESP Header Location..........................................7 43 3.2 Outbound Packet Processing...................................9 44 3.2.1 Security Association Lookup.............................9 45 3.2.2 Anti-replay Service.....................................9 46 3.2.3 Packet Encryption.......................................9 47 3.2.3.1 Scope of Encryption.................................9 48 3.2.3.2 Encryption Algorithms..............................10 49 3.2.4 Integrity Check Value Calculation......................10 50 3.2.4.1 Scope of Authentication Protection................10 51 3.2.4.2 Authentication Padding............................10 52 3.2.4.3 Authentication Algorithms.........................11 53 3.2.5 Fragmentation..........................................11 54 3.3 Inbound Packet Processing...................................11 55 3.3.1 Pre-ESP Processing Overview............................11 56 3.3.2 Security Association Lookup............................11 57 3.3.3 Anti-replay Service....................................12 58 3.3.4 Integrity Check Value Verification.....................13 59 3.3.5 Packet Decryption......................................13 60 4. Conformance Requirements.........................................14 61 5. Security Considerations..........................................14 62 Acknowledgements....................................................14 63 References..........................................................15 64 Disclaimer..........................................................17 65 Author Information..................................................17 66 Security Payload (ESP) 68 1. Introduction 70 The Encapsulating Security Payload (ESP) header is designed to 71 provide a mix of optional security services in IPv4 and IPv6. ESP 72 may be applied alone, in combination with the IP Authentication 73 Header (AH) [KA97b], or in a nested fashion, e.g., through the use of 74 tunnel mode (see below). Security services can be provided between a 75 pair of communicating hosts, between a pair of communicating security 76 gateways, or between a security gateway and a host. For more details 77 on how to use ESP and AH in various network environments, see 78 "Security Architecture for the Internet Protocol" [KA97a]. 80 The ESP header is inserted after the IP header and before the upper 81 layer protocol header (transport mode) or the encapsulated IP header 82 (tunnel mode). These modes are described in more detail below. 84 ESP is used to provide confidentiality, data origin authentication, 85 connectionless integrity, anti-replay service (a form of sequence 86 integrity), and limited traffic flow confidentiality. The set of 87 services provided depends on options selected at the time of Security 88 Association establishment and the implementation placement. 89 Confidentiality may be selected independent of all other services. 90 Data origin authentication and connectionless integrity are joint 91 services (hereafter referred to jointly as "authentication), 92 independent of confidentiality. An anti-replay service may be 93 selected only if data origin authentication is selected, but it is 94 independent of confidentiality. Traffic flow confidentiality depends 95 on confidentiality, and requires selection of tunnel mode. 97 It is assumed that the reader is familiar with the terms and concepts 98 described in the document "Security Architecture for the Internet 99 Protocol" [KA97a]. In particular, the reader should be familiar with 100 the definitions of security services offered by ESP (and by AH), the 101 concept of Security Associations, the different key management 102 options available for ESP (and AH), and the ways in which ESP can be 103 used in conjunction with the Authentication Header (AH). 105 Security Payload (ESP) 107 2. Encapsulating Security Payload Packet Format 109 +---------------+---------------+---------------+---------------+ ---- 110 | Security Parameters Index (SPI), (32 bits) | ^ 111 +---------------+---------------+---------------+---------------+ | 112 | Sequence Number (32 bits) | | 113 +---------------+---------------+---------------+---------------+ Auth/ 114 | Initialization Vector (variable) | Integrity 115 + + Coverage 116 | | | 117 +---------------+---------------+---------------+---------------+ | ----- 118 | Payload Data (variable) | | ^ 119 - - | | 120 | | | | 121 + +---------------+---------------+---------------+ | Confid. 122 | | Padding (0-255 bytes) | | Coverage 123 +---------------+ +---------------+---------------+ | | 124 | | Pad Length(8) | Next Header(8)| v v 125 +---------------+---------------+---------------+---------------+ -------- 126 | Authentication Data (variable) | 127 - - 128 | | 129 +---------------+---------------+---------------+---------------+ 130 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 132 The following subsections define the fields in the header format. 133 "Optional" means that the field is omitted if the option is not 134 selected, i.e., it is present in neither the packet as transmitted nor 135 as formatted for computation of an ICV. Whether or not an option is 136 selected is defined as part of Security Association (SA) 137 establishment. Thus the format of ESP packets for a given SA is 138 fixed, for the duration of the SA. In contrast, "mandatory" 139 fields are always present in the ESP packet format, for all SAs. 141 2.1 Security Parameters Index 143 The SPI is an arbitrary 32-bit value identifying the Security 144 Association for this datagram (relative to the destination IP address 145 contained in the IP header with which this security header is 146 associated). The set of SPI values in the range 1 through 255 are 147 reserved by the Internet Assigned Numbers Authority (IANA) for future 148 use; a reserved SPI value will not normally be assigned by IANA 149 unless the use of the assigned SPI value is specified in an RFC. A 150 value of zero indicates that no Security Association exists. (Note 151 that the SPI is similar to the SAID used in other security protocols. 152 The name has been changed because the semantics used here are not 153 exactly the same as those used in other security protocols.) 154 Security Payload (ESP) 156 ***Under what circumstances will a zero SPI be employed? Is this 157 ***vestigial, or is there still a use for a zero SPI? Is it a SKIP 158 ***support feature of some sort? 160 The SPI field is mandatory, and its value is ordinarily selected by 161 the destination system upon establishment of an SA (see "Security 162 Architecture for the Internet Protocol" for more details.) 164 2.2 Sequence Number 166 This unsigned 32-bit field contains a monotonically increasing 167 counter value (sequence number). The counter is initialized to 1 168 when an SA is established. The Sequence Number must never be allowed 169 to cycle; thus, it MUST be reset (by establishing a new SA and thus a 170 new key) prior to the transmission of 2^32-1 packets on an SA. 172 The Sequence Number is optional. It is only included if the anti- 173 replay service is selected as a security service for the SA. Since 174 the anti-replay service requires selection of the authentication 175 service as well, the Sequence Number MUST not be present in the 176 absence of the Authentication Data field (described below.) 178 2.3 Initialization Vector 180 This is a variable-length field used only when an explicit IV is 181 required by the selected encryption algorithm, mode or device. The 182 length of the IV is dependent upon the choice of encryption 183 algorithm, and is established during SA negotiation. The IV field is 184 optional, but all implementations must be capable of generating and 185 processing this field if they support algorithms or devices that 186 require an explicit IV. 188 2.4 Payload Data 190 Payload Data is a variable-length field containing data described by 191 the Next Header field. This field is an integral number of bytes in 192 length. The Payload Data field is mandatory. 194 ***We have a potential IPv6 alignment problem here, that may have 195 ***been present for some time. Ignoring the presence or absence of an 196 ***iv, the payload data will not be aligned on an 8-byte boundary if 197 ***the Sequence Number is omitted. This may cause a problem for 198 ***efficient crypto data transfer. If the IV is present, and the 199 ***Sequence Number is omitted, the same problem arises, starting with 200 ***the IV, unless the IV is of a compensating size. The decryption 201 ***process can fix the problem for higher layer protocols, because the 202 ***output buffer from decryption is usually distinct from the input 203 Security Payload (ESP) 205 ***buffer, but that still causes potential problems for transfer of 206 ***data to the crypto module. Also, if encryption is not employed, 207 ***this becomes a potential problem for authentication data being 208 ***passed up. We could solve this by adding an optional alignment 209 ***field to the ESP header, when required for IPv6. What do people think? 211 2.5 Padding (for Encryption) 213 If the confidentiality service has been selected, the Padding field 214 is used to fill the Payload Data to a multiple of the blocksize 215 required by the encryption algorithm. This blocksize requirement is 216 a parameter of the algorithm negotiated during SA establishment. 218 If encryption has not been selected, the Padding field is used to 219 align the Next Header field so that the last bit of that field ends 220 on a 32-bit boundary. 222 The Padding bytes SHOULD be initialized with random data and they are 223 transmitted. The transmitter can add 0-255 bytes of padding. Padding 224 beyond that required for encryption algorithm blocksize alignment may 225 be used to conceal the actual length of the payload, in support of 226 traffic flow confidentiality. However, inclusion of such additional 227 padding has adverse bandwidth implications and thus its use should be 228 undertaken with care. The Padding field is optional, but all 229 implementations MUST support generation and consumption of padding. 231 2.6 Pad Length 233 The Pad Length field indicates the number of pad bytes immediately 234 preceding it. The range of valid values is 0-255, where a value of 235 zero indicates that the byte immediately preceding the pad length 236 field is the last byte of the payload. The Pad Length field is 237 mandatory. 239 2.7 Next Header 241 The Next Header is an 8-bit field that identifies the type of data 242 contained in the Payload Data field, e.g., an extension header in 243 IPv6 or an upper layer protocol identifier. The value of this field 244 is chosen from the set of IP Protocol Numbers defined in the most 245 recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned 246 Numbers Authority (IANA). The Next Header field is mandatory. 248 2.8 Authentication Data 250 The Authentication Data is a variable-length field containing an 251 Integrity Check Value (ICV) computed over the ESP packet minus the 252 Security Payload (ESP) 254 Authentication Data. The length of the field depends upon the 255 authentication function selected. The mandatory-to-implement 256 authentication algorithms, HMAC with MD5 or SHA-1, both yield 96-bit 257 ICVs because of the truncation convention adopted for use in IPsec. 258 The Authentication Data field is optional. 260 3. Encapsulating Security Protocol Processing 262 3.1 ESP Header Location 264 Like AH, ESP may be employed in two ways: transport mode or tunnel 265 mode. The former mode is applicable only to host implementations and 266 provides protection for upper layer protocols, but not the IP header. 267 In this mode, ESP is inserted after the IP header and before an upper 268 layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, 269 this translates to placing ESP after the IP header (and any options 270 that it contains), but before the upper layer protocol. (Note that 271 the term "transport" mode should not be misconstrued as restricting 272 its use to TCP and UDP. For example, an ICMP message MAY be sent 273 using either "transport" mode or "tunnel" mode.) The following 274 diagram illustrates ESP transport mode positioning for a typical IPv4 275 packet, on a "before and after" basis. (The "ESP trailer" encompasses 276 any Padding, plus the Pad Length, and Next Header fields.) 278 BEFORE APPLYING ESP 279 ---------------------------- 280 IPv4 |orig IP hdr | | | 281 |(any options)| TCP | Data | 282 ---------------------------- 284 AFTER APPLYING ESP 285 ------------------------------------------------- 286 IPv4 |orig IP hdr | | | | ESP | ESP| 287 |(any options)| ESP | TCP | Data | Trailer |Auth| 288 ------------------------------------------------- 289 |<----- encrypted ---->| 290 |<------ authenticated ----->| 292 In the IPv6 context, ESP is viewed as an end-to-end payload, and thus 293 should appear after hop-by-hop, routing, and fragmentation extension 294 headers. The destination options extension header(s) could appear 295 either before or after the ESP header depending on the semantics 296 desired. However, since ESP protects only fields after the ESP 297 header, it generally may be desirable to place the destination 298 options header(s) after the ESP header. The following diagram 299 illustrates ESP transport mode positioning for a typical IPv6 packet. 301 Security Payload (ESP) 303 BEFORE APPLYING ESP 304 --------------------------------------- 305 IPv6 | | ext hdrs | | | 306 | orig IP hdr |if present| TCP | Data | 307 --------------------------------------- 309 AFTER APPLYING ESP 310 --------------------------------------------------------- 311 IPv6 | orig |hxh,rtg,frag|dest| |dest| | | ESP | ESP| 312 |IP hdr|if present**|opt*|ESP|opt*|TCP|Data|Trailer|Auth| 313 --------------------------------------------------------- 314 |<---- encrypted ---->| 315 |<---- authenticated ---->| 317 * = if present, could be before AH, after AH, or both 318 ** = hop by hop, routing, fragmentation headers 320 Tunnel mode ESP may be employed in either hosts or security gateways. 321 When ESP is implemented in a security gateway (to protect subscriber 322 transit traffic), tunnel mode must be used. In tunnel mode, the 323 "inner" IP header carries the ultimate source and destination 324 addresses, while an "outer" IP header may contain distinct IP 325 addresses, e.g., addresses of security gateways. In tunnel mode, ESP 326 protects the entire inner IP packet, including the entire inner IP 327 header. The position of ESP in tunnel mode, relative to the outer IP 328 header, is the same as for ESP in transport mode. The following 329 diagram illustrates ESP tunnel mode positioning for typical IPv4 and 330 IPv6 packets. 332 ----------------------------------------------------------- 333 IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| 334 |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| 335 ----------------------------------------------------------- 336 |<--------- encrypted ---------->| 337 |<----------- authenticated ---------->| 339 --------------------------------------------------------------- 340 IPv6 | new* | ext hdrs*| | orig*| ext hdrs*| | | ESP | ESP| 341 |IP hdr|if present|ESP|IP hdr|if present|TCP|Data|Trailer|Auth| 342 --------------------------------------------------------------- 343 |<---------- encrypted ----------->| 344 |<----------- authenticated ---------->| 346 * = construction of outer IP hdr/extensions and modification 347 of inner IP hdr/extensions is discussed below. 349 Security Payload (ESP) 351 3.2 Outbound Packet Processing 353 In transport mode, the transmitter encapsulates the upper layer 354 protocol information in the ESP header/trailer, and retains the 355 specified IP header (and any IP extension headers in the IPv6 356 context). In tunnel mode, the outer and inner IP header/extensions 357 can be inter-related in a variety of ways. The construction of the 358 outer IP header/extensions during the encapsulation process is 359 described in the document, "Security Architecture for the Internet 360 Protocol". 362 3.2.1 Security Association Lookup 364 ESP is applied to an outbound packet only after an IPsec 365 implementation determines that the packet is associated with an SA 366 that calls for ESP processing. The process of determining what, if 367 any, IPsec processing is applied to outbound traffic is described in 368 the document, "Security Architecture for the Internet Protocol". 370 3.2.2 Anti-replay Service 372 If the anti-replay service has been selected for this SA, the 373 transmitter increments the Sequence Number for this SA, checks to 374 ensure that the counter has not cycled, and inserts the new value 375 into the Sequence Number field. A transmitter MUST NOT send a packet 376 on an SA if doing so would cause the Sequence Number to cycle. 378 As mentioned in section 2.2, the anti-replay service requires the 379 selection of the authentication services thus the Sequence Number 380 field MUST NOT be present in the absence of the Authentication Data 381 field (described below.) 383 3.2.3 Packet Encryption 385 3.2.3.1 Scope of Encryption 387 In transport mode, if encryption has been selected, the transmitter 388 encapsulates the original upper layer protocol information into the 389 ESP payload field, adds any necessary padding, and encrypts the 390 result (Payload Data, Padding, Pad Length, and Next Header) using the 391 key, encryption algorithm, and algorithm mode indicated by the SA. 392 In tunnel mode, the transmitter encapsulates and encrypts the the 393 entire original IP datagram (plus the Padding, Pad Length, and Next 394 Header). 396 If both encryption and authentication have been selected, encryption 397 is performed first, before the authentication and the encryption does 398 Security Payload (ESP) 400 not encompass the Authentication Data field. This order of 401 processing facilitates rapid detection and rejection of replayed or 402 bogus packets by the receiver, prior to decrypting the packet, hence 403 potentially reducing the impact of denial of service attacks. It 404 also allows for the possibility of parallel processing of packets at 405 the receiver, i.e., decryption can take place in parallel with 406 authentication. Note that since the Authentication Data is not 407 protected by encryption, a keyed authentication algorithm must be 408 employed to compute the ICV. 410 3.2.3.2 Encryption Algorithms 412 If confidentiality is selected, the encryption algorithm employed is 413 specified by the SA. ESP is designed for use with symmetric 414 encryption algorithms. Because IP packets may arrive out of order, 415 each packet must carry either an explicit Initialization Vector (IV) 416 that allows the receiver to establish cryptographic synchronization 417 for decryption, or data derived from the packet header must suffice 418 to generate an IV at the receiver. Since ESP makes provision for 419 padding of the plaintext, encryption algorithms employed with ESP may 420 exhibit either block or stream mode characteristics. 422 At the time of writing, one mandatory-to-implement encryption 423 algorithm and mode has been defined for ESP. It is based on the Data 424 Encryption Standard (DES) [NIST77] in Cipher Block Chaining Mode 425 [NIST80]. Details of use of this mode are contained in [need a new 426 I-D with DES-CBC and implicit IV generation, but no overlap with this 427 document]. 429 3.2.4 Integrity Check Value Calculation 431 3.2.4.1 Scope of Authentication Protection 433 If authentication is selected for the SA, the transmitter computes 434 the ICV over the ESP packet minus the Authentication Data. Thus the 435 SPI, Sequence Number (if present), Initialization Vector (if 436 present), Payload Data, Padding (if present), Pad Length, and Next 437 Header are all encompassed by the ICV computation. If encryption has 438 been selected, the last 4 fields will be in ciphertext form. 440 3.2.4.2 Authentication Padding 442 For some authentication algorithms, the byte string over which the 443 ICV computation is performed must be a multiple of a blocksize 444 specified by the algorithm. If the length of this byte string does 445 not match the blocksize requirements for the algorithm, implicit 446 padding MUST be appended to the end of the ESP packet, prior to ICV 447 Security Payload (ESP) 449 computation. The padding octets MUST have a value of zero. The 450 blocksize (and hence the length of the padding) is specified by the 451 algorithm specification. This padding is not transmitted with the 452 packet. 454 3.2.4.3 Authentication Algorithms 456 The authentication algorithm employed for the ICV computation is 457 specified by the SA. For point-to-point communication, suitable 458 authentication algorithms include keyed Message Authentication Codes 459 (MACs) based on symmetric encryption algorithms (e.g., DES) or on 460 one-way hash functions (e.g., MD5 or SHA-1). For multicast 461 communication, one-way hash algorithms combined with asymmetric 462 signature algorithms are suitable. As of this writing, the 463 mandatory-to-implement authentication algorithms are based on the 464 former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or HMAC with MD5 465 [Riv92]. The output of the HMAC computation is truncated to (the 466 leftmost) 96 bits. Other algorithms, possibly with different ICV 467 lengths, MAY be supported. 469 3.2.5 Fragmentation 471 If necessary, fragmentation is performed after ESP processing within 472 an IPsec implementation. However, an IP packet to which ESP has been 473 applied may itself be fragmented by routers en route, including 474 security gateways that may apply AH or ESP (tunnel mode) to the 475 already-protected packet or fragments. 477 3.3 Inbound Packet Processing 479 3.3.1 Pre-ESP Processing Overview 481 If required, reassembly is performed prior to ESP processing. 483 3.3.2 Security Association Lookup 485 Upon receipt of a (reassembled) packet containing an ESP Header, the 486 receiver determines the appropriate (unidirectional) SA, based on the 487 destination IP address and the SPI. (This process is described in 488 more detail in the document, "Security Architecture for the Internet 489 Protocol".) The SA indicates whether the Sequence Number, 490 Initialization Vector, and Authentication Data fields should be 491 present, and it will specify the algorithms and keys to be employed 492 for decryption and ICV computations (if applicable). 494 If no valid Security Association exists for this session (for 495 example, the receiver has no key), the receiver MUST discard the 496 Security Payload (ESP) 498 packet and the failure MUST be recorded in an audit log. The log 499 entry MUST include the SPI value, date/time, Source Address, 500 Destination Address, and (in IPv6) the cleartext Flow ID. The log 501 entry MAY also include other identifying data. There is no 502 requirement for the receiver to transmit any message to the purported 503 transmitter in response to receipt of such packets (because of the 504 potential to induce denial of service via such actions). 506 3.3.3 Anti-replay Service 508 If the anti-replay service has been selected for this SA, the 509 receiver MUST verify that the packet contains a Sequence Number value 510 that does not duplicate the Sequence Number of any other packet 511 received during the life of this SA. This SHOULD be the first AH 512 check applied to a packet after it has been matched to an SA, to 513 speed rejection of duplicate packets. 515 Duplicates are rejected through the use of a sliding receive window. 516 (How the window is implemented is a local matter, but the following 517 text describes the functionality that the implementation must 518 exhibit.) The default window size is 32 and all AH implementations 519 MUST support this window size. A larger window size MAY be 520 established during SA negotiation. If a larger window size is 521 negotiated it MUST be a multiple of 32. 523 The "right" edge of the window represents the highest, validated 524 Reply Protection value received on this SA. Packets that contain 525 Sequence Numbers lower than the "left" edge of the window are 526 rejected. Packets falling within the window are checked against a 527 list of received packets within the window. An efficient means for 528 performing this check, based on the use of a bit mask, is described 529 in [KA97a]. 531 If the received packet falls within the window, then the receiver 532 proceeds to ICV verification. If the ICV validation fails, the 533 receiver MUST discard the received IP datagram as invalid and MUST 534 record the authentication failure in an audit log. If such a failure 535 occurs, the log entry MUST include the SPI value, date/time received, 536 Sending Address, Destination Address, and (in IPv6) Flow ID. The log 537 data MAY also include other information about the failed packet. The 538 window is updated only if the ICV verification succeeds. 540 DISCUSSION: 542 Note that if the packet is either inside the window and new, or 543 outside the window on the "right" side, the receiver MUST 544 authenticate the Sequence Number before updating the Sequence 545 Security Payload (ESP) 547 Number window data. 549 3.3.4 Integrity Check Value Verification 551 If authentication has been selected, the receiver computes the ICV 552 over the ESP packet minus the Authentication Data using the specified 553 authentication algorithm and verifies that it is the same as the ICV 554 included in the Authentication Data field of the packet. Details of 555 the computation are provided below. 557 If the computed and received ICV's match, then the datagram is valid, 558 and it is accepted. If the test fails, then the receiver MUST 559 discard the received IP datagram as invalid and MUST record the 560 authentication failure in an audit log. The log data MUST include the 561 SPI value, date/time received, Source Address, Destination Address, 562 and (in IPv6) the clear-text Flow ID. The log data MAY also include 563 other information about the failed packet. 565 DISCUSSION: 567 Begin by removing and saving the ICV value (Authentication Data 568 field). Next check the overall length of the ESP packet minus the 569 Authentication Data. If implicit padding is required, based on 570 the blocksize of the authentication algorithm, append zero-filled 571 bytes to the end of the ESP packet directly after the Next Header 572 field. Perform the ICV computation and compare the result with 573 the received value. (If a digital signature and one-way hash are 574 used for the ICV computation, the matching process is more complex 575 and will be described in the algorithm specification.) 577 3.3.5 Packet Decryption 579 If data confidentiality was selected, the receiver decrypts the ESP 580 Payload Data, Padding, Pad Length, and Next Header using the session 581 key that has been established for this traffic. If an explicit IV is 582 present, it is input to the decryption algorithm as per the algorithm 583 specification. If an implicit IV is employed, a local version of the 584 IV is constructed and input to the decryption algorithm as per the 585 algorithm specification. (Decryption may take place in parallel with 586 authentication, but care must be taken to avoid possible race 587 conditions with regard to packet access and reconstruction of the 588 decrypted packet.) 590 After decryption, the original IP datagram is reconstructed and 591 processed per the normal IP protocol specification. The exact steps 592 for reconstructing the original datagram depend on the mode (tunnel 593 Security Payload (ESP) 595 vs transport) and are described in the document, "Security 596 Architecture for the Internet Protocol." 598 Note that there are two ways in which the decryption can "fail". The 599 selected SA may not be correct or the encrypted ESP packet could be 600 corrupted. (The latter case would be detected if authentication is 601 selected for the SA, as would tampering with the SPI. However, an SA 602 mismatch might still occur due to tampering with the IP Destination 603 Address.) In either case, the erroneous result of the decryption 604 operation (an invalid IP datagram or transport-layer frame) will not 605 necessarily be detected by IPsec, and is the responsibility of later 606 protocol processing. 608 4. Conformance Requirements 610 Implementations that claim conformance or compliance with this 611 specification MUST implement the ESP syntax and processing described 612 here and MUST comply with all requirements of the "Security 613 Architecture for the Internet Protocol." Note that support for 614 manual key distribution is required, but its use is inconsistent with 615 anti-replay service, and thus a compliant implementation must not 616 negotiate this service in conjunction with SAs that are manually 617 keyed. A compliant ESP implementation MUST support the following 618 mandatory-to-implement algorithms (specified in [KBC97] and in [need 619 a new I-D with DES-CBC and implicit IV generation, but no overlap 620 with this document]. 622 - DES in CBC mode 623 - HMAC with MD5 624 - HMAC with SHA-1 626 5. Security Considerations 628 Security is central to the design of this protocol, and this security 629 considerations permeate the specification. Additional security- 630 relevant aspects of using IPsec protocol are discussed in the 631 document, "Security Architecture for the Internet Protocol". 633 Acknowledgements 635 Many of the concepts embodied in this specification were derived from 636 or influenced by the US Government's SP3 security protocol, ISO/IEC's 637 NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92 638 IB93]. 640 For over 2 years, this document has evolved through multiple versions 641 Security Payload (ESP) 643 and iterations. During this time, many people have contributed 644 significant ideas and energy to the process and the documents 645 themselves. The authors would like to thank the members of the IPSEC 646 and IPng working groups, with special mention of the efforts of (in 647 alphabetic order): Steve Bellovin, Steve Deering, Phil Karn, Perry 648 Metzger, David Mihelcic, Hilarie Orman, and William Simpson. In 649 addition, Charlie Lynn, Karen Seo, and Nina Yuan provided extensive 650 help in the review and editing of this version of the specification. 652 References 654 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP 655 Protocol Suite", ACM Computer Communications Review, Vol. 656 19, No. 2, March 1989. 658 [CERT95] Computer Emergency Response Team (CERT), "IP Spoofing 659 Attacks and Hijacked Terminal Connections", CA-95:01, 660 January 1995. Available via anonymous ftp from 661 info.cert.org. 663 [DH95] Steve Deering & Robert Hinden, Internet Protocol Version 6 664 (Ipv6) Specification, RFC 1883, December 1995. 666 [IB93] John Ioannidis & Matt Blaze, "Architecture and 667 Implementation of Network-layer Security Under Unix", 668 Proceedings of the USENIX Security Symposium, Santa Clara, 669 CA, October 1993. 671 [ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 672 DIS 11577, International Standards Organisation, Geneva, 673 Switzerland, 29 November 1992. 675 [KBC97] Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC: 676 Keyed-Hashing for Message Authentication", RFC-2104, 677 February 1997. 679 [Ken91] Steve Kent, "US DoD Security Options for the Internet 680 Protocol (IPSO)", RFC-1108, November 1991. 682 [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for 683 the Internet Protocol", Internet Draft, ?? 1997. 685 [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", 686 Internet Draft, March 1997. 688 [MS95] Perry Metzger & W.A. Simpson, "The ESP DES-CBC Transform", 689 RFC-1829, August 1995. 691 Security Payload (ESP) 693 [NIST77] US National Bureau of Standards, "Data Encryption 694 Standard", Federal Information Processing Standard (FIPS) 695 Publication 46, January 1977. 697 [NIST80] US National Bureau of Standards, "DES Modes of Operation" 698 Federal Information Processing Standard (FIPS) Publication 699 81, December 1980. 701 [NIST81] US National Bureau of Standards, "Guidelines for 702 Implementing and Using the Data Encryption Standard", 703 Federal Information Processing Standard (FIPS) Publication 704 74, April 1981. 706 [NIST88] US National Bureau of Standards, "Data Encryption 707 Standard", Federal Information Processing Standard (FIPS) 708 Publication 46-1, January 1988. 710 [Riv92] Ronald Rivest, MD5 Digest Algorithm, RFC-1321, April 1992. 712 [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995 714 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 715 October 1994. 717 [Sch94] Bruce Schneier, Applied Cryptography, John Wiley & Sons, 718 New York, NY, 1994. ISBN 0-471-59756-2 720 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, 721 Document SDN.301, Revision 1.5, 15 May 1989, as published 722 in NIST Publication NIST-IR-90-4250, February 1990. 724 Security Payload (ESP) 726 Disclaimer 728 The views and specification here are those of the authors and are not 729 necessarily those of their employers. The authors and their 730 employers specifically disclaim responsibility for any problems 731 arising from correct or incorrect implementation or use of this 732 specification. 734 Author Information 736 Stephen Kent 737 BBN Corporation 738 70 Fawcett Street 739 Cambridge, MA 02140 740 USA 741 Telephone: +1 (617) 873-3988 743 Randall Atkinson 744 @Home Network 745 385 Ravendale Drive 746 Mountain View, CA 94043 747 USA