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