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