idnits 2.17.1 draft-ietf-ipsec-esp-v2-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 83 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 82 has weird spacing: '... before an en...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 1998) is 9468 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: 'IB93' is defined on line 924, but no explicit reference was found in the text == Unused Reference: 'ISO92' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'SDNS89' is defined on line 953, 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. 'Bel96' -- Possible downref: Non-RFC (?) normative reference: ref. 'HC98' -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'MD97' -- Possible downref: Non-RFC (?) normative reference: ref. 'MG97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'MG97b' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS89' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 13 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-05.txt May 1998 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 Copyright (C) The Internet Society (May 1998). All Rights Reserved. 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....................................5 34 2.2 Sequence Number .............................................5 35 2.3 Payload Data.................................................6 36 2.4 Padding (for Encryption).....................................6 37 2.5 Pad Length...................................................7 38 2.6 Next Header..................................................8 39 2.7 Authentication Data..........................................8 40 3. Encapsulating Security Protocol Processing........................8 41 3.1 ESP Header Location..........................................8 42 3.2 Algorithms..................................................10 43 3.2.1 Encryption Algorithms..................................10 44 3.2.2 Authentication Algorithms..............................11 45 3.3 Outbound Packet Processing..................................11 46 3.3.1 Security Association Lookup............................11 47 3.3.2 Packet Encryption......................................11 48 3.3.3 Sequence Number Generation.............................12 49 3.3.4 Integrity Check Value Calculation......................13 50 3.3.5 Fragmentation..........................................13 51 3.4 Inbound Packet Processing...................................14 52 3.4.1 Reassembly.............................................14 53 3.4.2 Security Association Lookup............................14 54 3.4.3 Sequence Number Verification...........................14 55 3.4.4 Integrity Check Value Verification.....................16 56 3.4.5 Packet Decryption......................................16 57 4. Auditing.........................................................18 58 5. Conformance Requirements.........................................18 59 6. Security Considerations..........................................19 60 7. Differences from RFC 1827........................................19 61 Acknowledgements....................................................20 62 References..........................................................20 63 Disclaimer..........................................................21 64 Author Information..................................................21 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 (optional) confidentiality. The anti- 99 replay service may be selected only if data origin authentication is 100 selected, and its election is solely at the discretion of the 101 receiver. (Although the default calls for the sender to increment 102 the Sequence Number used for anti-replay, the service is effective 103 only if the receiver checks the Sequence Number.) Traffic flow 104 confidentiality requires selection of tunnel mode, and is most 105 effective if implemented at a security gateway, where traffic 106 aggregation may be able to mask true source-destination patterns. 107 Note that although both confidentiality and authentication are 108 optional, at least one of them MUST be selected. 110 It is assumed that the reader is familiar with the terms and concepts 111 described in the Security Architecture document. In particular, the 112 reader should be familiar with the definitions of security services 113 offered by ESP and AH, the concept of Security Associations, the ways 114 Security Payload (ESP) 116 in which ESP can be used in conjunction with the Authentication 117 Header (AH), and the different key management options available for 118 ESP and AH. (With regard to the last topic, the current key 119 management options required for both AH and ESP are manual keying and 120 automated keying via IKE [HC98].) 122 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 123 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 124 document, are to be interpreted as described in RFC 2119 [Bra97]. 126 2. Encapsulating Security Payload Packet Format 128 The protocol header (IPv4, IPv6, or Extension) immediately preceding the 129 ESP header will contain the value 50 in its Protocol (IPv4) or Next 130 Header (IPv6, Extension) field [STD-2]. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 135 | Security Parameters Index (SPI) | ^ 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Auth. 137 | Sequence Number | |Coverage 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----- 139 | Payload Data* (variable) | | ^ 140 ~ ~ | | 141 | | | | 142 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Confid. 143 | | Padding (0-255 bytes) | |Coverage* 144 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 145 | | Pad Length | Next Header | v v 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------- 147 | Authentication Data (variable) | 148 ~ ~ 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 * If included in the Payload field, cryptographic synchronization 153 data, e.g., an Initialization Vector (IV, see Section 2.3), 154 usually is not encrypted per se, although it often is referred to 155 as being part of the ciphertext. 157 The following subsections define the fields in the header format. 158 "Optional" means that the field is omitted if the option is not 159 selected, i.e., it is present in neither the packet as transmitted 160 nor as formatted for computation of an Integrity Check Value (ICV, 161 see Section 2.7). Whether or not an option is selected is defined as 162 Security Payload (ESP) 164 part of Security Association (SA) establishment. Thus the format of 165 ESP packets for a given SA is fixed, for the duration of the SA. In 166 contrast, "mandatory" fields are always present in the ESP packet 167 format, for all SAs. 169 2.1 Security Parameters Index 171 The SPI is an arbitrary 32-bit value that, in combination with the 172 destination IP address and security protocol (ESP), uniquely 173 identifies the Security Association for this datagram. The set of 174 SPI values in the range 1 through 255 are reserved by the Internet 175 Assigned Numbers Authority (IANA) for future use; a reserved SPI 176 value will not normally be assigned by IANA unless the use of the 177 assigned SPI value is specified in an RFC. It is ordinarily selected 178 by the destination system upon establishment of an SA (see the 179 Security Architecture document for more details). The SPI field is 180 mandatory. 182 The SPI value of zero (0) is reserved for local, implementation- 183 specific use and MUST NOT be sent on the wire. For example, a key 184 management implementation MAY use the zero SPI value to mean "No 185 Security Association Exists" during the period when the IPsec 186 implementation has requested that its key management entity establish 187 a new SA, but the SA has not yet been established. 189 2.2 Sequence Number 191 This unsigned 32-bit field contains a monotonically increasing 192 counter value (sequence number). It is mandatory and is always 193 present even if the receiver does not elect to enable the anti-replay 194 service for a specific SA. Processing of the Sequence Number field 195 is at the discretion of the receiver, i.e., the sender MUST always 196 transmit this field, but the receiver need not act upon it (see the 197 discussion of Sequence Number Verification in the "Inbound Packet 198 Processing" section below). 200 The sender's counter and the receiver's counter are initialized to 0 201 when an SA is established. (The first packet sent using a given SA 202 will have a Sequence Number of 1; see Section 3.3.3 for more details 203 on how the Sequence Number is generated.) If anti-replay is enabled 204 (the default), the transmitted Sequence Number must never be allowed 205 to cycle. Thus, the sender's counter and the receiver's counter MUST 206 be reset (by establishing a new SA and thus a new key) prior to the 207 transmission of the 2^32nd packet on an SA. 209 Security Payload (ESP) 211 2.3 Payload Data 213 Payload Data is a variable-length field containing data described by 214 the Next Header field. The Payload Data field is mandatory and is an 215 integral number of bytes in length. If the algorithm used to encrypt 216 the payload requires cryptographic synchronization data, e.g., an 217 Initialization Vector (IV), then this data MAY be carried explicitly 218 in the Payload field. Any encryption algorithm that requires such 219 explicit, per-packet synchronization data MUST indicate the length, 220 any structure for such data, and the location of this data as part of 221 an RFC specifying how the algorithm is used with ESP. If such 222 synchronization data is implicit, the algorithm for deriving the data 223 MUST be part of the RFC. 225 Note that with regard to ensuring the alignment of the (real) 226 ciphertext in the presence of an IV: 227 o For some IV-based modes of operation, the receiver treats the 228 IV as the start of the ciphertext, feeding it into the 229 algorithm directly. In these modes, alignment of the start of 230 the (real) ciphertext is not an issue at the receiver. 231 o In some cases, the receiver reads the IV in separately from 232 the ciphertext. In these cases, the algorithm specification 233 MUST address how alignment of the (real) ciphertext is to be 234 achieved. 236 2.4 Padding (for Encryption) 238 Several factors require or motivate use of the Padding field. 240 o If an encryption algorithm is employed that requires the 241 plaintext to be a multiple of some number of bytes, e.g., the 242 block size of a block cipher, the Padding field is used to 243 fill the plaintext (consisting of the Payload Data, Pad Length 244 and Next Header fields, as well as the Padding) to the size 245 required by the algorithm. 247 o Padding also may be required, irrespective of encryption 248 algorithm requirements, to ensure that the resulting 249 ciphertext terminates on a 4-byte boundary. Specifically, the 250 Pad Length and Next Header fields must be right aligned within 251 a 4-byte word, as illustrated in the ESP packet format figure 252 above, to ensure that the Authentication Data field (if 253 present) is aligned on a 4-byte boundary. 255 o Padding beyond that required for the algorithm or alignment 256 reasons cited above, may be used to conceal the actual length 257 of the payload, in support of (partial) traffic flow 258 Security Payload (ESP) 260 confidentiality. However, inclusion of such additional 261 padding has adverse bandwidth implications and thus its use 262 should be undertaken with care. 264 The sender MAY add 0-255 bytes of padding. Inclusion of the Padding 265 field in an ESP packet is optional, but all implementations MUST 266 support generation and consumption of padding. 268 a. For the purpose of ensuring that the bits to be encrypted are 269 a multiple of the algorithm's blocksize (first bullet above), 270 the padding computation applies to the Payload Data exclusive 271 of the IV, the Pad Length, and Next Header fields. 273 b. For the purposes of ensuring that the Authentication Data is 274 aligned on a 4-byte boundary (second bullet above), the 275 padding computation applies to the Payload Data inclusive of 276 the IV, the Pad Length, and Next Header fields. 278 If Padding bytes are needed but the encryption algorithm does not 279 specify the padding contents, then the following default processing 280 MUST be used. The Padding bytes are initialized with a series of 281 (unsigned, 1-byte) integer values. The first padding byte appended 282 to the plaintext is numbered 1, with subsequent padding bytes making 283 up a monotonically increasing sequence: 1, 2, 3, ... When this 284 padding scheme is employed, the receiver SHOULD inspect the Padding 285 field. (This scheme was selected because of its relative simplicity, 286 ease of implementation in hardware, and because it offers limited 287 protection against certain forms of "cut and paste" attacks in the 288 absence of other integrity measures, if the receiver checks the 289 padding values upon decryption.) 291 Any encryption algorithm that requires Padding other than the default 292 described above, MUST define the Padding contents (e.g., zeros or 293 random data) and any required receiver processing of these Padding 294 bytes in an RFC specifying how the algorithm is used with ESP. In 295 such circumstances, the content of the Padding field will be 296 determined by the encryption algorithm and mode selected and defined 297 in the corresponding algorithm RFC. The relevant algorithm RFC MAY 298 specify that a receiver MUST inspect the Padding field or that a 299 receiver MUST inform senders of how the receiver will handle the 300 Padding field. 302 2.5 Pad Length 304 The Pad Length field indicates the number of pad bytes immediately 305 preceding it. The range of valid values is 0-255, where a value of 306 Security Payload (ESP) 308 zero indicates that no Padding bytes are present. The Pad Length 309 field is mandatory. 311 2.6 Next Header 313 The Next Header is an 8-bit field that identifies the type of data 314 contained in the Payload Data field, e.g., an extension header in 315 IPv6 or an upper layer protocol identifier. The value of this field 316 is chosen from the set of IP Protocol Numbers defined in the most 317 recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned 318 Numbers Authority (IANA). The Next Header field is mandatory. 320 2.7 Authentication Data 322 The Authentication Data is a variable-length field containing an 323 Integrity Check Value (ICV) computed over the ESP packet minus the 324 Authentication Data. The length of the field is specified by the 325 authentication function selected. The Authentication Data field is 326 optional, and is included only if the authentication service has been 327 selected for the SA in question. The authentication algorithm 328 specification MUST specify the length of the ICV and the comparison 329 rules and processing steps for validation. 331 3. Encapsulating Security Protocol Processing 333 3.1 ESP Header Location 335 Like AH, ESP may be employed in two ways: transport mode or tunnel 336 mode. The former mode is applicable only to host implementations and 337 provides protection for upper layer protocols, but not the IP header. 338 (In this mode, note that for "bump-in-the-stack" or "bump-in-the- 339 wire" implementations, as defined in the Security Architecture 340 document, inbound and outbound IP fragments may require an IPsec 341 implementation to perform extra IP reassembly/fragmentation in order 342 to both conform to this specification and provide transparent IPsec 343 support. Special care is required to perform such operations within 344 these implementations when multiple interfaces are in use.) 346 In transport mode, ESP is inserted after the IP header and before an 347 upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other 348 IPsec headers that have already been inserted. In the context of 349 IPv4, this translates to placing ESP after the IP header (and any 350 options that it contains), but before the upper layer protocol. 351 (Note that the term "transport" mode should not be misconstrued as 352 restricting its use to TCP and UDP. For example, an ICMP message MAY 353 be sent using either "transport" mode or "tunnel" mode.) The 354 following diagram illustrates ESP transport mode positioning for a 355 Security Payload (ESP) 357 typical IPv4 packet, on a "before and after" basis. (The "ESP 358 trailer" encompasses any Padding, plus the Pad Length, and Next 359 Header fields.) 361 BEFORE APPLYING ESP 362 ---------------------------- 363 IPv4 |orig IP hdr | | | 364 |(any options)| TCP | Data | 365 ---------------------------- 367 AFTER APPLYING ESP 368 ------------------------------------------------- 369 IPv4 |orig IP hdr | ESP | | | ESP | ESP| 370 |(any options)| Hdr | TCP | Data | Trailer |Auth| 371 ------------------------------------------------- 372 |<----- encrypted ---->| 373 |<------ authenticated ----->| 375 In the IPv6 context, ESP is viewed as an end-to-end payload, and thus 376 should appear after hop-by-hop, routing, and fragmentation extension 377 headers. The destination options extension header(s) could appear 378 either before or after the ESP header depending on the semantics 379 desired. However, since ESP protects only fields after the ESP 380 header, it generally may be desirable to place the destination 381 options header(s) after the ESP header. The following diagram 382 illustrates ESP transport mode positioning for a typical IPv6 packet. 384 BEFORE APPLYING ESP 385 --------------------------------------- 386 IPv6 | | ext hdrs | | | 387 | orig IP hdr |if present| TCP | Data | 388 --------------------------------------- 390 AFTER APPLYING ESP 391 --------------------------------------------------------- 392 IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| 393 |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth| 394 --------------------------------------------------------- 395 |<---- encrypted ---->| 396 |<---- authenticated ---->| 398 * = if present, could be before ESP, after ESP, or both 400 ESP and AH headers can be combined in a variety of modes. The IPsec 401 Architecture document describes the combinations of security 402 associations that must be supported. 404 Security Payload (ESP) 406 Tunnel mode ESP may be employed in either hosts or security gateways. 407 When ESP is implemented in a security gateway (to protect subscriber 408 transit traffic), tunnel mode must be used. In tunnel mode, the 409 "inner" IP header carries the ultimate source and destination 410 addresses, while an "outer" IP header may contain distinct IP 411 addresses, e.g., addresses of security gateways. In tunnel mode, ESP 412 protects the entire inner IP packet, including the entire inner IP 413 header. The position of ESP in tunnel mode, relative to the outer IP 414 header, is the same as for ESP in transport mode. The following 415 diagram illustrates ESP tunnel mode positioning for typical IPv4 and 416 IPv6 packets. 418 ----------------------------------------------------------- 419 IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP| 420 |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth| 421 ----------------------------------------------------------- 422 |<--------- encrypted ---------->| 423 |<----------- authenticated ---------->| 425 ------------------------------------------------------------ 426 IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP| 427 |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth| 428 ------------------------------------------------------------ 429 |<--------- encrypted ----------->| 430 |<---------- authenticated ---------->| 432 * = if present, construction of outer IP hdr/extensions and 433 modification of inner IP hdr/extensions is discussed 434 below. 436 3.2 Algorithms 438 The mandatory-to-implement algorithms are described in Section 5, 439 "Conformance Requirements". Other algorithms MAY be supported. Note 440 that although both confidentiality and authentication are optional, 441 at least one of these services MUST be selected hence both algorithms 442 MUST NOT be simultaneously NULL. 444 3.2.1 Encryption Algorithms 446 The encryption algorithm employed is specified by the SA. ESP is 447 designed for use with symmetric encryption algorithms. Because IP 448 packets may arrive out of order, each packet must carry any data 449 required to allow the receiver to establish cryptographic 450 synchronization for decryption. This data may be carried explicitly 451 in the payload field, e.g., as an IV (as described above), or the 452 data may be derived from the packet header. Since ESP makes 453 Security Payload (ESP) 455 provision for padding of the plaintext, encryption algorithms 456 employed with ESP may exhibit either block or stream mode 457 characteristics. Note that since encryption (confidentiality) is 458 optional, this algorithm may be "NULL". 460 3.2.2 Authentication Algorithms 462 The authentication algorithm employed for the ICV computation is 463 specified by the SA. For point-to-point communication, suitable 464 authentication algorithms include keyed Message Authentication Codes 465 (MACs) based on symmetric encryption algorithms (e.g., DES) or on 466 one-way hash functions (e.g., MD5 or SHA-1). For multicast 467 communication, one-way hash algorithms combined with asymmetric 468 signature algorithms are appropriate, though performance and space 469 considerations currently preclude use of such algorithms. Note that 470 since authentication is optional, this algorithm may be "NULL". 472 3.3 Outbound Packet Processing 474 In transport mode, the sender encapsulates the upper layer protocol 475 information in the ESP header/trailer, and retains the specified IP 476 header (and any IP extension headers in the IPv6 context). In tunnel 477 mode, the outer and inner IP header/extensions can be inter-related 478 in a variety of ways. The construction of the outer IP 479 header/extensions during the encapsulation process is described in 480 the Security Architecture document. If there is more than one IPsec 481 header/extension required by security policy, the order of the 482 application of the security headers MUST be defined by security 483 policy. 485 3.3.1 Security Association Lookup 487 ESP is applied to an outbound packet only after an IPsec 488 implementation determines that the packet is associated with an SA 489 that calls for ESP processing. The process of determining what, if 490 any, IPsec processing is applied to outbound traffic is described in 491 the Security Architecture document. 493 3.3.2 Packet Encryption 495 In this section, we speak in terms of encryption always being applied 496 because of the formatting implications. This is done with the 497 understanding that "no confidentiality" is offered by using the NULL 498 encryption algorithm. Accordingly, the sender: 499 1. encapsulates (into the ESP Payload field): 500 - for transport mode -- just the original upper layer 501 protocol information. 503 Security Payload (ESP) 505 - for tunnel mode -- the entire original IP datagram. 506 2. adds any necessary padding. 507 3. encrypts the result (Payload Data, Padding, Pad Length, and 508 Next Header) using the key, encryption algorithm, algorithm 509 mode indicated by the SA and cryptographic synchronization 510 data (if any). 511 - If explicit cryptographic synchronization data, e.g., 512 an IV, is indicated, it is input to the encryption 513 algorithm per the algorithm specification and placed 514 in the Payload field. 515 - If implicit cryptographic synchronication data, e.g., 516 an IV, is indicated, it is constructed and input to 517 the encryption algorithm as per the algorithm 518 specification. 520 The exact steps for constructing the outer IP header depend on the 521 mode (transport or tunnel) and are described in the Security 522 Architecture document. 524 If authentication is selected, encryption is performed first, before 525 the authentication, and the encryption does not encompass the 526 Authentication Data field. This order of processing facilitates 527 rapid detection and rejection of replayed or bogus packets by the 528 receiver, prior to decrypting the packet, hence potentially reducing 529 the impact of denial of service attacks. It also allows for the 530 possibility of parallel processing of packets at the receiver, i.e., 531 decryption can take place in parallel with authentication. Note that 532 since the Authentication Data is not protected by encryption, a keyed 533 authentication algorithm must be employed to compute the ICV. 535 3.3.3 Sequence Number Generation 537 The sender's counter is initialized to 0 when an SA is established. 538 The sender increments the Sequence Number for this SA and inserts the 539 new value into the Sequence Number field. Thus the first packet sent 540 using a given SA will have a Sequence Number of 1. 542 If anti-replay is enabled (the default), the sender checks to ensure 543 that the counter has not cycled before inserting the new value in the 544 Sequence Number field. In other words, the sender MUST NOT send a 545 packet on an SA if doing so would cause the Sequence Number to cycle. 546 An attempt to transmit a packet that would result in Sequence Number 547 overflow is an auditable event. (Note that this approach to Sequence 548 Number management does not require use of modular arithmetic.) 550 The sender assumes anti-replay is enabled as a default, unless 551 otherwise notified by the receiver (see 3.4.3). Thus, if the counter 552 Security Payload (ESP) 554 has cycled, the sender will set up a new SA and key (unless the SA 555 was configured with manual key management). 557 If anti-replay has been disabled, the sender does not need to monitor 558 or reset the counter, e.g., in the case of manual key management (see 559 Section 5). 561 3.3.4 Integrity Check Value Calculation 563 If authentication is selected for the SA, the sender computes the ICV 564 over the ESP packet minus the Authentication Data. Thus the SPI, 565 Sequence Number, Payload Data, Padding (if present), Pad Length, and 566 Next Header are all encompassed by the ICV computation. Note that 567 the last 4 fields will be in ciphertext form, since encryption is 568 performed prior to authentication. 570 For some authentication algorithms, the byte string over which the 571 ICV computation is performed must be a multiple of a blocksize 572 specified by the algorithm. If the length of this byte string does 573 not match the blocksize requirements for the algorithm, implicit 574 padding MUST be appended to the end of the ESP packet, (after the 575 Next Header field) prior to ICV computation. The padding octets MUST 576 have a value of zero. The blocksize (and hence the length of the 577 padding) is specified by the algorithm specification. This padding 578 is not transmitted with the packet. Note that MD5 and SHA-1 are 579 viewed as having a 1-byte blocksize because of their internal padding 580 conventions. 582 3.3.5 Fragmentation 584 If necessary, fragmentation is performed after ESP processing within 585 an IPsec implementation. Thus, transport mode ESP is applied only to 586 whole IP datagrams (not to IP fragments). An IP packet to which ESP 587 has been applied may itself be fragmented by routers en route, and 588 such fragments must be reassembled prior to ESP processing at a 589 receiver. In tunnel mode, ESP is applied to an IP packet, the 590 payload of which may be a fragmented IP packet. For example, a 591 security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec 592 implementation (as defined in the Security Architecture document) may 593 apply tunnel mode ESP to such fragments. 595 NOTE: For transport mode -- As mentioned at the beginning of Section 596 3.1, bump-in-the-stack and bump-in-the-wire implementations may have 597 to first reassemble a packet fragmented by the local IP layer, then 598 apply IPsec, and then fragment the resulting packet. 600 Security Payload (ESP) 602 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire 603 implementations, it will be necessary to walk through all the 604 extension headers to determine if there is a fragmentation header and 605 hence that the packet needs reassembling prior to IPsec processing. 607 3.4 Inbound Packet Processing 609 3.4.1 Reassembly 611 If required, reassembly is performed prior to ESP processing. If a 612 packet offered to ESP for processing appears to be an IP fragment, 613 i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set, 614 the receiver MUST discard the packet; this is an auditable event. The 615 audit log entry for this event SHOULD include the SPI value, 616 date/time received, Source Address, Destination Address, Sequence 617 Number, and (in IPv6) the Flow ID. 619 NOTE: For packet reassembly, the current IPv4 spec does NOT require 620 either the zero'ing of the OFFSET field or the clearing of the MORE 621 FRAGMENTS flag. In order for a reassembled packet to be processed by 622 IPsec (as opposed to discarded as an apparent fragment), the IP code 623 must do these two things after it reassembles a packet. 625 3.4.2 Security Association Lookup 627 Upon receipt of a (reassembled) packet containing an ESP Header, the 628 receiver determines the appropriate (unidirectional) SA, based on the 629 destination IP address, security protocol (ESP), and the SPI. (This 630 process is described in more detail in the Security Architecture 631 document.) The SA indicates whether the Sequence Number field will 632 be checked, whether the Authentication Data field should be present, 633 and it will specify the algorithms and keys to be employed for 634 decryption and ICV computations (if applicable). 636 If no valid Security Association exists for this session (for 637 example, the receiver has no key), the receiver MUST discard the 638 packet; this is an auditable event. The audit log entry for this 639 event SHOULD include the SPI value, date/time received, Source 640 Address, Destination Address, Sequence Number, and (in IPv6) the 641 cleartext Flow ID. 643 3.4.3 Sequence Number Verification 645 All ESP implementations MUST support the anti-replay service, though 646 its use may be enabled or disabled by the receiver on a per-SA basis. 648 Security Payload (ESP) 650 This service MUST NOT be enabled unless the authentication service 651 also is enabled for the SA, since otherwise the Sequence Number field 652 has not been integrity protected. (Note that there are no provisions 653 for managing transmitted Sequence Number values among multiple 654 senders directing traffic to a single SA (irrespective of whether the 655 destination address is unicast, broadcast, or multicast). Thus the 656 anti-replay service SHOULD NOT be used in a multi-sender environment 657 that employs a single SA.) 659 If the receiver does not enable anti-replay for an SA, no inbound 660 checks are performed on the Sequence Number. However, from the 661 perspective of the sender, the default is to assume that anti-replay 662 is enabled at the receiver. To avoid having the sender do 663 unnecessary sequence number monitoring and SA setup (see section 664 3.3.3), if an SA establishment protocol such as IKE is employed, the 665 receiver SHOULD notify the sender, during SA establishment, if the 666 receiver will not provide anti-replay protection. 668 If the receiver has enabled the anti-replay service for this SA, the 669 receive packet counter for the SA MUST be initialized to zero when 670 the SA is established. For each received packet, the receiver MUST 671 verify that the packet contains a Sequence Number that does not 672 duplicate the Sequence Number of any other packets received during 673 the life of this SA. This SHOULD be the first ESP check applied to a 674 packet after it has been matched to an SA, to speed rejection of 675 duplicate packets. 677 Duplicates are rejected through the use of a sliding receive window. 678 (How the window is implemented is a local matter, but the following 679 text describes the functionality that the implementation must 680 exhibit.) A MINIMUM window size of 32 MUST be supported; but a 681 window size of 64 is preferred and SHOULD be employed as the default. 682 Another window size (larger than the MINIMUM) MAY be chosen by the 683 receiver. (The receiver does NOT notify the sender of the window 684 size.) 686 The "right" edge of the window represents the highest, validated 687 Sequence Number value received on this SA. Packets that contain 688 Sequence Numbers lower than the "left" edge of the window are 689 rejected. Packets falling within the window are checked against a 690 list of received packets within the window. An efficient means for 691 performing this check, based on the use of a bit mask, is described 692 in the Security Architecture document. 694 If the received packet falls within the window and is new, or if the 695 packet is to the right of the window, then the receiver proceeds to 696 ICV verification. If the ICV validation fails, the receiver MUST 697 Security Payload (ESP) 699 discard the received IP datagram as invalid; this is an auditable 700 event. The audit log entry for this event SHOULD include the SPI 701 value, date/time received, Source Address, Destination Address, the 702 Sequence Number, and (in IPv6) the Flow ID. The receive window is 703 updated only if the ICV verification succeeds. 705 DISCUSSION: 707 Note that if the packet is either inside the window and new, or is 708 outside the window on the "right" side, the receiver MUST 709 authenticate the packet before updating the Sequence Number window 710 data. 712 3.4.4 Integrity Check Value Verification 714 If authentication has been selected, the receiver computes the ICV 715 over the ESP packet minus the Authentication Data using the specified 716 authentication algorithm and verifies that it is the same as the ICV 717 included in the Authentication Data field of the packet. Details of 718 the computation are provided below. 720 If the computed and received ICV's match, then the datagram is valid, 721 and it is accepted. If the test fails, then the receiver MUST 722 discard the received IP datagram as invalid; this is an auditable 723 event. The log data SHOULD include the SPI value, date/time 724 received, Source Address, Destination Address, the Sequence Number, 725 and (in IPv6) the cleartext Flow ID. 727 DISCUSSION: 729 Begin by removing and saving the ICV value (Authentication Data 730 field). Next check the overall length of the ESP packet minus the 731 Authentication Data. If implicit padding is required, based on 732 the blocksize of the authentication algorithm, append zero-filled 733 bytes to the end of the ESP packet directly after the Next Header 734 field. Perform the ICV computation and compare the result with 735 the saved value, using the comparison rules defined by the 736 algorithm specification. (For example, if a digital signature and 737 one-way hash are used for the ICV computation, the matching 738 process is more complex.) 740 3.4.5 Packet Decryption 742 As in section 3.3.2, "Packet Encryption", we speak here in terms of 743 encryption always being applied because of the formatting 744 implications. This is done with the understanding that "no 745 Security Payload (ESP) 747 confidentiality" is offered by using the NULL encryption algorithm. 748 Accordingly, the receiver: 750 1. decrypts the ESP Payload Data, Padding, Pad Length, and Next 751 Header using the key, encryption algorithm, algorithm mode, 752 and cryptographic synchronization data (if any), indicated by 753 the SA. 754 - If explicit cryptographic synchronization data, e.g., 755 an IV, is indicated, it is taken from the Payload 756 field and input to the decryption algorithm as per the 757 algorithm specification. 758 - If implicit cryptographic synchronization data, e.g., 759 an IV, is indicated, a local version of the IV is 760 constructed and input to the decryption algorithm as 761 per the algorithm specification. 762 2. processes any padding as specified in the encryption 763 algorithm specification. If the default padding scheme (see 764 Section 2.4) has been employed, the receiver SHOULD inspect 765 the Padding field before removing the padding prior to 766 passing the decrypted data to the next layer. 767 3. reconstructs the original IP datagram from: 768 - for transport mode -- original IP header plus the 769 original upper layer protocol information in the ESP 770 Payload field 771 - for tunnel mode -- tunnel IP header + the entire IP 772 datagram in the ESP Payload field. 774 The exact steps for reconstructing the original datagram depend on 775 the mode (transport or tunnel) and are described in the Security 776 Architecture document. At a minimum, in an IPv6 context, the 777 receiver SHOULD ensure that the decrypted data is 8-byte aligned, to 778 facilitate processing by the protocol identified in the Next Header 779 field. 781 If authentication has been selected, verification and decryption MAY 782 be performed serially or in parallel. If performed serially, then 783 ICV verification SHOULD be performed first. If performed in 784 parallel, verification MUST be completed before the decrypted packet 785 is passed on for further processing. This order of processing 786 facilitates rapid detection and rejection of replayed or bogus 787 packets by the receiver, prior to decrypting the packet, hence 788 potentially reducing the impact of denial of service attacks. Note: 789 If the receiver performs decryption in parallel with authentication, 790 care must be taken to avoid possible race conditions with regard to 791 packet access and reconstruction of the decrypted packet. 793 Note that there are several ways in which the decryption can "fail": 795 Security Payload (ESP) 797 a. The selected SA may not be correct -- The SA may be 798 mis-selected due to tampering with the SPI, destination 799 address, or IPsec protocol type fields. Such errors, if they 800 map the packet to another extant SA, will be 801 indistinguishable from a corrupted packet, (case c). 802 Tampering with the SPI can be detected by use of 803 authentication. However, an SA mismatch might still occur 804 due to tampering with the IP Destination Address or the IPsec 805 protocol type field. 807 b. The pad length or pad values could be erroneous -- Bad pad 808 lengths or pad values can be detected irrespective of the use 809 of authentication. 811 c. The encrypted ESP packet could be corrupted -- This can be 812 detected if authentication is selected for the SA., 814 In case (a) or (c), the erroneous result of the decryption operation 815 (an invalid IP datagram or transport-layer frame) will not 816 necessarily be detected by IPsec, and is the responsibility of later 817 protocol processing. 819 4. Auditing 821 Not all systems that implement ESP will implement auditing. However, 822 if ESP is incorporated into a system that supports auditing, then the 823 ESP implementation MUST also support auditing and MUST allow a system 824 administrator to enable or disable auditing for ESP. For the most 825 part, the granularity of auditing is a local matter. However, 826 several auditable events are identified in this specification and for 827 each of these events a minimum set of information that SHOULD be 828 included in an audit log is defined. Additional information also MAY 829 be included in the audit log for each of these events, and additional 830 events, not explicitly called out in this specification, also MAY 831 result in audit log entries. There is no requirement for the 832 receiver to transmit any message to the purported sender in response 833 to the detection of an auditable event, because of the potential to 834 induce denial of service via such action. 836 5. Conformance Requirements 838 Implementations that claim conformance or compliance with this 839 specification MUST implement the ESP syntax and processing described 840 here and MUST comply with all requirements of the Security 841 Architecture document. If the key used to compute an ICV is manually 842 Security Payload (ESP) 844 distributed, correct provision of the anti-replay service would 845 require correct maintenance of the counter state at the sender, until 846 the key is replaced, and there likely would be no automated recovery 847 provision if counter overflow were imminent. Thus a compliant 848 implementation SHOULD NOT provide this service in conjunction with 849 SAs that are manually keyed. A compliant ESP implementation MUST 850 support the following mandatory-to-implement algorithms: 852 - DES in CBC mode [MD97] 853 - HMAC with MD5 [MG97a] 854 - HMAC with SHA-1 [MG97b] 855 - NULL Authentication algorithm 856 - NULL Encryption algorithm 858 Since ESP encryption and authentication are optional, support for the 859 2 "NULL" algorithms is required to maintain consistency with the way 860 these services are negotiated. NOTE that while authentication and 861 encryption can each be "NULL", they MUST NOT both be "NULL". 863 6. Security Considerations 865 Security is central to the design of this protocol, and thus security 866 considerations permeate the specification. Additional security- 867 relevant aspects of using the IPsec protocol are discussed in the 868 Security Architecture document. 870 7. Differences from RFC 1827 872 This document differs from RFC 1827 [ATK95] in several significant 873 ways. The major difference is that, this document attempts to 874 specify a complete framework and context for ESP, whereas RFC 1827 875 provided a "shell" that was completed through the definition of 876 transforms. The combinatorial growth of transforms motivated the 877 reformulation of the ESP specification as a more complete document, 878 with options for security services that may be offered in the context 879 of ESP. Thus, fields previously defined in transform documents are 880 now part of this base ESP specification. For example, the fields 881 necessary to support authentication (and anti-replay) are now defined 882 here, even though the provision of this service is an option. The 883 fields used to support padding for encryption, and for next protocol 884 identification, are now defined here as well. Packet processing 885 consistent with the definition of these fields also is included in 886 the document. 888 Security Payload (ESP) 890 Acknowledgements 892 Many of the concepts embodied in this specification were derived from 893 or influenced by the US Government's SP3 security protocol, ISO/IEC's 894 NLSP, or from the proposed swIPe security protocol. [SDNS89, ISO92, 895 IB93]. 897 For over 3 years, this document has evolved through multiple versions 898 and iterations. During this time, many people have contributed 899 significant ideas and energy to the process and the documents 900 themselves. The authors would like to thank Karen Seo for providing 901 extensive help in the review, editing, background research, and 902 coordination for this version of the specification. The authors 903 would also like to thank the members of the IPsec and IPng working 904 groups, with special mention of the efforts of (in alphabetic order): 905 Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David 906 Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina 907 Yuan. 909 References 911 [ATK95] R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 912 1827, August 1997. 914 [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security 915 Protocols", Proceedings of the Sixth Usenix Unix Security 916 Symposium, July, 1996. 918 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 919 Requirement Level," RFC-2119, March 1997. 921 [HC98] D. Harkins & D. Carrel, "The Internet Key Exchange (IKE)", 922 Internet Draft, February 1998. 924 [IB93] John Ioannidis & Matt Blaze, "Architecture and 925 Implementation of Network-layer Security Under Unix", 926 Proceedings of the USENIX Security Symposium, Santa Clara, 927 CA, October 1993. 929 [ISO92] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 930 DIS 11577, International Standards Organisation, Geneva, 931 Switzerland, 29 November 1992. 933 [KA97a] Steve Kent, Randall Atkinson, "Security Architecture for 934 the Internet Protocol", Internet Draft, March 1998. 936 Security Payload (ESP) 938 [KA97b] Steve Kent, Randall Atkinson, "IP Authentication Header", 939 Internet Draft, March 1998. 941 [MD97] C. Madson & N. Doraswamy, "The ESP DES-CBC Cipher Algorithm 942 With Explicit IV", Internet Draft, February 1998. 944 [MG97a] C. Madson & R. Glenn, "The Use of HMAC-MD5-96 within ESP 945 and AH", Internet Draft, February 1998. 947 [MG97b] C. Madson & R. Glenn, "The Use of HMAC-SHA-1-96 within ESP 948 and AH", Internet Draft, February 1998. 950 [STD-2] J. Reynolds and J. Postel, "Assigned Numbers", STD-2, 20 951 October 1994. 953 [SDNS89] SDNS Secure Data Network System, Security Protocol 3, SP3, 954 Document SDN.301, Revision 1.5, 15 May 1989, as published 955 in NIST Publication NIST-IR-90-4250, February 1990. 957 Disclaimer 959 The views and specification here are those of the authors and are not 960 necessarily those of their employers. The authors and their 961 employers specifically disclaim responsibility for any problems 962 arising from correct or incorrect implementation or use of this 963 specification. 965 Author Information 967 Stephen Kent 968 BBN Corporation 969 70 Fawcett Street 970 Cambridge, MA 02140 971 USA 972 E-mail: kent@bbn.com 973 Telephone: +1 (617) 873-3988 975 Randall Atkinson 976 @Home Network 977 425 Broadway, 978 Redwood City, CA 94063 979 USA 980 E-mail: rja@corp.home.net 981 Telephone: +1 (415) 569-5000 982 Security Payload (ESP) 984 Copyright (C) The Internet Society (May 1998). All Rights Reserved. 986 This document and translations of it may be copied and furnished to 987 others, and derivative works that comment on or otherwise explain it 988 or assist in its implementation may be prepared, copied, published 989 and distributed, in whole or in part, without restriction of any 990 kind, provided that the above copyright notice and this paragraph are 991 included on all such copies and derivative works. However, this 992 document itself may not be modified in any way, such as by removing 993 the copyright notice or references to the Internet Society or other 994 Internet organizations, except as needed for the purpose of 995 developing Internet standards in which case the procedures for 996 copyrights defined in the Internet Standards process must be 997 followed, or as required to translate it into languages other than 998 English. 1000 The limited permissions granted above are perpetual and will not be 1001 revoked by the Internet Society or its successors or assigns. 1003 This document and the information contained herein is provided on an 1004 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1005 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1006 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1007 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1008 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.