idnits 2.17.1 draft-ietf-ipsec-rfc2401bis-05.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 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4190. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 4198), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** 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? ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 105 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 512 has weird spacing: '...support multi...' == Line 1029 has weird spacing: '...g value examp...' == Line 1031 has weird spacing: '...elector selec...' == Line 1610 has weird spacing: '...oc addr list ...' == Line 1615 has weird spacing: '...em addr list ...' == (19 more instances...) == 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 (June 2005) is 6889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NiBlBaBL98' is mentioned on line 590, but not defined == Missing Reference: 'RaFlBl01' is mentioned on line 591, but not defined == Missing Reference: 'FaLiHaMeTr00' is mentioned on line 609, but not defined == Missing Reference: 'ToEgWa04' is mentioned on line 609, but not defined == Missing Reference: 'RFC 2474' is mentioned on line 2264, but not defined == Missing Reference: 'BBCDWW98' is mentioned on line 2264, but not defined == Missing Reference: 'RaCoCaDe04' is mentioned on line 2305, but not defined -- Looks like a reference, but probably isn't: '0' on line 3565 -- Looks like a reference, but probably isn't: '1' on line 3544 -- Looks like a reference, but probably isn't: '2' on line 3516 -- Looks like a reference, but probably isn't: '3' on line 3423 ** Obsolete normative reference: RFC 2463 (ref. 'CD98') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'DH98') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'Eas03' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kau04' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken04a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken04b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch03' -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'Mobip') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 2828 (ref. 'Shi00') (Obsoleted by RFC 4949) Summary: 14 errors (**), 0 flaws (~~), 19 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Kent 2 Internet Draft K. Seo 3 draft-ietf-ipsec-rfc2401bis-05.txt BBN Technologies 4 Obsoletes: RFC 2401 December 2004 5 Expires June 2005 7 Security Architecture for the Internet Protocol 9 Dedicated to the memory of Charlie Lynn, a long time senior 10 colleague at BBN, who made very significant contributions to 11 the IPsec documents. 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 This document is an Internet Draft and is subject to all provisions 21 of Section 10 of RFC2026. Internet Drafts are working documents of 22 the Internet Engineering Task Force (IETF), its areas, and its 23 working groups. Note that other groups may also distribute working 24 documents as Internet Drafts. Internet Drafts are draft documents 25 valid for a maximum of 6 months and may be updated, replaced, or 26 obsoleted by other documents at any time. It is inappropriate to use 27 Internet Drafts as reference material or to cite them other than as a 28 "work in progress". 30 The list of current Internet Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes an updated version of the "Security 41 Architecture for IP", which is designed to provide security services 42 for traffic at the IP layer. This document obsoletes RFC 2401 43 (November 1998). 45 Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor: 46 Please remove this line prior to publication as an RFC.] 48 Table of Contents 50 1. Introduction.........................................................4 51 1.1 Summary of Contents of Document.................................4 52 1.2 Audience........................................................4 53 1.3 Related Documents...............................................5 54 2. Design Objectives....................................................5 55 2.1 Goals/Objectives/Requirements/Problem Description...............5 56 2.2 Caveats and Assumptions.........................................6 57 3. System Overview .....................................................7 58 3.1 What IPsec Does.................................................7 59 3.2 How IPsec Works.................................................9 60 3.3 Where IPsec Can Be Implemented.................................10 61 4. Security Associations...............................................11 62 4.1 Definition and Scope...........................................11 63 4.2 SA Functionality...............................................15 64 4.3 Combining SAs..................................................16 65 4.4 Major IPsec Databases..........................................17 66 4.4.1 The Security Policy Database (SPD)........................18 67 4.4.1.1 Selectors............................................24 68 4.4.1.2 Structure of an SPD entry............................27 69 4.4.1.3 More re: Fields Associated with Next Layer Protocols.29 70 4.4.2 Security Association Database (SAD).......................31 71 4.4.2.1 Data Items in the SAD................................32 72 4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD..34 73 4.4.3 Peer Authorization Database (PAD).........................38 74 4.5 SA and Key Management..........................................39 75 4.5.1 Manual Techniques.........................................39 76 4.5.2 Automated SA and Key Management...........................39 77 4.5.3 Locating a Security Gateway...............................40 78 4.6 SAs and Multicast..............................................41 79 5. IP Traffic Processing...............................................42 80 5.1 Outbound IP Traffic Processing (protected-to-unprotected)......43 81 5.1.1 Handling an Outbound Packet That Must Be Discarded........45 82 5.1.2 Header Construction for Tunnel Mode.......................46 83 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..........48 84 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..........49 85 5.2 Processing Inbound IP Traffic (unprotected-to-protected).......50 86 6. ICMP Processing ....................................................53 87 6.1 Processing ICMP Error Messages Directed to an IPsec 88 Implementation......................................54 89 6.1.1 ICMP Error Messages Received on the Unprotected 90 Side of the Boundary................................54 91 6.1.2 ICMP Error Messages Received on the Protected 92 Side of the Boundary................................55 93 6.2 Processing Protected, Transit ICMP Error Messages..............55 94 7. Handling Fragments (on the protected side of the IPsec boundary)....56 95 7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments...57 96 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments.............58 97 7.3 Stateful Fragment Checking.....................................59 98 7.4 BYPASS/DISCARD traffic.........................................59 99 8. Path MTU/DF Processing..............................................60 100 8.1 DF Bit.........................................................60 101 8.2 Path MTU (PMTU) Discovery......................................60 102 8.2.1 Propagation of PMTU.......................................60 103 8.2.2 PMTU Aging................................................61 104 9. Auditing............................................................61 105 10. Conformance Requirements...........................................62 106 11. Security Considerations............................................62 107 12. IANA Considerations................................................62 108 13. Differences from RFC 2401..........................................62 109 Acknowledgements.......................................................65 110 Appendix A -- Glossary.................................................66 111 Appendix B -- Decorrelation............................................69 112 Appendix C -- ASN.1 for an SPD Entry...................................72 113 Appendix D -- Fragment Handling Rationale..............................78 114 D.1 Transport Mode and Fragments...................................78 115 D.2 Tunnel Mode and Fragments......................................79 116 D.3 The Problem of Non-Initial Fragments...........................80 117 D.4 BYPASS/DISCARD traffic.........................................83 118 D.5 Just say no to ports?..........................................83 119 D.6 Other Suggested Solutions......................................84 120 D.7 Consistency....................................................85 121 D.8 Conclusions....................................................85 122 Appendix E -- Example of Supporting Nested SAs via SPD and Forwarding 123 Table Entries......................................86 124 References.............................................................88 125 Author Information.....................................................90 126 Notices................................................................91 128 1. Introduction 130 1.1 Summary of Contents of Document 132 This document specifies the base architecture for IPsec compliant 133 systems. It describes how to provide a set of security services for 134 traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] 135 environments. This document describes the requirements for systems 136 that implement IPsec, the fundamental elements of such systems, and 137 how the elements fit together and fit into the IP environment. It 138 also describes the security services offered by the IPsec protocols, 139 and how these services can be employed in the IP environment. This 140 document does not address all aspects of the IPsec architecture. 141 Other documents address additional architectural details in 142 specialized environments, e.g., use of IPsec in Network Address 143 Translation (NAT) environments and more comprehensive support for IP 144 multicast. The fundamental components of the IPsec security 145 architecture are discussed in terms of their underlying, required 146 functionality. Additional RFCs (see Section 1.3 for pointers to 147 other documents) define the protocols in (a), (c), and (d). 149 a. Security Protocols -- Authentication Header (AH) and 150 Encapsulating Security Payload (ESP) 151 b. Security Associations -- what they are and how they work, 152 how they are managed, associated processing 153 c. Key Management -- manual and automated (The Internet Key 154 Exchange (IKE)) 155 d. Cryptographic algorithms for authentication and encryption 157 This document is not a Security Architecture for the Internet; it 158 addresses security only at the IP layer, provided through the use of 159 a combination of cryptographic and protocol security mechanisms. 161 The spelling "IPsec" is preferred and used throughout this and all 162 related IPsec standards. All other capitalizations of IPsec (e.g., 163 IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of 164 the sequence of letters "IPsec" should be understood to refer to the 165 IPsec protocols. 167 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 168 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 169 document, are to be interpreted as described in RFC 2119 [Bra97]. 171 1.2 Audience 173 The target audience for this document is primarily individuals who 174 implement this IP security technology or who architect systems that 175 will use this technology. Technically adept users of this technology 176 (end users or system administrators) also are part of the target 177 audience. A glossary is provided in Appendix A to help fill in gaps 178 in background/vocabulary. This document assumes that the reader is 179 familiar with the Internet Protocol (IP), related networking 180 technology, and general information system security terms and 181 concepts. 183 1.3 Related Documents 185 As mentioned above, other documents provide detailed definitions of 186 some of the components of IPsec and of their inter-relationship. 187 They include RFCs on the following topics: 189 a. security protocols -- RFCs describing the Authentication Header 190 (AH) [Ken04b] and Encapsulating Security Payload (ESP) [Ken04a] 191 protocols. 192 b. cryptographic algorithms for integrity and encryption -- one RFC 193 that defines the mandatory, default algorithms for use with AH 194 and ESP [Eas03], a similar RFC that defines the mandatory 195 algorithms for use with IKEv2 [Sch03] plus a separate RFC for 196 each cryptographic algorithm. 197 c. automatic key management -- RFCs on "The Internet Key Exchange 198 (IKEv2) Protocol" [Kau04] and "Cryptographic Algorithms for use 199 in the Internet Key Exchange Version 2" [Sch03] 201 2. Design Objectives 203 2.1 Goals/Objectives/Requirements/Problem Description 205 IPsec is designed to provide interoperable, high quality, 206 cryptographically-based security for IPv4 and IPv6. The set of 207 security services offered includes access control, connectionless 208 integrity, data origin authentication, detection and rejection of 209 replays (a form of partial sequence integrity), confidentiality (via 210 encryption), and limited traffic flow confidentiality. These 211 services are provided at the IP layer, offering protection in a 212 standard fashion for all protocols that may be carried over IP 213 (including IP itself). 215 IPsec includes a specification for minimal firewall functionality, 216 since that is an essential aspect of access control at the IP layer. 217 Implementations are free to provide more sophisticated firewall 218 mechanisms, and to implement the IPsec-mandated functionality using 219 those more sophisticated mechanisms. (Note that interoperability may 220 suffer if additional firewall constraints on traffic flows are 221 imposed by an IPsec implementation but cannot be negotiated based on 222 the traffic selector features defined in this document and negotiated 223 via IKEv2.) The IPsec firewall function makes use of the 224 cryptographically-enforced authentication and integrity provided for 225 all IPsec traffic to offer better access control than could be 226 obtained through use of a firewall (one not privy to IPsec internal 227 parameters) plus separate cryptographic protection. 229 Most of the security services are provided through use of two traffic 230 security protocols, the Authentication Header (AH) and the 231 Encapsulating Security Payload (ESP), and through the use of 232 cryptographic key management procedures and protocols. The set of 233 IPsec protocols employed in a context, and the ways in which they are 234 employed, will be determined by the users/administrators in that 235 context. It is the goal of the IPsec architecture to ensure that 236 compliant implementations include the services and management 237 interfaces needed to meet the security requirements of a broad user 238 population. 240 When IPsec is correctly implemented and deployed, it ought not 241 adversely affect users, hosts, and other Internet components that do 242 not employ IPsec for traffic protection. IPsec security protocols 243 (AH & ESP, and to a lesser extent, IKE) are designed to be 244 cryptographic algorithm-independent. This modularity permits 245 selection of different sets of cryptographic algorithms as 246 appropriate, without affecting the other parts of the implementation. 247 For example, different user communities may select different sets of 248 cryptographic algorithms (creating cryptographically-enforced 249 cliques) if required. 251 To facilitate interoperability in the global Internet, a set of 252 default cryptographic algorithms for use with AH and ESP is specified 253 in [Eas03] and a set of mandatory-to-implement algorithms for IKEv2 254 is specified in [Sch03]. [Eas03] and [Sch03] will be periodically 255 updated to keep pace with computational and cryptologic advances. By 256 specifying these algorithms in documents that are separate from the 257 AH, ESP, and IKEv2 specifications, these algorithms can be updated or 258 replaced without affecting the standardization progress of the rest 259 of the IPsec document suite. The use of these cryptographic 260 algorithms, in conjunction with IPsec traffic protection and key 261 management protocols, is intended to permit system and application 262 developers to deploy high quality, Internet layer, cryptographic 263 security technology. 265 2.2 Caveats and Assumptions 267 The suite of IPsec protocols and associated default cryptographic 268 algorithms are designed to provide high quality security for Internet 269 traffic. However, the security offered by use of these protocols 270 ultimately depends on the quality of the their implementation, which 271 is outside the scope of this set of standards. Moreover, the 272 security of a computer system or network is a function of many 273 factors, including personnel, physical, procedural, compromising 274 emanations, and computer security practices. Thus IPsec is only one 275 part of an overall system security architecture. 277 Finally, the security afforded by the use of IPsec is critically 278 dependent on many aspects of the operating environment in which the 279 IPsec implementation executes. For example, defects in OS security, 280 poor quality of random number sources, sloppy system management 281 protocols and practices, etc. can all degrade the security provided 282 by IPsec. As above, none of these environmental attributes are 283 within the scope of this or other IPsec standards. 285 3. System Overview 287 This section provides a high level description of how IPsec works, 288 the components of the system, and how they fit together to provide 289 the security services noted above. The goal of this description is 290 to enable the reader to "picture" the overall process/system, see how 291 it fits into the IP environment, and to provide context for later 292 sections of this document, which describe each of the components in 293 more detail. 295 An IPsec implementation operates in a host, as a security gateway, or 296 as an independent device, affording protection to IP traffic. (A 297 security gateway is an intermediate system implementing IPsec, e.g., 298 a firewall or router that has been IPsec-enabled.) More detail on 299 these classes of implementations is provided later, in Section 3.3. 300 The protection offered by IPsec is based on requirements defined by a 301 Security Policy Database (SPD) established and maintained by a user 302 or system administrator, or by an application operating within 303 constraints established by either of the above. In general, packets 304 are selected for one of three processing actions based on IP and next 305 layer header information (Selectors, Section 4.4.1.1) matched against 306 entries in the Security Policy Database (SPD). Each packet is either 307 PROTECTed using IPsec security services, DISCARDed, or allowed to 308 BYPASS IPsec protection, based on the applicable SPD policies 309 identified by the Selectors. 311 3.1 What IPsec Does 313 IPsec creates a boundary between unprotected and protected 314 interfaces, for a host or a network (see Figure 1 below). Traffic 315 traversing the boundary is subject to the access controls specified 316 by the user or administrator responsible for the IPsec configuration. 317 These controls indicate whether packets cross the boundary unimpeded, 318 are afforded security services via AH or ESP, or are discarded. IPsec 319 security services are offered at the IP layer through selection of 320 appropriate security protocols, cryptographic algorithms, and 321 cryptographic keys. IPsec can be used to protect one or more "paths" 322 (a) between a pair of hosts, (b) between a pair of security gateways, 323 or (c) between a security gateway and a host. A compliant host 324 implementation MUST support (a) and (c) and a compliant security 325 gateway must support all three of these forms of connectivity, since 326 under certain circumstances a security gateway acts as a host. 328 Unprotected 329 ^ ^ 330 | | 331 +-------------|-------|-------+ 332 | +-------+ | | | 333 | |Discard|<--| V | 334 | +-------+ |B +--------+ | 335 ................|y..| AH/ESP |..... IPsec Boundary 336 | +---+ |p +--------+ | 337 | |IKE|<----|a ^ | 338 | +---+ |s | | 339 | +-------+ |s | | 340 | |Discard|<--| | | 341 | +-------+ | | | 342 +-------------|-------|-------+ 343 | | 344 V V 345 Protected 347 Figure 1. Top Level IPsec Processing Model 349 In this diagram, "unprotected" refers to an interface that might also 350 be described as "black" or "ciphertext." Here, "protected" refers to 351 an interface that might also be described as "red" or "plaintext." 352 The protected interface noted above may be internal, e.g., in a host 353 implementation of IPsec, the protected interface may link to a socket 354 layer interface presented by the OS. In this document, the term 355 "inbound" refers to traffic entering an IPsec implementation via the 356 unprotected interface or emitted by the implementation on the 357 unprotected side of the boundary and directed towards the protected 358 interface. The term "outbound" refers to traffic entering the 359 implementation via the protected interface, or emitted by the 360 implementation on the protected side of the boundary and directed 361 toward the unprotected interface. An IPsec implementation may 362 support more than one interface on either or both sides of the 363 boundary. 365 Note the facilities for discarding traffic on either side of the 366 IPsec boundary, the BYPASS facility that allows traffic to transit 367 the boundary without cryptographic protection, and the reference to 368 IKE as a protected-side key and security management function. 370 IPsec optionally supports negotiation of IP compression [SMPT01], 371 motivated in part by the observation that when encryption is employed 372 within IPsec, it prevents effective compression by lower protocol 373 layers. 375 3.2 How IPsec Works 377 IPsec uses two protocols to provide traffic security services -- 378 Authentication Header (AH) and Encapsulating Security Payload (ESP). 379 Both protocols are described in detail in their respective RFCs 380 [Ken04b, Ken04a]. IPsec implementations MUST support ESP and MAY 381 support AH. (Support for AH has been downgraded to MAY because 382 experience has shown that there are very few contexts in which ESP 383 cannot provide the requisite security services. Note that ESP can be 384 used to provide only integrity, without confidentiality, making it 385 comparable to AH in most contexts.) 387 o The IP Authentication Header (AH) [Ken04b] offers integrity and 388 data origin authentication, with optional (at the discretion of 389 the receiver) anti-replay features. 391 o The Encapsulating Security Payload (ESP) protocol [Ken04a] offers 392 the same set of services, and also offers confidentiality. Use of 393 ESP to provide confidentiality without integrity is NOT 394 RECOMMENDED. When ESP is used with confidentiality enabled, there 395 are provisions for limited traffic flow confidentiality, i.e., 396 provisions for concealing packet length, and for facilitating 397 efficient generation and discard of dummy packets. This capability 398 is likely to be effective primarily in VPN and overlay network 399 contexts. 401 o Both AH and ESP offer access control, enforced through the 402 distribution of cryptographic keys and the management of traffic 403 flows as dictated by the Security Policy Database (SPD, Section 404 4.4.1). 406 These protocols may be applied individually or in combination with 407 each other to provide IPv4 and IPv6 security services. However, most 408 security requirements can be met through the use of ESP by itself. 409 Each protocol supports two modes of use: transport mode and tunnel 410 mode. In transport mode, AH and ESP provide protection primarily for 411 next layer protocols; in tunnel mode, AH and ESP are applied to 412 tunneled IP packets. The differences between the two modes are 413 discussed in Section 4.1. 415 IPsec allows the user (or system administrator) to control the 416 granularity at which a security service is offered. For example, one 417 can create a single encrypted tunnel to carry all the traffic between 418 two security gateways or a separate encrypted tunnel can be created 419 for each TCP connection between each pair of hosts communicating 420 across these gateways. IPsec, through the SPD management paradigm, 421 incorporates facilities for specifying: 423 o which security protocol (AH or ESP) to employ, the mode (transport 424 or tunnel), security service options, what cryptographic 425 algorithms to use, and in what combinations to use the specified 426 protocols and services, 428 o the granularity at which protection should be applied. 430 Because most of the security services provided by IPsec require the 431 use of cryptographic keys, IPsec relies on a separate set of 432 mechanisms for putting these keys in place. This document requires 433 support for both manual and automated distribution of keys. It 434 specifies a specific public-key based approach (IKEv2 [Kau04]) for 435 automated key management, but other automated key distribution 436 techniques MAY be used. 438 Note: This document mandates support for several features for which 439 support is available in IKEv2 but not in IKEv1, e.g., negotiation of 440 an SA representing ranges of local and remote ports or negotiation of 441 multiple SAs with the same selectors. Therefore this document assumes 442 use of IKEv2 or a key and security association management system with 443 comparable features. 445 3.3 Where IPsec Can Be Implemented 447 There are many ways in which IPsec may be implemented in a host, or 448 in conjunction with a router or firewall to create a security 449 gateway, or as an independent security device. 451 a. IPsec may be integrated into the native IP stack. This requires 452 access to the IP source code and is applicable to both hosts and 453 security gateways, although native host implementations benefit 454 the most from this strategy, as explained later (Section 4.4.1, 455 paragraph 6; Section 4.4.1.1, last paragraph). 457 b. In a "bump-in-the-stack" (BITS) implementation, IPsec is 458 implemented "underneath" an existing implementation of an IP 459 protocol stack, between the native IP and the local network 460 drivers. Source code access for the IP stack is not required in 461 this context, making this implementation approach appropriate for 462 use with legacy systems. This approach, when it is adopted, is 463 usually employed in hosts. 465 c. The use of a dedicated, inline security protocol processor is a 466 common design feature of systems used by the military, and of some 467 commercial systems as well. It is sometimes referred to as a 468 "bump-in-the-wire" (BITW) implementation. Such implementations 469 may be designed to serve either a host or a gateway. Usually the 470 BITW device is itself IP addressable. When supporting a single 471 host, it may be quite analogous to a BITS implementation, but in 472 supporting a router or firewall, it must operate like a security 473 gateway. 475 This document often talks in terms of use of IPsec by a host or a 476 security gateway, without regard to whether the implementation is 477 native, BITS or BITW. When the distinctions among these 478 implementation options are significant, the document makes reference 479 to specific implementation approaches. 481 4. Security Associations 483 This section defines Security Association management requirements for 484 all IPv6 implementations and for those IPv4 implementations that 485 implement AH, ESP, or both AH and ESP. The concept of a "Security 486 Association" (SA) is fundamental to IPsec. Both AH and ESP make use 487 of SAs and a major function of IKE is the establishment and 488 maintenance of SAs. All implementations of AH or ESP MUST support 489 the concept of an SA as described below. The remainder of this 490 section describes various aspects of SA management, defining required 491 characteristics for SA policy management and SA management 492 techniques. 494 4.1 Definition and Scope 496 An SA is a simplex "connection" that affords security services to the 497 traffic carried by it. Security services are afforded to an SA by 498 the use of AH, or ESP, but not both. If both AH and ESP protection 499 are applied to a traffic stream, then two SAs must be created and 500 coordinated to effect protection through iterated application of the 501 security protocols. To secure typical, bi-directional communication 502 between two IPsec-enabled systems, a pair of SAs (one in each 503 direction) is required. IKE explicitly creates SA pairs in 504 recognition of this common usage requirement. 506 For an SA used to carry unicast traffic, the SPI (Security Parameters 507 Index - see Appendix A and AH [Ken04b] and ESP [Ken04a] 508 specifications) by itself suffices to specify an SA. However, as a 509 local matter, an implementation may choose to use the SPI in 510 conjunction with the IPsec protocol type (AH or ESP) for SA 511 identification. If an IPsec implementation supports multicast, then 512 it MUST support multicast SAs using the algorithm below for mapping 513 inbound IPsec datagrams to SAs. Implementations that support only 514 unicast traffic need not implement this demultiplexing algorithm. 516 In many secure multicast (or anycast) architectures, e.g., [RFC3740], 517 a central Group Controller/Key Server unilaterally assigns the Group 518 Security Association's (GSA's) SPI. This SPI assignment is not 519 negotiated or coordinated with the key management (e.g., IKE) 520 subsystems that reside in the individual end systems that constitute 521 the group. Consequently, it is possible that a GSA and a unicast SA 522 can simultaneously use the same SPI. A multicast-capable IPsec 523 implementation MUST correctly de-multiplex inbound traffic even in 524 the context of SPI collisions. 526 Each entry in the SA Database (SAD) (Section 4.4.2) must indicate 527 whether the SA lookup makes use of the destination IP address, or the 528 destination and source IP addresses, in addition to the SPI. For 529 multicast SAs, the protocol field is not employed for SA lookups. For 530 each inbound, IPsec-protected packet, an implementation must conduct 531 its search of the SAD such that it finds the entry that matches the 532 "longest" SA identifier. In this context, if two or more SAD entries 533 match based on the SPI value, then the entry that also matches based 534 on destination address, or destination and source address (as 535 indicated in the SAD entry) is the "longest" match. This implies a 536 logical ordering of the SAD search as follows: 538 1. Search the SAD for a match on the combination of SPI, 539 destination address, and source address. If an SAD entry 540 matches, then process the inbound packet with that 541 matching SAD entry. Otherwise, proceed to step 2. 543 2. Search the SAD for a match on both SPI and destination address. 544 If the SAD entry matches then process the inbound packet 545 with that matching SAD entry. Otherwise, proceed to step 3. 547 3. Search the SAD for a match on only SPI if the receiver has 548 chosen to maintain a single SPI space for AH and ESP, and on 549 both SPI and protocol otherwise. If an SAD entry matches then 550 process the inbound packet with that matching SAD entry. 551 Otherwise, discard the packet and log an auditable event. 553 In practice, an implementation may choose any method (or none at all) 554 to accelerate this search, although its externally visible behavior 555 MUST be functionally equivalent to having searched the SAD in the 556 above order. For example, a software-based implementation could index 557 into a hash table by the SPI. The SAD entries in each hash table 558 bucket's linked list could be kept sorted to have those SAD entries 559 with the longest SA identifiers first in that linked list. Those SAD 560 entries having the shortest SA identifiers could be sorted so that 561 they are the last entries in the linked list. A hardware-based 562 implementation may be able to effect the longest match search 563 intrinsically, using commonly available Ternary Content-Addressable 564 Memory (TCAM0 features. 566 The indication of whether source and destination address matching is 567 required to map inbound IPsec traffic to SAs MUST be set either as a 568 side effect of manual SA configuration or via negotiation using an SA 569 management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source- 570 Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier 571 composed of an SPI, a destination multicast address, and source 572 address. An Any-Source Multicast group SA requires only an SPI and a 573 destination multicast address as an identifier. 575 If different classes of traffic (distinguished by Differentiated 576 Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the 577 same SA, and if the receiver is employing the optional anti-replay 578 feature available in both AH and ESP, this could result in 579 inappropriate discarding of lower priority packets due to the 580 windowing mechanism used by this feature. Therefore a sender SHOULD 581 put traffic of different classes, but with the same selector values, 582 on different SAs to support QoS appropriately. To permit this, the 583 IPsec implementation MUST permit establishment and maintenance of 584 multiple SAs between a given sender and receiver, with the same 585 selectors. Distribution of traffic among these parallel SAs to 586 support QoS is locally determined by the sender and is not negotiated 587 by IKE. The receiver MUST process the packets from the different SAs 588 without prejudice. 590 DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and Explicit 591 Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", 592 as that term in used in this architecture, the sender will need a 593 mechanism to direct packets with a given (set of) DSCP values to the 594 appropriate SA. This mechanism might be termed a "classifier". 596 As noted above, two types of SAs are defined: transport mode and 597 tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose 598 to require that both SAs in a pair be of the same mode, transport or 599 tunnel. 601 A transport mode SA is an SA typically employed between a pair of 602 hosts to provide end-to-end security services. When security is 603 desired between two intermediate systems along a path (vs. end-to-end 604 use of IPsec), transport mode MAY be used between security gateways 605 or between a security gateway and a host. In the case where 606 transport mode is used between security gateways or between a 607 security gateway and a host, transport mode may be used to support 608 in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling 609 [FaLiHaMeTr00] or Dynamic routing [ToEgWa04]) over transport mode 610 SAs. To clarify, the use of transport mode by an intermediate system 611 (e.g., a security gateway) is permitted only when applied to packets 612 whose source address (for outbound packets) or destination address 613 (for inbound packets) is an address belonging to the intermediate 614 system itself. The access control functions that are an important 615 part of IPsec are significantly limited in this context, as they 616 cannot be applied to the end-to-end headers of the packets that 617 traverse a transport mode SA used in this fashion. Thus this way of 618 using transport mode should be evaluated carefully before being 619 employed in a specific context. 621 In IPv4, a transport mode security protocol header appears 622 immediately after the IP header and any options, and before any next 623 layer protocols (e.g., TCP or UDP). In IPv6, the security protocol 624 header appears after the base IP header and selected extension 625 headers, but may appear before or after destination options; it MUST 626 appear before next layer protocols (e.g., TCP, UDP, SCTP). In the 627 case of ESP, a transport mode SA provides security services only for 628 these next layer protocols, not for the IP header or any extension 629 headers preceding the ESP header. In the case of AH, the protection 630 is also extended to selected portions of the IP header preceding it, 631 selected portions of extension headers, and selected options 632 (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or 633 IPv6 Destination extension headers). For more details on the 634 coverage afforded by AH, see the AH specification [Ken04b]. 636 A tunnel mode SA is essentially an SA applied to an IP tunnel, with 637 the access controls applied to the headers of the traffic inside the 638 tunnel. Two hosts MAY establish a tunnel mode SA between themselves. 639 Aside from the two exceptions below, whenever either end of a 640 security association is a security gateway, the SA MUST be tunnel 641 mode. Thus an SA between two security gateways is typically a tunnel 642 mode SA, as is an SA between a host and a security gateway. The two 643 exceptions are as follows. 645 o Where traffic is destined for a security gateway, e.g., SNMP 646 commands, the security gateway is acting as a host and transport 647 mode is allowed. In this case, the SA terminates at a host 648 (management) function within a security gateway and thus merits 649 different treatment. 651 o As noted above, security gateways MAY support a transport mode SA 652 to provide security for IP traffic between two intermediate 653 systems along a path, e.g., between a host and a security gateway 654 or between two security gateways. 656 Several concerns motivate the use of tunnel mode for an SA involving 657 a security gateway. For example, if there are multiple paths (e.g., 658 via different security gateways) to the same destination behind a 659 security gateway, it is important that an IPsec packet be sent to the 660 security gateway with which the SA was negotiated. Similarly, a 661 packet that might be fragmented en-route must have all the fragments 662 delivered to the same IPsec instance for reassembly prior to 663 cryptographic processing. Also, when a fragment is processed by IPsec 664 and transmitted, then fragmented en-route, it is critical that there 665 be inner and outer headers to retain the fragmentation state data for 666 the pre- and post-IPsec packet formats. Hence there are several 667 reasons for employing tunnel mode when either end of an SA is a 668 security gateway. (Use of an IP-in-IP tunnel in conjunction with 669 transport mode can also address these fragmentation issues. However, 670 this configuration limits the ability of IPsec to enforce access 671 control policies on traffic.) 673 Note: AH and ESP cannot be applied using transport mode to IPv4 674 packets that are fragments. Only tunnel mode can be employed in such 675 cases. For IPv6, it would be feasible to carry a plaintext fragment 676 on a transport mode SA; however, for simplicity, this restriction 677 also applies to IPv6 packets. See Section 7 for more details on 678 handling plaintext fragments on the protected side of the IPsec 679 barrier. 681 For a tunnel mode SA, there is an "outer" IP header that specifies 682 the IPsec processing source and destination, plus an "inner" IP 683 header that specifies the (apparently) ultimate source and 684 destination for the packet. The security protocol header appears 685 after the outer IP header, and before the inner IP header. If AH is 686 employed in tunnel mode, portions of the outer IP header are afforded 687 protection (as above), as well as all of the tunneled IP packet 688 (i.e., all of the inner IP header is protected, as well as next layer 689 protocols). If ESP is employed, the protection is afforded only to 690 the tunneled packet, not to the outer header. 692 In summary, 694 a) A host implementation of IPsec MUST support both transport and 695 tunnel mode. This is true for native, BITS, and BITW 696 implementations for hosts. 698 b) A security gateway MUST support tunnel mode and MAY support 699 transport mode. If it supports transport mode, that should be 700 used only when the security gateway is acting as a host, e.g., for 701 network management, or to provide security between two 702 intermediate systems along a path. 704 4.2 SA Functionality 706 The set of security services offered by an SA depends on the security 707 protocol selected, the SA mode, the endpoints of the SA, and on the 708 election of optional services within the protocol. 710 For example, both AH and ESP offer integrity and authentication 711 services, but the coverage differs for each protocol and differs for 712 transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6 713 extension header must be protected en-route between sender and 714 receiver, AH can provide this service, except for IP or extension 715 headers that may change in a fashion not predictable by the sender. 716 However, the same security may be achieved in some contexts by 717 applying ESP to a tunnel carrying a packet. 719 The granularity of access control provided is determined by the 720 choice of the selectors that define each SA. Moreover, the 721 authentication means employed by IPsec peers, e.g., during creation 722 of an IKE (vs. child) SA also effects the granularity of the access 723 control afforded. 725 If confidentiality is selected, then an ESP (tunnel mode) SA between 726 two security gateways can offer partial traffic flow confidentiality. 727 The use of tunnel mode allows the inner IP headers to be encrypted, 728 concealing the identities of the (ultimate) traffic source and 729 destination. Moreover, ESP payload padding also can be invoked to 730 hide the size of the packets, further concealing the external 731 characteristics of the traffic. Similar traffic flow confidentiality 732 services may be offered when a mobile user is assigned a dynamic IP 733 address in a dialup context, and establishes a (tunnel mode) ESP SA 734 to a corporate firewall (acting as a security gateway). Note that 735 fine granularity SAs generally are more vulnerable to traffic 736 analysis than coarse granularity ones that are carrying traffic from 737 many subscribers. 739 Note: A compliant implementation MUST NOT allow instantiation of an 740 ESP SA that employs both NULL encryption and no integrity algorithm. 741 An attempt to negotiate such an SA is an auditable event by both 742 initiator and responder. The audit log entry for this event SHOULD 743 include the current date/time, local IKE IP address, and remote IKE 744 IP address. The initiator SHOULD record the relevant SPD entry. 746 4.3 Combining SAs 748 This document does not require support for nested security 749 associations or for what RFC 2401 called "SA bundles." These features 750 still can be effected by appropriate configuration of both the SPD 751 and the local forwarding functions (for inbound and outbound 752 traffic), but this capability is outside of the IPsec module and thus 753 the scope of this specification. As a result, management of 754 nested/bundled SAs is potentially more complex and less assured than 755 under the model implied by RFC 2401. An implementation that provides 756 support for nested SAs SHOULD provide a management interface that 757 enables a user or administrator to express the nesting requirement, 758 and then create the appropriate SPD entries and forwarding table 759 entries to effect the requisite processing. (See Appendix E for an 760 example of how to configure nested SAs.) 762 4.4 Major IPsec Databases 764 Many of the details associated with processing IP traffic in an IPsec 765 implementation are largely a local matter, not subject to 766 standardization. However, some external aspects of the processing 767 must be standardized to ensure interoperability and to provide a 768 minimum management capability that is essential for productive use of 769 IPsec. This section describes a general model for processing IP 770 traffic relative to IPsec functionality, in support of these 771 interoperability and functionality goals. The model described below 772 is nominal; implementations need not match details of this model as 773 presented, but the external behavior of implementations MUST 774 correspond to the externally observable characteristics of this model 775 in order to be compliant. 777 There are three nominal databases in this model: the Security Policy 778 Database (SPD), the Security Association Database (SAD), and the Peer 779 Authorization Database (PAD). The first specifies the policies that 780 determine the disposition of all IP traffic inbound or outbound from 781 a host or security gateway (Section 4.4.1). The second database 782 contains parameters that are associated with each established (keyed) 783 SA (Section 4.4.2). The third database, the Peer Authorization 784 Database (PAD) provides a link between an SA management protocol like 785 IKE and the SPD (Section 4.4.3). 787 Multiple Separate IPsec Contexts 789 If an IPsec implementation acts as a security gateway for multiple 790 subscribers, it MAY implement multiple separate IPsec contexts. 791 Each context MAY have and MAY use completely independent 792 identities, policies, key management SAs, and/or IPsec SAs. This 793 is for the most part a local implementation matter. However, a 794 means for associating inbound (SA) proposals with local contexts 795 is required. To this end, if supported by the key management 796 protocol in use, context identifiers MAY be conveyed from 797 initiator to responder in the signaling messages, with the result 798 that IPsec SAs are created with a binding to a particular context. 799 For example, a security gateway that provides VPN service to 800 multiple customers will be able to associate each customer's 801 traffic with the correct VPN. 803 Forwarding vs Security Decisions 805 The IPsec model described here embodies a clear separation between 806 forwarding (routing) and security decisions, to accommodate a wide 807 range of contexts where IPsec may be employed. Forwarding may be 808 trivial, in the case where there are only two interfaces, or it 809 may be complex, e.g., if there are multiple protected or 810 unprotected interfaces or if the context in which IPsec is 811 implemented employs a sophisticated forwarding function. IPsec 812 assumes only that outbound and inbound traffic that has passed 813 through IPsec processing is forwarded in a fashion consistent with 814 the context in which IPsec is implemented. Support for nested SAs 815 is optional; if required, it requires coordination between 816 forwarding tables and SPD entries to cause a packet to traverse 817 the IPsec boundary more than once. 819 "Local" vs "Remote" 821 In this document, with respect to IP addresses and ports, the 822 terms "Local" and "Remote" are used for policy rules. "Local" 823 refers to the entity being protected by an IPsec implementation, 824 i.e., the "source" address/port of outbound packets or the 825 "destination" address/port of inbound packets. "Remote" refers to 826 a peer entity or peer entities. The terms "source" and 827 "destination" are used for packet header fields. 829 "Non-initial" vs "Initial" Fragments 831 Throughout this document, the phrase "non-initial" fragments is 832 used to mean fragments that do not contain all of the selector 833 values that may be needed for access control (e.g., they might not 834 contain Next Layer Protocol, source and destination ports, ICMP 835 message type/code, Mobility Header type). And the phrase "initial" 836 fragment is used to mean a fragment that contains all the selector 837 values needed for access control. However, it should be noted that 838 for IPv6, which fragment contains the Next Layer Protocol and 839 ports (or ICMP message type/code or Mobility Header type) will 840 depend on the kind and number of extension headers present. The 841 "initial" fragment might not be the first fragment, in this 842 context. 844 4.4.1 The Security Policy Database (SPD) 846 An SA is a management construct used to enforce security policy for 847 traffic crossing the IPsec boundary. Thus an essential element of SA 848 processing is an underlying Security Policy Database (SPD) that 849 specifies what services are to be offered to IP datagrams and in what 850 fashion. The form of the database and its interface are outside the 851 scope of this specification. However, this section specifies minimum 852 management functionality that must be provided, to allow a user or 853 system administrator to control whether and how IPsec is applied to 854 traffic transmitted or received by a host or transiting a security 855 gateway. The SPD, or relevant caches, must be consulted during the 856 processing of all traffic (inbound and outbound), including traffic 857 not protected by IPsec, that traverses the IPsec boundary. This 858 includes IPsec management traffic such as IKE. An IPsec 859 implementation MUST have at least one SPD, and it MAY support 860 multiple SPDs, if appropriate for the context in which the IPsec 861 implementation operates. There is no requirement to maintain SPDs on 862 a per interface basis, as was specified in RFC 2401. However, if an 863 implementation supports multiple SPDs, then it MUST include an 864 explicit SPD selection function, that is invoked to select the 865 appropriate SPD for outbound traffic processing. The inputs to this 866 function are the outbound packet and any local metadata (e.g., the 867 interface via which the packet arrived) required to effect the SPD 868 selection function. The output of the function is an SPD identifier 869 (SPD-ID). 871 The SPD is an ordered database, consistent with the use of ACLs or 872 packet filters in firewalls, routers, etc. The ordering requirement 873 arises because entries often will overlap due to the presence of 874 (non-trivial) ranges as values for selectors. Thus a user or 875 administrator MUST be able to order the entries to express a desired 876 access control policy. There is no way to impose a general, canonical 877 order on SPD entries, because of the allowed use of wildcards for 878 selector values and because the different types of selectors are not 879 hierarchically related. 881 Processing Choices: DISCARD, BYPASS, PROTECT 883 An SPD must discriminate among traffic that is afforded IPsec 884 protection and traffic that is allowed to bypass IPsec. This 885 applies to the IPsec protection to be applied by a sender and to 886 the IPsec protection that must be present at the receiver. For 887 any outbound or inbound datagram, three processing choices are 888 possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The 889 first choice refers to traffic that is not allowed to traverse the 890 IPsec boundary (in the specified direction). The second choice 891 refers to traffic that is allowed to cross the IPsec boundary 892 without IPsec protection. The third choice refers to traffic that 893 is afforded IPsec protection, and for such traffic the SPD must 894 specify the security protocols to be employed, their mode, 895 security service options, and the cryptographic algorithms to be 896 used. 898 SPD-SPD-S, SPD-SPD-I, SPD-SPD-O 900 An SPD is logically divided into three pieces. The SPD-SPD-S 901 (secure traffic) contains entries for all traffic subject to IPsec 902 protection. SPD-O (outbound) contains entries for all outbound 903 traffic that is to be bypassed or discarded. SPD-I (inbound) is 904 applied to inbound traffic that will be bypassed or discarded. All 905 three of these can be decorrelated (with the exception noted above 906 for native host implementations) to facilitate caching. If an 907 IPsec implementation supports only one SPD, then the SPD consists 908 of all three parts. If multiple SPDs are supported, some of them 909 may be partial, e.g., some SPDs might contain only SPD-I entries, 910 to control inbound bypassed traffic on a per-interface basis. The 911 split allows SPD-I to be consulted without having to consult SPD- 912 S, for such traffic. Since the SPD-I is just a part of the SPD, if 913 a packet that is looked up in the SPD-I cannot be matched to an 914 entry there, then the packet MUST be discarded. Note that for 915 outbound traffic, if a match is not found in SPD-S, then SPD-O 916 must be checked to see if the traffic should be bypassed. 917 Similarly, if SPD-O is checked first and no match is found, then 918 SPD-S must be checked. In an ordered, non-decorrelated SPD, the 919 entries for the SPD-S, SPD-I, and SPD-O are interleaved. So there 920 is one look up in the SPD. 922 SPD entries 924 Each SPD entry specifies packet disposition as BYPASS, DISCARD, or 925 PROTECT. The entry is keyed by a list of one or more selectors. 926 The SPD contains an ordered list of these entries. The required 927 selector types are defined in Section 4.4.1.1. These selectors are 928 used to define the granularity of the SAs that are created in 929 response to an outbound packet or in response to a proposal from a 930 peer. The detailed structure of an SPD entry is described in 931 Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that 932 matches anything that is otherwise unmatched, and discards it. 934 The SPD MUST permit a user or administrator to specify policy 935 entries as follows: 937 - SPD-I: For inbound traffic that is to be bypassed or discarded, 938 the entry consists of the values of the selectors that apply to 939 the traffic to be bypassed or discarded. 941 - SPD-O: For outbound traffic that is to be bypassed or 942 discarded, the entry consists of the values of the selectors 943 that apply to the traffic to be bypassed or discarded. 945 - SPD-S: For traffic that is to be protected using IPsec, the 946 entry consists of the values of the selectors that apply to the 947 traffic to be protected via AH or ESP, controls on how to 948 create SAs based on these selectors, and the parameters needed 949 to effect this protection (e.g., algorithms, modes, etc.). Note 950 that an SPD-S entry also contains information such as "populate 951 from packet" (PFP) flag (see paragraphs below on "How To Derive 952 the Values for an SAD entry") and bits indicating whether the 953 SA lookup makes use of the local and remote IP addresses in 954 addition to the SPI (see AH [Ken04b] or ESP [Ken04a] 955 specifications). 957 Representing directionality in an SPD entry 959 For traffic protected by IPsec, the Local and Remote address and 960 ports in an SPD entry are swapped to represent directionality, 961 consistent with IKE conventions. In general, the protocols that 962 IPsec deals with have the property of requiring symmetric SAs with 963 flipped Local/Remote IP addresses. However, for ICMP, there is 964 often no such bi-directional authorization requirement. 965 Nonetheless, for the sake of uniformity and simplicity, SPD 966 entries for ICMP are specified in the same way as for other 967 protocols. Note also that for ICMP, Mobility Header, and non- 968 initial fragments, there are no port fields in these packets. ICMP 969 has message type and code and Mobility Header has mobility header 970 type. Thus SPD entries have provisions for expressing access 971 controls appropriate for these protocols, in lieu of the normal 972 port field controls. For bypassed or discarded traffic, separate 973 inbound and outbound entries are supported, e.g., to permit 974 unidirectional flows if required. 976 OPAQUE and ANY 978 For each selector in an SPD entry, in addition to the literal 979 values that define a match, there are two special values: ANY and 980 OPAQUE. ANY is a wildcard that matches any value in the 981 corresponding field of the packet, or that matches packets where 982 that field is not present or is obscured. OPAQUE indicates that 983 the corresponding selector field is not available for examination 984 because it may not be present in a fragment, does not exist for 985 the given Next Layer Protocol, or because prior application of 986 IPsec may have encrypted the value. The ANY value encompasses the 987 OPAQUE value. Thus OPAQUE need be used only when it is necessary 988 to distinguish between the case of any allowed value for a field, 989 vs. the absence or unavailability (e.g., due to encryption) of the 990 field. 992 How To Derive the Values for an SAD entry 994 For each selector in an SPD entry, the entry specifies how to 995 derive the corresponding values for a new SA Database (SAD, see 996 Section 4.4.2) entry from those in the SPD and the packet. The 997 goal is to allow an SAD entry and an SPD cache entry to be created 998 based on specific selector values from the packet, or from the 999 matching SPD entry. For outbound traffic, there are SPD-S cache 1000 entries and SPD-O cache entries. For inbound traffic not 1001 protected by IPsec, there are SPD-I cache entries and there is the 1002 SAD, which represents the cache for inbound IPsec-protected 1003 traffic (See Figure 3 in Section 5.2). If IPsec processing is 1004 specified for an entry, a "populate from packet" (PFP) flag may be 1005 asserted for one or more of the selectors in the SPD entry (Local 1006 IP address; Remote IP address; Next Layer Protocol; and, depending 1007 on Next Layer Protocol, Local port and Remote port, or ICMP 1008 type/code, or Mobility Header type). If asserted for a given 1009 selector X, the flag indicates that the SA to be created should 1010 take its value for X from the value in the packet. Otherwise, the 1011 SA should take its value(s) for X from the value(s) in the SPD 1012 entry. Note: In the non-PFP case, the selector values negotiated 1013 by the SA management protocol (e.g., IKEv2) may be a subset of 1014 those in the SPD entry, depending on the SPD policy of the peer. 1015 Also, whether a single flag is used for, e.g., source port, ICMP 1016 type/code, and MH type, or a separate flag is used for each, is a 1017 local matter. 1019 The following example illustrates the use of the PFP flag in the 1020 context of a security gateway or a BITS/BITW implementation. 1021 Consider an SPD entry where the allowed value for Remote address 1022 is a range of IPv4 addresses: 192.168.2.1 to 192.168.2.10. Suppose 1023 an outbound packet arrives with a destination address of 1024 192.168.2.3, and there is no extant SA to carry this packet. The 1025 value used for the SA created to transmit this packet could be 1026 either of the two values shown below, depending on what the SPD 1027 entry for this selector says is the source of the selector value: 1029 PFP flag value example of new 1030 for the Remote SAD dest. address 1031 addr. selector selector value 1032 --------------- ------------ 1033 a. PFP TRUE 192.168.2.3 (one host) 1034 b. PFP FALSE 192.168.2.1 to 192.168.2.10 (range of hosts) 1036 Note that if the SPD entry above had a value of ANY for the Remote 1037 address, then the SAD selector value would have to be ANY for case 1038 (b), but would still be as illustrated for case (a). Thus the PFP 1039 flag can be used to prohibit sharing of an SA, even among packets 1040 that match the same SPD entry. 1042 Management Interface 1044 For every IPsec implementation, there MUST be a management 1045 interface that allows a user or system administrator to manage the 1046 SPD. The interface must allow the user (or administrator) to 1047 specify the security processing to be applied to every packet that 1048 traverses the IPsec boundary. (In a native host IPsec 1049 implementation making use of a socket interface, the SPD may not 1050 need to be consulted on a per packet basis, as noted above.) The 1051 management interface for the SPD MUST allow creation of entries 1052 consistent with the selectors defined in Section 4.4.1.1, and MUST 1053 support (total) ordering of these entries, as seen via this 1054 interface. The SPD entries' selectors are analogous to the ACL or 1055 packet filters commonly found in a stateless firewall or packet 1056 filtering router and which are currently managed this way. 1058 In host systems, applications MAY be allowed to create SPD 1059 entries. (The means of signaling such requests to the IPsec 1060 implementation are outside the scope of this standard.) However, 1061 the system administrator MUST be able to specify whether or not a 1062 user or application can override (default) system policies. The 1063 form of the management interface is not specified by this document 1064 and may differ for hosts vs. security gateways, and within hosts 1065 the interface may differ for socket-based vs. BITS 1066 implementations. However, this document does specify a standard 1067 set of SPD elements that all IPsec implementations MUST support. 1069 Decorrelation 1071 The processing model described in this document assumes the 1072 ability to decorrelate overlapping SPD entries to permit caching, 1073 which enables more efficient processing of outbound traffic in 1074 security gateways and BITS/BITW implementations. Decorrelation 1075 [CoSa04] is only a means of improving performance and simplifying 1076 the processing description. This RFC does not require a compliant 1077 implementation to make use of decorrelation. For example, native 1078 host implementations typically make use of caching implicitly 1079 because they bind SAs to socket interfaces, and thus there is no 1080 requirement to be able to decorrelate SPD entries in these 1081 implementations. 1083 Note: Unless otherwise qualified, the use of "SPD" refers to the 1084 body of policy information in both ordered or decorrelated 1085 (unordered) state. ppendix B provides an algorithm that can be 1086 used to decorrelate SPD entries, but any algorithm that produces 1087 equivalent output may be used. Note that when an SPD entry is 1088 decorrelated all the resulting entries MUST be linked together, so 1089 that all members of the group derived from an individual, SPD 1090 entry (prior to decorrelation) can all be placed into caches and 1091 into the SAD at the same time. For example, suppose one starts 1092 with an entry A (from an ordered SPD) that when decorrelated, 1093 yields entries A1, A2 and A3. When a packet comes along that 1094 matches, say A2, and triggers the creation of an SA, the SA 1095 management protocol, e.g., IKEv2, negotiates A. And all 3 1096 decorrelated entries, A1, A2, and A3 are placed in the appropriate 1097 SPD-S cache and linked to the SA. The intent is that use of a 1098 decorrelated SPD ought not to create more SAs than would have 1099 resulted from use of a not-decorrelated SPD. Note also that if a 1100 decorrelated SPD is employed, the original entry from the 1101 (correlated) SPD should be retained and passed to the SA 1102 management protocol, e.g., IKE. Passing the correlated SPD entry 1103 to the SA management protocol keeps the use of a decorrelated SPD 1104 a local matter, not visible to peers. When acting as a responder, 1105 the peer uses a correlated SPD entry for matching, and for issuing 1106 a "narrowed" response. Then the decorrelated entries are used to 1107 populate the SPD-S cache. 1109 Handling Changes to the SPD while the System is Running 1111 If a change is made to the SPD while the system is running, a 1112 check SHOULD be made of the effect of this change on extant SAs. 1113 An implementation SHOULD check the impact of an SPD change on 1114 extant SAs and SHOULD provide a user/administrator with a 1115 mechanism for configuring what actions to take, e.g., delete an 1116 affected SA, allow an affected SA to continue unchanged, etc. 1118 4.4.1.1 Selectors 1120 An SA may be fine-grained or coarse-grained, depending on the 1121 selectors used to define the set of traffic for the SA. For example, 1122 all traffic between two hosts may be carried via a single SA, and 1123 afforded a uniform set of security services. Alternatively, traffic 1124 between a pair of hosts might be spread over multiple SAs, depending 1125 on the applications being used (as defined by the Next Layer Protocol 1126 and related fields, e.g., ports), with different security services 1127 offered by different SAs. Similarly, all traffic between a pair of 1128 security gateways could be carried on a single SA, or one SA could be 1129 assigned for each communicating host pair. The following selector 1130 parameters MUST be supported by all IPsec implementations to 1131 facilitate control of SA granularity. Note that both Local and Remote 1132 addresses should either be IPv4 or IPv6, but not a mix of address 1133 types. Also, note that the Local/Remote port selectors (and ICMP 1134 message type and code, and Mobility Header type) may be labeled as 1135 OPAQUE to accommodate situations where these fields are inaccessible 1136 due to packet fragmentation. 1138 - Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges 1139 of IP addresses (unicast, anycast, broadcast (IPv4 only), or 1140 multicast group). This structure allows expression of a single 1141 IP address (via a trivial range), or a list of addresses (each a 1142 trivial range), or a range of addresses (low and high values, 1143 inclusive), as well as the most generic form of a list of 1144 ranges. Address ranges are used to support more than one remote 1145 system sharing the same SA, e.g., behind a security gateway. 1147 - Local IP Address(es) (IPv4 or IPv6): this is a list of ranges of 1148 IP addresses (unicast, anycast, broadcast (IPv4 only), or 1149 multicast group). This structure allows expression of a single 1150 IP address (via a trivial range), or a list of addresses (each a 1151 trivial range), or a range of addresses (low and high values, 1152 inclusive), as well as the most generic form of a list of 1153 ranges. Address ranges are used to support more than one source 1154 system sharing the same SA, e.g., behind a security gateway. 1155 Local refers to the address(es) being protected by this 1156 implementation (or policy entry). 1158 - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the 1159 IPv6 "Next Header" fields. This is an individual protocol 1160 number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol 1161 is whatever comes after any IP extension headers that are 1162 present. To simplify locating the Next Layer Protocol, there 1163 SHOULD be a mechanism for configuring which IPv6 extension 1164 headers to skip. The default configuration for which protocols 1165 to skip SHOULD include the following protocols: 0 (Hop-by-hop 1166 options), 43 (Routing Header), 44 (Fragmentation Header), and 60 1167 (Destination Options). Note: The default list does NOT include 1168 51 (AH), or 50 (ESP). From a selector lookup point of view, 1169 IPsec treats AH and ESP as Next Layer Protocols. 1171 Several additional selectors depend on the Next Layer Protocol 1172 value: 1174 * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, 1175 SCTP, ...), then there are selectors for Local and Remote 1176 Ports. Each of these selectors has a list of ranges of 1177 values. Note that the Local and Remote ports may not be 1178 available in the case of receipt of a fragmented packet or if 1179 the port fields have been protected by IPsec (encrypted), 1180 thus a value of OPAQUE also MUST be supported. Note: In a 1181 non-initial fragment, port values will not be available. If a 1182 port selector specifies a value other than ANY or OPAQUE, it 1183 cannot match packets that are non-initial fragments. If the 1184 SA requires a port value other than ANY or OPAQUE, an 1185 arriving fragment without ports MUST be discarded. (See 1186 Section 7 Handling Fragments.) 1188 * If the Next Layer Protocol is a Mobility Header, then there 1189 is a selector for IPv6 Mobility Header Message Type (MH type) 1190 [Mobip]. This is an 8-bit value that identifies a particular 1191 mobility message. Note that the MH type may not be available 1192 in the case of receipt of a fragmented packet. (See Section 7 1193 Handling Fragments.) For IKE, the IPv6 mobility header 1194 message type (MH type) is placed in the most significant 1195 eight bits of the 16 bit local "port" selector. 1197 * If the Next Layer Protocol value is ICMP then there is a 1198 16-bit selector for the ICMP message type and code. The 1199 message type is a single 8-bit value, which defines the type 1200 of an ICMP message, or ANY. The ICMP code is a single 8-bit 1201 value that defines a specific subtype for an ICMP message. 1203 For IKE, the message type is placed in the most significant 8 1204 bits of the 16-bit selector and the code is placed in the 1205 least significant 8 bits. This 16-bit selector can contain a 1206 single type and a range of codes, a single type and ANY code, 1207 ANY type and ANY code. Given a policy entry with a range of 1208 Types (T-start to T-end) and a range of Codes (C-start to C- 1209 end), and an ICMP packet with Type t and Code c, an 1210 implementation MUST test for a match using 1212 (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + 1213 C-end 1215 Note that the ICMP message type and code may not be available 1216 in the case of receipt of a fragmented packet. (See Section 7 1217 Handling Fragments.) 1219 - Name: This is not a selector like the others above. It is not 1220 acquired from a packet. A name may be used as a symbolic 1221 identifier for an IPsec Local or Remote address. Named SPD 1222 entries are used in two ways: 1224 1. A named SPD entry is used by a responder (not an initiator) 1225 in support of access control when an IP address would not be 1226 appropriate for the Remote IP address selector, e.g., for 1227 "road warriors." The name used to match this field is 1228 communicated during the IKE negotiation in the ID payload. 1229 In this context, the initiator's Source IP address (inner IP 1230 header in tunnel mode) is bound to the Remote IP address in 1231 the SAD entry created by the IKE negotiation. This address 1232 overrides the Remote IP address value in the SPD, when the 1233 SPD entry is selected in this fashion. All IPsec 1234 implementations MUST support this use of names. 1236 2. A named SPD entry may be used by an initiator to identify a 1237 user for whom an IPsec SA will be created (or for whom 1238 traffic may be bypassed). The initiator's IP source address 1239 (from inner IP header in tunnel mode) is used to replace the 1240 following if and when they are created: 1242 - local address in the SPD cache entry 1243 - local address in the outbound SAD entry 1244 - remote address in the inbound SAD entry 1246 Support for this use is optional for multi-user, native host 1247 implementations and not applicable to other implementations. 1248 Note that this name is used only locally; it is not 1249 communicated by the key management protocol. 1251 An SPD entry can contain both a name (or a list of names) and 1252 also values for the Local or Remote IP address. The identifiers 1253 employed in named SPD entries are one of the following four 1254 types: 1256 a. a fully qualified user name string (email), e.g., 1257 mozart@foo.example.com 1258 (this corresponds to ID_RFC822_ADDR in IKEv2) 1260 b. a fully qualified DNS name, e.g., 1261 foo.example.com 1262 (this corresponds to ID_FQDN in IKEv2) 1264 c. X.500 distinguished name, e.g., 1265 C = US, SP = MA, 1266 O = BBN Technologies, CN = Stephen T. Kent 1267 (this corresponds to ID_DER_ASN1_DN in IKEv2, after 1268 decoding) 1270 d. a byte string 1271 (this corresponds to Key_ID in IKEv2) 1273 The IPsec implementation context determines how selectors are used. 1274 For example, a native host implementation typically makes use of a 1275 socket interface. When a new connection is established the SPD can 1276 be consulted and an SA bound to the socket. Thus traffic sent via 1277 that socket need not result in additional lookups to the SPD (SPD-O 1278 and SPD-S) cache. In contrast, a BITS, BITW, or security gateway 1279 implementation needs to look at each packet and perform an 1280 SPD-O/SPD-S cache lookup based on the selectors. 1282 4.4.1.2 Structure of an SPD entry 1284 This section contains a prose description of an SPD entry. Also, 1285 Appendix C provides an example of an ASN.1 definition of an SPD 1286 entry. 1288 This text describes the SPD in a fashion that maps directly into IKE 1289 payloads to ensure that the policy required by SPD entries can be 1290 negotiated through IKE. The management GUI can offer the user other 1291 forms of data entry and display, e.g., the option of using address 1292 prefixes as well as ranges, and symbolic names for protocols, ports, 1293 etc. (Do not confuse the use of symbolic names in a management 1294 interface with the SPD selector "Name".) Note that Remote/Local apply 1295 only to IP addresses and ports, not to ICMP message type/code or 1296 Mobility Header type. Also, if the reserved, symbolic selector value 1297 OPAQUE or ANY is employed for a given selector type, only that value 1298 may appear in the list for that selector, and it must appear only 1299 once in the list for that selector. Note that ANY and OPAQUE are 1300 local syntax conventions -- IKEv2 negotiates these values via the 1301 ranges indicated below: 1303 ANY: start = 0 end = 1304 OPAQUE: start = end = 0 1306 An SPD is an ordered list of entries each of which contains the 1307 following fields. 1309 o Name -- a list of IDs. This quasi-selector is optional. 1310 The forms that MUST be supported are described above in 1311 Section 4.4.1.1 under "Name". 1313 o PFP flags -- one per traffic selector. A given flag, e.g., 1314 for Next Layer Protocol, applies to the relevant selector 1315 across all "selector sets" (see below) contained in an SPD 1316 entry. When creating an SA, each flag specifies for the 1317 corresponding traffic selector whether to instantiate the 1318 selector from the corresponding field in the packet that 1319 triggered the creation of the SA or from the value(s) in the 1320 corresponding SPD entry (see Section 4.4.1, "How To Derive 1321 the Values for an SAD entry"). Whether a single flag is used 1322 for, e.g., source port, ICMP type/code, and MH type, or a 1323 separate flag is used for each, is a local matter. There 1324 are PFP flags for: 1325 - Local Address 1326 - Remote Address 1327 - Next Layer Protocol 1328 - Local Port, or ICMP message type/code or Mobility 1329 Header type (depending on the next layer protocol) 1330 - Remote Port, or ICMP message type/code or Mobility 1331 Header type (depending on the next layer protocol) 1333 o One to N selector sets that correspond to the "condition" 1334 for applying a particular IPsec action. Each selector set 1335 contains: 1336 - Local Address 1337 - Remote Address 1338 - Next Layer Protocol 1339 - Local Port, or ICMP message type/code or Mobility 1340 Header type (depending on the next layer protocol) 1341 - Remote Port, or ICMP message type/code or Mobility 1342 Header type (depending on the next layer protocol) 1344 Note: The "next protocol" selector is an individual value 1345 (unlike the local and remote IP addresses) in a selector 1346 set entry. This is consistent with how IKE v2 negotiates 1347 the TS values for an SA. It also makes sense because one 1348 may need to associate different port fields with different 1349 protocols. It is possible to associate multiple protocols 1350 (and ports) with a single SA by specifying multiple selector 1351 sets for that SA. 1353 o processing info -- which action is required -- PROTECT, 1354 BYPASS, or DISCARD. There is just one action that goes with 1355 all the selector sets, not a separate action for each set. 1356 If the required processing is PROTECT, the entry contains 1357 the following information. 1358 - IPsec mode -- tunnel or transport 1359 - (if tunnel mode) local tunnel address -- For a 1360 non-mobile host, if there is just one interface, this 1361 is straightforward; and if there are multiple 1362 interfaces, this must be statically configured. For a 1363 mobile host, the specification of the local address 1364 is handled externally to IPsec. 1365 - (if tunnel mode) remote tunnel address -- There is no 1366 standard way to determine this. See 4.5.3 "Locating a 1367 Security Gateway". 1368 - extended sequence number -- Is this SA using extended 1369 sequence numbers? 1370 - stateful fragment checking -- Is this SA using stateful 1371 fragment checking (see Section 7 for more details) 1372 - Bypass DF bit (T/F) - applicable to tunnel mode SAs 1373 - Bypass DSCP (T/F) or map to unprotected DSCP values 1374 (array) if needed to restrict bypass of DSCP values - 1375 applicable to tunnel mode SAs 1376 - IPsec protocol - AH or ESP 1377 - algorithms -- which ones to use for AH, which ones to 1378 use for ESP, which ones to use for combined mode, 1379 ordered by decreasing priority 1381 It is a local matter as to what information is kept with regard to 1382 handling extant SAs when the SPD is changed. 1384 4.4.1.3 More re: Fields Associated with Next Layer Protocols 1386 Additional selectors are often associated with fields in the Next 1387 Layer Protocol header. A particular Next Layer Protocol can have 1388 zero, one, or two selectors. There may be situations where there 1389 aren't both local and remote selectors for the fields that are 1390 dependent on the Next Layer Protocol. The IPv6 Mobility Header has 1391 only a Mobility Header message type. AH and ESP have no further 1392 selector fields. A system may be willing to send an ICMP message 1393 type and code that it does not want to receive. In the descriptions 1394 below, "port" is used to mean a field that is dependent on the Next 1395 Layer Protocol. 1397 A. If a Next Layer Protocol has no "port" selectors, then 1398 the Local and Remote "port" selectors are set to OPAQUE in 1399 the relevant SPD entry, e.g., 1401 Local's 1402 next layer protocol = AH 1403 "port" selector = OPAQUE 1405 Remote's 1406 next layer protocol = AH 1407 "port" selector = OPAQUE 1409 B. If a Next Layer Protocol has only one selector, e.g., 1410 Mobility Header type, then that field is placed in the 1411 Local "port" selector in the relevant SPD entry, and the 1412 Remote "port" selector is set to OPAQUE in the relevant 1413 SPD entry, e.g., 1415 Local's 1416 next layer protocol = Mobility Header 1417 "port" selector = Mobility Header message type 1419 Remote's 1420 next layer protocol = Mobility Header 1421 "port" selector = OPAQUE 1423 C. If a system is willing to send traffic with a particular 1424 "port" value but NOT receive traffic with that kind of 1425 port value, the system's traffic selectors are set as 1426 follows in the relevant SPD entry: 1428 Local's 1429 next layer protocol = ICMP 1430 "port" selector = 1432 Remote's 1433 next layer protocol = ICMP 1434 "port" selector = OPAQUE 1436 D. To indicate that a system is willing to receive traffic 1437 with a particular "port" value but NOT send that kind of 1438 traffic, the system's traffic selectors are set as follows 1439 in the relevant SPD entry: 1441 Local's 1442 next layer protocol = ICMP 1443 "port" selector = OPAQUE 1445 Remote's 1446 next layer protocol = ICMP 1447 "port" selector = 1449 For example, if a security gateway is willing to allow 1450 systems behind it to send ICMP traceroutes, but is not 1451 willing to let outside systems run ICMP traceroutes to 1452 systems behind it, then the security gateway's traffic 1453 selectors are set as follows in the relevant SPD entry: 1455 Local's 1456 next layer protocol = 1 (ICMPv4) 1457 "port" selector = 30 (traceroute) 1459 Remote's 1460 next layer protocol = 1 (ICMPv4) 1461 "port" selector = OPAQUE 1463 4.4.2 Security Association Database (SAD) 1465 In each IPsec implementation there is a nominal Security Association 1466 Database(SAD), in which each entry defines the parameters associated 1467 with one SA. Each SA has an entry in the SAD. For outbound 1468 processing, each SAD entry is pointed to by entries in the SPD-S part 1469 of the SPD cache. For inbound processing, for unicast SAs, the SPI is 1470 used either alone to look up an SA, or the SPI may be used in 1471 conjunction with the IPsec protocol type. If an IPsec implementation 1472 supports multicast, the SPI plus destination address, or SPI plus 1473 destination and source addresses are used to look up the SA. (See 1474 Section 4.1 for details on the algorithm that MUST be used for 1475 mapping inbound IPsec datagrams to SAs.) The following parameters are 1476 associated with each entry in the SAD. They should all be present 1477 except where otherwise noted, e.g., AH Authentication algorithm. This 1478 description does not purport to be a MIB, only a specification of the 1479 minimal data items required to support an SA in an IPsec 1480 implementation. 1482 For each of the selectors defined in Section 4.4.1.1, the entry for 1483 an inbound SA in the SAD MUST be initially populated with the value 1484 or values negotiated at the time the SA was created. (See Section 1485 4.4.1, paragraph on Handling Changes to the SPD while the System is 1486 Running for guidance on the effect of SPD changes on extant SAs.) For 1487 a receiver, these values are used to check that the header fields of 1488 an inbound packet (after IPsec processing) match the selector values 1489 negotiated for the SA. Thus, the SAD acts as a cache for checking the 1490 selectors of inbound traffic arriving on SAs. For the receiver, this 1491 is part of verifying that a packet arriving on an SA is consistent 1492 with the policy for the SA. (See Section 6 for rules for ICMP 1493 messages.) These fields can have the form of specific values, 1494 ranges, ANY, or OPAQUE, as described in section 4.4.1.1, "Selectors." 1496 4.4.2.1 Data Items in the SAD 1498 The following data items MUST be in the SAD: 1500 o Security Parameter Index (SPI): a 32-bit value selected by the 1501 receiving end of an SA to uniquely identify the SA. In an SAD 1502 entry for an outbound SA, the SPI is used to construct the 1503 packet's AH or ESP header. In an SAD entry for an inbound SA, the 1504 SPI is used to map traffic to the appropriate SA (see text on 1505 unicast/multicast in Section 4.1). 1507 o Sequence Number Counter: a 64-bit counter used to generate the 1508 Sequence Number field in AH or ESP headers. 64-bit sequence 1509 numbers are the default, but 32-bit sequence numbers are also 1510 supported if negotiated. 1512 o Sequence Counter Overflow: a flag indicating whether overflow of 1513 the Sequence Number Counter should generate an auditable event and 1514 prevent transmission of additional packets on the SA, or whether 1515 rollover is permitted. The audit log entry for this event SHOULD 1516 include the SPI value, current date/time, Local Address, Remote 1517 Address, and the selectors from the relevant SAD entry. 1519 o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) 1520 used to determine whether an inbound AH or ESP packet is a replay. 1522 Note: If anti-replay has been disabled by the receiver for an SA, 1523 e.g., in the case of a manually keyed SA, then the Anti-Replay 1524 Window is ignored for the SA in question. 64-bit sequence numbers 1525 are the default, but this counter size accommodates 32-bit 1526 sequence numbers as well. 1528 o AH Authentication algorithm, key, etc. This is required only if AH 1529 is supported. 1531 o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode 1532 algorithm is used, these fields will not be applicable. 1534 o ESP integrity algorithm, keys, etc. If the integrity service is 1535 not selected, these fields will not be applicable. If a combined 1536 mode algorithm is used, these fields will not be applicable. 1538 o ESP combined mode algorithms, key(s), etc. This data is used when 1539 a combined mode (encryption and integrity) algorithm is used with 1540 ESP. If a combined mode algorithm is not used, these fields are 1541 not applicable. 1543 o Lifetime of this SA: a time interval after which an SA must be 1544 replaced with a new SA (and new SPI) or terminated, plus an 1545 indication of which of these actions should occur. This may be 1546 expressed as a time or byte count, or a simultaneous use of both 1547 with the first lifetime to expire taking precedence. A compliant 1548 implementation MUST support both types of lifetimes, and MUST 1549 support a simultaneous use of both. If time is employed, and if 1550 IKE employs X.509 certificates for SA establishment, the SA 1551 lifetime must be constrained by the validity intervals of the 1552 certificates, and the NextIssueDate of the CRLs used in the IKE 1553 exchange for the SA. Both initiator and responder are responsible 1554 for constraining the SA lifetime in this fashion. Note: The 1555 details of how to handle the refreshing of keys when SAs expire is 1556 a local matter. However, one reasonable approach is: 1558 (a) If byte count is used, then the implementation SHOULD count the 1559 number of bytes to which the IPsec cryptographic algorithm is 1560 applied. For ESP, this is the encryption algorithm (including 1561 Null encryption) and for AH, this is the authentication 1562 algorithm. This includes pad bytes, etc. Note that 1563 implementations MUST be able to handle having the counters at 1564 the ends of an SA get out of synch, e.g., because of packet 1565 loss or because the implementations at each end of the SA 1566 aren't doing things the same way. 1568 (b) There SHOULD be two kinds of lifetime -- a soft lifetime that 1569 warns the implementation to initiate action such as setting up 1570 a replacement SA; and a hard lifetime when the current SA ends 1571 and is destroyed. 1573 (c) If the entire packet does not get delivered during the SAs 1574 lifetime, the packet SHOULD be discarded. 1576 o IPsec protocol mode: tunnel or transport. Indicates which mode of 1577 AH or ESP is applied to traffic on this SA. 1579 o Stateful fragment checking flag. Indicates whether or not stateful 1580 fragment checking applies to this SA. 1582 o Bypass DF bit (T/F) - applicable to tunnel mode SAs 1584 o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if 1585 needed to restrict bypass of DSCP values - applicable to tunnel 1586 mode SAs 1588 o Path MTU: any observed path MTU and aging variables. 1590 o Tunnel header IP source and destination address - both addresses 1591 must be either IPv4 or IPv6 addresses. The version implies the 1592 type of IP header to be used. Only used when the IPsec protocol 1593 mode is tunnel. 1595 4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD 1597 For each selector, the following tables show the relationship 1598 between the value in the SPD, the PFP flag, the value in the 1599 triggering packet and the resulting value in the SAD. Note that 1600 the administrative interface for IPsec can use various syntactic 1601 options to make it easier for the administrator to enter rules. 1602 For example, although a list of ranges is what IKEv2 sends, it 1603 might be clearer and less error prone for the user to enter a 1604 single IP address or IP address prefix. 1606 Value in 1607 Triggering Resulting SAD 1608 Selector SPD Entry PFP Packet Entry 1609 -------- ---------------- --- ------------ -------------- 1610 loc addr list of ranges 0 IP addr "S" list of ranges 1611 ANY 0 IP addr "S" ANY 1612 list of ranges 1 IP addr "S" "S" 1613 ANY 1 IP addr "S" "S" 1615 rem addr list of ranges 0 IP addr "D" list of ranges 1616 ANY 0 IP addr "D" ANY 1617 list of ranges 1 IP addr "D" "D" 1618 ANY 1 IP addr "D" "D" 1620 protocol list of prot's* 0 prot. "P" list of prot's* 1621 ANY** 0 prot. "P" ANY 1622 OPAQUE**** 0 prot. "P" OPAQUE 1624 list of prot's* 0 not avail. discard packet 1625 ANY** 0 not avail. ANY 1626 OPAQUE**** 0 not avail. OPAQUE 1628 list of prot's* 1 prot. "P" "P" 1629 ANY** 1 prot. "P" "P" 1630 OPAQUE**** 1 prot. "P" *** 1632 list of prot's* 1 not avail. discard packet 1633 ANY** 1 not avail. discard packet 1634 OPAQUE**** 1 not avail. *** 1636 If the protocol is one that has two ports then there will be 1637 selectors for both Local and Remote ports. 1639 Value in 1640 Triggering Resulting SAD 1641 Selector SPD Entry PFP Packet Entry 1642 -------- ---------------- --- ------------ -------------- 1643 loc port list of ranges 0 src port "s" list of ranges 1644 ANY 0 src port "s" ANY 1645 OPAQUE 0 src port "s" OPAQUE 1647 list of ranges 0 not avail. discard packet 1648 ANY 0 not avail. ANY 1649 OPAQUE 0 not avail. OPAQUE 1651 list of ranges 1 src port "s" "s" 1652 ANY 1 src port "s" "s" 1653 OPAQUE 1 src port "s" *** 1655 list of ranges 1 not avail. discard packet 1656 ANY 1 not avail. discard packet 1657 OPAQUE 1 not avail. *** 1659 rem port list of ranges 0 dst port "d" list of ranges 1660 ANY 0 dst port "d" ANY 1661 OPAQUE 0 dst port "d" OPAQUE 1663 list of ranges 0 not avail discard packet 1664 ANY 0 not avail ANY 1665 OPAQUE 0 not avail. OPAQUE 1667 list of ranges 1 dst port "d" "d" 1668 ANY 1 dst port "d" "d" 1669 OPAQUE 1 dst port "d" *** 1671 list of ranges 1 not avail. discard packet 1672 ANY 1 not avail. discard packet 1673 OPAQUE 1 not avail. *** 1675 If the protocol is mobility header then there will be a selector 1676 for mh type. 1678 Value in 1679 Triggering Resulting SAD 1680 Selector SPD Entry PFP Packet Entry 1681 -------- ---------------- --- ------------ -------------- 1682 mh type list of ranges 0 mh type "T" list of ranges 1683 ANY 0 mh type "T" ANY 1684 OPAQUE 0 mh type "T" OPAQUE 1686 list of ranges 0 not avail. discard packet 1687 ANY 0 not avail. ANY 1688 OPAQUE 0 not avail. OPAQUE 1690 list of ranges 1 mh type "T" "T" 1691 ANY 1 mh type "T" "T" 1692 OPAQUE 1 mh type "T" *** 1694 list of ranges 1 not avail. discard packet 1695 ANY 1 not avail. discard packet 1696 OPAQUE 1 not avail. *** 1698 If the protocol is ICMP, then there will be a 16-bit selector for 1699 ICMP type and ICMP code. Note that the type and code are bound to 1700 each other, i.e., the codes apply to the particular type. This 1701 16-bit selector can contain a single type and a range of codes, a 1702 single type and ANY code, and ANY type and ANY code. 1704 Value in 1705 Triggering Resulting SAD 1706 Selector SPD Entry PFP Packet Entry 1707 --------- ---------------- --- ------------ -------------- 1708 ICMP type a single type & 0 type "t" & single type & 1709 and code range of codes code "c" range of codes 1710 a single type & 0 type "t" & single type & 1711 ANY code code "c" ANY code 1712 ANY type & ANY 0 type "t" & ANY type & 1713 code code "c" ANY code 1714 OPAQUE 0 type "t" & OPAQUE 1715 code "c" 1717 a single type & 0 not avail. discard packet 1718 range of codes 1719 a single type & 0 not avail. discard packet 1720 ANY code 1721 ANY type & 0 not avail. ANY type & 1722 ANY code ANY code 1723 OPAQUE 0 not avail. OPAQUE 1725 a single type & 1 type "t" & "t" and "c" 1726 range of codes code "c" 1727 a single type & 1 type "t" & "t" and "c" 1728 ANY code code "c" 1729 ANY type & 1 type "t" & "t" and "c" 1730 ANY code code "c" 1731 OPAQUE 1 type "t" & *** 1732 code "c" 1734 a single type & 1 not avail. discard packet 1735 range of codes 1736 a single type & 1 not avail. discard packet 1737 ANY code 1738 ANY type & 1 not avail. discard packet 1739 ANY code 1740 OPAQUE 1 not avail. *** 1742 If the name selector is used... 1744 Value in 1745 Triggering Resulting SAD 1746 Selector SPD Entry PFP Packet Entry 1747 --------- ---------------- --- ------------ -------------- 1748 name list of system- N/A packet from N/A 1749 dependent user or 1750 user or sys. system 1751 names 1753 * "List of protocols" is the information, not the way 1754 that the SPD or SAD or IKv2 have to represent this 1755 information. 1756 ** 0 (zero) is used by IKE to indicate ANY for 1757 protocol. 1758 *** Use of PFP=1 with an OPAQUE value is an error and 1759 SHOULD be prohibited by an IPsec implementation. 1760 **** The protocol field cannot be OPAQUE in IPv4. This 1761 table entry applies only to IPv6. 1763 4.4.3 Peer Authorization Database (PAD) 1765 The Peer Authorization Database (PAD) provides a link between an SA 1766 management protocol like IKE and the SPD. The PAD indicates the range 1767 of identities that an IPv4 or IPv6 peer is authorized to represent 1768 when (child) SAs are negotiated with the peer. The identities may be 1769 a list of IPv4 or IPv6 address ranges or a set of symbolic names. 1770 The IP version of the identities does not have to be the same as that 1771 of the IP version of the peer representing them. The fundamental 1772 requirement associated with the PAD is that the traffic selectors 1773 passed by the SA management protocol for comparison against the SPD 1774 MUST be verified as authorized relative to the authenticated peer of 1775 the SA management protocol. (See also Section 4.5.3, which levies 1776 requirements on the PAD in support of locating security gateways.) 1778 The PAD also specifies how to authenticate each peer, e.g., via 1779 shared secret or use of a certificate. If a shared secret is used, 1780 the secret is stored here. If a certificate is to be used, a trust 1781 anchor for validating the certificate is available via the PAD. The 1782 PAD also MAY include data in support of certificate revocation status 1783 checking, if this information is not otherwise available from the 1784 trust anchor or the peer's certificate. Because the PAD might be 1785 incorporated into the SA management protocol implementation, it is 1786 not discussed extensively in this document. 1788 4.5 SA and Key Management 1790 All IPsec implementations MUST support both manual and automated SA 1791 and cryptographic key management. The IPsec protocols, AH and ESP, 1792 are largely independent of the associated SA management techniques, 1793 although the techniques involved do affect some of the security 1794 services offered by the protocols. For example, the optional anti- 1795 replay service available for AH and ESP requires automated SA 1796 management. Moreover, the granularity of key distribution employed 1797 with IPsec determines the granularity of authentication provided. In 1798 general, data origin authentication in AH and ESP is limited by the 1799 extent to which secrets used with the integrity algorithm (or with a 1800 key management protocol that creates such secrets) are shared among 1801 multiple possible sources. 1803 The following text describes the minimum requirements for both types 1804 of SA management. 1806 4.5.1 Manual Techniques 1808 The simplest form of management is manual management, in which a 1809 person manually configures each system with keying material and SA 1810 management data relevant to secure communication with other systems. 1811 Manual techniques are practical in small, static environments but 1812 they do not scale well. For example, a company could create a 1813 Virtual Private Network (VPN) using IPsec in security gateways at 1814 several sites. If the number of sites is small, and since all the 1815 sites come under the purview of a single administrative domain, this 1816 might be a feasible context for manual management techniques. In 1817 this case, the security gateway might selectively protect traffic to 1818 and from other sites within the organization using a manually 1819 configured key, while not protecting traffic for other destinations. 1820 It also might be appropriate when only selected communications need 1821 to be secured. A similar argument might apply to use of IPsec 1822 entirely within an organization for a small number of hosts and/or 1823 gateways. Manual management techniques often employ statically 1824 configured, symmetric keys, though other options also exist. 1826 4.5.2 Automated SA and Key Management 1828 Widespread deployment and use of IPsec requires an Internet-standard, 1829 scalable, automated, SA management protocol. Such support is required 1830 to facilitate use of the anti-replay features of AH and ESP, and to 1831 accommodate on-demand creation of SAs, e.g., for user- and session- 1832 oriented keying. (Note that the notion of "rekeying" an SA actually 1833 implies creation of a new SA with a new SPI, a process that generally 1834 implies use of an automated SA/key management protocol.) 1836 The default automated key management protocol selected for use with 1837 IPsec is IKEv2 [Kau04]. This document assumes the availability of 1838 certain functions from the key management protocol which are not 1839 supported by IKEv1. Other automated SA management protocols MAY be 1840 employed. 1842 When an automated SA/key management protocol is employed, the output 1843 from this protocol is used to generate multiple keys for a single SA. 1844 This also occurs because distinct keys are used for each of the two 1845 SAs created by IKE. If both integrity and confidentiality are 1846 employed, then a minimum of four keys are required. Additionally, 1847 some cryptographic algorithms may require multiple keys, e.g., 3DES. 1849 The Key Management System may provide a separate string of bits for 1850 each key or it may generate one string of bits from which all keys 1851 are extracted. If a single string of bits is provided, care needs to 1852 be taken to ensure that the parts of the system that map the string 1853 of bits to the required keys do so in the same fashion at both ends 1854 of the SA. To ensure that the IPsec implementations at each end of 1855 the SA use the same bits for the same keys, and irrespective of which 1856 part of the system divides the string of bits into individual keys, 1857 the encryption keys MUST be taken from the first (left-most, high- 1858 order) bits and the integrity keys MUST be taken from the remaining 1859 bits. The number of bits for each key is defined in the relevant 1860 cryptographic algorithm specification RFC. In the case of multiple 1861 encryption keys or multiple integrity keys, the specification for the 1862 cryptographic algorithm must specify the order in which they are to 1863 be selected from a single string of bits provided to the 1864 cryptographic algorithm. 1866 4.5.3 Locating a Security Gateway 1868 This section discusses issues relating to how a host learns about the 1869 existence of relevant security gateways and once a host has contacted 1870 these security gateways, how it knows that these are the correct 1871 security gateways. The details of where the required information is 1872 stored is a local matter, but the Peer Authorization Database 1873 described in Section 4.4 is the most likely candidate. (Note: S* 1874 indicates a system that is running IPsec, e.g., SH1 and SG2 below.) 1876 Consider a situation in which a remote host (SH1) is using the 1877 Internet to gain access to a server or other machine (H2) and there 1878 is a security gateway (SG2), e.g., a firewall, through which H1's 1879 traffic must pass. An example of this situation would be a mobile 1880 host (road warrior) crossing the Internet to his home organization's 1881 firewall (SG2). This situation raises several issues: 1883 1. How does SH1 know/learn about the existence of the security 1884 gateway SG2? 1886 2. How does it authenticate SG2, and once it has authenticated SG2, 1887 how does it confirm that SG2 has been authorized to represent H2? 1889 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to 1890 contact H2? 1892 4. How does SH1 know/learn about any additional gateways that provide 1893 alternate paths to H2? 1895 To address these problems, an IPsec-supporting host or security 1896 gateway MUST have an administrative interface that allows the 1897 user/administrator to configure the address of one or more security 1898 gateways for ranges of destination addresses that require its use. 1899 This includes the ability to configure information for locating and 1900 authenticating one or more security gateways and verifying the 1901 authorization of these gateways to represent the destination host. 1902 (The authorization function is implied in the PAD.) This document 1903 does not address the issue of how to automate the 1904 discovery/verification of security gateways. The IP Security Policy 1905 (IPSP) Working Group is a possible future source of guidance. One of 1906 its goals is to produce an Internet Draft on a "Security Gateway 1907 Discovery, Policy Exchange and Negotiation Protocol". 1909 4.6 SAs and Multicast 1911 The receiver-orientation of the SA implies that, in the case of 1912 unicast traffic, the destination system will select the SPI value. 1913 By having the destination select the SPI value, there is no potential 1914 for manually configured SAs to conflict with automatically configured 1915 (e.g., via a key management protocol) SAs or for SAs from multiple 1916 sources to conflict with each other. For multicast traffic, there 1917 are multiple destination systems associated with a single SA. So 1918 some system or person will need to coordinate among all multicast 1919 groups to select an SPI or SPIs on behalf of each multicast group and 1920 then communicate the group's IPsec information to all of the 1921 legitimate members of that multicast group via mechanisms not defined 1922 here. 1924 Multiple senders to a multicast group SHOULD use a single Security 1925 Association (and hence SPI) for all traffic to that group when a 1926 symmetric key encryption or integrity algorithm is employed. In such 1927 circumstances, the receiver knows only that the message came from a 1928 system possessing the key for that multicast group. In such 1929 circumstances, a receiver generally will not be able to authenticate 1930 which system sent the multicast traffic. Specifications for other, 1931 more general multicast approaches are deferred to the IETF Multicast 1932 Security Working Group. 1934 5. IP Traffic Processing 1936 As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", 1937 the SPD (or associated caches) MUST be consulted during the 1938 processing of all traffic that crosses the IPsec protection boundary, 1939 including IPsec management traffic. If no policy is found in the SPD 1940 that matches a packet (for either inbound or outbound traffic), the 1941 packet MUST be discarded. To simplify processing, and to allow for 1942 very fast SA lookups (for SG/BITS/BITW), this document introduces the 1943 notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), 1944 and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As 1945 mentioned earlier, the SAD acts as a cache for checking the selectors 1946 of inbound IPsec-protected traffic arriving on SAs.) There is 1947 nominally one cache per SPD. For the purposes of this specification, 1948 it is assumed that each cached entry will map to exactly one SA. 1949 Note, however, exceptions arise when one uses multiple SAs to carry 1950 traffic of different priorities (e.g., as indicated by distinct DSCP 1951 values) but the same selectors. 1953 Since SPD entries may overlap, one cannot safely cache these entries 1954 in general. Simple caching might result in a match against a cache 1955 entry whereas an ordered search of the SPD would have resulted in a 1956 match against a different entry. But, if the SPD entries are first 1957 decorrelated, then the resulting entries can safely be cached. Each 1958 cached entry will indicate that matching traffic should be bypassed 1959 or discarded, appropriately. (Note: The original SPD entry might 1960 result in multiple SAs, e.g., because of PFP.) Unless otherwise 1961 noted, all references below to the "SPD" or "SPD cache" or "cache" 1962 are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache 1963 containing entries from the decorrelated SPD. 1965 Note: In a host IPsec implementation based on sockets, the SPD will 1966 be consulted whenever a new socket is created, to determine what, if 1967 any, IPsec processing will be applied to the traffic that will flow 1968 on that socket. This provides an implicit caching mechanism and the 1969 portions of the preceding discussion that address caching can be 1970 ignored in such implementations. 1972 Note: It is assumed that one starts with a correlated SPD because 1973 that is how users and administrators are accustomed to managing these 1974 sorts of access control lists or firewall filter rules. Then the 1975 decorrelation algorithm is applied to build a list of cache-able SPD 1976 entries. The decorrelation is invisible at the management interface. 1978 For inbound IPsec traffic, the SAD entry selected by the SPI serves 1979 as the cache for the selectors to be matched against arriving IPsec 1980 packets, after AH or ESP processing has been performed. 1982 5.1 Outbound IP Traffic Processing (protected-to-unprotected) 1984 First consider the path for traffic entering the implementation via a 1985 protected interface and exiting via an unprotected interface. 1987 Unprotected Interface 1988 ^ 1989 | 1990 (nested SAs) +----------+ 1991 -------------------|Forwarding|<-----+ 1992 | +----------+ | 1993 | ^ | 1994 | | BYPASS | 1995 V +-----+ | 1996 +-------+ | SPD | +--------+ 1997 ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec 1998 | (*) | | (*) |---->|(AH/ESP)| boundary 1999 +-------+ +-----+ +--------+ 2000 | +-------+ / ^ 2001 | |DISCARD| <--/ | 2002 | +-------+ | 2003 | | 2004 | +-------------+ 2005 |---------------->|SPD Selection| 2006 +-------------+ 2007 ^ 2008 | +------+ 2009 | -->| ICMP | 2010 | / +------+ 2011 |/ 2012 | 2013 | 2014 Protected Interface 2016 Figure 2. Processing Model for Outbound Traffic 2017 (*) = The SPD caches are shown here. If there 2018 is a cache miss, then the SPD is checked. 2019 There is no requirement that an 2020 implementation buffer the packet if 2021 there is a cache miss. 2023 IPsec MUST perform the following steps when processing outbound 2024 packets: 2026 1. When a packet arrives from the subscriber (protected) interface, 2027 invoke the SPD selection function to obtain the SPD-ID needed to 2028 choose the appropriate SPD. (If the implementation uses only one 2029 SPD, this step is a no-op.) 2031 2. Match the packet headers against the cache for the SPD specified 2032 by the SPD-ID from step 1. Note that this cache contains entries 2033 from SPD-O and SPD-S. 2035 3a. If there is a match, then process the packet as specified by the 2036 matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH 2037 or ESP. If IPsec processing is applied, there is a link from the 2038 SPD cache entry to the relevant SAD entry (specifying the mode, 2039 cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec 2040 processing is as previously defined, for tunnel or transport modes 2041 and for AH or ESP, as specified in their respective RFCs [Ken04b 2042 and Ken04a]. Note that the SA PMTU value, plus the value of the 2043 stateful fragment checking flag (and the DF bit in the IP header 2044 of the outbound packet) determine whether the packet can (must) be 2045 fragmented prior to or after IPsec processing, or if it must be 2046 discarded and an ICMP PMTU message is sent. 2048 3b. If no match is found in the cache, search the SPD (SPD-S and SPD- 2049 O parts) specified by SPD-ID. If the SPD entry calls for BYPASS or 2050 DISCARD, create one or more new outbound SPD cache entries and if 2051 BYPASS, create one or more new inbound SPD cache entries. (More 2052 than one cache entry may be created since a decorrelated SPD entry 2053 may be linked to other such entries that were created as a side 2054 effect of the decorrelation process.) If the SPD entry calls for 2055 PROTECT, i.e., creation of an SA, the key management mechanism 2056 (e.g., IKEv2) is invoked to create the SA. If SA creation 2057 succeeds, a new outbound (SPD-S) cache entry is created, along 2058 with outbound and inbound SAD entries, otherwise the packet is 2059 discarded. (A packet that triggers an SPD lookup MAY be discarded 2060 by the implementation, or it MAY be processed against the newly 2061 created cache entry, if one is created.) Since SAs are created in 2062 pairs, an SAD entry for the corresponding inbound SA also is 2063 created, and it contains the selector values derived from the SPD 2064 entry (and packet, if any PFP flags were "true") used to create 2065 the inbound SA, for use in checking inbound traffic delivered via 2066 the SA. 2068 4. The packet is passed to the outbound forwarding function 2069 (operating outside of the IPsec implementation), to select the 2070 interface to which the packet will be directed. This function may 2071 cause the packet to be passed back across the IPsec boundary, for 2072 additional IPsec processing, e.g., in support of nested SAs. If 2073 so, there MUST be an entry in SPD-I database that permits inbound 2074 bypassing of the packet, otherwise the packet will be discarded. 2075 If necessary, i.e., if there is more than one SPD-I, the traffic 2076 being looped back MAY be tagged as coming from this internal 2077 interface. This would allow the use of a different SPD-I for 2078 "real" external traffic vs looped traffic, if needed. 2080 Note: With the exception of IPv4 and IPv6 transport mode, an SG, 2081 BITS, or BITW implementation MAY fragment packets before applying 2082 IPsec. (This applies only to IPv4. For IPv6 packets, only the 2083 originator is allowed to fragment them.) The device SHOULD have a 2084 configuration setting to disable this. The resulting fragments are 2085 evaluated against the SPD in the normal manner. Thus, fragments not 2086 containing port numbers (or ICMP message type and code, or Mobility 2087 Header type) will only match rules having port (or ICMP message type 2088 and code, or MH type) selectors of OPAQUE or ANY. (See section 7 for 2089 more details.) 2091 Note: With regard to determining and enforcing the PMTU of an SA, the 2092 IPsec system MUST follow the steps described in Section 8.2. 2094 5.1.1 Handling an Outbound Packet That Must Be Discarded 2096 If an IPsec system receives an outbound packet that it finds it must 2097 discard, it SHOULD be capable of generating and sending an ICMP 2098 message to indicate to the sender of the outbound packet that the 2099 packet was discarded. The type and code of the ICMP message will 2100 depend on the reason for discarding the packet, as specified below. 2101 The reason SHOULD be recorded in the audit log. The audit log entry 2102 for this event SHOULD include the reason, current date/time, and the 2103 selector values from the packet. 2105 a. The selectors of the packet matched an SPD entry requiring the 2106 packet to be discarded. 2108 IPv4 Type = 3 (destination unreachable) Code = 13 2109 (Communication Administratively Prohibited) 2111 IPv6 Type = 1 (destination unreachable) Code = 1 2112 (Communication with destination administratively 2113 prohibited) 2115 b1. The IPsec system successfully reached the remote peer but was 2116 unable to negotiate the SA required by the SPD entry matching the 2117 packet, e.g., because the remote peer is administratively 2118 prohibited from communicating with the initiator, or the 2119 initiating peer was unable to authenticate itself to the remote 2120 peer, or the remote peer was unable to authenticate itself to the 2121 initiating peer, or SPD at remote peer did not have a suitable 2122 entry, etc. 2124 IPv4 Type = 3 (destination unreachable) Code = 13 2125 (Communication Administratively Prohibited) 2127 IPv6 Type = 1 (destination unreachable) Code = 1 2128 (Communication with destination administratively 2129 prohibited) 2131 b2. The IPsec system was unable to set up the SA required by the SPD 2132 entry matching the packet because the IPsec peer at the other end 2133 of the exchange could not be contacted. 2135 IPv4 Type = 3 (destination unreachable) Code = 1 (host 2136 unreachable) 2138 IPv6 Type = 1 (destination unreachable) Code = 3 (address 2139 unreachable) 2141 Note that an attacker behind a security gateway could send packets 2142 with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it 2143 to send ICMP messages to W.X.Y.Z. This creates an opportunity for a 2144 DoS attack among hosts behind a security gateway. To address this, a 2145 security gateway SHOULD include a management control to allow an 2146 administrator to configure an IPsec implementation to send or not 2147 send the ICMP messages under these circumstances, and if this 2148 facility is selected, to rate limit the transmission of such ICMP 2149 responses. 2151 5.1.2 Header Construction for Tunnel Mode 2153 This section describes the handling of the inner and outer IP 2154 headers, extension headers, and options for AH and ESP tunnels, with 2155 regard to outbound traffic processing. This includes how to 2156 construct the encapsulating (outer) IP header, how to process fields 2157 in the inner IP header, and what other actions should be taken for 2158 outbound, tunnel mode traffic. The general processing described here 2159 is modeled after RFC 2003, "IP Encapsulation with IP" [Per96]: 2161 o The outer IP header Source Address and Destination Address 2162 identify the "endpoints" of the tunnel (the encapsulator and 2163 decapsulator). The inner IP header Source Address and Destination 2164 Addresses identify the original sender and recipient of the 2165 datagram, (from the perspective of this tunnel), respectively. 2166 (See footnote 3 after the table in 5.1.2.1 for more details on the 2167 encapsulating source IP address.) 2169 o The inner IP header is not changed except as noted below for TTL 2170 (or Hop Limit) and the DS/ECN Fields. The inner IP header 2171 otherwise remains unchanged during its delivery to the tunnel exit 2172 point. 2174 o No change to IP options or extension headers in the inner header 2175 occurs during delivery of the encapsulated datagram through the 2176 tunnel. 2178 Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC 2179 2003) in several ways: 2181 o IPsec offers certain controls to a security administrator to 2182 manage covert channels (which would not normally be a concern for 2183 tunneling) and to ensure that the receiver examines the right 2184 portions of the received packet re: application of access 2185 controls. An IPsec implementation MAY be configurable with regard 2186 to how it processes the outer DS field for tunnel mode for 2187 transmitted packets. For outbound traffic, one configuration 2188 setting for the outer DS field will operate as described in the 2189 following sections on IPv4 and IPv6 header processing for IPsec 2190 tunnels. Another will allow the outer DS field to be mapped to a 2191 fixed value, which MAY be configured on a per SA basis. (The value 2192 might really be fixed for all traffic outbound from a device, but 2193 per SA granularity allows that as well.) This configuration option 2194 allows a local administrator to decide whether the covert channel 2195 provided by copying these bits outweighs the benefits of copying. 2197 o IPsec describes how to handle ECN or DS. 2199 o IPsec allows the IP version of the encapsulating header to be 2200 different from that of the inner header. 2202 The tables in the following sub-sections show the handling for the 2203 different header/option fields ("constructed" means that the value in 2204 the outer field is constructed independently of the value in the 2205 inner). 2207 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode 2209 <-- How Outer Hdr Relates to Inner Hdr --> 2210 Outer Hdr at Inner Hdr at 2211 IPv4 Encapsulator Decapsulator 2212 Header fields: -------------------- ------------ 2213 version 4 (1) no change 2214 header length constructed no change 2215 DS Field copied from inner hdr (5) no change 2216 ECN Field copied from inner hdr constructed (6) 2217 total length constructed no change 2218 ID constructed no change 2219 flags (DF,MF) constructed, DF (4) no change 2220 fragment offset constructed no change 2221 TTL constructed (2) decrement (2) 2222 protocol AH, ESP no change 2223 checksum constructed constructed (2)(6) 2224 src address constructed (3) no change 2225 dest address constructed (3) no change 2226 Options never copied no change 2228 1. The IP version in the encapsulating header can be 2229 different from the value in the inner header. 2231 2. The TTL in the inner header is decremented by the 2232 encapsulator prior to forwarding and by the decapsulator 2233 if it forwards the packet. (The IPv4 checksum changes 2234 when the TTL changes.) 2236 Note: Decrementing the TTL value is a normal part of 2237 forwarding a packet. Thus, a packet originating from 2238 the same node as the encapsulator does not have its TTL 2239 decremented, since the sending node is originating the 2240 packet rather than forwarding it. 2242 3. Local and Remote addresses depend on the SA, which is 2243 used to determine the Remote address which in turn 2244 determines which Local address (net interface) is used 2245 to forward the packet. 2247 Note: For multicast traffic, the destination address, or 2248 source and destination addresses, may be required for 2249 demuxing. In that case, it is important to ensure 2250 consistency over the lifetime of the SA by ensuring that 2251 the source address that appears in the encapsulating 2252 tunnel header is the same as the one that was negotiated 2253 during the SA establishment process. There is an 2254 exception to this general rule, i.e., a mobile IPsec 2255 implementation will update its source address as it 2256 moves. 2258 4. Configuration determines whether to copy from the inner 2259 header (IPv4 only), clear, or set the DF. 2261 5. If the packet will immediately enter a domain for which 2262 the DSCP value in the outer header is not appropriate, 2263 that value MUST be mapped to an appropriate value for 2264 the domain [RFC 2474]. See RFC 2475[BBCDWW98] for 2265 further information. 2267 6. If the ECN field in the inner header is set to ECT(0) or 2268 ECT(1) and the ECN field in the outer header is set to 2269 CE, then set the ECN field in the inner header to CE, 2270 otherwise make no change to the ECN field in the inner 2271 header. (The IPv4 checksum changes when the ECN 2272 changes.) 2274 Note: IPsec does not copy the options from the inner header into the 2275 outer header, nor does IPsec construct the options in the outer 2276 header. However, post-IPsec code MAY insert/construct options for the 2277 outer header. 2279 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode 2281 See previous section 5.1.2.1 for notes 1-6 indicated by (footnote 2282 number). 2284 <-- How Outer Hdr Relates Inner Hdr ---> 2285 Outer Hdr at Inner Hdr at 2286 IPv6 Encapsulator Decapsulator 2287 Header fields: -------------------- ------------ 2288 version 6 (1) no change 2289 DS Field copied from inner hdr (5) no change 2290 ECN Field copied from inner hdr constructed (6) 2291 flow label copied or configured (8) no change 2292 payload length constructed no change 2293 next header AH,ESP,routing hdr no change 2294 hop limit constructed (2) decrement (2) 2295 src address constructed (3) no change 2296 dest address constructed (3) no change 2297 Extension headers never copied (7) no change 2299 7. IPsec does not copy the extension headers from the inner 2300 packet into outer headers, nor does IPsec construct 2301 extension headers in the outer header. However, post- 2302 IPsec code MAY insert/construct extension headers for 2303 the outer header. 2305 8. See [RaCoCaDe04]. Copying is acceptable only for end 2306 systems, not SGs. If an SG copied flow labels from the 2307 inner header to the outer header, collisions might 2308 result. 2310 5.2 Processing Inbound IP Traffic (unprotected-to-protected) 2312 Inbound processing is somewhat different from outbound processing, 2313 because of the use of SPIs to map IPsec protected traffic to SAs. The 2314 inbound SPD cache (SPD-I) is applied only to bypassed or discarded 2315 traffic. If an arriving packet appears to be an IPsec fragment from 2316 an unprotected interface, reassembly is performed prior to IPsec 2317 processing. The intent for any SPD cache is that a packet that fails 2318 to match any entry is then referred to the corresponding SPD. Every 2319 SPD SHOULD have a nominal, final entry that catches anything that is 2320 otherwise unmatched, and discards it. This ensures that non-IPsec 2321 protected traffic that arrives and does not match any SPD-I entry 2322 will be discarded. 2324 Unprotected Interface 2325 | 2326 V 2327 +-----+ IPsec protected 2328 ------------------->|Demux|-------------------+ 2329 | +-----+ | 2330 | | | 2331 | Not IPsec | | 2332 | | | 2333 | V | 2334 | +-------+ +---------+ | 2335 | |DISCARD|<---|SPD-I (*)| | 2336 | +-------+ +---------+ | 2337 | | | 2338 | |-----+ | 2339 | | | | 2340 | | V | 2341 | | +------+ | 2342 | | | ICMP | | 2343 | | +------+ | 2344 | | V 2345 +---------+ | +--------+ 2346 ....|SPD-O (*)|............|....................|PROCESS |...IPsec 2347 +---------+ | |(AH/ESP)| Boundary 2348 ^ | +--------+ 2349 | | +---+ | 2350 | BYPASS | +-->|IKE| | 2351 | | | +---+ | 2352 | V | V 2353 | +----------+ +---------+ +----+ 2354 |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| 2355 nested SAs +----------+ +---------+ +----+ 2356 | 2357 V 2358 Protected Interface 2360 Figure 3. Inbound Traffic Processing Model 2361 (*) = The caches are shown here. If there is 2362 a cache miss, then the SPD is checked. 2363 There is no requirement that an 2364 implementation buffer the packet if 2365 there is a cache miss. 2367 Prior to performing AH or ESP processing, any IP fragments that 2368 arrive via the unprotected interface are reassembled (by IP). Each 2369 inbound IP datagram to which IPsec processing will be applied is 2370 identified by the appearance of the AH or ESP values in the IP Next 2371 Protocol field (or of AH or ESP as a next layer protocol in the IPv6 2372 context). 2374 IPsec MUST perform the following steps: 2376 1. When a packet arrives, it may be tagged with the ID of the 2377 interface (physical or virtual) via which it arrived, if necessary 2378 to support multiple SPDs and associated SPD-I caches. (The 2379 interface ID is mapped to a corresponding SPD-ID.) 2381 2. The packet is examined and demuxed into one of two categories: 2382 - If the packet appears to be IPsec protected and it is addressed 2383 to this device, an attempt is made to map it to an active SA 2384 via the SAD. Note that the device may have multiple IP 2385 addresses that may be used in the SAD lookup, e.g., in the case 2386 of protocols such as SCTP. 2387 - Traffic not addressed to this device, or addressed to this 2388 device and not AH or ESP, is directed to SPD-I lookup. (This 2389 implies that IKE traffic MUST have an explicit BYPASS entry in 2390 the SPD.) If multiple SPDs are employed, the tag assigned to 2391 the packet in step 1 is used to select the appropriate SPD-I 2392 (and cache) to search. SPD-I lookup determines whether the 2393 action is DISCARD or BYPASS. 2395 3a. If the packet is addressed to the IPsec device and AH or ESP is 2396 specified as the protocol, the packet is looked up in the SAD. For 2397 unicast traffic, use only the SPI (or SPI plus protocol). For 2398 multicast traffic, use the SPI plus the destination or SPI plus 2399 destination and source addresses, as specified in section 4.1. In 2400 either case (unicast or multicast), if there is no match, discard 2401 the traffic. This is an auditable event. The audit log entry for 2402 this event SHOULD include the current date/time, SPI, source and 2403 destination of the packet, IPsec protocol, and any other selector 2404 values of the packet that are available. If the packet is found 2405 in the SAD, process it accordingly (see step 4). 2407 3b. If the packet is not addressed to the device or is addressed to 2408 this device and is not AH or ESP, look up the packet header in the 2409 (appropriate) SPD-I cache. If there is a match and the packet is 2410 to be discarded or bypassed, do so. If there is no cache match, 2411 look up the packet in the corresponding SPD-I and create a cache 2412 entry as appropriate. (No SAs are created in response to receipt 2413 of a packet that requires IPsec protection; only BYPASS or DISCARD 2414 cache entries can be created this way.) If there is no match, 2415 discard the traffic. This is an auditable event. The audit log 2416 entry for this event SHOULD include the current date/time, SPI if 2417 available, IPsec protocol if available, source and destination of 2418 the packet, and any other selector values of the packet that are 2419 available. 2421 3c. Processing of ICMP messages is assumed to take place on the 2422 unprotected side of the IPsec boundary. Unprotected ICMP messages 2423 are examined and local policy is applied to determine whether to 2424 accept or reject these messages and, if accepted, what action to 2425 take as a result. For example, if an ICMP unreachable message is 2426 received, the implementation must decide whether to act on it, 2427 reject it, or act on it with constraints. (See Section 6.) 2429 4. Apply AH or ESP processing as specified, using the SAD entry 2430 selected in step 3a above. Then match the packet against the 2431 inbound selectors identified by the SAD entry to verify that the 2432 received packet is appropriate for the SA via which it was 2433 received. 2435 If an IPsec system receives an inbound packet on an SA and the 2436 packet's header fields are not consistent with the selectors for 2437 the SA, it MUST discard the packet. This is an auditable event. 2438 The audit log entry for this event SHOULD include the current 2439 date/time, SPI, IPsec protocol(s), source and destination of the 2440 packet, and any other selector values of the packet that are 2441 available, and the selector values from the relevant SAD entry. 2442 The system SHOULD also be capable of generating and sending an IKE 2443 notification of INVALID_SELECTORS to the sender (IPsec peer), 2444 indicating that the received packet was discarded because of 2445 failure to pass selector checks. 2447 To minimize the impact of a DoS attack, or a mis-configured peer, 2448 the IPsec system SHOULD include a management control to allow an 2449 administrator to configure the IPsec implementation to send or not 2450 send this IKE notification, and if this facility is selected, to 2451 rate limit the transmission of such notifications. 2453 After traffic is bypassed or processed through IPsec, it is handed 2454 to the inbound forwarding function for disposition. This function 2455 may cause the packet to be sent (outbound) across the IPsec 2456 boundary for additional inbound IPsec processing, e.g., in support 2457 of nested SAs. If so, then as with ALL outbound traffic that is to 2458 be bypassed, the packet MUST be matched against an SPD-O entry. 2459 Ultimately, the packet should be forwarded to the destination host 2460 or process for disposition. 2462 6. ICMP Processing 2464 This section describes IPsec handling of ICMP traffic. There are two 2465 categories of ICMP traffic: error messages (e.g., type = destination 2466 unreachable) and non-error messages (e.g., type = echo). This section 2467 applies exclusively to error messages. Disposition of non-error, 2468 ICMP messages (that are not addressed to the IPsec implementation 2469 itself) MUST be explicitly accounted for using SPD entries. 2471 The discussion in this section applies to ICMPv6 as well as to 2472 ICMPv4. Also, a mechanism SHOULD be provided to allow an 2473 administrator to cause ICMP error messages (selected, all, or none) 2474 to be logged as an aid to problem diagnosis. 2476 6.1 Processing ICMP Error Messages Directed to an IPsec Implementation 2478 6.1.1 ICMP Error Messages Received on the Unprotected Side of the 2479 Boundary 2481 Figure 3 in Section 5.2 shows a distinct ICMP processing module on 2482 the unprotected side of the IPsec boundary, for processing ICMP 2483 messages (error or otherwise) that are addressed to the IPsec device 2484 and that are not protected via AH or ESP. An ICMP message of this 2485 sort is unauthenticated and its processing may result in denial or 2486 degradation of service. This suggests that, in general, it would be 2487 desirable to ignore such messages. However, many ICMP messages will 2488 be received by hosts or security gateways from unauthenticated 2489 sources, e.g., routers in the public Internet. Ignoring these ICMP 2490 messages can degrade service, e.g., because of a failure to process 2491 PMTU message and redirection messages. Thus there is also a 2492 motivation for accepting and acting upon unauthenticated ICMP 2493 messages. 2495 To accommodate both ends of this spectrum, a compliant IPsec 2496 implementation MUST permit a local administrator to configure an 2497 IPsec implementation to accept or reject unauthenticated ICMP 2498 traffic. This control MUST be at the granularity of ICMP type and 2499 MAY be at the granularity of ICMP type and code. Additionally, an 2500 implementation SHOULD incorporate mechanisms and parameters for 2501 dealing with such traffic. For example, there could be the ability to 2502 establish a minimum PMTU for traffic (on a per destination basis), to 2503 prevent receipt of an unauthenticated ICMP from setting the PMTU to a 2504 trivial size. 2506 If an ICMP PMTU message passes the checks above and the system is 2507 configured to accept it, then there are two possibilities. If the 2508 implementation applies fragmentation on the ciphertext side of the 2509 boundary, then the accepted PMTU information is passed to the 2510 forwarding module (outside of the IPsec implementation) which uses it 2511 to manage outbound packet fragmentation. If the implementation is 2512 configured to effect plaintext side fragmentation, then the PMTU 2513 information is passed to the plaintext side and processed as 2514 described in Section 8.2. 2516 6.1.2 ICMP Error Messages Received on the Protected Side of the Boundary 2518 These ICMP messages are not authenticated, but they do come from 2519 sources on the protected side of the IPsec boundary. Thus these 2520 messages generally are viewed as more "trustworthy" than their 2521 counterparts arriving from sources on the unprotected side of the 2522 boundary. The major security concern here is that a compromised host 2523 or router might emit erroneous ICMP error messages that could degrade 2524 service for other devices "behind" the security gateway, or that 2525 could even result in violations of confidentiality. For example, if a 2526 bogus ICMP redirect were consumed by a security gateway, it could 2527 cause the forwarding table on the protected side of the boundary to 2528 be modified so as to deliver traffic to an inappropriate destination 2529 "behind" the gateway. Thus implementers MUST provide controls to 2530 allow local administrators to constrain the processing of ICMP error 2531 messages received on the protected side of the boundary, and directed 2532 to the IPsec implementation. These controls are of the same type as 2533 those employed on the unprotected side, described above in Section 2534 6.1.1. 2536 6.2 Processing Protected, Transit ICMP Error Messages 2538 When an ICMP error message is transmitted via an SA to a device 2539 "behind" an IPsec implementation, both the payload and the header of 2540 the ICMP message require checking from an access control perspective. 2541 If one of these messages is forwarded to a host behind a security 2542 gateway, the receiving host IP implementation will make decisions 2543 based on the payload, i.e., the header of the packet that purportedly 2544 triggered the error response. Thus an IPsec implementation MUST be 2545 configurable to check that this payload header information is 2546 consistent with the SA via which it arrives. (This means that the 2547 payload header, with source and destination address and port fields 2548 reversed, matches the traffic selectors for the SA.) If this sort of 2549 check is not performed, then for example, anyone with whom the 2550 receiving IPsec system (A) has an active SA could send an ICMP 2551 destination dead message that refers to any host/net with which A is 2552 currently communicating, and thus effect a highly efficient DoS 2553 attack re: communication with other peers of A. Normal IPsec 2554 receiver processing of traffic is not sufficient to protect against 2555 such attacks. However, not all contexts may require such checks, so 2556 it is also necessary to allow a local administrator to configure an 2557 implementation to NOT perform such checks. 2559 To accommodate both policies, the following convention is adopted. If 2560 an administrator wants to allow ICMP error messages to be carried by 2561 an SA without inspection of the payload, then configure an SPD entry 2562 that explicitly allows for carriage of such traffic. If an 2563 administrator wants IPsec to check the payload of ICMP error messages 2564 for consistency, then do not create any SPD entries that accommodate 2565 carriage of such traffic based on the ICMP packet header. This 2566 convention motivates the following processing description. 2568 IPsec senders and receivers MUST support the following processing for 2569 ICMP error messages that are sent and received via SAs. 2571 If an SA exists that accommodates an outbound ICMP error message, 2572 then the message is mapped to the SA and only the IP and ICMP headers 2573 are checked upon receipt, just as would be the case for other 2574 traffic. If no SA exists that matches the traffic selectors 2575 associated with an ICMP error message, then the SPD is searched to 2576 determine if such an SA can be created. If so, the SA is created and 2577 the ICMP error message is transmitted via that SA. Upon receipt, this 2578 message is subject to the usual traffic selector checks at the 2579 receiver. This processing is exactly what would happen for traffic in 2580 general, and thus does not represent any special processing for ICMP 2581 error messages. 2583 If no SA exists that would carry the outbound ICMP message in 2584 question, and if no SPD entry would allow carriage of this outbound 2585 ICMP error message, then an IPsec implementation MUST map the message 2586 to the SA that would carry the return traffic associated with the 2587 packet that triggered the ICMP error message. This requires an IPsec 2588 implementation to detect outbound ICMP error messages that map to no 2589 extant SA or SPD entry, and treat them specially with regard to SA 2590 creation and lookup. The implementation extracts the header for the 2591 packet that triggered the error (from the ICMP message payload), 2592 reverses the source and destination IP address fields, extracts the 2593 protocol field, and reverses the port fields (if accessible). It then 2594 uses this extracted information to locate an appropriate, active 2595 outbound SA, and transmits the error message via this SA. If no such 2596 SA exists, no SA will be created, and this is an auditable event. 2598 If an IPsec implementation receives an inbound ICMP error message on 2599 an SA, and the IP and ICMP headers of the message do not match the 2600 traffic selectors for the SA, the receiver MUST process the received 2601 message in a special fashion. Specifically, the receiver must extract 2602 the header of the triggering packet from the ICMP payload, and 2603 reverse fields as described above to determine if the packet is 2604 consistent with the selectors for the SA via which the ICMP error 2605 message was received. If the packet fails this check, the IPsec 2606 implementation MUST NOT forwarded the ICMP message to the 2607 destination. This is an auditable event. 2609 7. Handling Fragments (on the protected side of the IPsec boundary) 2611 Earlier sections of this document describe mechanisms for (a) 2612 fragmenting an outbound packet after IPsec processing has been 2613 applied and reassembling it at the receiver before IPsec processing 2614 and (b) handling inbound fragments received from the unprotected side 2615 of the IPsec boundary. This section describes how an implementation 2616 should handle the processing of outbound plaintext fragments on the 2617 protected side of the IPsec boundary. (See Appendix D for discussion 2618 of Fragment Handling Rationale.) In particular, it addresses: 2620 o mapping an outbound non-initial fragment to the right SA 2621 (or finding the right SPD entry) 2622 o verifying that a received non-initial fragment is 2623 authorized for the SA via which it was received 2624 o mapping outbound and inbound non-initial fragments to the 2625 right SPD-O/SPD-I entry or the relevant cache entry, for 2626 BYPASS/DISCARD traffic 2628 Note: In Section 4.1, transport mode SAs have been defined to not 2629 carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two 2630 special values, ANY and OPAQUE, were defined for selectors and that 2631 ANY includes OPAQUE. The term "non-trivial" is used to mean that the 2632 selector has a value other than OPAQUE or ANY. 2634 Note: The term "non-initial fragment" is used here to indicate a 2635 fragment that does not contain all the selector values that may be 2636 needed for access control. As observed in Section 4.4.1, depending 2637 on the Next Layer Protocol, in addition to Ports, the ICMP message 2638 type/code or Mobility Header type could be missing from non-initial 2639 fragments. Also, for IPv6, even the first fragment might NOT contain 2640 the Next Layer Protocol or Ports (or ICMP message type/code, or 2641 Mobility Header type) depending on the kind and number of extension 2642 headers present. If a non-initial fragment contains the Port (or 2643 ICMP type and code or Mobility header type) but not the Next Layer 2644 Protocol, then unless there is an SPD entry for the relevant 2645 Local/Remote addresses with ANY for Next Layer Protocol and Port (or 2646 ICMP type and code or Mobility header type), the fragment would not 2647 contain all the selector information needed for access control. 2649 To address the above issues, three approaches have been defined: 2651 o Tunnel mode SAs that carry initial and non-initial fragments 2652 (See Section 7.1) 2653 o Separate tunnel mode SAs for non-initial fragments (See 2654 Section 7.2) 2655 o Stateful fragment checking (See Section 7.3) 2657 7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments 2659 All implementations MUST support tunnel mode SAs that are configured 2660 to pass traffic without regard to port field (or ICMP type/code or 2661 Mobility Header type) values. If the SA will carry traffic for 2662 specified protocols, the selector set for the SA MUST specify the 2663 port fields (or ICMP type/code or Mobility Header type) as ANY. An SA 2664 defined in this fashion will carry all traffic including initial and 2665 non-initial fragments for the indicated Local/Remote addresses and 2666 specified Next Layer protocol(s). If the SA will carry traffic 2667 without regard to a specific protocol value (i.e., ANY is specified 2668 as the (Next Layer) protocol selector value), then the port field 2669 values are undefined and MUST be set to ANY as well. (As noted in 2670 4.4.1, ANY includes OPAQUE as well as all specific values.) 2672 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments 2674 An implementation MAY support tunnel mode SAs that will carry only 2675 non-initial fragments, separate from non-fragmented packets and 2676 initial fragments. The OPAQUE value will be used to specify port (or 2677 ICMP type/code or Mobility Header type) field selectors for an SA to 2678 carry such fragments. Receivers MUST perform a minimum offset check 2679 on IPv4 (non-initial) fragments to protect against overlapping 2680 fragment attacks when SAs of this type are employed. Because such 2681 checks cannot be performed on IPv6 non-initial fragments, users and 2682 administrators are advised that carriage of such fragments may be 2683 dangerous, and implementers may choose to NOT support such SAs for 2684 IPv6 traffic. Also, an SA of this sort will carry all non-initial 2685 fragments that match a specified Local/Remote address pair and 2686 protocol value, i.e., the fragments carried on this SA belong to 2687 packets that if not fragmented, might have gone on separate SAs of 2688 differing security. Therefore users and administrators are advised 2689 to protect such traffic using ESP (with integrity) and the 2690 "strongest" integrity and encryption algorithms in use between both 2691 peers. (Determination of the "strongest" algorithms requires 2692 imposing an ordering of the available algorithms, a local 2693 determination at the discretion of the initiator of the SA.) 2695 Specific port (or ICMP type/code or Mobility header type) selector 2696 values will be used to define SAs to carry initial fragments and non- 2697 fragmented packets. This approach can be used if a user or 2698 administrator wants to create one or more tunnel mode SAs between the 2699 same Local/Remote addresses that discriminate based on port (or ICMP 2700 type/code or Mobility header type) fields. These SAs MUST have non- 2701 trivial protocol selector values, otherwise approach #1 above MUST be 2702 used. 2704 Note: In general, for the approach described in this section, one 2705 needs only a single SA between two implementations to carry all non- 2706 initial fragments. However, if one chooses to have multiple SAs 2707 between the two implementations for QoS differentiation, then one 2708 might also want multiple SAs to carry fragments-without-ports, one 2709 for each supported QoS class. Since support for QoS via distinct SAs 2710 is a local matter, not mandated by this document, the choice to have 2711 multiple SAs to carry non-initial fragments should also be local. 2713 7.3 Stateful Fragment Checking 2715 An implementation MAY support some form of stateful fragment checking 2716 for a tunnel mode SA with non-trivial port (or ICMP type/code or MH 2717 type) field values (not ANY or OPAQUE). Implementations that will 2718 transmit non-initial fragments on a tunnel mode SA that makes use of 2719 non-trivial port (or ICMP type/code or MH type) selectors MUST notify 2720 a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. 2722 The peer MUST reject this proposal if it will not accept non-initial 2723 fragments in this context. If an implementation does not successfully 2724 negotiate transmission of non-initial fragments for such an SA, it 2725 MUST NOT send such fragments over the SA. This standard does not 2726 specify how peers will deal with such fragments, e.g., via reassembly 2727 or other means, at either sender or receiver. However, a receiver 2728 MUST discard non-initial fragments that arrive on an SA with non- 2729 trivial port (or ICMP type/code or MH type) selector values unless 2730 this feature has been negotiated. Also, the receiver MUST discard 2731 non-initial fragments that do not comply with the security policy 2732 applied to the overall packet. Discarding such packets is an 2733 auditable event. Note that in network configurations where fragments 2734 of a packet might be sent or received via different security gateways 2735 or BITW implementations, stateful strategies for tracking fragments 2736 may fail. 2738 7.4 BYPASS/DISCARD traffic 2740 All implementations MUST support DISCARDing of fragments using the 2741 normal SPD packet classification mechanisms. All implementations MUST 2742 support stateful fragment checking to accommodate BYPASS traffic for 2743 which a non-trivial port range is specified. The concern is that 2744 BYPASS of a cleartext, non-initial fragment arriving at an IPsec 2745 implementation could undermine the security afforded IPsec-protected 2746 traffic directed to the same destination. For example, consider an 2747 IPsec implementation configured with an SPD entry that calls for 2748 IPsec-protection of traffic between a specific source/destination 2749 address pair, and for a specific protocol and destination port, e.g., 2750 TCP traffic on port 23 (Telnet). Assume that the implementation also 2751 allows BYPASS of traffic from the same source/destination address 2752 pair and protocol, but for a different destination port, e.g., port 2753 119 (NNTP). An attacker could send a non-initial fragment (with a 2754 forged source address) that, if bypassed, could overlap with IPsec- 2755 protected traffic from the same source and thus violate the integrity 2756 of the IPsec-protected traffic. Requiring stateful fragment checking 2757 for BYPASS entries with non-trivial port ranges prevents attacks of 2758 this sort. 2760 8. Path MTU/DF Processing 2762 The application of AH or ESP to an outbound packet increases the size 2763 of a packet and thus may cause a packet to exceed the PMTU for the SA 2764 via which the packet will travel. An IPsec implementation also may 2765 receive an unprotected ICMP PMTU message and, if it choose to act 2766 upon it, the result will affect outbound traffic processing. This 2767 section describes the processing required of an IPsec implementation 2768 to deal with these two PMTU issues. 2770 8.1 DF Bit 2772 All IPsec implementations MUST support the option of copying the DF 2773 bit from an outbound packet to the tunnel mode header that it emits, 2774 when traffic is carried via a tunnel mode SA. This means that it MUST 2775 be possible to configure the implementation's treatment of the DF bit 2776 (set, clear, copy from inner header) for each SA. 2778 8.2 Path MTU Discovery (PMTU) 2780 This section discusses IPsec handling for unprotected Path MTU 2781 Discovery messages. ICMP PMTU is used here to refer to an ICMP 2782 message for: 2784 IPv4 (RFC 792 [Pos81b]): 2785 - Type = 3 (Destination Unreachable) 2786 - Code = 4 (Fragmentation needed and DF set) 2787 - Next-Hop MTU in the low-order 16 bits of the 2788 second word of the ICMP header (labeled "unused" 2789 in RFC 792), with high-order 16 bits set to zero) 2791 IPv6 (RFC 2463 [CD98]): 2792 - Type = 2 (Packet Too Big) 2793 - Code = 0 (Fragmentation needed) 2794 - Next-Hop MTU in the 32 bit MTU field of the ICMP6 2795 message 2797 8.2.1 Propagation of PMTU 2799 When an IPsec implementation receives an unauthenticated PMTU 2800 message, and it is configured to process (vs. ignore) such messages, 2801 it maps the message to the SA to which it corresponds. This mapping 2802 is effected by extracting the header information from the payload of 2803 the PMTU message and applying the procedure described in Section 5.2. 2804 The PMTU determined by this message is used to update the SAD PMTU 2805 field, taking into account the size of the AH or ESP header that will 2806 be applied, any crypto synchronization data, and the overhead imposed 2807 by an additional IP header, in the case of a tunnel mode SA. 2809 In a native host implementation it is possible to maintain PMTU data 2810 at the same granularity as for unprotected communication, so there is 2811 no loss of functionality. Signaling of the PMTU information is 2812 internal to the host. For all other IPsec implementation options, the 2813 PMTU data must be propagated via a synthesized ICMP PMTU. In these 2814 cases, the IPsec implementation SHOULD wait for outbound traffic to 2815 be mapped to the SAD entry When such traffic arrives, if the traffic 2816 would exceed the updated PMTU value the traffic MUST be handled as 2817 follows: 2819 Case 1: Original (cleartext) packet is IPv4 and has the DF 2820 bit set. The implementation SHOULD discard the packet 2821 and send a PMTU ICMP message. 2823 Case 2: Original (cleartext) packet is IPv4 and has the DF 2824 bit clear. The implementation SHOULD fragment (before or 2825 after encryption per its configuration) and then forward 2826 the fragments. It SHOULD NOT send a PMTU ICMP message. 2828 Case 3: Original (cleartext) packet is IPv6. The implementation 2829 SHOULD discard the packet and send a PMTU ICMP message. 2831 8.2.2 PMTU Aging 2833 In all IPsec implementations the PMTU associated with an SA MUST be 2834 "aged" and some mechanism is required to update the PMTU in a timely 2835 manner, especially for discovering if the PMTU is smaller than 2836 required by current network conditions. A given PMTU has to remain 2837 in place long enough for a packet to get from the source of the SA to 2838 the peer, and to propagate an ICMP error message if the current PMTU 2839 is too big. 2841 Implementations SHOULD use the approach described in the Path MTU 2842 Discovery document (RFC 1191 [MD90], Section 6.3), which suggests 2843 periodically resetting the PMTU to the first-hop data-link MTU and 2844 then letting the normal PMTU Discovery processes update the PMTU as 2845 necessary. The period SHOULD be configurable. 2847 9. Auditing 2849 IPsec implementations are not required to support auditing. For the 2850 most part, the granularity of auditing is a local matter. However, 2851 several auditable events are identified in this document and for each 2852 of these events a minimum set of information that SHOULD be included 2853 in an audit log is defined. Additional information also MAY be 2854 included in the audit log for each of these events, and additional 2855 events, not explicitly called out in this specification, also MAY 2856 result in audit log entries. There is no requirement for the 2857 receiver to transmit any message to the purported transmitter in 2858 response to the detection of an auditable event, because of the 2859 potential to induce denial of service via such action. 2861 10. Conformance Requirements 2863 All IPv4 IPsec implementations MUST comply with all requirements of 2864 this document. All IPv6 implementations MUST comply with all 2865 requirements of this document. 2867 11. Security Considerations 2869 The focus of this document is security; hence security considerations 2870 permeate this specification. 2872 If an IPsec implementation is configured to pass ICMP error messages 2873 over SAs based on the ICMP header values, without checking the header 2874 information from the ICMP message payload, serious vulnerabilities 2875 may arise. Consider a scenario in which several sites (A, B, and C) 2876 are connected to one another via ESP-protected tunnels: A-B, A-C, and 2877 B-C. Also assume that the traffic selectors for each tunnel specify 2878 ANY for protocol and port fields and IP source/destination address 2879 ranges that encompass the address range for the systems behind the 2880 security gateways serving each site. This would allow a host at site 2881 B to send an ICMP destination dead message to any host at site A, 2882 that declares all hosts on the net at site C to be unreachable. This 2883 is a very efficient DoS attack that could have been prevented if the 2884 ICMP error messages were subjected to the checks that IPsec provides, 2885 if the SPD is suitably configured, as described in Section 6.2. 2887 12. IANA Considerations 2889 This document has no actions for IANA. 2891 13. Differences from RFC 2401 2893 This architecture document differs substantially from RFC 2401 in 2894 detail and in organization, but the fundamental notions are 2895 unchanged. 2897 o The processing model has been revised to address new IPsec 2898 scenarios, improve performance and simplify implementation. This 2899 includes a separation between forwarding (routing) and SPD 2900 selection, several SPD changes, and the addition of an outbound 2901 SPD cache and an inbound SPD cache for bypassed or discarded 2902 traffic. There is also a new database, the Peer Authorization 2903 Database (PAD). This provides a link between an SA management 2904 protocol like IKE and the SPD. 2906 o There is no longer a requirement to support nested SAs or "SA 2907 bundles." Instead this functionality can be achieved through SPD 2908 and forwarding table configuration. An example of a 2909 configuration has been added in Appendix E. 2911 o SPD entries were redefined to provide more flexibility. Each SPD 2912 entry now consists of 1 to N sets of selectors, where each 2913 selector set contains one protocol and a "list of ranges" can now 2914 be specified for the Local IP address, Remote IP address, and 2915 whatever fields (if any) are associated with the Next Layer 2916 Protocol (Local Port, Remote Port, ICMP message type and code, and 2917 Mobility Header Type). An individual value for a selector is 2918 represented via a trivial range and ANY is represented via a range 2919 than spans all values for the selector. An example of an ASN.1 2920 description is included in Appendix C. 2922 o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and 2923 ECN. The tunnel section has been updated to explain how to handle 2924 DSCP and ECN bits. 2926 o For tunnel mode SAs, an SG, BITS, or BITW implementation is now 2927 allowed to fragment packets before applying IPsec. This applies 2928 only to IPv4. For IPv6 packets, only the originator is allowed to 2929 fragment them. 2931 o When security is desired between two intermediate systems along a 2932 path or between an intermediate system and an end system, 2933 transport mode may now be used between security gateways and 2934 between a security gateway and a host. 2936 o This document clarifies that for all traffic that crosses the IPsec 2937 boundary, including IPsec management traffic, the SPD or 2938 associated caches must be consulted. 2940 o This document defines how to handle the situation of a security 2941 gateway with multiple subscribers requiring separate IPsec 2942 contexts. 2944 o A definition of reserved SPIs has been added. 2946 o Text has been added explaining why ALL IP packets must be checked 2947 -- IPsec includes minimal firewall functionality to support access 2948 control at the IP layer. 2950 o The tunnel section has been updated to clarify how to handle the IP 2951 options field and IPv6 extension headers when constructing the 2952 outer header. 2954 o SA mapping for inbound traffic has been updated to be consistent 2955 with the changes made in AH and ESP for support of unicast, 2956 anycast, and multicast SAs. 2958 o Guidance has been added re: how to handle the covert channel 2959 created in tunnel mode by copying the DSCP value to outer header. 2961 o Support for AH in both IPv4 and IPv6 is no longer required. 2963 o PMTU handling has been updated. The appendix on 2964 PMTU/DF/Fragmentation has been deleted. 2966 o Added text saying "The IP Security Policy (IPSP) Working Group is a 2967 possible future source of guidance. One of their goals is to 2968 produce a Internet Draft on a "Security Gateway Discovery, Policy 2969 Exchange and Negotiation Protocol." 2971 o Three approaches have been added for handling plaintext fragments 2972 on the protected side of the IPsec boundary. Appendix D documents 2973 the rationale behind them. 2975 o Added revised text describing how to derive selector values for SAs 2976 (from the SPD entry or from the packet, etc.) 2978 o Added a new table describing the relationship between selector 2979 values in an SPD entry, the PFP flag, and resulting selector 2980 values in the corresponding SAD entry. 2982 o Added Appendix B to describe decorrelation. 2984 o Added text describing how to handle an outbound packet which must 2985 be discarded. 2987 o Added text describing how to handle a DISCARDED inbound packet, 2988 i.e., one that does not match the SA upon which it arrived. 2990 o IPv6 mobility header has been added as a possible Next Layer 2991 Protocol. IPv6 mobility header message type has been added as a 2992 selector. 2994 o ICMP message type and code have been added as selectors. 2996 o The selector "data sensitivity level" has been removed to simplify 2997 things. 2999 o Updated text describing handling ICMP error messages. The appendix 3000 on "Categorization of ICMP messages" has been deleted. 3002 o The text for the selector name has been updated and clarified. 3004 o The "Next Layer Protocol" has been further explained and a default 3005 list of protocols to skip when looking for the Next Layer Protocol 3006 has been added. 3008 o The text has been amended to say that this document assumes use of 3009 IKEv2 or an SA management protocol with comparable features. 3011 o Text has been added clarifying the algorithm for mapping inbound 3012 IPsec datagrams to SAs in the presence of multicast SAs. 3014 o The appendix "Sequence Space Window Code Example" has been removed. 3016 o With respect to IP addresses and ports, the terms "Local" and 3017 "Remote" are used for policy rules (replacing source and 3018 destination). "Local" refers to the entity being protected by an 3019 IPsec implementation, i.e., the "source" address/port of outbound 3020 packets or the "destination" address/port of inbound packets. 3021 "Remote" refers to a peer entity or peer entities. The terms 3022 "source" and "destination" are still used for packet header 3023 fields. 3025 Acknowledgements 3027 The authors would like to acknowledge the contributions of Ran 3028 Atkinson, who played a critical role in initial IPsec activities, and 3029 who authored the first series of IPsec standards: RFCs 1825-1827; and 3030 Charlie Lynn, who made significant contributions to the second series 3031 of IPsec standards (RFCs 2401,2402,and 2406) and to the current 3032 versions, especially with regard to IPv6 issues. The authors also 3033 would like to thank the members of the IPsec and MSEC working groups 3034 who have contributed to the development of this protocol 3035 specification. 3037 Appendix A -- Glossary 3039 This section provides definitions for several key terms that are 3040 employed in this document. Other documents provide additional 3041 definitions and background information relevant to this technology, 3042 e.g., [Shi00, VK83, HA94]. Included in this glossary are generic 3043 security service and security mechanism terms, plus IPsec-specific 3044 terms. 3046 Access Control 3047 Access control is a security service that prevents unauthorized 3048 use of a resource, including the prevention of use of a resource 3049 in an unauthorized manner. In the IPsec context, the resource to 3050 which access is being controlled is often: 3051 o for a host, computing cycles or data 3052 o for a security gateway, a network behind the gateway 3053 or bandwidth on that network. 3055 Anti-replay 3056 [See "Integrity" below] 3058 Authentication 3059 This term is used informally to refer to the combination of two 3060 nominally distinct security services, data origin authentication 3061 and connectionless integrity. See the definitions below for each 3062 of these services. 3064 Availability 3065 Availability, when viewed as a security service, addresses the 3066 security concerns engendered by attacks against networks that deny 3067 or degrade service. For example, in the IPsec context, the use of 3068 anti-replay mechanisms in AH and ESP support availability. 3070 Confidentiality 3071 Confidentiality is the security service that protects data from 3072 unauthorized disclosure. The primary confidentiality concern in 3073 most instances is unauthorized disclosure of application level 3074 data, but disclosure of the external characteristics of 3075 communication also can be a concern in some circumstances. 3076 Traffic flow confidentiality is the service that addresses this 3077 latter concern by concealing source and destination addresses, 3078 message length, or frequency of communication. In the IPsec 3079 context, using ESP in tunnel mode, especially at a security 3080 gateway, can provide some level of traffic flow confidentiality. 3081 (See also traffic analysis, below.) 3083 Data Origin Authentication 3084 Data origin authentication is a security service that verifies the 3085 identity of the claimed source of data. This service is usually 3086 bundled with connectionless integrity service. 3088 Encryption 3089 Encryption is a security mechanism used to transform data from an 3090 intelligible form (plaintext) into an unintelligible form 3091 (ciphertext), to provide confidentiality. The inverse 3092 transformation process is designated "decryption". Oftimes the 3093 term "encryption" is used to generically refer to both processes. 3095 Integrity 3096 Integrity is a security service that ensures that modifications to 3097 data are detectable. Integrity comes in various flavors to match 3098 application requirements. IPsec supports two forms of integrity: 3099 connectionless and a form of partial sequence integrity. 3100 Connectionless integrity is a service that detects modification of 3101 an individual IP datagram, without regard to the ordering of the 3102 datagram in a stream of traffic. The form of partial sequence 3103 integrity offered in IPsec is referred to as anti-replay 3104 integrity, and it detects arrival of duplicate IP datagrams 3105 (within a constrained window). This is in contrast to connection- 3106 oriented integrity, which imposes more stringent sequencing 3107 requirements on traffic, e.g., to be able to detect lost or re- 3108 ordered messages. Although authentication and integrity services 3109 often are cited separately, in practice they are intimately 3110 connected and almost always offered in tandem. 3112 Protected vs Unprotected 3113 "Protected" refers to the systems or interfaces that are inside 3114 the IPsec protection boundary and "unprotected" refers to the 3115 systems or interfaces that are outside the IPsec protection 3116 boundary. IPsec provides a boundary through which traffic passes. 3117 There is an asymmetry to this barrier, which is reflected in the 3118 processing model. Outbound data, if not discarded or bypassed, is 3119 protected via the application of AH or ESP and the addition of the 3120 corresponding headers. Inbound data, if not discarded or 3121 bypassed, is processed via the removal of AH or ESP headers. In 3122 this document, inbound traffic enters an IPsec implementation from 3123 the "unprotected" interface. Outbound traffic enters the 3124 implementation via the "protected" interface, or is internally 3125 generated by the implementation on the "protected" side of the 3126 boundary and directed toward the "unprotected" interface. An IPsec 3127 implementation may support more than one interface on either or 3128 both sides of the boundary. The protected interface may be 3129 internal, e.g., in a host implementation of IPsec. The protected 3130 interface may link to a socket layer interface presented by the 3131 OS. 3133 Security Association (SA) 3134 A simplex (uni-directional) logical connection, created for 3135 security purposes. All traffic traversing an SA is provided the 3136 same security processing. In IPsec, an SA is an internet layer 3137 abstraction implemented through the use of AH or ESP. State data 3138 associated with an SA is represented in the SA Database (SAD). 3140 Security Gateway 3141 A security gateway is an intermediate system that acts as the 3142 communications interface between two networks. The set of hosts 3143 (and networks) on the external side of the security gateway is 3144 termed unprotected (they are generally at least less protected 3145 than those "behind" the SG), while the networks and hosts on the 3146 internal side are viewed as protected. The internal subnets and 3147 hosts served by a security gateway are presumed to be trusted by 3148 virtue of sharing a common, local, security administration. (See 3149 "Trusted Subnetwork" below.) In the IPsec context, a security 3150 gateway is a point at which AH and/or ESP is implemented in order 3151 to serve a set of internal hosts, providing security services for 3152 these hosts when they communicate with external hosts also 3153 employing IPsec (either directly or via another security gateway). 3155 SPI 3156 Acronym for "Security Parameters Index" (SPI). The SPI is an 3157 arbitrary 32-bit value that is used by a receiver to identify the 3158 SA to which an incoming packet should be bound. For a unicast SA, 3159 the SPI can be used by itself to specify an SA, or it may be used 3160 in conjunction with the IPsec protocol type. Additional IP 3161 address information is used to identify multicast SAs. The SPI is 3162 carried in AH and ESP protocols to enable the receiving system to 3163 select the SA under which a received packet will be processed. An 3164 SPI has only local significance, as defined by the creator of the 3165 SA (usually the receiver of the packet carrying the SPI); thus an 3166 SPI is generally viewed as an opaque bit string. However, the 3167 creator of an SA may choose to interpret the bits in an SPI to 3168 facilitate local processing. 3170 Traffic Analysis 3171 The analysis of network traffic flow for the purpose of deducing 3172 information that is useful to an adversary. Examples of such 3173 information are frequency of transmission, the identities of the 3174 conversing parties, sizes of packets, flow identifiers, etc. 3175 [Sch94] 3177 Appendix B - Decorrelation 3179 This appendix is based on work done for caching of policies in the IP 3180 Security Policy Working Group by Luis Sanchez, Matt Condell, and John 3181 Zao. 3183 Two SPD entries are correlated if there is a non-null intersection 3184 between the values of corresponding selectors in each entry. Caching 3185 correlated SPD entries can lead to incorrect policy enforcement. A 3186 solution to this problem, that still allows for caching, is to remove 3187 the ambiguities by decorrelating the entries. That is, the SPD 3188 entries must be rewritten so that for every pair of entries there 3189 exists a selector for which there is a null intersection between the 3190 values in both of the entries. Once the entries are decorrelated, 3191 there is no longer any ordering requirement on them, since only one 3192 entry will match any lookup. The next section describes 3193 decorrelation in more detail and presents an algorithm that may be 3194 used to implement decorrelation. 3196 B.1 Decorrelation Algorithm 3198 The basic decorrelation algorithm takes each entry in a correlated 3199 SPD and divides it up into a set of entries using a tree structure. 3200 The nodes of the tree are the selectors that may overlap between the 3201 policies. At each node, the algorithm creates a branch for each of 3202 the values of the selector. It also creates one branch for the 3203 complement of the union of all selector values. Policies are then 3204 formed by traversing the tree from the root to each leaf. The 3205 policies at the leaves are compared to the set of already 3206 decorrelated policy rules. Each policy at a leaf is either completely 3207 overridden by a policy in the already decorrelated set and is 3208 discarded or is decorrelated with all the policies in the 3209 decorrelated set and is added to it. 3211 The basic algorithm does not guarantee an optimal set of decorrelated 3212 entries. That is, the entries may be broken up into smaller sets 3213 than is necessary, though they will still provide all the necessary 3214 policy information. Some extensions to the basic algorithm are 3215 described later to improve this and improve the performance of the 3216 algorithm. 3218 C A set of ordered, correlated entries (a correlated SPD) 3219 Ci The ith entry in C. 3220 U The set of decorrelated entries being built from C 3221 Ui The ith entry in U. 3222 Sik The kth selection for policy Ci 3223 Ai The action for policy Ci 3225 A policy (SPD entry) P may be expressed as a sequence of selector 3226 values and an action (BYPASS, DISCARD, or PROTECT): 3228 Ci = Si1 x Si2 x ... x Sik -> Ai 3230 1) Put C1 in set U as U1 3232 For each policy Cj (j > 1) in C 3234 2) If Cj is decorrelated with every entry in U, then add it to U. 3236 3) If Cj is correlated with one or more entries in U, create a tree 3237 rooted at the policy Cj that partitions Cj into a set of decorrelated 3238 entries. The algorithm starts with a root node where no selectors 3239 have yet been chosen. 3241 A) Choose a selector in Cj, Sjn, that has not yet been chosen when 3242 traversing the tree from the root to this node. If there are no 3243 selectors not yet used, continue to the next unfinished branch 3244 until all branches have been completed. When the tree is 3245 completed, go to step D. 3247 T is the set of entries in U that are correlated with the entry 3248 at this node. 3250 The entry at this node is the entry formed by the selector 3251 values of each of the branches between the root and this node. 3252 Any selector values that are not yet represented by branches 3253 assume the corresponding selector value in Cj, since the values 3254 in Cj represent the maximum value for each selector. 3256 B) Add a branch to the tree for each value of the selector Sjn that 3257 appears in any of the entries in T. (If the value is a superset 3258 of the value of Sjn in Cj, then use the value in Cj, since that 3259 value represents the universal set.) Also add a branch for the 3260 complement of the union of all the values of the selector Sjn 3261 in T. When taking the complement, remember that the universal 3262 set is the value of Sjn in Cj. A branch need not be created 3263 for the null set. 3265 C) Repeat A and B until the tree is completed. 3267 D) The entry to each leaf now represents an entry that is a subset 3268 of Cj. The entries at the leaves completely partition Cj in 3269 such a way that each entry is either completely overridden by 3270 an entry in U, or is decorrelated with the entries in U. 3272 Add all the decorrelated entries at the leaves of the tree to U. 3274 4) Get next Cj and go to 2. 3276 5) When all entries in C have been processed, then U will contain an 3277 decorrelated version of C. 3279 There are several optimizations that can be made to this algorithm. 3280 A few of them are presented here. 3282 It is possible to optimize, or at least improve, the amount of 3283 branching that occurs by carefully choosing the order of the 3284 selectors used for the next branch. For example, if a selector Sjn 3285 can be chosen so that all the values for that selector in T are equal 3286 to or a superset of the value of Sjn in Cj, then only a single branch 3287 needs to be created (since the complement will be null). 3289 Branches of the tree do not have to proceed with the entire 3290 decorrelation algorithm. For example, if a node represents an entry 3291 that is decorrelated with all the entries in U, then there is no 3292 reason to continue decorrelating that branch. Also, if a branch is 3293 completely overridden by an entry in U, then there is no reason to 3294 continue decorrelating the branch. 3296 An additional optimization is to check to see if a branch is 3297 overridden by one of the CORRELATED entries in set C that has already 3298 been decorrelated. That is, if the branch is part of decorrelating 3299 Cj, then check to see if it was overridden by an entry Cm, m < j. 3300 This is a valid check, since all the entries Cm are already expressed 3301 in U. 3303 Along with checking if an entry is already decorrelated in step 2, 3304 check if Cj is overridden by any entry in U. If it is, skip it since 3305 it is not relevant. An entry x is overridden by another entry y if 3306 every selector in x is equal to or a subset of the corresponding 3307 selector in entry y. 3309 Appendix C -- ASN.1 for an SPD Entry 3311 This appendix is included as an additional way to describe SPD 3312 entries, as defined in Section 4.4.1. It uses ASN.1 syntax. Since it 3313 describes encodings to be used with IKEv2, to express SPD entries, 3314 using ASN.1 constraints, it will not compile as shown due to 3315 "duplicate" tags. However it has been successfully complied when 3316 augmented with appropriate compiler directives. This syntax is merely 3317 illustrative and need not be employed in an implementation to achieve 3318 compliance. The SPD description in Section 4.4.1 is normative. 3320 SPDModule 3321 -- need a module identifier to be assigned from the IPsec WG arc 3323 DEFINITIONS IMPLICIT TAGS ::= 3325 BEGIN 3327 IMPORTS 3328 Name 3329 FROM PKIX1Explicit88 3330 { iso(1) identified-organization(3) 3331 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3332 id-mod(0) id-pkix1-explicit(18) } ; 3334 -- An SPD is a list of policies in decreasing order of preference 3335 SPD ::= SEQUENCE OF SPDEntry 3337 SPDEntry ::= CHOICE { 3338 iPsecEntry IPsecEntry, -- PROTECT traffic 3339 bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS 3341 IPsecEntry ::= SEQUENCE { -- Each entry consists of: 3342 name NameSets OPTIONAL, 3343 pFPs PacketFlags, -- Populate from packet flags 3344 -- Applies to ALL of the corresponding 3345 -- traffic selectors in the SelectorLists 3346 condition SelectorLists, -- Policy "condition" 3347 processing Processing -- Policy "action" 3348 } 3350 BypassOrDiscardEntry ::= SEQUENCE { 3351 bypass BOOLEAN, -- TRUE: BYPASS, FALSE: DISCARD 3352 condition InOutBound } 3354 InOutBound ::= CHOICE { 3355 outbound [0] SelectorLists, 3356 inbound [1] SelectorLists, 3357 bothways [2] BothWays } 3359 BothWays ::= SEQUENCE { 3360 inbound SelectorLists, 3361 outbound SelectorLists } 3363 NameSets ::= SEQUENCE { 3364 passed SET OF Names, -- Matched to IKE ID 3365 local SET OF Names } -- Used internally 3367 Names ::= CHOICE { -- IKEv2 IDs: 3368 dName DistinguishedName, -- ID_DER_ASN1_DN 3369 fqdn FQDN, -- ID_FQDN 3370 rfc822 [0] RFC822Name, -- ID_RFC822_ADDR 3371 keyID OCTET STRING } -- KEY_ID 3373 DistinguishedName ::= Name 3375 FQDN ::= IA5String 3377 RFC822Name ::= IA5String 3379 PacketFlags ::= BIT STRING { 3380 -- if set, take selector value from packet establishing SA 3381 -- else use value in SPD entry 3382 localAddr (0), 3383 remoteAddr (1), 3384 protocol (2), 3385 localPort (3), 3386 remotePort (4) } 3388 SelectorLists ::= SET OF SelectorList 3390 SelectorList ::= SEQUENCE { 3391 localAddr AddrList, 3392 remoteAddr AddrList, 3393 protocol ProtocolChoice } 3395 Processing ::= SEQUENCE { 3396 extSeqNum BOOLEAN, -- TRUE: 64 bit counter, FALSE: 32 bit 3397 seqOverflow BOOLEAN, -- TRUE: rekey, FALSE: terminate & audit 3398 fragCheck BOOLEAN, -- TRUE: stateful fragment checking, 3399 -- FALSE: no stateful fragment checking 3400 lifetime SALifetime, 3401 spi ManualSPI, 3402 algorithms ProcessingAlgs, 3403 tunnel TunnelOptions OPTIONAL } -- if absent, use transport mode 3405 SALifetime ::= SEQUENCE { 3406 seconds [0] INTEGER OPTIONAL, 3407 bytes [1] INTEGER OPTIONAL } 3409 ManualSPI ::= SEQUENCE { 3410 spi INTEGER, 3411 keys KeyIDs } 3413 KeyIDs ::= SEQUENCE OF OCTET STRING 3415 ProcessingAlgs ::= CHOICE { 3416 ah [0] IntegrityAlgs, -- AH 3417 esp [1] ESPAlgs} -- ESP 3419 ESPAlgs ::= CHOICE { 3420 integrity [0] IntegrityAlgs, -- ESP integrity only 3421 confidentiality [1] ConfidentialityAlgs, -- ESP confidentiality only 3422 both [2] IntegrityConfidentialityAlgs, 3423 combined [3] CombinedModeAlgs } 3425 IntegrityConfidentialityAlgs ::= SEQUENCE { -- must have both 3426 integrity IntegrityAlgs, 3427 confidentiality ConfidentialityAlgs } 3429 -- Integrity Algorithms, ordered by decreasing preference 3430 IntegrityAlgs ::= SEQUENCE OF IntegrityAlg 3432 -- Confidentiality Algorithms, ordered by decreasing preference 3433 ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg 3435 -- Integrity Algorithms 3436 IntegrityAlg ::= SEQUENCE { 3437 algorithm IntegrityAlgType, 3438 parameters ANY DEFINED BY algorithm OPTIONAL } 3440 IntegrityAlgType ::= INTEGER { 3441 none (0), 3442 auth-HMAC-MD5-96 (1), 3443 auth-HMAC-SHA1-96 (2), 3444 auth-DES-MAC (3), 3445 auth-KPDK-MD5 (4), 3446 auth-AES-XCBC-96 (5) 3447 -- tbd (6..65535) 3448 } 3450 -- Confidentiality Algorithms 3451 ConfidentialityAlg ::= SEQUENCE { 3452 algorithm ConfidentialityAlgType, 3453 parameters ANY DEFINED BY algorithm OPTIONAL } 3455 ConfidentialityAlgType ::= INTEGER { 3456 encr-DES-IV64 (1), 3457 encr-DES (2), 3458 encr-3DES (3), 3459 encr-RC5 (4), 3460 encr-IDEA (5), 3461 encr-CAST (6), 3462 encr-BLOWFISH (7), 3463 encr-3IDEA (8), 3464 encr-DES-IV32 (9), 3465 encr-RC4 (10), 3466 encr-NULL (11), 3467 encr-AES-CBC (12), 3468 encr-AES-CTR (13) 3469 -- tbd (14..65535) 3470 } 3472 CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg 3474 CombinedModeAlg ::= SEQUENCE { 3475 algorithm CombinedModeType, 3476 parameters ANY DEFINED BY algorithm } -- as defined outside of 3477 -- this document for AES modes. 3479 CombinedModeType ::= INTEGER { 3480 comb-AES-CCM (1), 3481 comb-AES-GCM (2) 3482 -- tbd (3..65535) 3483 } 3485 TunnelOptions ::= SEQUENCE { 3486 dscp DSCP, 3487 ecn BOOLEAN, -- TRUE: Copy CE to inner header 3488 df DF 3489 addresses TunnelAddresses } 3491 TunnelAddresses ::= CHOICE { 3492 ipv4 IPv4Pair, 3493 ipv6 [0] IPv6Pair } 3495 IPv4Pair ::= SEQUENCE { 3496 local OCTET STRING (SIZE(4)), 3497 remote OCTET STRING (SIZE(4)) } 3499 IPv6Pair ::= SEQUENCE { 3500 local OCTET STRING (SIZE(16)), 3501 remote OCTET STRING (SIZE(16)) } 3503 DSCP ::= SEQUENCE { 3504 copy BOOLEAN, -- TRUE: copy from inner header, FALSE: do not 3505 mapping OCTET STRING OPTIONAL} -- pointer to table if no copy 3507 DF ::= INTEGER { 3508 clear (0), 3509 set (1), 3510 copy (2) } 3512 ProtocolChoice::= CHOICE { 3513 anyProt AnyProtocol, -- for ANY protocol 3514 noNext [0] NoNextLayerProtocol, -- has no next layer items 3515 oneNext [1] OneNextLayerProtocol, -- has one next layer item 3516 twoNext [2] TwoNextLayerProtocol, -- has two next layer items 3517 fragment FragmentNoNext } -- has no next layer info 3519 AnyProtocol ::= SEQUENCE { 3520 id INTEGER (0), -- ANY protocol 3521 nextLayer AnyNextLayers } 3523 AnyNextLayers ::= SEQUENCE { -- with either 3524 first AnyNextLayer, -- ANY next layer selector 3525 second AnyNextLayer } -- ANY next layer selector 3527 NoNextLayerProtocol ::= INTEGER (2..254) 3529 FragmentNoNext ::= INTEGER (44) -- Fragment identifier 3531 OneNextLayerProtocol ::= SEQUENCE { 3532 id INTEGER (1..254), -- ICMP, MH, ICMPv6 3533 nextLayer NextLayerChoice } -- ICMP Type*256+Code 3534 -- MH Type*256 3536 TwoNextLayerProtocol ::= SEQUENCE { 3537 id INTEGER (2..254), -- Protocol 3538 local NextLayerChoice, -- Local and 3539 remote NextLayerChoice } -- Remote ports 3541 NextLayerChoice ::= CHOICE { 3542 any AnyNextLayer, 3543 opaque [0] OpaqueNextLayer, 3544 range [1] NextLayerRange } 3546 -- Representation of ANY in next layer field 3547 AnyNextLayer ::= SEQUENCE { 3548 start INTEGER (0), 3549 end INTEGER (65535) } 3551 -- Representation of OPAQUE in next layer field. 3552 -- Matches IKE convention 3553 OpaqueNextLayer ::= SEQUENCE { 3554 start INTEGER (65535), 3555 end INTEGER (0) } 3557 -- Range for a next layer field 3558 NextLayerRange ::= SEQUENCE { 3559 start INTEGER (0..65535), 3560 end INTEGER (0..65535) } 3562 -- List of IP addresses 3563 AddrList ::= SEQUENCE { 3564 v4List IPv4List OPTIONAL, 3565 v6List [0] IPv6List OPTIONAL } 3567 -- IPv4 address representations 3568 IPv4List ::= SEQUENCE OF IPv4Range 3570 IPv4Range ::= SEQUENCE { -- close, but not quite right ... 3571 ipv4Start OCTET STRING (SIZE (4)), 3572 ipv4End OCTET STRING (SIZE (4)) } 3574 -- IPv6 address representations 3575 IPv6List ::= SEQUENCE OF IPv6Range 3577 IPv6Range ::= SEQUENCE { -- close, but not quite right ... 3578 ipv6Start OCTET STRING (SIZE (16)), 3579 ipv6End OCTET STRING (SIZE (16)) } 3581 END 3583 Appendix D -- Fragment Handling Rationale 3585 There are three issues that must be resolved re processing of 3586 (plaintext) fragments in IPsec: 3588 - mapping a non-initial, outbound fragment to the right SA 3589 (or finding the right SPD entry) 3590 - verifying that a received, non-initial fragment is authorized 3591 for the SA via which it is received 3592 - mapping outbound and inbound non-initial fragments to the 3593 right SPD/cache entry, for BYPASS/DISCARD traffic. 3595 The first and third issues arise because we need a deterministic 3596 algorithm for mapping traffic to SAs (and SPD/cache entries). All 3597 three issues are important because we want to make sure that non- 3598 initial fragments that cross the IPsec boundary do not cause the 3599 access control policies in place at the receiver (or transmitter) to 3600 be violated. 3602 D.1 Transport Mode and Fragments 3604 First, we note that transport mode SAs have been defined to not 3605 carry fragments. This is a carryover from RFC 2401, where transport 3606 mode SAs always terminated at end points. This is a fundamental 3607 requirement because, in the worst case, an IPv4 fragment to which 3608 IPsec was applied, might then be fragmented (as a ciphertext packet), 3609 en route to the destination. IP fragment reassembly procedures at the 3610 IPsec receiver would not be able to distinguish between pre-IPsec 3611 fragments and fragments created after IPsec processing. 3613 For IPv6, only the sender is allowed to fragment a packet. As for 3614 IPv4, an IPsec implementation is allowed to fragment tunnel mode 3615 packets after IPsec processing, because it is the sender relative to 3616 the (outer) tunnel header. However, unlike IPv4, it would be feasible 3617 to carry a plaintext fragment on a transport mode SA, because the 3618 fragment header in IPv6 would appear after the AH or ESP header, and 3619 thus would not cause confusion at the receiver re reassembly. 3620 Specifically, the receiver would not attempt reassembly for the 3621 fragment until after IPsec processing. To keep things simple, this 3622 specification prohibits carriage of fragments on transport mode SAs 3623 for IPv6 traffic. 3625 When only end systems used transport mode SAs, the prohibition on 3626 carriage of fragments was not a problem, since we assumed that the 3627 end system could be configured to not offer a fragment to IPsec. For 3628 a native host implementation this seems reasonable, and, as someone 3629 already noted, RFC 2401 warned that a BITS implementation might have 3630 to reassemble fragments before performing an SA lookup. (It would 3631 then apply AH or ESP and could re-fragment the packet after IPsec 3632 processing.) Because a BITS implementation is assumed to be able to 3633 have access to all traffic emanating from its host, even if the host 3634 has multiple interfaces, this was deemed a reasonable mandate. 3636 In this specification, it is acceptable to use transport mode in 3637 cases where the IPsec implementation is not the ultimate destination, 3638 e.g., between two SGs. In principle, this creates a new opportunity 3639 for outbound, plaintext fragments to be mapped to a transport mode SA 3640 for IPsec processing. However, in these new contexts in which a 3641 transport mode SA is now approved for use, it seems likely that we 3642 can continue to prohibit transmission of fragments, as seen by IPsec, 3643 i.e., packets that have an "outer header" with a non-zero fragment 3644 offset field. For example, in an IP overlay network, packets being 3645 sent over transport mode SAs are IP-in-IP tunneled and thus have the 3646 necessary inner header to accommodate fragmentation prior to IPsec 3647 processing. When carried via a transport mode SA, IPsec would not 3648 examine the inner IP header for such traffic, and thus would not 3649 consider the packet to be a fragment. 3651 D.2 Tunnel Mode and Fragments 3653 For tunnel mode SAs, it has always been the case that outbound 3654 fragments might arrive for processing at an IPsec implementation. The 3655 need to accommodate fragmented outbound packets can pose a problem 3656 because a non-initial fragment generally will not contain the port 3657 fields associated with a next layer protocol such as TCP, UDP, or 3658 SCTP. Thus, depending on the SPD configuration for a given IPsec 3659 implementation, plaintext fragments might or might not pose a 3660 problem. 3662 For example, if the SPD requires that all traffic between two address 3663 ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries 3664 apply to this address range), then it should be easy to carry non- 3665 initial fragments on the SA defined for this address range, since the 3666 SPD entry implies an intent to carry ALL traffic between the address 3667 ranges. But, if there are multiple SPD entries that could match a 3668 fragment, and if these entries reference different subsets of port 3669 fields (vs. ANY), then it is not possible to map an outbound non- 3670 initial fragment to the right entry, unambiguously. (If we choose to 3671 allow carriage of fragments on transport mode SAs for IPv6, the 3672 problems arises in that context as well.) 3674 This problem largely, though not exclusively, motivated the 3675 definition of OPAQUE as a selector value for port fields in RFC 2401. 3676 The other motivation for OPAQUE is the observation that port fields 3677 might not be accessible due to the prior application of IPsec. For 3678 example, if a host applied IPsec to its traffic and that traffic 3679 arrived at an SG, these fields would be encrypted. The algorithm 3680 specified for locating the "next layer protocol" described in RFC 3681 2401 also motivated use of OPAQUE to accommodate an encrypted next 3682 layer protocol field in such circumstances. Nonetheless, the primary 3683 use of the OPAQUE value was to match traffic selector fields in 3684 packets that did not contain port fields (non-initial fragments), or 3685 packets in which the port fields were already encrypted (as a result 3686 of nested application of IPsec). RFC 2401 was ambiguous in discussing 3687 the use of OPAQUE vs. ANY, suggesting in some places that ANY might 3688 be an alternative to OPAQUE. 3690 We gain additional access control capability by defining both ANY and 3691 OPAQUE values. OPAQUE can be defined to match only fields that are 3692 not accessible. We could define ANY as the complement of OPAQUE, 3693 i.e., it would match all values but only for accessible port fields. 3694 We have therefore simplified the procedure employed to locate the 3695 next layer protocol in this document, so that we treat ESP and AH as 3696 next layer protocols. As a result, the notion of an encrypted next 3697 layer protocol field has vanished, and there is also no need to worry 3698 about encrypted port fields either. And accordingly, OPAQUE will be 3699 applicable only to non-initial fragments. 3701 Since we have adopted the definitions above for ANY and OPAQUE, we 3702 need to clarify how these values work when the specified protocol 3703 does not have port fields, and when ANY is used for the protocol 3704 selector. Accordingly, if a specific protocol value is used as a 3705 selector, and if that protocol has no port fields, then the port 3706 field selectors are to be ignored and ANY MUST be specified as the 3707 value for the port fields. (In this context, ICMP TYPE and CODE 3708 values are lumped together as a single port field (for IKEv2 3709 negotiation), as is the IPv6 Mobility Header TYPE value.) If the 3710 protocol selector is ANY, then this should be treated as equivalent 3711 to specifying a protocol for which no port fields are defined, and 3712 thus the port selectors should be ignored, and MUST be set to ANY. 3714 D.3. The Problem of Non-Initial Fragments 3716 For an SG implementation, it is obvious that fragments might arrive 3717 from end systems behind the SG. A BITW implementation also may 3718 encounter fragments from a host or gateway behind it. (As noted 3719 earlier, native host implementations and BITS implementations 3720 probably can avoid the problems described below.) In the worst case, 3721 fragments from a packet might arrive at distinct BITW or SG 3722 instantiations and thus preclude reassembly as a solution option. 3723 Hence, in RFC 2401 we adopted a general requirement that fragments 3724 must be accommodated in tunnel mode for all implementations. However, 3725 RFC 2401 did not provide a perfect solution. The use of OPAQUE as a 3726 selector value for port fields (a SHOULD in RFC 2401) allowed an SA 3727 to carry non-initial fragments. 3729 Using the features defined in RFC 2401, if one defined an SA between 3730 two IPsec (SG or BITW) implementations using the OPAQUE value for 3731 both port fields, then all non-initial fragments matching the S/D 3732 address and protocol values for the SA would be mapped to that SA. 3733 Initial fragments would NOT map to this SA, if we adopt a strict 3734 definition of OPAQUE. However, RFC 2401 did not provide detailed 3735 guidance on this and thus it may not have been apparent that use of 3736 this feature would essentially create a "non-initial fragment only" 3737 SA. 3739 In the course of discussing the "fragment-only" SA approach, it was 3740 noted that some subtle problems, problems not considered in RFC 2401, 3741 would have to be avoided. For example, an SA of this sort must be 3742 configured to offer the "highest quality" security services for any 3743 traffic between the indicated S/D addresses (for the specified 3744 protocol). This is necessary to ensure that any traffic captured by 3745 the fragment-only SA is not offered degraded security relative to 3746 what it would have been offered if the packet were not fragmented. A 3747 possible problem here is that we may not be able to identify the 3748 "highest quality" security services defined for use between two IPsec 3749 implementation, since the choice of security protocols, options, and 3750 algorithms is a lattice, not a totally ordered set. (We might safely 3751 say that BYPASS < AH < ESP w/integrity, but it gets complicated if we 3752 have multiple ESP encryption or integrity algorithm options.) So, one 3753 has to impose a total ordering on these security parameters to make 3754 this work, but this can be done locally. 3756 However, this conservative strategy has a possible performance down 3757 side; if most traffic traversing an IPsec implementation for a given 3758 S/D address pair (and specified protocol) is bypassed, then a 3759 fragment-only SA for that address pair might cause a dramatic 3760 increase in the volume of traffic afforded crypto processing. If the 3761 crypto implementation cannot support high traffic rates, this could 3762 cause problems. (An IPsec implementation that is capable of line rate 3763 or near line rate crypto performance would not be adversely affected 3764 by this SA configuration approach. Nonetheless, the performance 3765 impact is a potential concern, specific to implementation 3766 capabilities.) 3768 Another concern is that non-initial fragments sent over a dedicated 3769 SA might be used to effect overlapping reassembly attacks, when 3770 combined with an apparently acceptable initial fragment. (This sort 3771 of attack assumes creation of bogus fragments, and is not a side 3772 effect of normal fragmentation.) This concern is easily addressed in 3773 IPv4, by checking the fragment offset value to ensure that no non- 3774 initial fragments have a small enough offset to overlap port fields 3775 that should be contained in the initial fragment. Recall that the 3776 IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 3777 bytes, so any ports should be present in the initial fragment. If we 3778 require all non-initial fragments to have an offset of say 128 or 3779 greater, just to be on the safe side, this should prevent successful 3780 attacks of this sort. If the intent is only to protect against this 3781 sort of reassembly attack, this check need be implemented only by a 3782 receiver. 3784 IPv6 also has a fragment offset, carried in the fragmentation 3785 extension header. However, IPv6 extension headers are variable in 3786 length and there is no analogous max header length value that we can 3787 use to check non-initial fragments, to reject ones that might be used 3788 for an attack of the sort noted above. A receiver would need to 3789 maintain state analogous to reassembly state, to provide equivalent 3790 protection. So, only for IPv4 it is feasible to impose a fragment 3791 offset check that would reject attacks designed to circumvent port 3792 field checks by IPsec (or firewalls) when passing non-initial 3793 fragments. 3795 Another possible concern is that in some topologies and SPD 3796 configurations this approach might result in an access control 3797 surprise. The notion is that if we create an SA to carry ALL (non- 3798 initial) fragments then that SA would carry some traffic that might 3799 otherwise arrive as plaintext via a separate path, e.g., a path 3800 monitored by a proxy firewall. But, this concern arises only if the 3801 other path allows initial fragments to traverse it without requiring 3802 reassembly, presumably a bad idea for a proxy firewall. Nonetheless, 3803 this does represent a potential problem in some topologies and under 3804 certain assumptions re: SPD and (other) firewall rule sets, and 3805 administrators need to be warned of this possibility. 3807 A less serious concern is that non-initial fragments sent over a non- 3808 initial fragment-only SA might represent a DoS opportunity, in that 3809 they could be sent when no valid, initial fragment will ever arrive. 3810 This might be used to attack hosts behind an SG or BITW device. 3811 However, the incremental risk posed by this sort of attack, which can 3812 be mounted only by hosts behind an SG or BITW device, seems small. 3814 If we interpret the ANY selector value as encompassing OPAQUE, then a 3815 single SA with ANY values for both port fields would be able to 3816 accommodate all traffic matching the S/D address and protocol traffic 3817 selectors, an alternative to using the OPAQUE value. But, using ANY 3818 here precludes multiple, distinct SAs between the same IPsec 3819 implementations for the same address pairs and protocol. So, it is 3820 not an exactly equivalent alternative. 3822 Fundamentally, fragment handling problems arise only when more than 3823 one SA is defined with the same S/D address and protocol selector 3824 values, but with different port field selector values. 3826 D.4 BYPASS/DISCARD Traffic 3828 We also have to address the non-initial fragment processing issue for 3829 BYPASS/DISCARD entries, independent of SA processing. This is largely 3830 a local matter for two reasons: 3831 1) We have no means for coordinating SPD entries for such 3832 traffic between IPsec implementations since IKE is not 3833 invoked. 3834 2) Many of these entries refer to traffic that is NOT 3835 directed to or received from a location that is using 3836 IPsec. So there is no peer IPsec implementation with 3837 which to coordinate via any means. 3839 However, this document should provide guidance here, consistent with 3840 our goal of offering a well-defined, access control function for all 3841 traffic, relative to the IPsec boundary. To that end, this document 3842 says that implementations MUST support fragment reassembly for 3843 BYPASS/DISCARD traffic when port fields are specified. An 3844 implementation also MUST permit a user or administrator to accept 3845 such traffic or reject such traffic using the SPD conventions 3846 described in Secion 4.4.1. The concern is that BYPASS of a 3847 cleartext, non-initial fragment arriving at an IPsec implementation 3848 could undermine the security afforded IPsec-protected traffic 3849 directed to the same destination. For example, consider an IPsec 3850 implementation configured with an SPD entry that calls for IPsec- 3851 protection of traffic between a specific source/destination address 3852 pair, and for a specific protocol and destination port, e.g., TCP 3853 traffic on port 23 (Telnet). Assume that the implementation also 3854 allows BYPASS of traffic from the same source/destination address 3855 pair and protocol, but for a different destination port, e.g., port 3856 119 (NNTP). An attacker could send a non-initial fragment (with a 3857 forged source address) that, if bypassed, could overlap with IPsec- 3858 protected traffic from the same source and thus violate the integrity 3859 of the IPsec-protected traffic. Requiring stateful fragment checking 3860 for BYPASS entries with non-trivial port ranges prevents attacks of 3861 this sort. 3863 D.5 Just say no to ports? 3865 It has been suggested that we could avoid the problems described 3866 above by not allowing port field selectors to be used in tunnel mode. 3867 But the discussion above shows this to be an unnecessarily stringent 3868 approach, i.e., since no problems arise for the native OS and BITS 3869 implementations. Moreover, some WG members have described scenarios 3870 where use of tunnel mode SAs with (non-trivial) port field selectors 3871 is appropriate. So the challenge is defining a strategy that can deal 3872 with this problem in BITW and SG contexts. Also note that 3873 BYPASS/DISCARD entries in the SPD that make use of ports pose the 3874 same problems, irrespective of tunnel vs. transport mode notions. 3876 Some folks have suggested that a firewall behind an SG or BITW should 3877 be left to enforce port level access controls, and the effects of 3878 fragmentation. However, this seems to be an incongruous suggestion in 3879 that elsewhere in IPsec (e.g., in IKE payloads) we are concerned 3880 about firewalls that always discard fragments. If many firewalls 3881 don't pass fragments in general, why should we expect them to deal 3882 with fragments in this case? So, this analysis rejects the suggestion 3883 of disallowing use of port field selectors with tunnel mode SAs. 3885 D.6 Other Suggested Solutions 3887 One suggestion is to reassemble fragments at the sending IPsec 3888 implementation, and thus avoid the problem entirely. This approach is 3889 invisible to a receiver and thus could be adopted as a purely local 3890 implementation option. 3892 A more sophisticated version of this suggestion calls for 3893 establishing and maintaining minimal state from each initial fragment 3894 encountered, to allow non-initial fragments to be matched to the 3895 right SAs or SPD/cache entries. This implies an extension to the 3896 current processing model (and the old one). The IPsec implementation 3897 would intercept all fragments, capture Source/Destination IP 3898 addresses, protocol, packet ID, and port fields from initial 3899 fragments and then use this data to map non-initial fragments to SAs 3900 that require port fields. If this approach is employed, the receiver 3901 needs to employ an equivalent scheme, as it too must verify that 3902 received fragments are consistent with SA selector values. A non- 3903 initial fragment that arrives prior to an initial fragment could be 3904 cached or discarded, awaiting arrival of the corresponding initial 3905 fragment. 3907 A downside of both approaches noted above is that they will not 3908 always work. When a BITW device or SG is configured in a topology 3909 that might allow some fragments for a packet to be processed at 3910 different SGs or BITW devices, then there is no guarantee that all 3911 fragments will ever arrive at the same IPsec device. This approach 3912 also raises possible processing problems. If the sender caches non- 3913 initial fragments until the corresponding initial fragment arrives, 3914 buffering problems might arise, especially at high speeds. If the 3915 non-initial fragments are discarded rather than cached, there is no 3916 guarantee that traffic will ever pass, e.g., retransmission will 3917 result in different packet IDs that cannot be matched with prior 3918 transmissions. In any case, housekeeping procedures will be needed to 3919 decide when to delete the fragment state data, adding some complexity 3920 to the system. Nonetheless, this is a viable solution in some 3921 topologies, and these are likely to be common topologies. 3923 The Working Group rejected an earlier version of the convention of 3924 creating an SA to carry only non-initial fragments, something that 3925 was supported implicitly under the RFC 2401 model via use of OPAQUE 3926 port fields, but never clearly articulated in RFC 2401. The 3927 (rejected) text called for each non-initial fragment to be treated as 3928 protocol 44 (the IPv6 fragment header protocol ID) by the sender and 3929 receiver. This approach has the potential to make IPv4 and IPv6 3930 fragment handling more uniform, but it does not fundamentally change 3931 the problem, nor does it address the issue of fragment handling for 3932 BYPASS/DISCARD traffic. Given the fragment overlap attack problem 3933 that IPv6 poses, it does not seem that it is worth the effort to 3934 adopt this strategy. 3936 D.7 Consistency 3938 Earlier the WG agreed to allow an IPsec BITS, BITW or SG to perform 3939 fragmentation prior to IPsec processing. If this fragmentation is 3940 performed after SA lookup at the sender, there is no "mapping to the 3941 right SA" problem. But, the receiver still needs to be able to verify 3942 that the non-initial fragments are consistent with the SA via which 3943 they are received. Since the initial fragment might be lost en route, 3944 the receiver encounters all of the potential problems noted above. 3945 Thus, if we are to be consistent in our decisions, we need to say how 3946 a receiver will deal with the non-initial fragments that arrive. 3948 D.8 Conclusions 3950 There is no simple, uniform way to handle fragments in all contexts. 3951 Different approaches work better in different contexts. Thus this 3952 document offers 3 choices -- one MUST and two MAYs. At some point in 3953 the future, if the community gains experience with the two MAYs, they 3954 may become SHOULDs or MUSTs or other approaches may be proposed. 3956 Appendix E - Example of Supporting Nested SAs via SPD and Forwarding 3957 Table Entries 3959 This appendix provides an example of how to configure the SPD and 3960 forwarding tables to support a nested pair of SAs, consistent with 3961 the new processing model. For simplicity, this example assumes just 3962 one SPD-I. 3964 The goal in this example is to support a transport mode SA from A to 3965 C, carried over a tunnel mode SA from A to B. For example, A might be 3966 a laptop connected to the public internet, B a firewall that protects 3967 a corporate network, and C a server on the corporate network that 3968 demands end-to-end authentication of A's traffic. 3970 +---+ +---+ +---+ 3971 | A |=====| B | | C | 3972 | |------------| | 3973 | |=====| | | | 3974 +---+ +---+ +---+ 3976 A's SPD contains entries of the form: 3978 Next Layer 3979 Rule Local Remote Protocol Action 3980 ---- ----- ------ ---------- ----------------------- 3981 1 C A ESP BYPASS 3982 2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf) 3983 3 A C ANY PROTECT(ESP,transport,integr-only) 3984 4 A B ICMP,IKE BYPASS 3986 A's unprotected-side forwarding table is set so that outbound packets 3987 destined for C are looped back to the protected side. A's protected 3988 side forwarding table is set so that inbound ESP packets are looped 3989 back to the unprotected side. A's forwarding tables contain entries 3990 of the form: 3992 Unprotected-side forwarding table 3994 Rule Local Remote Protocol Action 3995 ---- ----- ------ -------- --------------------------- 3996 1 A C ANY loop back to protected side 3997 2 A B ANY forward to B 3999 Protected-side forwarding table 4001 Rule Local Remote Protocol Action 4002 ---- ----- ------ -------- ----------------------------- 4003 1 A C ESP loop back to unprotected side 4005 An outbound TCP packet from A to C would match SPD rule 3 and have 4006 transport mode ESP applied to it. The unprotected-side forwarding 4007 table would then loop back the packet. The packet is compared against 4008 SPD-I (see Figure 2), matches SPD rule 1, and so it is BYPASSed. The 4009 packet is treated as an outbound packet and compared against the SPD 4010 for a third time. This time it matches SPD rule 2, so ESP is applied 4011 in tunnel mode. This time the forwarding table doesn't loop back the 4012 packet, because the outer destination address is B, so the packet 4013 goes out onto the wire. 4015 An inbound TCP packet from C to A, is wrapped in two ESP headers; the 4016 outer header (ESP in tunnel mode) shows B as the source whereas the 4017 inner header (ESP transport mode) shows C as the source. Upon arrival 4018 at A, the packet would be mapped to an SA based on the SPI, have the 4019 outer header removed, and be decrypted and integrity-checked. Then it 4020 would be matched against the SAD selectors for this SA, which would 4021 specify C as the source and A as the destination, derived from SPD 4022 rule 2. The protected-side forwarding function would then send it 4023 back to the unprotected side based on the addresses and the next 4024 layer protocol (ESP), indicative of nesting. It is compared against 4025 SPD-O (see figure 3) and found to match SPD rule 1, so it is 4026 BYPASSed. The packet is mapped to an SA based on the SPI, integrity- 4027 checked, and compared against the SAD selectors derived from SPD rule 4028 3. The forwarding function then passes it up to the next layer, 4029 because it isn't an ESP packet. 4031 References 4033 Normative 4035 [BBCDWW98]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 4036 and W. Weiss, "An Architecture for Differentiated Service", 4037 RFC 2475, December 1998. 4039 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 4040 Requirement Level", BCP 14, RFC 2119, March 1997. 4042 [CD98] Conta, A. and S. Deering, "Internet Control Message 4043 Protocol (ICMPv6) for the Internet Protocol Version 6 4044 (IPv6) Specification", RFC 2463, December 1998. 4046 [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 4047 (IPv6) Specification", RFC 2460, December 1998. 4049 [Eas03] Eastlake, D., "Cryptographic Algorithm Implementation 4050 Requirements For ESP And AH", ???, ???? 2004. 4052 [RFC Editor: Please update reference [Eas03] "Cryptographic 4053 Algorithm Implementation Requirements For ESP And AH" 4054 (draft-ietf-ipsec-esp-ah-algorithms-02.txt) with the RFC 4055 number and month when it is issued.] 4057 [Kau04] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", 4058 RFC ???, ???? 2004. 4060 [RFC Editor: Please update the reference [Kau04] "The 4061 Internet Key Exchange (IKEv2) Protocol" (draft-ietf-ipsec- 4062 ikev2-17.txt) with the RFC number and month when it is 4063 issued.] 4065 [Ken04a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4066 ???, ???? 2004. 4068 [RFC Editor: Please update the reference [Ken04a] "IP 4069 Encapsulating Security Payload (ESP)" (draft-ietf-ipsec- 4070 esp-v3-09.txt) with the RFC number and month when it is 4071 issued.] 4073 [Ken04b] Kent, S., "IP Authentication Header", RFC ???, ??? 2004. 4075 [RFC Editor: Please update the reference [Ken04b] "IP 4076 Authentication Header" (draft-ietf-ipsec-rfc2402bis-09.txt) 4077 with the RFC number and month when it is issued.] 4079 [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4080 November 1990. 4082 [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 4083 1981 4085 [Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, 4086 September 1981 4088 [Sch03] Schiller, J., "Cryptographic Algorithms for use in the 4089 Internet Key Exchange Version 2", RFC ???, ???? 2003 4091 [RFC Editor: Please update the reference [Sch03] 4092 "Cryptographic Algorithms for use in the Internet Key 4093 Exchange Version 2" (draft-ietf-ipsec- 4094 ikev2-algorithms-05.txt) with the RFC number and month when 4095 it is issued.] 4097 Informative 4099 [CoSa04] Condell, M., and Sanchez, L. On the Deterministic 4100 Enforcement of Un-ordered Security Policies", BBN Technical 4101 Memo 1346, March 2004 4103 [FaLiHaMeTr00]Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, 4104 P., "Generic Routing Encapsulation (GRE), RFC 2784, March 4105 2000. 4107 [Gro02] Grossman, D., "New Terminology and Clarifications for 4108 Diffserv", RFC 3260, April 2002. 4110 [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for 4111 IP", WWork in Progress, November 3, 2002. 4113 [HA94] Haller, N., and Atkinson, R., "On Internet Authentication", 4114 RFC 1704, October 1994 4116 [Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 4117 IPv6", RFC 3775, June 2004 4119 [NiBlBaBL98]Nichols, K., Blake, S., Baker, F., Black, D., "Definition 4120 of the Differentiated Services Field (DS Field) in the IPv4 4121 and IPv6 Headers", RFC2474, December 1998. 4123 [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 4124 October 1996. 4126 [RaFlBl01]Ramakrishnan, K., Floyd, S., Black, D., "The Addition of 4127 Explicit Congestion Notification (ECN) to IP", RFC 3168, 4128 September 2001. 4130 [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group 4131 Domain of Interpretation", RFC 3547, July 2003. 4133 [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security 4134 Architecture", RFC 3740, March 2004. 4136 [RaCoCaDe04]Rajahalme, J., Conta, A., Carpenter, B., Deering, S., 4137 "IPv6 Flow Label Specification, RFC 3697, March 2004. 4139 [Sch94] Schneier, B., Applied Cryptography, Section 8.6, John 4140 Wiley & Sons, New York, NY, 1994. 4142 [Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May 4143 2000. 4145 [SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 4146 Payload Compression Protocol (IPComp)", RFC 3173, September 4147 2001. 4149 [ToEgWa04]Touch, J., Eggert, L., Wang, Y., Use of IPsec Transport 4150 Mode for Dynamic Routing, RFC 3884, September 2004. 4152 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- 4153 level Networks", ACM Computing Surveys, Vol. 15, No. 2, 4154 June 1983. 4156 Author Information 4158 Stephen Kent 4159 BBN Technologies 4160 10 Moulton Street 4161 Cambridge, MA 02138 4162 USA 4163 Phone: +1 (617) 873-3988 4164 EMail: kent@bbn.com 4166 Karen Seo 4167 BBN Technologies 4168 10 Moulton Street 4169 Cambridge, MA 02138 4170 USA 4171 Phone: +1 (617) 873-3152 4172 EMail: kseo@bbn.com 4174 Notices 4176 "The IETF takes no position regarding the validity or scope of any 4177 Intellectual Property Rights or other rights that might be claimed to 4178 pertain to the implementation or use of the technology described in 4179 this document or the extent to which any license under such rights 4180 might or might not be available; nor does it represent that it has 4181 made any independent effort to identify any such rights. Information 4182 on the procedures with respect to rights in RFC documents can be 4183 found in BCP 78 and BCP 79. 4185 Copies of IPR disclosures made to the IETF Secretariat and any 4186 assurances of licenses to be made available, or the result of an 4187 attempt made to obtain a general license or permission for the use of 4188 such proprietary rights by implementers or users of this 4189 specification can be obtained from the IETF on-line IPR repository at 4190 http://www.ietf.org/ipr. 4192 The IETF invites any interested party to bring to its attention any 4193 copyrights, patents or patent applications, or other proprietary 4194 rights that may cover technology that may be required to implement 4195 this standard. Please address the information to the IETF at ietf- 4196 ipr@ietf.org." 4198 Copyright (C) The Internet Society (2004). 4200 This document is subject to the rights, licenses and restrictions 4201 contained in BCP 78, and except as set forth therein, the authors 4202 retain all their rights. 4204 "This document and the information contained herein are provided on 4205 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 4206 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 4207 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 4208 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4209 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4212 This document and translations of it may be copied and furnished to 4213 others, and derivative works that comment on or otherwise explain it 4214 or assist in its implementation may be prepared, copied, published 4215 and distributed, in whole or in part, without restriction of any 4216 kind, provided that the above copyright notice and this paragraph are 4217 included on all such copies and derivative works. However, this 4218 document itself may not be modified in any way, such as by removing 4219 the copyright notice or references to the Internet Society or other 4220 Internet organizations, except as needed for the purpose of 4221 developing Internet standards in which case the procedures for 4222 copyrights defined in the Internet Standards process must be 4223 followed, or as required to translate it into languages other than 4224 English. 4226 The limited permissions granted above are perpetual and will not be 4227 revoked by the Internet Society or its successors or assigns. 4229 Expires June 2005