idnits 2.17.1 draft-ietf-ipsec-rfc2401bis-06.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 3978, Section 5.5 on line 4622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4592. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 4598), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? == 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 1054 has weird spacing: '...g value examp...' == Line 1056 has weird spacing: '...elector selec...' == Line 1744 has weird spacing: '...oc addr list ...' == Line 1749 has weird spacing: '...em addr list ...' == Line 1754 has weird spacing: '...rotocol list ...' == (9 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 (September 2005) is 6788 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 616, but not defined == Missing Reference: 'RaFlBl01' is mentioned on line 617, but not defined == Missing Reference: 'FaLiHaMeTr00' is mentioned on line 635, but not defined == Missing Reference: 'ToEgWa04' is mentioned on line 635, but not defined == Missing Reference: 'WaKiHo97' is mentioned on line 1338, but not defined == Missing Reference: 'HarCar98' is mentioned on line 2035, but not defined == Missing Reference: 'RFC 2474' is mentioned on line 2605, but not defined == Missing Reference: 'BBCDWW98' is mentioned on line 2605, but not defined == Missing Reference: 'RaCoCaDe04' is mentioned on line 2646, but not defined -- Looks like a reference, but probably isn't: '0' on line 3952 -- Looks like a reference, but probably isn't: '1' on line 3931 -- Looks like a reference, but probably isn't: '2' on line 3901 -- Looks like a reference, but probably isn't: '3' on line 3804 ** 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. 'Eas05' -- Possible downref: Non-RFC (?) normative reference: ref. 'Kau05' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken05a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ken05b' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch05' -- 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: 8 errors (**), 0 flaws (~~), 20 warnings (==), 20 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-06.txt BBN Technologies 4 Obsoletes: RFC 2401 March 2005 5 Expires September 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 six 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 28 "work in progress". The list of current Internet-Drafts can be 29 accessed at http://www.ietf.org/1id-abstracts.html. The list of 30 Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright (C) The Internet Society (2005). All Rights Reserved. 35 Abstract 37 This document describes an updated version of the "Security 38 Architecture for IP", which is designed to provide security services 39 for traffic at the IP layer. This document obsoletes RFC 2401 40 (November 1998). 42 Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor: 43 Please remove this line prior to publication as an RFC.] 45 Table of Contents 46 1. Introduction........................................................4 47 1.1 Summary of Contents of Document................................4 48 1.2 Audience.......................................................4 49 1.3 Related Documents..............................................5 50 2. Design Objectives...................................................5 51 2.1 Goals/Objectives/Requirements/Problem Description..............5 52 2.2 Caveats and Assumptions........................................6 53 3. System Overview ....................................................7 54 3.1 What IPsec Does................................................7 55 3.2 How IPsec Works................................................9 56 3.3 Where IPsec Can Be Implemented................................10 57 4. Security Associations..............................................11 58 4.1 Definition and Scope..........................................11 59 4.2 SA Functionality..............................................16 60 4.3 Combining SAs.................................................17 61 4.4 Major IPsec Databases.........................................17 62 4.4.1 The Security Policy Database (SPD).......................19 63 4.4.1.1 Selectors...........................................25 64 4.4.1.2 Structure of an SPD entry...........................29 65 4.4.1.3 More re: Fields Associated with Next Layer 66 Protocols...........................................31 67 4.4.2 Security Association Database (SAD)......................33 68 4.4.2.1 Data Items in the SAD...............................34 69 4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD.36 70 4.4.3 Peer Authorization Database (PAD)........................41 71 4.4.3.1 PAD Entry IDs and Matching Rules....................42 72 4.4.3.2 IKE Peer Authentication Data........................43 73 4.4.3.3 Child SA Authorization Data.........................44 74 4.4.3.4 How the PAD Is Used.................................44 75 4.5 SA and Key Management.........................................45 76 4.5.1 Manual Techniques........................................46 77 4.5.2 Automated SA and Key Management..........................46 78 4.5.3 Locating a Security Gateway..............................47 79 4.6 SAs and Multicast.............................................48 80 5. IP Traffic Processing..............................................48 81 5.1 Outbound IP Traffic Processing (protected-to-unprotected).....49 82 5.1.1 Handling an Outbound Packet That Must Be Discarded.......52 83 5.1.2 Header Construction for Tunnel Mode......................53 84 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode.........55 85 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode.........56 86 5.2 Processing Inbound IP Traffic (unprotected-to-protected)......57 87 6. ICMP Processing ...................................................61 88 6.1 Processing ICMP Error Messages Directed to an IPsec 89 Implementation.....................................61 90 6.1.1 ICMP Error Messages Received on the Unprotected 91 Side of the Boundary...............................61 92 6.1.2 ICMP Error Messages Received on the Protected 93 Side of the Boundary...............................62 95 6.2 Processing Protected, Transit ICMP Error Messages.............62 96 7. Handling Fragments (on the protected side of the IPsec boundary)...64 97 7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments..65 98 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments............65 99 7.3 Stateful Fragment Checking....................................66 100 7.4 BYPASS/DISCARD traffic........................................66 101 8. Path MTU/DF Processing.............................................67 102 8.1 DF Bit........................................................67 103 8.2 Path MTU (PMTU) Discovery.....................................67 104 8.2.1 Propagation of PMTU......................................68 105 8.2.2 PMTU Aging...............................................68 106 9. Auditing...........................................................69 107 10. Conformance Requirements..........................................69 108 11. Security Considerations...........................................69 109 12. IANA Considerations...............................................70 110 13. Differences from RFC 2401.........................................70 111 Acknowledgements......................................................73 112 Appendix A -- Glossary................................................74 113 Appendix B -- Decorrelation...........................................77 114 Appendix C -- ASN.1 for an SPD Entry..................................80 115 Appendix D -- Fragment Handling Rationale.............................86 116 D.1 Transport Mode and Fragments..................................86 117 D.2 Tunnel Mode and Fragments.....................................87 118 D.3 The Problem of Non-Initial Fragments..........................88 119 D.4 BYPASS/DISCARD traffic........................................91 120 D.5 Just say no to ports?.........................................91 121 D.6 Other Suggested Solutions.....................................92 122 D.7 Consistency...................................................93 123 D.8 Conclusions...................................................93 124 Appendix E -- Example of Supporting Nested SAs via SPD and Forwarding 125 Table Entries.....................................94 126 References............................................................96 127 Author Information....................................................99 128 Notices..............................................................100 129 1. Introduction 131 1.1 Summary of Contents of Document 133 This document specifies the base architecture for IPsec compliant 134 systems. It describes how to provide a set of security services for 135 traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] 136 environments. This document describes the requirements for systems 137 that implement IPsec, the fundamental elements of such systems, and 138 how the elements fit together and fit into the IP environment. It 139 also describes the security services offered by the IPsec protocols, 140 and how these services can be employed in the IP environment. This 141 document does not address all aspects of the IPsec architecture. 142 Other documents address additional architectural details in 143 specialized environments, e.g., use of IPsec in Network Address 144 Translation (NAT) environments and more comprehensive support for IP 145 multicast. The fundamental components of the IPsec security 146 architecture are discussed in terms of their underlying, required 147 functionality. Additional RFCs (see Section 1.3 for pointers to 148 other documents) define the protocols in (a), (c), and (d). 150 a. Security Protocols -- Authentication Header (AH) and 151 Encapsulating Security Payload (ESP) 152 b. Security Associations -- what they are and how they work, 153 how they are managed, associated processing 154 c. Key Management -- manual and automated (The Internet Key 155 Exchange (IKE)) 156 d. Cryptographic algorithms for authentication and encryption 158 This document is not a Security Architecture for the Internet; it 159 addresses security only at the IP layer, provided through the use of 160 a combination of cryptographic and protocol security mechanisms. 162 The spelling "IPsec" is preferred and used throughout this and all 163 related IPsec standards. All other capitalizations of IPsec (e.g., 164 IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of 165 the sequence of letters "IPsec" should be understood to refer to the 166 IPsec protocols. 168 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 169 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 170 document, are to be interpreted as described in RFC 2119 [Bra97]. 172 1.2 Audience 174 The target audience for this document is primarily individuals who 175 implement this IP security technology or who architect systems that 176 will use this technology. Technically adept users of this technology 177 (end users or system administrators) also are part of the target 178 audience. A glossary is provided in Appendix A to help fill in gaps 179 in background/vocabulary. This document assumes that the reader is 180 familiar with the Internet Protocol (IP), related networking 181 technology, and general information system security terms and 182 concepts. 184 1.3 Related Documents 186 As mentioned above, other documents provide detailed definitions of 187 some of the components of IPsec and of their inter-relationship. 188 They include RFCs on the following topics: 190 a. security protocols -- RFCs describing the Authentication 191 Header (AH) [Ken05b] and Encapsulating Security Payload 192 (ESP) [Ken05a] protocols. 193 b. cryptographic algorithms for integrity and encryption - one 194 RFC that defines the mandatory, default algorithms for use 195 with AH and ESP [Eas05], a similar RFC that defines the 196 mandatory algorithms for use with IKE v2 [Sch05] plus a 197 separate RFC for each cryptographic algorithm. 198 c. automatic key management -- RFCs on "The Internet Key 199 Exchange (IKE v2) Protocol" [Kau05] and "Cryptographic 200 Algorithms for use in the Internet Key Exchange Version 2" 201 [Sch05]. 203 2. Design Objectives 205 2.1 Goals/Objectives/Requirements/Problem Description 207 IPsec is designed to provide interoperable, high quality, 208 cryptographically-based security for IPv4 and IPv6. The set of 209 security services offered includes access control, connectionless 210 integrity, data origin authentication, detection and rejection of 211 replays (a form of partial sequence integrity), confidentiality (via 212 encryption), and limited traffic flow confidentiality. These 213 services are provided at the IP layer, offering protection in a 214 standard fashion for all protocols that may be carried over IP 215 (including IP itself). 217 IPsec includes a specification for minimal firewall functionality, 218 since that is an essential aspect of access control at the IP layer. 219 Implementations are free to provide more sophisticated firewall 220 mechanisms, and to implement the IPsec-mandated functionality using 221 those more sophisticated mechanisms. (Note that interoperability may 222 suffer if additional firewall constraints on traffic flows are 223 imposed by an IPsec implementation but cannot be negotiated based on 224 the traffic selector features defined in this document and negotiated 225 via IKE v2.) The IPsec firewall function makes use of the 226 cryptographically-enforced authentication and integrity provided for 227 all IPsec traffic to offer better access control than could be 228 obtained through use of a firewall (one not privy to IPsec internal 229 parameters) plus separate cryptographic protection. 231 Most of the security services are provided through use of two traffic 232 security protocols, the Authentication Header (AH) and the 233 Encapsulating Security Payload (ESP), and through the use of 234 cryptographic key management procedures and protocols. The set of 235 IPsec protocols employed in a context, and the ways in which they are 236 employed, will be determined by the users/administrators in that 237 context. It is the goal of the IPsec architecture to ensure that 238 compliant implementations include the services and management 239 interfaces needed to meet the security requirements of a broad user 240 population. 242 When IPsec is correctly implemented and deployed, it ought not 243 adversely affect users, hosts, and other Internet components that do 244 not employ IPsec for traffic protection. IPsec security protocols 245 (AH & ESP, and to a lesser extent, IKE) are designed to be 246 cryptographic algorithm-independent. This modularity permits 247 selection of different sets of cryptographic algorithms as 248 appropriate, without affecting the other parts of the implementation. 249 For example, different user communities may select different sets of 250 cryptographic algorithms (creating cryptographically-enforced 251 cliques) if required. 253 To facilitate interoperability in the global Internet, a set of 254 default cryptographic algorithms for use with AH and ESP is specified 255 in [Eas05] and a set of mandatory-to-implement algorithms for IKE v2 256 is specified in [Sch05]. [Eas05] and [Sch05] will be periodically 257 updated to keep pace with computational and cryptologic advances. By 258 specifying these algorithms in documents that are separate from the 259 AH, ESP, and IKE v2 specifications, these algorithms can be updated 260 or replaced without affecting the standardization progress of the 261 rest of the IPsec document suite. The use of these cryptographic 262 algorithms, in conjunction with IPsec traffic protection and key 263 management protocols, is intended to permit system and application 264 developers to deploy high quality, Internet layer, cryptographic 265 security technology. 267 2.2 Caveats and Assumptions 269 The suite of IPsec protocols and associated default cryptographic 270 algorithms are designed to provide high quality security for Internet 271 traffic. However, the security offered by use of these protocols 272 ultimately depends on the quality of the their implementation, which 273 is outside the scope of this set of standards. Moreover, the 274 security of a computer system or network is a function of many 275 factors, including personnel, physical, procedural, compromising 276 emanations, and computer security practices. Thus IPsec is only one 277 part of an overall system security architecture. 279 Finally, the security afforded by the use of IPsec is critically 280 dependent on many aspects of the operating environment in which the 281 IPsec implementation executes. For example, defects in OS security, 282 poor quality of random number sources, sloppy system management 283 protocols and practices, etc. can all degrade the security provided 284 by IPsec. As above, none of these environmental attributes are 285 within the scope of this or other IPsec standards. 287 3. System Overview 289 This section provides a high level description of how IPsec works, 290 the components of the system, and how they fit together to provide 291 the security services noted above. The goal of this description is 292 to enable the reader to "picture" the overall process/system, see how 293 it fits into the IP environment, and to provide context for later 294 sections of this document, which describe each of the components in 295 more detail. 297 An IPsec implementation operates in a host, as a security gateway, or 298 as an independent device, affording protection to IP traffic. (A 299 security gateway is an intermediate system implementing IPsec, e.g., 300 a firewall or router that has been IPsec-enabled.) More detail on 301 these classes of implementations is provided later, in Section 3.3. 302 The protection offered by IPsec is based on requirements defined by a 303 Security Policy Database (SPD) established and maintained by a user 304 or system administrator, or by an application operating within 305 constraints established by either of the above. In general, packets 306 are selected for one of three processing actions based on IP and next 307 layer header information (Selectors, Section 4.4.1.1) matched against 308 entries in the Security Policy Database (SPD). Each packet is either 309 PROTECTed using IPsec security services, DISCARDed, or allowed to 310 BYPASS IPsec protection, based on the applicable SPD policies 311 identified by the Selectors. 313 3.1 What IPsec Does 315 IPsec creates a boundary between unprotected and protected 316 interfaces, for a host or a network (see Figure 1 below). Traffic 317 traversing the boundary is subject to the access controls specified 318 by the user or administrator responsible for the IPsec configuration. 319 These controls indicate whether packets cross the boundary unimpeded, 320 are afforded security services via AH or ESP, or are discarded. IPsec 321 security services are offered at the IP layer through selection of 322 appropriate security protocols, cryptographic algorithms, and 323 cryptographic keys. IPsec can be used to protect one or more "paths" 324 (a) between a pair of hosts, (b) between a pair of security gateways, 325 or (c) between a security gateway and a host. A compliant host 326 implementation MUST support (a) and (c) and a compliant security 327 gateway must support all three of these forms of connectivity, since 328 under certain circumstances a security gateway acts as a host. 330 Unprotected 331 ^ ^ 332 | | 333 +-------------|-------|-------+ 334 | +-------+ | | | 335 | |Discard|<--| V | 336 | +-------+ |B +--------+ | 337 ................|y..| AH/ESP |..... IPsec Boundary 338 | +---+ |p +--------+ | 339 | |IKE|<----|a ^ | 340 | +---+ |s | | 341 | +-------+ |s | | 342 | |Discard|<--| | | 343 | +-------+ | | | 344 +-------------|-------|-------+ 345 | | 346 V V 347 Protected 349 Figure 1. Top Level IPsec Processing Model 351 In this diagram, "unprotected" refers to an interface that might also 352 be described as "black" or "ciphertext." Here, "protected" refers to 353 an interface that might also be described as "red" or "plaintext." 354 The protected interface noted above may be internal, e.g., in a host 355 implementation of IPsec, the protected interface may link to a socket 356 layer interface presented by the OS. In this document, the term 357 "inbound" refers to traffic entering an IPsec implementation via the 358 unprotected interface or emitted by the implementation on the 359 unprotected side of the boundary and directed towards the protected 360 interface. The term "outbound" refers to traffic entering the 361 implementation via the protected interface, or emitted by the 362 implementation on the protected side of the boundary and directed 363 toward the unprotected interface. An IPsec implementation may 364 support more than one interface on either or both sides of the 365 boundary. 367 Note the facilities for discarding traffic on either side of the 368 IPsec boundary, the BYPASS facility that allows traffic to transit 369 the boundary without cryptographic protection, and the reference to 370 IKE as a protected-side key and security management function. 372 IPsec optionally supports negotiation of IP compression [SMPT01], 373 motivated in part by the observation that when encryption is employed 374 within IPsec, it prevents effective compression by lower protocol 375 layers. 377 3.2 How IPsec Works 379 IPsec uses two protocols to provide traffic security services -- 380 Authentication Header (AH) and Encapsulating Security Payload (ESP). 381 Both protocols are described in detail in their respective RFCs 382 [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY 383 support AH. (Support for AH has been downgraded to MAY because 384 experience has shown that there are very few contexts in which ESP 385 cannot provide the requisite security services. Note that ESP can be 386 used to provide only integrity, without confidentiality, making it 387 comparable to AH in most contexts.) 389 o The IP Authentication Header (AH) [Ken05b] offers integrity and 390 data origin authentication, with optional (at the discretion of 391 the receiver) anti-replay features. 393 o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers 394 the same set of services, and also offers confidentiality. Use of 395 ESP to provide confidentiality without integrity is NOT 396 RECOMMENDED. When ESP is used with confidentiality enabled, there 397 are provisions for limited traffic flow confidentiality, i.e., 398 provisions for concealing packet length, and for facilitating 399 efficient generation and discard of dummy packets. This capability 400 is likely to be effective primarily in VPN and overlay network 401 contexts. 403 o Both AH and ESP offer access control, enforced through the 404 distribution of cryptographic keys and the management of traffic 405 flows as dictated by the Security Policy Database (SPD, Section 406 4.4.1). 408 These protocols may be applied individually or in combination with 409 each other to provide IPv4 and IPv6 security services. However, most 410 security requirements can be met through the use of ESP by itself. 411 Each protocol supports two modes of use: transport mode and tunnel 412 mode. In transport mode, AH and ESP provide protection primarily for 413 next layer protocols; in tunnel mode, AH and ESP are applied to 414 tunneled IP packets. The differences between the two modes are 415 discussed in Section 4.1. 417 IPsec allows the user (or system administrator) to control the 418 granularity at which a security service is offered. For example, one 419 can create a single encrypted tunnel to carry all the traffic between 420 two security gateways or a separate encrypted tunnel can be created 421 for each TCP connection between each pair of hosts communicating 422 across these gateways. IPsec, through the SPD management paradigm, 423 incorporates facilities for specifying: 425 o which security protocol (AH or ESP) to employ, the mode (transport 426 or tunnel), security service options, what cryptographic 427 algorithms to use, and in what combinations to use the specified 428 protocols and services, 430 o the granularity at which protection should be applied. 432 Because most of the security services provided by IPsec require the 433 use of cryptographic keys, IPsec relies on a separate set of 434 mechanisms for putting these keys in place. This document requires 435 support for both manual and automated distribution of keys. It 436 specifies a specific public-key based approach (IKE v2 [Kau05]) for 437 automated key management, but other automated key distribution 438 techniques MAY be used. 440 Note: This document mandates support for several features for which 441 support is available in IKE v2 but not in IKE v1, e.g., negotiation 442 of an SA representing ranges of local and remote ports or negotiation 443 of multiple SAs with the same selectors. Therefore this document 444 assumes use of IKE v2 or a key and security association management 445 system with comparable features. 447 3.3 Where IPsec Can Be Implemented 449 There are many ways in which IPsec may be implemented in a host, or 450 in conjunction with a router or firewall to create a security 451 gateway, or as an independent security device. 453 a. IPsec may be integrated into the native IP stack. This requires 454 access to the IP source code and is applicable to both hosts and 455 security gateways, although native host implementations benefit 456 the most from this strategy, as explained later (Section 4.4.1, 457 paragraph 6; Section 4.4.1.1, last paragraph). 459 b. In a "bump-in-the-stack" (BITS) implementation, IPsec is 460 implemented "underneath" an existing implementation of an IP 461 protocol stack, between the native IP and the local network 462 drivers. Source code access for the IP stack is not required in 463 this context, making this implementation approach appropriate for 464 use with legacy systems. This approach, when it is adopted, is 465 usually employed in hosts. 467 c. The use of a dedicated, inline security protocol processor is a 468 common design feature of systems used by the military, and of some 469 commercial systems as well. It is sometimes referred to as a 470 "bump-in-the-wire" (BITW) implementation. Such implementations 471 may be designed to serve either a host or a gateway. Usually the 472 BITW device is itself IP addressable. When supporting a single 473 host, it may be quite analogous to a BITS implementation, but in 474 supporting a router or firewall, it must operate like a security 475 gateway. 477 This document often talks in terms of use of IPsec by a host or a 478 security gateway, without regard to whether the implementation is 479 native, BITS or BITW. When the distinctions among these 480 implementation options are significant, the document makes reference 481 to specific implementation approaches. 483 A host implementation of IPsec may appear in devices that might not 484 be viewed as "hosts." For example, a router might employ IPsec to 485 protect routing protocols (e.g., BGP) and management functions (e.g., 486 Telnet), without affecting subscriber traffic traversing the router. 487 A security gateway might employ separate IPsec implementations to 488 protect its management traffic and subscriber traffic. The 489 architecture described in this document is very flexible. For 490 example, a computer with a full-featured, compliant, native OS IPsec 491 implementation should be capable of being configured to protect 492 resident (host) applications and to provide security gateway 493 protection for traffic traversing the computer. Such configuration 494 would make use of the forwarding tables and the SPD selection 495 function described in Sections 5.1 and 5.2. 497 4. Security Associations 499 This section defines Security Association management requirements for 500 all IPv6 implementations and for those IPv4 implementations that 501 implement AH, ESP, or both AH and ESP. The concept of a "Security 502 Association" (SA) is fundamental to IPsec. Both AH and ESP make use 503 of SAs and a major function of IKE is the establishment and 504 maintenance of SAs. All implementations of AH or ESP MUST support 505 the concept of an SA as described below. The remainder of this 506 section describes various aspects of SA management, defining required 507 characteristics for SA policy management and SA management 508 techniques. 510 4.1 Definition and Scope 512 An SA is a simplex "connection" that affords security services to the 513 traffic carried by it. Security services are afforded to an SA by 514 the use of AH, or ESP, but not both. If both AH and ESP protection 515 are applied to a traffic stream, then two SAs must be created and 516 coordinated to effect protection through iterated application of the 517 security protocols. To secure typical, bi-directional communication 518 between two IPsec-enabled systems, a pair of SAs (one in each 519 direction) is required. IKE explicitly creates SA pairs in 520 recognition of this common usage requirement. 522 For an SA used to carry unicast traffic, the SPI (Security Parameters 523 Index - see Appendix A and AH [Ken05b] and ESP [Ken05a] 524 specifications) by itself suffices to specify an SA. However, as a 525 local matter, an implementation may choose to use the SPI in 526 conjunction with the IPsec protocol type (AH or ESP) for SA 527 identification. If an IPsec implementation supports multicast, then 528 it MUST support multicast SAs using the algorithm below for mapping 529 inbound IPsec datagrams to SAs. Implementations that support only 530 unicast traffic need not implement this demultiplexing algorithm. 532 In many secure multicast architectures, e.g., [RFC3740], a central 533 Group Controller/Key Server unilaterally assigns the Group Security 534 Association's (GSA's) SPI. This SPI assignment is not negotiated or 535 coordinated with the key management (e.g., IKE) subsystems that 536 reside in the individual end systems that constitute the group. 537 Consequently, it is possible that a GSA and a unicast SA can 538 simultaneously use the same SPI. A multicast-capable IPsec 539 implementation MUST correctly de-multiplex inbound traffic even in 540 the context of SPI collisions. 542 Each entry in the SA Database (SAD) (Section 4.4.2) must indicate 543 whether the SA lookup makes use of the destination IP address, or the 544 destination and source IP addresses, in addition to the SPI. For 545 multicast SAs, the protocol field is not employed for SA lookups. For 546 each inbound, IPsec-protected packet, an implementation must conduct 547 its search of the SAD such that it finds the entry that matches the 548 "longest" SA identifier. In this context, if two or more SAD entries 549 match based on the SPI value, then the entry that also matches based 550 on destination address, or destination and source address (as 551 indicated in the SAD entry) is the "longest" match. This implies a 552 logical ordering of the SAD search as follows: 554 1. Search the SAD for a match on the combination of SPI, 555 destination address, and source address. If an SAD entry 556 matches, then process the inbound packet with that 557 matching SAD entry. Otherwise, proceed to step 2. 559 2. Search the SAD for a match on both SPI and destination address. 560 If the SAD entry matches then process the inbound packet 561 with that matching SAD entry. Otherwise, proceed to step 3. 563 3. Search the SAD for a match on only SPI if the receiver has 564 chosen to maintain a single SPI space for AH and ESP, and on 565 both SPI and protocol otherwise. If an SAD entry matches then 566 process the inbound packet with that matching SAD entry. 568 Otherwise, discard the packet and log an auditable event. 570 In practice, an implementation may choose any method (or none at all) 571 to accelerate this search, although its externally visible behavior 572 MUST be functionally equivalent to having searched the SAD in the 573 above order. For example, a software-based implementation could index 574 into a hash table by the SPI. The SAD entries in each hash table 575 bucket's linked list could be kept sorted to have those SAD entries 576 with the longest SA identifiers first in that linked list. Those SAD 577 entries having the shortest SA identifiers could be sorted so that 578 they are the last entries in the linked list. A hardware-based 579 implementation may be able to effect the longest match search 580 intrinsically, using commonly available Ternary Content-Addressable 581 Memory (TCAM) features. 583 The indication of whether source and destination address matching is 584 required to map inbound IPsec traffic to SAs MUST be set either as a 585 side effect of manual SA configuration or via negotiation using an SA 586 management protocol, e.g., IKE or GDOI [RFC3547]. Typically, 587 Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA 588 identifier composed of an SPI, a destination multicast address, and 589 source address. An Any-Source Multicast group SA requires only an SPI 590 and a destination multicast address as an identifier. 592 If different classes of traffic (distinguished by Differentiated 593 Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the 594 same SA, and if the receiver is employing the optional anti-replay 595 feature available in both AH and ESP, this could result in 596 inappropriate discarding of lower priority packets due to the 597 windowing mechanism used by this feature. Therefore a sender SHOULD 598 put traffic of different classes, but with the same selector values, 599 on different SAs to support QoS appropriately. To permit this, the 600 IPsec implementation MUST permit establishment and maintenance of 601 multiple SAs between a given sender and receiver, with the same 602 selectors. Distribution of traffic among these parallel SAs to 603 support QoS is locally determined by the sender and is not negotiated 604 by IKE. The receiver MUST process the packets from the different SAs 605 without prejudice. These requirements apply to both transport and 606 tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in 607 question appear in the inner IP header. In transport mode, the DSCP 608 value might change en route, but this should not cause problems with 609 respect to IPsec processing since the value is not employed for SA 610 selection and MUST NOT be checked as part of SA/packet validation. 611 However, if significant re-ordering of packets occurs in an SA, e.g., 612 as a result of changes to DSCP values en route, this may trigger 613 packet discarding by a receiver due to application of the anti-replay 614 mechanism. 616 DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and Explicit 617 Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", 618 as that term in used in this architecture, the sender will need a 619 mechanism to direct packets with a given (set of) DSCP values to the 620 appropriate SA. This mechanism might be termed a "classifier". 622 As noted above, two types of SAs are defined: transport mode and 623 tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose 624 to require that both SAs in a pair be of the same mode, transport or 625 tunnel. 627 A transport mode SA is an SA typically employed between a pair of 628 hosts to provide end-to-end security services. When security is 629 desired between two intermediate systems along a path (vs. end-to-end 630 use of IPsec), transport mode MAY be used between security gateways 631 or between a security gateway and a host. In the case where 632 transport mode is used between security gateways or between a 633 security gateway and a host, transport mode may be used to support 634 in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling 635 [FaLiHaMeTr00] or Dynamic routing [ToEgWa04]) over transport mode 636 SAs. To clarify, the use of transport mode by an intermediate system 637 (e.g., a security gateway) is permitted only when applied to packets 638 whose source address (for outbound packets) or destination address 639 (for inbound packets) is an address belonging to the intermediate 640 system itself. The access control functions that are an important 641 part of IPsec are significantly limited in this context, as they 642 cannot be applied to the end-to-end headers of the packets that 643 traverse a transport mode SA used in this fashion. Thus this way of 644 using transport mode should be evaluated carefully before being 645 employed in a specific context. 647 In IPv4, a transport mode security protocol header appears 648 immediately after the IP header and any options, and before any next 649 layer protocols (e.g., TCP or UDP). In IPv6, the security protocol 650 header appears after the base IP header and selected extension 651 headers, but may appear before or after destination options; it MUST 652 appear before next layer protocols (e.g., TCP, UDP, SCTP). In the 653 case of ESP, a transport mode SA provides security services only for 654 these next layer protocols, not for the IP header or any extension 655 headers preceding the ESP header. In the case of AH, the protection 656 is also extended to selected portions of the IP header preceding it, 657 selected portions of extension headers, and selected options 658 (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or 659 IPv6 Destination extension headers). For more details on the 660 coverage afforded by AH, see the AH specification [Ken05b]. 662 A tunnel mode SA is essentially an SA applied to an IP tunnel, with 663 the access controls applied to the headers of the traffic inside the 664 tunnel. Two hosts MAY establish a tunnel mode SA between themselves. 666 Aside from the two exceptions below, whenever either end of a 667 security association is a security gateway, the SA MUST be tunnel 668 mode. Thus an SA between two security gateways is typically a tunnel 669 mode SA, as is an SA between a host and a security gateway. The two 670 exceptions are as follows. 672 o Where traffic is destined for a security gateway, e.g., SNMP 673 commands, the security gateway is acting as a host and transport 674 mode is allowed. In this case, the SA terminates at a host 675 (management) function within a security gateway and thus merits 676 different treatment. 678 o As noted above, security gateways MAY support a transport mode SA 679 to provide security for IP traffic between two intermediate 680 systems along a path, e.g., between a host and a security gateway 681 or between two security gateways. 683 Several concerns motivate the use of tunnel mode for an SA involving 684 a security gateway. For example, if there are multiple paths (e.g., 685 via different security gateways) to the same destination behind a 686 security gateway, it is important that an IPsec packet be sent to the 687 security gateway with which the SA was negotiated. Similarly, a 688 packet that might be fragmented en-route must have all the fragments 689 delivered to the same IPsec instance for reassembly prior to 690 cryptographic processing. Also, when a fragment is processed by IPsec 691 and transmitted, then fragmented en-route, it is critical that there 692 be inner and outer headers to retain the fragmentation state data for 693 the pre- and post-IPsec packet formats. Hence there are several 694 reasons for employing tunnel mode when either end of an SA is a 695 security gateway. (Use of an IP-in-IP tunnel in conjunction with 696 transport mode can also address these fragmentation issues. However, 697 this configuration limits the ability of IPsec to enforce access 698 control policies on traffic.) 700 Note: AH and ESP cannot be applied using transport mode to IPv4 701 packets that are fragments. Only tunnel mode can be employed in such 702 cases. For IPv6, it would be feasible to carry a plaintext fragment 703 on a transport mode SA; however, for simplicity, this restriction 704 also applies to IPv6 packets. See Section 7 for more details on 705 handling plaintext fragments on the protected side of the IPsec 706 barrier. 708 For a tunnel mode SA, there is an "outer" IP header that specifies 709 the IPsec processing source and destination, plus an "inner" IP 710 header that specifies the (apparently) ultimate source and 711 destination for the packet. The security protocol header appears 712 after the outer IP header, and before the inner IP header. If AH is 713 employed in tunnel mode, portions of the outer IP header are afforded 714 protection (as above), as well as all of the tunneled IP packet 715 (i.e., all of the inner IP header is protected, as well as next layer 716 protocols). If ESP is employed, the protection is afforded only to 717 the tunneled packet, not to the outer header. 719 In summary, 721 a) A host implementation of IPsec MUST support both transport and 722 tunnel mode. This is true for native, BITS, and BITW 723 implementations for hosts. 725 b) A security gateway MUST support tunnel mode and MAY support 726 transport mode. If it supports transport mode, that should be 727 used only when the security gateway is acting as a host, e.g., for 728 network management, or to provide security between two 729 intermediate systems along a path. 731 4.2 SA Functionality 733 The set of security services offered by an SA depends on the security 734 protocol selected, the SA mode, the endpoints of the SA, and on the 735 election of optional services within the protocol. 737 For example, both AH and ESP offer integrity and authentication 738 services, but the coverage differs for each protocol and differs for 739 transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6 740 extension header must be protected en-route between sender and 741 receiver, AH can provide this service, except for IP or extension 742 headers that may change in a fashion not predictable by the sender. 743 However, the same security may be achieved in some contexts by 744 applying ESP to a tunnel carrying a packet. 746 The granularity of access control provided is determined by the 747 choice of the selectors that define each SA. Moreover, the 748 authentication means employed by IPsec peers, e.g., during creation 749 of an IKE (vs. child) SA also effects the granularity of the access 750 control afforded. 752 If confidentiality is selected, then an ESP (tunnel mode) SA between 753 two security gateways can offer partial traffic flow confidentiality. 754 The use of tunnel mode allows the inner IP headers to be encrypted, 755 concealing the identities of the (ultimate) traffic source and 756 destination. Moreover, ESP payload padding also can be invoked to 757 hide the size of the packets, further concealing the external 758 characteristics of the traffic. Similar traffic flow confidentiality 759 services may be offered when a mobile user is assigned a dynamic IP 760 address in a dialup context, and establishes a (tunnel mode) ESP SA 761 to a corporate firewall (acting as a security gateway). Note that 762 fine granularity SAs generally are more vulnerable to traffic 763 analysis than coarse granularity ones that are carrying traffic from 764 many subscribers. 766 Note: A compliant implementation MUST NOT allow instantiation of an 767 ESP SA that employs both NULL encryption and no integrity algorithm. 768 An attempt to negotiate such an SA is an auditable event by both 769 initiator and responder. The audit log entry for this event SHOULD 770 include the current date/time, local IKE IP address, and remote IKE 771 IP address. The initiator SHOULD record the relevant SPD entry. 773 4.3 Combining SAs 775 This document does not require support for nested security 776 associations or for what RFC 2401 called "SA bundles." These features 777 still can be effected by appropriate configuration of both the SPD 778 and the local forwarding functions (for inbound and outbound 779 traffic), but this capability is outside of the IPsec module and thus 780 the scope of this specification. As a result, management of 781 nested/bundled SAs is potentially more complex and less assured than 782 under the model implied by RFC 2401. An implementation that provides 783 support for nested SAs SHOULD provide a management interface that 784 enables a user or administrator to express the nesting requirement, 785 and then create the appropriate SPD entries and forwarding table 786 entries to effect the requisite processing. (See Appendix E for an 787 example of how to configure nested SAs.) 789 4.4 Major IPsec Databases 791 Many of the details associated with processing IP traffic in an IPsec 792 implementation are largely a local matter, not subject to 793 standardization. However, some external aspects of the processing 794 must be standardized to ensure interoperability and to provide a 795 minimum management capability that is essential for productive use of 796 IPsec. This section describes a general model for processing IP 797 traffic relative to IPsec functionality, in support of these 798 interoperability and functionality goals. The model described below 799 is nominal; implementations need not match details of this model as 800 presented, but the external behavior of implementations MUST 801 correspond to the externally observable characteristics of this model 802 in order to be compliant. 804 There are three nominal databases in this model: the Security Policy 805 Database (SPD), the Security Association Database (SAD), and the Peer 806 Authorization Database (PAD). The first specifies the policies that 807 determine the disposition of all IP traffic inbound or outbound from 808 a host or security gateway (Section 4.4.1). The second database 809 contains parameters that are associated with each established (keyed) 810 SA (Section 4.4.2). The third database, the Peer Authorization 811 Database (PAD) provides a link between an SA management protocol like 812 IKE and the SPD (Section 4.4.3). 814 Multiple Separate IPsec Contexts 816 If an IPsec implementation acts as a security gateway for multiple 817 subscribers, it MAY implement multiple separate IPsec contexts. 818 Each context MAY have and MAY use completely independent 819 identities, policies, key management SAs, and/or IPsec SAs. This 820 is for the most part a local implementation matter. However, a 821 means for associating inbound (SA) proposals with local contexts 822 is required. To this end, if supported by the key management 823 protocol in use, context identifiers MAY be conveyed from 824 initiator to responder in the signaling messages, with the result 825 that IPsec SAs are created with a binding to a particular context. 826 For example, a security gateway that provides VPN service to 827 multiple customers will be able to associate each customer's 828 traffic with the correct VPN. 830 Forwarding vs Security Decisions 832 The IPsec model described here embodies a clear separation between 833 forwarding (routing) and security decisions, to accommodate a wide 834 range of contexts where IPsec may be employed. Forwarding may be 835 trivial, in the case where there are only two interfaces, or it 836 may be complex, e.g., if the context in which IPsec is implemented 837 employs a sophisticated forwarding function. IPsec assumes only 838 that outbound and inbound traffic that has passed through IPsec 839 processing is forwarded in a fashion consistent with the context 840 in which IPsec is implemented. Support for nested SAs is optional; 841 if required, it requires coordination between forwarding tables 842 and SPD entries to cause a packet to traverse the IPsec boundary 843 more than once. 845 "Local" vs "Remote" 847 In this document, with respect to IP addresses and ports, the 848 terms "Local" and "Remote" are used for policy rules. "Local" 849 refers to the entity being protected by an IPsec implementation, 850 i.e., the "source" address/port of outbound packets or the 851 "destination" address/port of inbound packets. "Remote" refers to 852 a peer entity or peer entities. The terms "source" and 853 "destination" are used for packet header fields. 855 "Non-initial" vs "Initial" Fragments 857 Throughout this document, the phrase "non-initial" fragments is 858 used to mean fragments that do not contain all of the selector 859 values that may be needed for access control (e.g., they might not 860 contain Next Layer Protocol, source and destination ports, ICMP 861 message type/code, Mobility Header type). And the phrase "initial" 862 fragment is used to mean a fragment that contains all the selector 863 values needed for access control. However, it should be noted that 864 for IPv6, which fragment contains the Next Layer Protocol and 865 ports (or ICMP message type/code or Mobility Header type) will 866 depend on the kind and number of extension headers present. The 867 "initial" fragment might not be the first fragment, in this 868 context. 870 4.4.1 The Security Policy Database (SPD) 872 An SA is a management construct used to enforce security policy for 873 traffic crossing the IPsec boundary. Thus an essential element of SA 874 processing is an underlying Security Policy Database (SPD) that 875 specifies what services are to be offered to IP datagrams and in what 876 fashion. The form of the database and its interface are outside the 877 scope of this specification. However, this section specifies minimum 878 management functionality that must be provided, to allow a user or 879 system administrator to control whether and how IPsec is applied to 880 traffic transmitted or received by a host or transiting a security 881 gateway. The SPD, or relevant caches, must be consulted during the 882 processing of all traffic (inbound and outbound), including traffic 883 not protected by IPsec, that traverses the IPsec boundary. This 884 includes IPsec management traffic such as IKE. An IPsec 885 implementation MUST have at least one SPD, and it MAY support 886 multiple SPDs, if appropriate for the context in which the IPsec 887 implementation operates. There is no requirement to maintain SPDs on 888 a per interface basis, as was specified in RFC 2401. However, if an 889 implementation supports multiple SPDs, then it MUST include an 890 explicit SPD selection function, that is invoked to select the 891 appropriate SPD for outbound traffic processing. The inputs to this 892 function are the outbound packet and any local metadata (e.g., the 893 interface via which the packet arrived) required to effect the SPD 894 selection function. The output of the function is an SPD identifier 895 (SPD-ID). 897 The SPD is an ordered database, consistent with the use of ACLs or 898 packet filters in firewalls, routers, etc. The ordering requirement 899 arises because entries often will overlap due to the presence of 900 (non-trivial) ranges as values for selectors. Thus a user or 901 administrator MUST be able to order the entries to express a desired 902 access control policy. There is no way to impose a general, canonical 903 order on SPD entries, because of the allowed use of wildcards for 904 selector values and because the different types of selectors are not 905 hierarchically related. 907 Processing Choices: DISCARD, BYPASS, PROTECT 909 An SPD must discriminate among traffic that is afforded IPsec 910 protection and traffic that is allowed to bypass IPsec. This 911 applies to the IPsec protection to be applied by a sender and to 912 the IPsec protection that must be present at the receiver. For 913 any outbound or inbound datagram, three processing choices are 914 possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The 915 first choice refers to traffic that is not allowed to traverse the 916 IPsec boundary (in the specified direction). The second choice 917 refers to traffic that is allowed to cross the IPsec boundary 918 without IPsec protection. The third choice refers to traffic that 919 is afforded IPsec protection, and for such traffic the SPD must 920 specify the security protocols to be employed, their mode, 921 security service options, and the cryptographic algorithms to be 922 used. 924 SPD-S, SPD-I, SPD-O 926 An SPD is logically divided into three pieces. The SPD-S (secure 927 traffic) contains entries for all traffic subject to IPsec 928 protection. SPD-O (outbound) contains entries for all outbound 929 traffic that is to be bypassed or discarded. SPD-I (inbound) is 930 applied to inbound traffic that will be bypassed or discarded. All 931 three of these can be decorrelated (with the exception noted above 932 for native host implementations) to facilitate caching. If an 933 IPsec implementation supports only one SPD, then the SPD consists 934 of all three parts. If multiple SPDs are supported, some of them 935 may be partial, e.g., some SPDs might contain only SPD-I entries, 936 to control inbound bypassed traffic on a per-interface basis. The 937 split allows SPD-I to be consulted without having to consult 938 SPD-S, for such traffic. Since the SPD-I is just a part of the 939 SPD, if a packet that is looked up in the SPD-I cannot be matched 940 to an entry there, then the packet MUST be discarded. Note that 941 for outbound traffic, if a match is not found in SPD-S, then SPD-O 942 must be checked to see if the traffic should be bypassed. 943 Similarly, if SPD-O is checked first and no match is found, then 944 SPD-S must be checked. In an ordered, non-decorrelated SPD, the 945 entries for the SPD-S, SPD-I, and SPD-O are interleaved. So there 946 is one look up in the SPD. 948 SPD entries 950 Each SPD entry specifies packet disposition as BYPASS, DISCARD, or 951 PROTECT. The entry is keyed by a list of one or more selectors. 952 The SPD contains an ordered list of these entries. The required 953 selector types are defined in Section 4.4.1.1. These selectors are 954 used to define the granularity of the SAs that are created in 955 response to an outbound packet or in response to a proposal from a 956 peer. The detailed structure of an SPD entry is described in 957 Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that 958 matches anything that is otherwise unmatched, and discards it. 960 The SPD MUST permit a user or administrator to specify policy 961 entries as follows: 963 - SPD-I: For inbound traffic that is to be bypassed or discarded, 964 the entry consists of the values of the selectors that apply to 965 the traffic to be bypassed or discarded. 967 - SPD-O: For outbound traffic that is to be bypassed or 968 discarded, the entry consists of the values of the selectors 969 that apply to the traffic to be bypassed or discarded. 971 - SPD-S: For traffic that is to be protected using IPsec, the 972 entry consists of the values of the selectors that apply to the 973 traffic to be protected via AH or ESP, controls on how to 974 create SAs based on these selectors, and the parameters needed 975 to effect this protection (e.g., algorithms, modes, etc.). Note 976 that an SPD-S entry also contains information such as "populate 977 from packet" (PFP) flag (see paragraphs below on "How To Derive 978 the Values for an SAD entry") and bits indicating whether the 979 SA lookup makes use of the local and remote IP addresses in 980 addition to the SPI (see AH [Ken05b] or ESP [Ken05a] 981 specifications). 983 Representing directionality in an SPD entry 985 For traffic protected by IPsec, the Local and Remote address and 986 ports in an SPD entry are swapped to represent directionality, 987 consistent with IKE conventions. In general, the protocols that 988 IPsec deals with have the property of requiring symmetric SAs with 989 flipped Local/Remote IP addresses. However, for ICMP, there is 990 often no such bi-directional authorization requirement. 991 Nonetheless, for the sake of uniformity and simplicity, SPD 992 entries for ICMP are specified in the same way as for other 993 protocols. Note also that for ICMP, Mobility Header, and 994 non-initial fragments, there are no port fields in these packets. 995 ICMP has message type and code and Mobility Header has mobility 996 header type. Thus SPD entries have provisions for expressing 997 access controls appropriate for these protocols, in lieu of the 998 normal port field controls. For bypassed or discarded traffic, 999 separate inbound and outbound entries are supported, e.g., to 1000 permit unidirectional flows if required. 1002 OPAQUE and ANY 1004 For each selector in an SPD entry, in addition to the literal 1005 values that define a match, there are two special values: ANY and 1006 OPAQUE. ANY is a wildcard that matches any value in the 1007 corresponding field of the packet, or that matches packets where 1008 that field is not present or is obscured. OPAQUE indicates that 1009 the corresponding selector field is not available for examination 1010 because it may not be present in a fragment, does not exist for 1011 the given Next Layer Protocol, or because prior application of 1012 IPsec may have encrypted the value. The ANY value encompasses the 1013 OPAQUE value. Thus OPAQUE need be used only when it is necessary 1014 to distinguish between the case of any allowed value for a field, 1015 vs. the absence or unavailability (e.g., due to encryption) of the 1016 field. 1018 How To Derive the Values for an SAD entry 1020 For each selector in an SPD entry, the entry specifies how to 1021 derive the corresponding values for a new SA Database (SAD, see 1022 Section 4.4.2) entry from those in the SPD and the packet. The 1023 goal is to allow an SAD entry and an SPD cache entry to be created 1024 based on specific selector values from the packet, or from the 1025 matching SPD entry. For outbound traffic, there are SPD-S cache 1026 entries and SPD-O cache entries. For inbound traffic not 1027 protected by IPsec, there are SPD-I cache entries and there is the 1028 SAD, which represents the cache for inbound IPsec-protected 1029 traffic (See Section 4.4.2). If IPsec processing is specified for 1030 an entry, a "populate from packet" (PFP) flag may be asserted for 1031 one or more of the selectors in the SPD entry (Local IP address; 1032 Remote IP address; Next Layer Protocol; and, depending on Next 1033 Layer Protocol, Local port and Remote port, or ICMP type/code, or 1034 Mobility Header type). If asserted for a given selector X, the 1035 flag indicates that the SA to be created should take its value for 1036 X from the value in the packet. Otherwise, the SA should take its 1037 value(s) for X from the value(s) in the SPD entry. Note: In the 1038 non-PFP case, the selector values negotiated by the SA management 1039 protocol (e.g., IKE v2) may be a subset of those in the SPD entry, 1040 depending on the SPD policy of the peer. Also, whether a single 1041 flag is used for, e.g., source port, ICMP type/code, and MH type, 1042 or a separate flag is used for each, is a local matter. 1044 The following example illustrates the use of the PFP flag in the 1045 context of a security gateway or a BITS/BITW implementation. 1046 Consider an SPD entry where the allowed value for Remote address 1047 is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an 1048 outbound packet arrives with a destination address of 192.0.2.3, 1049 and there is no extant SA to carry this packet. The value used for 1050 the SA created to transmit this packet could be either of the two 1051 values shown below, depending on what the SPD entry for this 1052 selector says is the source of the selector value: 1054 PFP flag value example of new 1055 for the Remote SAD dest. address 1056 addr. selector selector value 1057 --------------- ------------ 1058 a. PFP TRUE 192.0.2.3 (one host) 1059 b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts) 1061 Note that if the SPD entry above had a value of ANY for the Remote 1062 address, then the SAD selector value would have to be ANY for case 1063 (b), but would still be as illustrated for case (a). Thus the PFP 1064 flag can be used to prohibit sharing of an SA, even among packets 1065 that match the same SPD entry. 1067 Management Interface 1069 For every IPsec implementation, there MUST be a management 1070 interface that allows a user or system administrator to manage the 1071 SPD. The interface must allow the user (or administrator) to 1072 specify the security processing to be applied to every packet that 1073 traverses the IPsec boundary. (In a native host IPsec 1074 implementation making use of a socket interface, the SPD may not 1075 need to be consulted on a per packet basis, as noted above.) The 1076 management interface for the SPD MUST allow creation of entries 1077 consistent with the selectors defined in Section 4.4.1.1, and MUST 1078 support (total) ordering of these entries, as seen via this 1079 interface. The SPD entries' selectors are analogous to the ACL or 1080 packet filters commonly found in a stateless firewall or packet 1081 filtering router and which are currently managed this way. 1083 In host systems, applications MAY be allowed to create SPD 1084 entries. (The means of signaling such requests to the IPsec 1085 implementation are outside the scope of this standard.) However, 1086 the system administrator MUST be able to specify whether or not a 1087 user or application can override (default) system policies. The 1088 form of the management interface is not specified by this document 1089 and may differ for hosts vs. security gateways, and within hosts 1090 the interface may differ for socket-based vs. BITS 1091 implementations. However, this document does specify a standard 1092 set of SPD elements that all IPsec implementations MUST support. 1094 Decorrelation 1096 The processing model described in this document assumes the 1097 ability to decorrelate overlapping SPD entries to permit caching, 1098 which enables more efficient processing of outbound traffic in 1099 security gateways and BITS/BITW implementations. Decorrelation 1100 [CoSa04] is only a means of improving performance and simplifying 1101 the processing description. This RFC does not require a compliant 1102 implementation to make use of decorrelation. For example, native 1103 host implementations typically make use of caching implicitly 1104 because they bind SAs to socket interfaces, and thus there is no 1105 requirement to be able to decorrelate SPD entries in these 1106 implementations. 1108 Note: Unless otherwise qualified, the use of "SPD" refers to the 1109 body of policy information in both ordered or decorrelated 1110 (unordered) state. Appendix B provides an algorithm that can be 1111 used to decorrelate SPD entries, but any algorithm that produces 1112 equivalent output may be used. Note that when an SPD entry is 1113 decorrelated all the resulting entries MUST be linked together, so 1114 that all members of the group derived from an individual, SPD 1115 entry (prior to decorrelation) can all be placed into caches and 1116 into the SAD at the same time. For example, suppose one starts 1117 with an entry A (from an ordered SPD) that when decorrelated, 1118 yields entries A1, A2 and A3. When a packet comes along that 1119 matches, say A2, and triggers the creation of an SA, the SA 1120 management protocol, e.g., IKE v2, negotiates A. And all 3 1121 decorrelated entries, A1, A2, and A3 are placed in the appropriate 1122 SPD-S cache and linked to the SA. The intent is that use of a 1123 decorrelated SPD ought not to create more SAs than would have 1124 resulted from use of a not-decorrelated SPD. 1126 If a decorrelated SPD is employed, there are three options for 1127 what an initiator sends to a peer via an SA management protocol 1128 (e.g., IKE). By sending the complete set of linked, decorrelated 1129 entries that were selected from the SPD, a peer is given the best 1130 possible information to enable selection of the appropriate SPD 1131 entry at its end, especially if the peer has also decorrelated its 1132 SPD. However, if a large number of decorrelated entries are 1133 linked, this may create large packets for SA negotiation, and 1134 hence fragmentation problems for the SA management protocol. 1136 Alternatively, the original entry from the (correlated) SPD may be 1137 retained and passed to the SA management protocol. Passing the 1138 correlated SPD entry keeps the use of a decorrelated SPD a local 1139 matter, not visible to peers, and avoids possible fragmentation 1140 concerns, although it provides less precise info to a responder 1141 for matching against the responder's SPD. 1143 An intermediate approach is to send a subset of the complete set 1144 of linked, decorrelated SPD entries. This approach can avoid the 1145 fragmentation problems cited above and yet provide better 1146 information than the original, correlated entry. The major 1147 shortcoming of this approach is that it may cause additional SAs 1148 to be created later, since only a subset of the linked, 1149 decorrelated entries are sent to a peer. Implementers are free to 1150 employ any of the approaches cited above. 1152 A responder uses the traffic selector proposals it receives via an 1153 SA management protocol to select an appropriate entry in its SPD. 1154 The intent of the matching is to select an SPD entry and create an 1155 SA that most closely matches the intent of the initiator, so that 1156 traffic traversing the resulting SA will be accepted at both ends. 1157 If the responder employs a decorrelated SPD, it SHOULD use the 1158 decorrelated SPD entries for matching, as this will generally 1159 result in creation of SAs that are more likely to match the intent 1160 of both peers. If the responder has a correlated SPD, then it 1161 SHOULD match the proposals against the correlated entries. For 1162 IKE v2, use of a decorrelated SPD offers the best opportunity for 1163 a responder to generate a "narrowed" response. 1165 In all cases, when a decorrelated SPD is available, the 1166 decorrelated entries are used to populate the SPD-S cache. If the 1167 SPD is not decorrelated, caching is not allowed and an ordered 1168 search of SPD MUST be performed to verify that inbound traffic 1169 arriving on an SA is consistent with the access control policy 1170 expressed in the SPD. 1172 Handling Changes to the SPD while the System is Running 1174 If a change is made to the SPD while the system is running, a 1175 check SHOULD be made of the effect of this change on extant SAs. 1176 An implementation SHOULD check the impact of an SPD change on 1177 extant SAs and SHOULD provide a user/administrator with a 1178 mechanism for configuring what actions to take, e.g., delete an 1179 affected SA, allow an affected SA to continue unchanged, etc. 1181 4.4.1.1 Selectors 1183 An SA may be fine-grained or coarse-grained, depending on the 1184 selectors used to define the set of traffic for the SA. For example, 1185 all traffic between two hosts may be carried via a single SA, and 1186 afforded a uniform set of security services. Alternatively, traffic 1187 between a pair of hosts might be spread over multiple SAs, depending 1188 on the applications being used (as defined by the Next Layer Protocol 1189 and related fields, e.g., ports), with different security services 1190 offered by different SAs. Similarly, all traffic between a pair of 1191 security gateways could be carried on a single SA, or one SA could be 1192 assigned for each communicating host pair. The following selector 1193 parameters MUST be supported by all IPsec implementations to 1194 facilitate control of SA granularity. Note that both Local and Remote 1195 addresses should either be IPv4 or IPv6, but not a mix of address 1196 types. Also, note that the Local/Remote port selectors (and ICMP 1197 message type and code, and Mobility Header type) may be labeled as 1198 OPAQUE to accommodate situations where these fields are inaccessible 1199 due to packet fragmentation. 1201 - Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges 1202 of IP addresses (unicast, broadcast (IPv4 only)). This structure 1203 allows expression of a single IP address (via a trivial range), 1204 or a list of addresses (each a trivial range), or a range of 1205 addresses (low and high values, inclusive), as well as the most 1206 generic form of a list of ranges. Address ranges are used to 1207 support more than one remote system sharing the same SA, e.g., 1208 behind a security gateway. 1210 - Local IP Address(es) (IPv4 or IPv6): this is a list of ranges of 1211 IP addresses (unicast, broadcast (IPv4 only)). This structure 1212 allows expression of a single IP address (via a trivial range), 1213 or a list of addresses (each a trivial range), or a range of 1214 addresses (low and high values, inclusive), as well as the most 1215 generic form of a list of ranges. Address ranges are used to 1216 support more than one source system sharing the same SA, e.g., 1217 behind a security gateway. Local refers to the address(es) 1218 being protected by this implementation (or policy entry). 1220 Note: The SPD does not include support for multicast address 1221 entries. To support multicast SAs, an implementation should make 1222 use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries 1223 require a different structure, i.e., one cannot use of the 1224 symmetric relationship associated with local and remote address 1225 values for unicast SAs in a multicast context. Specifically, 1226 outbound traffic directed to a multicast address on an SA would 1227 not be received on a companion, inbound SA with the multicast 1228 address as the source. 1230 - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the 1231 IPv6 "Next Header" fields. This is an individual protocol 1232 number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol 1233 is whatever comes after any IP extension headers that are 1234 present. To simplify locating the Next Layer Protocol, there 1235 SHOULD be a mechanism for configuring which IPv6 extension 1236 headers to skip. The default configuration for which protocols 1237 to skip SHOULD include the following protocols: 0 (Hop-by-hop 1238 options), 43 (Routing Header), 44 (Fragmentation Header), and 60 1239 (Destination Options). Note: The default list does NOT include 1240 51 (AH), or 50 (ESP). From a selector lookup point of view, 1241 IPsec treats AH and ESP as Next Layer Protocols. 1243 Several additional selectors depend on the Next Layer Protocol 1244 value: 1246 * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, 1247 SCTP, ...), then there are selectors for Local and Remote 1248 Ports. Each of these selectors has a list of ranges of 1249 values. Note that the Local and Remote ports may not be 1250 available in the case of receipt of a fragmented packet or if 1251 the port fields have been protected by IPsec (encrypted), 1252 thus a value of OPAQUE also MUST be supported. Note: In a 1253 non-initial fragment, port values will not be available. If a 1254 port selector specifies a value other than ANY or OPAQUE, it 1255 cannot match packets that are non-initial fragments. If the 1256 SA requires a port value other than ANY or OPAQUE, an 1257 arriving fragment without ports MUST be discarded. (See 1258 Section 7 Handling Fragments.) 1260 * If the Next Layer Protocol is a Mobility Header, then there 1261 is a selector for IPv6 Mobility Header Message Type (MH type) 1262 [Mobip]. This is an 8-bit value that identifies a particular 1263 mobility message. Note that the MH type may not be available 1264 in the case of receipt of a fragmented packet. (See Section 7 1265 Handling Fragments.) For IKE, the IPv6 mobility header 1266 message type (MH type) is placed in the most significant 1267 eight bits of the 16-bit local "port" selector. 1269 * If the Next Layer Protocol value is ICMP then there is a 1270 16-bit selector for the ICMP message type and code. The 1271 message type is a single 8-bit value, which defines the type 1272 of an ICMP message, or ANY. The ICMP code is a single 8-bit 1273 value that defines a specific subtype for an ICMP message. 1274 For IKE, the message type is placed in the most significant 8 1275 bits of the 16-bit selector and the code is placed in the 1276 least significant 8 bits. This 16-bit selector can contain a 1277 single type and a range of codes, a single type and ANY code, 1278 ANY type and ANY code. Given a policy entry with a range of 1279 Types (T-start to T-end) and a range of Codes (C-start to 1280 C-end), and an ICMP packet with Type t and Code c, an 1281 implementation MUST test for a match using 1283 (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + 1284 C-end 1286 Note that the ICMP message type and code may not be available 1287 in the case of receipt of a fragmented packet. (See Section 7 1288 Handling Fragments.) 1290 - Name: This is not a selector like the others above. It is not 1291 acquired from a packet. A name may be used as a symbolic 1292 identifier for an IPsec Local or Remote address. Named SPD 1293 entries are used in two ways: 1295 1. A named SPD entry is used by a responder (not an initiator) 1296 in support of access control when an IP address would not be 1297 appropriate for the Remote IP address selector, e.g., for 1298 "road warriors." The name used to match this field is 1299 communicated during the IKE negotiation in the ID payload. 1300 In this context, the initiator's Source IP address (inner IP 1301 header in tunnel mode) is bound to the Remote IP address in 1302 the SAD entry created by the IKE negotiation. This address 1303 overrides the Remote IP address value in the SPD, when the 1304 SPD entry is selected in this fashion. All IPsec 1305 implementations MUST support this use of names. 1307 2. A named SPD entry may be used by an initiator to identify a 1308 user for whom an IPsec SA will be created (or for whom 1309 traffic may be bypassed). The initiator's IP source address 1310 (from inner IP header in tunnel mode) is used to replace the 1311 following if and when they are created: 1313 - local address in the SPD cache entry 1314 - local address in the outbound SAD entry 1315 - remote address in the inbound SAD entry 1317 Support for this use is optional for multi-user, native host 1318 implementations and not applicable to other implementations. 1319 Note that this name is used only locally; it is not 1320 communicated by the key management protocol. Also, name 1321 forms other than those used for case 1 above (responder) are 1322 applicable in the initiator context (see below). 1324 An SPD entry can contain both a name (or a list of names) and 1325 also values for the Local or Remote IP address. 1327 For case 1, responder, the identifiers employed in named SPD 1328 entries are one of the following four types: 1330 a. a fully qualified user name string (email), e.g., 1331 mozart@foo.example.com 1332 (this corresponds to ID_RFC822_ADDR in IKE v2) 1334 b. a fully qualified DNS name, e.g., 1335 foo.example.com 1336 (this corresponds to ID_FQDN in IKE v2) 1338 c. X.500 distinguished name, e.g., [WaKiHo97], 1340 CN = Stephen T. Kent, O = BBN Technologies, 1341 SP = MA, C = US 1343 (this corresponds to ID_DER_ASN1_DN in IKE v2, after 1344 decoding) 1346 d. a byte string 1347 (this corresponds to Key_ID in IKE v2) 1349 For case 2, initiator, the identifiers employed in named SPD 1350 entries are of type byte string. They are likely to be Unix 1351 UIDs, Windows security IDs or something similar, but could also 1352 be a user name or account name. In all cases, this identifier 1353 is only of local concern and is not transmitted. 1355 The IPsec implementation context determines how selectors are used. 1356 For example, a native host implementation typically makes use of a 1357 socket interface. When a new connection is established the SPD can 1358 be consulted and an SA bound to the socket. Thus traffic sent via 1359 that socket need not result in additional lookups to the SPD (SPD-O 1360 and SPD-S) cache. In contrast, a BITS, BITW, or security gateway 1361 implementation needs to look at each packet and perform an 1362 SPD-O/SPD-S cache lookup based on the selectors. 1364 4.4.1.2 Structure of an SPD entry 1366 This section contains a prose description of an SPD entry. Also, 1367 Appendix C provides an example of an ASN.1 definition of an SPD 1368 entry. 1370 This text describes the SPD in a fashion that is intended to map 1371 directly into IKE payloads to ensure that the policy required by SPD 1372 entries can be negotiated through IKE. Unfortunately, the semantics 1373 of the version of IKE v2 published concurrently with this document 1374 [Kau05] do not align precisely with those defined for the SPD. 1375 Specifically, IKE v2 does not enable negotiation of a single SA that 1376 binds multiple pairs of local and remote addresses and ports to a 1377 single SA. Instead, when multiple local and remote addresses and 1378 ports are negotiated for an SA, IKE v2 treats these not as pairs, but 1379 as (unordered) sets of local and remote values that can be 1380 arbitrarily paired. Until IKE provides a facility that conveys the 1381 semantics that are expressed in the SPD via selector sets (as 1382 described below), users MUST NOT include multiple selector sets in a 1383 single SPD entry unless the access control intent aligns with the IKE 1384 "mix and match" semantics. An implementation MAY warn users, to alert 1385 them to this problem if users create SPD entries with multiple 1386 selector sets, the syntax of which indicates possible conflicts with 1387 current IKE semantics. 1389 The management GUI can offer the user other forms of data entry and 1390 display, e.g., the option of using address prefixes as well as 1391 ranges, and symbolic names for protocols, ports, etc. (Do not confuse 1392 the use of symbolic names in a management interface with the SPD 1393 selector "Name".) Note that Remote/Local apply only to IP addresses 1394 and ports, not to ICMP message type/code or Mobility Header type. 1395 Also, if the reserved, symbolic selector value OPAQUE or ANY is 1396 employed for a given selector type, only that value may appear in the 1397 list for that selector, and it must appear only once in the list for 1398 that selector. Note that ANY and OPAQUE are local syntax conventions 1399 -- IKE v2 negotiates these values via the ranges indicated below: 1401 ANY: start = 0 end = 1402 OPAQUE: start = end = 0 1404 An SPD is an ordered list of entries each of which contains the 1405 following fields. 1407 o Name -- a list of IDs. This quasi-selector is optional. 1408 The forms that MUST be supported are described above in 1409 Section 4.4.1.1 under "Name". 1411 o PFP flags -- one per traffic selector. A given flag, e.g., 1412 for Next Layer Protocol, applies to the relevant selector 1413 across all "selector sets" (see below) contained in an SPD 1414 entry. When creating an SA, each flag specifies for the 1415 corresponding traffic selector whether to instantiate the 1416 selector from the corresponding field in the packet that 1418 triggered the creation of the SA or from the value(s) in 1419 the corresponding SPD entry (see Section 4.4.1, "How To 1420 Derive the Values for an SAD entry"). Whether a single 1421 flag is used for, e.g., source port, ICMP type/code, and 1422 MH type, or a separate flag is used for each, is a local 1423 matter. There are PFP flags for: 1424 - Local Address 1425 - Remote Address 1426 - Next Layer Protocol 1427 - Local Port, or ICMP message type/code or Mobility 1428 Header type (depending on the next layer protocol) 1429 - Remote Port, or ICMP message type/code or Mobility 1430 Header type (depending on the next layer protocol) 1432 o One to N selector sets that correspond to the "condition" 1433 for applying a particular IPsec action. Each selector set 1434 contains: 1435 - Local Address 1436 - Remote Address 1437 - Next Layer Protocol 1438 - Local Port, or ICMP message type/code or Mobility 1439 Header type (depending on the next layer protocol) 1440 - Remote Port, or ICMP message type/code or Mobility 1441 Header type (depending on the next layer protocol) 1443 Note: The "next protocol" selector is an individual value 1444 (unlike the local and remote IP addresses) in a selector 1445 set entry. This is consistent with how IKE v2 negotiates 1446 the TS values for an SA. It also makes sense because one 1447 may need to associate different port fields with different 1448 protocols. It is possible to associate multiple protocols 1449 (and ports) with a single SA by specifying multiple 1450 selector sets for that SA. 1452 o processing info -- which action is required -- PROTECT, 1453 BYPASS, or DISCARD. There is just one action that goes with 1454 all the selector sets, not a separate action for each set. 1455 If the required processing is PROTECT, the entry contains 1456 the following information. 1457 - IPsec mode -- tunnel or transport 1458 - (if tunnel mode) local tunnel address -- For a 1459 non-mobile host, if there is just one interface, this 1460 is straightforward; and if there are multiple 1461 interfaces, this must be statically configured. For a 1462 mobile host, the specification of the local address 1463 is handled externally to IPsec. 1464 - (if tunnel mode) remote tunnel address -- There is no 1465 standard way to determine this. See 4.5.3 "Locating a 1466 Security Gateway". 1467 - extended sequence number -- Is this SA using extended 1468 sequence numbers? 1469 - stateful fragment checking -- Is this SA using 1470 stateful fragment checking (see Section 7 for more 1471 details) 1472 - Bypass DF bit (T/F) -- applicable to tunnel mode SAs 1473 - Bypass DSCP (T/F) or map to unprotected DSCP values 1474 (array) if needed to restrict bypass of DSCP values -- 1475 applicable to tunnel mode SAs 1476 - IPsec protocol -- AH or ESP 1477 - algorithms -- which ones to use for AH, which ones to 1478 use for ESP, which ones to use for combined mode, 1479 ordered by decreasing priority 1481 It is a local matter as to what information is kept with regard to 1482 handling extant SAs when the SPD is changed. 1484 4.4.1.3 More re: Fields Associated with Next Layer Protocols 1486 Additional selectors are often associated with fields in the Next 1487 Layer Protocol header. A particular Next Layer Protocol can have 1488 zero, one, or two selectors. There may be situations where there 1489 aren't both local and remote selectors for the fields that are 1490 dependent on the Next Layer Protocol. The IPv6 Mobility Header has 1491 only a Mobility Header message type. AH and ESP have no further 1492 selector fields. A system may be willing to send an ICMP message 1493 type and code that it does not want to receive. In the descriptions 1494 below, "port" is used to mean a field that is dependent on the Next 1495 Layer Protocol. 1497 A. If a Next Layer Protocol has no "port" selectors, then 1498 the Local and Remote "port" selectors are set to OPAQUE in 1499 the relevant SPD entry, e.g., 1501 Local's 1502 next layer protocol = AH 1503 "port" selector = OPAQUE 1505 Remote's 1506 next layer protocol = AH 1507 "port" selector = OPAQUE 1509 B. If a Next Layer Protocol has only one selector, e.g., 1510 Mobility Header type, then that field is placed in the 1511 Local "port" selector in the relevant SPD entry, and the 1512 Remote "port" selector is set to OPAQUE in the relevant 1513 SPD entry, e.g., 1515 Local's 1516 next layer protocol = Mobility Header 1517 "port" selector = Mobility Header message type 1519 Remote's 1520 next layer protocol = Mobility Header 1521 "port" selector = OPAQUE 1523 C. If a system is willing to send traffic with a particular 1524 "port" value but NOT receive traffic with that kind of 1525 port value, the system's traffic selectors are set as 1526 follows in the relevant SPD entry: 1528 Local's 1529 next layer protocol = ICMP 1530 "port" selector = 1532 Remote's 1533 next layer protocol = ICMP 1534 "port" selector = OPAQUE 1536 D. To indicate that a system is willing to receive traffic 1537 with a particular "port" value but NOT send that kind of 1538 traffic, the system's traffic selectors are set as follows 1539 in the relevant SPD entry: 1541 Local's 1542 next layer protocol = ICMP 1543 "port" selector = OPAQUE 1545 Remote's 1546 next layer protocol = ICMP 1547 "port" selector = 1549 For example, if a security gateway is willing to allow 1550 systems behind it to send ICMP traceroutes, but is not 1551 willing to let outside systems run ICMP traceroutes to 1552 systems behind it, then the security gateway's traffic 1553 selectors are set as follows in the relevant SPD entry: 1555 Local's 1556 next layer protocol = 1 (ICMPv4) 1557 "port" selector = 30 (traceroute) 1559 Remote's 1560 next layer protocol = 1 (ICMPv4) 1561 "port" selector = OPAQUE 1563 4.4.2 Security Association Database (SAD) 1565 In each IPsec implementation there is a nominal Security Association 1566 Database (SAD), in which each entry defines the parameters associated 1567 with one SA. Each SA has an entry in the SAD. For outbound 1568 processing, each SAD entry is pointed to by entries in the SPD-S part 1569 of the SPD cache. For inbound processing, for unicast SAs, the SPI is 1570 used either alone to look up an SA, or the SPI may be used in 1571 conjunction with the IPsec protocol type. If an IPsec implementation 1572 supports multicast, the SPI plus destination address, or SPI plus 1573 destination and source addresses are used to look up the SA. (See 1574 Section 4.1 for details on the algorithm that MUST be used for 1575 mapping inbound IPsec datagrams to SAs.) The following parameters are 1576 associated with each entry in the SAD. They should all be present 1577 except where otherwise noted, e.g., AH Authentication algorithm. This 1578 description does not purport to be a MIB, only a specification of the 1579 minimal data items required to support an SA in an IPsec 1580 implementation. 1582 For each of the selectors defined in Section 4.4.1.1, the entry for 1583 an inbound SA in the SAD MUST be initially populated with the value 1584 or values negotiated at the time the SA was created. (See Section 1585 4.4.1, paragraph on Handling Changes to the SPD while the System is 1586 Running for guidance on the effect of SPD changes on extant SAs.) For 1587 a receiver, these values are used to check that the header fields of 1588 an inbound packet (after IPsec processing) match the selector values 1589 negotiated for the SA. Thus, the SAD acts as a cache for checking the 1590 selectors of inbound traffic arriving on SAs. For the receiver, this 1591 is part of verifying that a packet arriving on an SA is consistent 1592 with the policy for the SA. (See Section 6 for rules for ICMP 1593 messages.) These fields can have the form of specific values, 1594 ranges, ANY, or OPAQUE, as described in section 4.4.1.1, "Selectors." 1595 Note also, that there are a couple of situations in which the SAD can 1596 have entries for SAs that do not have corresponding entries in the 1597 SPD. Since 2401bis does not mandate that the SAD be selectively 1598 cleared when the SPD is changed, SAD entries can remain when the SPD 1599 entries that created them are changed or deleted. Also, if a manually 1600 keyed SA is created, there could be an SAD entry for this SA that 1601 does not correspond to any SPD entry. 1603 Note: The SAD can support multicast SAs, if manually configured. An 1604 outbound multicast SA has the same structure as a unicast SA. The 1605 source address is that of the sender and the destination address is 1606 the multicast group address. An inbound, multicast SA must be 1607 configured with the source addresses of each peer authorized to 1608 transmit to the multicast SA in question. The SPI value for a 1609 multicast SA is provided by a multicast group controller, not by the 1610 receiver, as for a unicast SA. Because an SAD entry may be required 1611 to accommodate multiple, individual IP source addresses that were 1612 part of an SPD entry (for unicast SAs), the required facility for 1613 inbound, multicast SAs is a feature already present in an IPsec 1614 implementation. However, because the SPD has no provisions for 1615 accommodating multicast entries, this document does not specify an 1616 automated way to create an SAD entry for a multicast, inbound SA. 1617 Only manually configured SAD entries can be created to accommodate 1618 inbound, multicast traffic. 1620 4.4.2.1 Data Items in the SAD 1622 The following data items MUST be in the SAD: 1624 o Security Parameter Index (SPI): a 32-bit value selected by the 1625 receiving end of an SA to uniquely identify the SA. In an SAD 1626 entry for an outbound SA, the SPI is used to construct the 1627 packet's AH or ESP header. In an SAD entry for an inbound SA, the 1628 SPI is used to map traffic to the appropriate SA (see text on 1629 unicast/multicast in Section 4.1). 1631 o Sequence Number Counter: a 64-bit counter used to generate the 1632 Sequence Number field in AH or ESP headers. 64-bit sequence 1633 numbers are the default, but 32-bit sequence numbers are also 1634 supported if negotiated. 1636 o Sequence Counter Overflow: a flag indicating whether overflow of 1637 the Sequence Number Counter should generate an auditable event and 1638 prevent transmission of additional packets on the SA, or whether 1639 rollover is permitted. The audit log entry for this event SHOULD 1640 include the SPI value, current date/time, Local Address, Remote 1641 Address, and the selectors from the relevant SAD entry. 1643 o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) 1644 used to determine whether an inbound AH or ESP packet is a replay. 1646 Note: If anti-replay has been disabled by the receiver for an SA, 1647 e.g., in the case of a manually keyed SA, then the Anti-Replay 1648 Window is ignored for the SA in question. 64-bit sequence numbers 1649 are the default, but this counter size accommodates 32-bit 1650 sequence numbers as well. 1652 o AH Authentication algorithm, key, etc. This is required only if AH 1653 is supported. 1655 o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode 1656 algorithm is used, these fields will not be applicable. 1658 o ESP integrity algorithm, keys, etc. If the integrity service is 1659 not selected, these fields will not be applicable. If a combined 1660 mode algorithm is used, these fields will not be applicable. 1662 o ESP combined mode algorithms, key(s), etc. This data is used when 1663 a combined mode (encryption and integrity) algorithm is used with 1664 ESP. If a combined mode algorithm is not used, these fields are 1665 not applicable. 1667 o Lifetime of this SA: a time interval after which an SA must be 1668 replaced with a new SA (and new SPI) or terminated, plus an 1669 indication of which of these actions should occur. This may be 1670 expressed as a time or byte count, or a simultaneous use of both 1671 with the first lifetime to expire taking precedence. A compliant 1672 implementation MUST support both types of lifetimes, and MUST 1673 support a simultaneous use of both. If time is employed, and if 1674 IKE employs X.509 certificates for SA establishment, the SA 1675 lifetime must be constrained by the validity intervals of the 1676 certificates, and the NextIssueDate of the CRLs used in the IKE 1677 exchange for the SA. Both initiator and responder are responsible 1678 for constraining the SA lifetime in this fashion. Note: The 1679 details of how to handle the refreshing of keys when SAs expire is 1680 a local matter. However, one reasonable approach is: 1682 (a) If byte count is used, then the implementation SHOULD count the 1683 number of bytes to which the IPsec cryptographic algorithm is 1684 applied. For ESP, this is the encryption algorithm (including 1685 Null encryption) and for AH, this is the authentication 1686 algorithm. This includes pad bytes, etc. Note that 1687 implementations MUST be able to handle having the counters at 1688 the ends of an SA get out of synch, e.g., because of packet 1689 loss or because the implementations at each end of the SA 1690 aren't doing things the same way. 1692 (b) There SHOULD be two kinds of lifetime -- a soft lifetime that 1693 warns the implementation to initiate action such as setting up 1694 a replacement SA; and a hard lifetime when the current SA ends 1695 and is destroyed. 1697 (c) If the entire packet does not get delivered during the SAs 1698 lifetime, the packet SHOULD be discarded. 1700 o IPsec protocol mode: tunnel or transport. Indicates which mode of 1701 AH or ESP is applied to traffic on this SA. 1703 o Stateful fragment checking flag. Indicates whether or not stateful 1704 fragment checking applies to this SA. 1706 o Bypass DF bit (T/F) - applicable to tunnel mode SAs where both 1707 inner and outer headers are IPv4. 1709 o DSCP values -- the set of DSCP values allowed for packets carried 1710 over this SA. If no values are specified, no DSCP-specific 1711 filtering is applied. If one or more values are specified, these 1712 are used to select one SA among several that match the traffic 1713 selectors for an outbound packet. Note that these values are NOT 1714 checked against inbound traffic arriving on the SA. 1716 o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if 1717 needed to restrict bypass of DSCP values - applicable to tunnel 1718 mode SAs. This feature maps DSCP values from an inner header to 1719 values in an outer header, e.g., to address covert channel 1720 signaling concerns. 1722 o Path MTU: any observed path MTU and aging variables. 1724 o Tunnel header IP source and destination address - both addresses 1725 must be either IPv4 or IPv6 addresses. The version implies the 1726 type of IP header to be used. Only used when the IPsec protocol 1727 mode is tunnel. 1729 4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD 1731 For each selector, the following tables show the relationship 1732 between the value in the SPD, the PFP flag, the value in the 1733 triggering packet and the resulting value in the SAD. Note that 1734 the administrative interface for IPsec can use various syntactic 1735 options to make it easier for the administrator to enter rules. 1736 For example, although a list of ranges is what IKE v2 sends, it 1737 might be clearer and less error prone for the user to enter a 1738 single IP address or IP address prefix. 1740 Value in 1741 Triggering Resulting SAD 1742 Selector SPD Entry PFP Packet Entry 1743 -------- ---------------- --- ------------ -------------- 1744 loc addr list of ranges 0 IP addr "S" list of ranges 1745 ANY 0 IP addr "S" ANY 1746 list of ranges 1 IP addr "S" "S" 1747 ANY 1 IP addr "S" "S" 1749 rem addr list of ranges 0 IP addr "D" list of ranges 1750 ANY 0 IP addr "D" ANY 1751 list of ranges 1 IP addr "D" "D" 1752 ANY 1 IP addr "D" "D" 1754 protocol list of prot's* 0 prot. "P" list of prot's* 1755 ANY** 0 prot. "P" ANY 1756 OPAQUE**** 0 prot. "P" OPAQUE 1758 list of prot's* 0 not avail. discard packet 1759 ANY** 0 not avail. ANY 1760 OPAQUE**** 0 not avail. OPAQUE 1762 list of prot's* 1 prot. "P" "P" 1763 ANY** 1 prot. "P" "P" 1764 OPAQUE**** 1 prot. "P" *** 1766 list of prot's* 1 not avail. discard packet 1767 ANY** 1 not avail. discard packet 1768 OPAQUE**** 1 not avail. *** 1770 If the protocol is one that has two ports then there will be 1771 selectors for both Local and Remote ports. 1773 Value in 1774 Triggering Resulting SAD 1775 Selector SPD Entry PFP Packet Entry 1776 -------- ---------------- --- ------------ -------------- 1777 loc port list of ranges 0 src port "s" list of ranges 1778 ANY 0 src port "s" ANY 1779 OPAQUE 0 src port "s" OPAQUE 1781 list of ranges 0 not avail. discard packet 1782 ANY 0 not avail. ANY 1783 OPAQUE 0 not avail. OPAQUE 1785 list of ranges 1 src port "s" "s" 1786 ANY 1 src port "s" "s" 1787 OPAQUE 1 src port "s" *** 1789 list of ranges 1 not avail. discard packet 1790 ANY 1 not avail. discard packet 1791 OPAQUE 1 not avail. *** 1793 rem port list of ranges 0 dst port "d" list of ranges 1794 ANY 0 dst port "d" ANY 1795 OPAQUE 0 dst port "d" OPAQUE 1797 list of ranges 0 not avail. discard packet 1798 ANY 0 not avail. ANY 1799 OPAQUE 0 not avail. OPAQUE 1801 list of ranges 1 dst port "d" "d" 1802 ANY 1 dst port "d" "d" 1803 OPAQUE 1 dst port "d" *** 1805 list of ranges 1 not avail. discard packet 1806 ANY 1 not avail. discard packet 1807 OPAQUE 1 not avail. *** 1809 If the protocol is mobility header then there will be a selector 1810 for mh type. 1812 Value in 1813 Triggering Resulting SAD 1814 Selector SPD Entry PFP Packet Entry 1815 -------- ---------------- --- ------------ -------------- 1816 mh type list of ranges 0 mh type "T" list of ranges 1817 ANY 0 mh type "T" ANY 1818 OPAQUE 0 mh type "T" OPAQUE 1820 list of ranges 0 not avail. discard packet 1821 ANY 0 not avail. ANY 1822 OPAQUE 0 not avail. OPAQUE 1824 list of ranges 1 mh type "T" "T" 1825 ANY 1 mh type "T" "T" 1826 OPAQUE 1 mh type "T" *** 1828 list of ranges 1 not avail. discard packet 1829 ANY 1 not avail. discard packet 1830 OPAQUE 1 not avail. *** 1832 If the protocol is ICMP, then there will be a 16-bit selector for 1833 ICMP type and ICMP code. Note that the type and code are bound to 1834 each other, i.e., the codes apply to the particular type. This 1835 16-bit selector can contain a single type and a range of codes, a 1836 single type and ANY code, and ANY type and ANY code. 1838 Value in 1839 Triggering Resulting SAD 1840 Selector SPD Entry PFP Packet Entry 1841 --------- ---------------- --- ------------ -------------- 1842 ICMP type a single type & 0 type "t" & single type & 1843 and code range of codes code "c" range of codes 1844 a single type & 0 type "t" & single type & 1845 ANY code code "c" ANY code 1846 ANY type & ANY 0 type "t" & ANY type & 1847 code code "c" ANY code 1848 OPAQUE 0 type "t" & OPAQUE 1849 code "c" 1851 a single type & 0 not avail. discard packet 1852 range of codes 1853 a single type & 0 not avail. discard packet 1854 ANY code 1855 ANY type & 0 not avail. ANY type & 1856 ANY code ANY code 1857 OPAQUE 0 not avail. OPAQUE 1859 a single type & 1 type "t" & "t" and "c" 1860 range of codes code "c" 1861 a single type & 1 type "t" & "t" and "c" 1862 ANY code code "c" 1863 ANY type & 1 type "t" & "t" and "c" 1864 ANY code code "c" 1865 OPAQUE 1 type "t" & *** 1866 code "c" 1868 a single type & 1 not avail. discard packet 1869 range of codes 1870 a single type & 1 not avail. discard packet 1871 ANY code 1872 ANY type & 1 not avail. discard packet 1873 ANY code 1874 OPAQUE 1 not avail. *** 1876 If the name selector is used... 1878 Value in 1879 Triggering Resulting SAD 1880 Selector SPD Entry PFP Packet Entry 1881 --------- ---------------- --- ------------ -------------- 1882 name list of user or N/A N/A N/A 1883 system names 1885 * "List of protocols" is the information, not the way 1886 that the SPD or SAD or IKv2 have to represent this 1887 information. 1888 ** 0 (zero) is used by IKE to indicate ANY for 1889 protocol. 1890 *** Use of PFP=1 with an OPAQUE value is an error and 1891 SHOULD be prohibited by an IPsec implementation. 1892 **** The protocol field cannot be OPAQUE in IPv4. This 1893 table entry applies only to IPv6. 1895 4.4.3 Peer Authorization Database (PAD) 1897 The Peer Authorization Database (PAD) provides the link between the 1898 SPD and a security association management protocol such as IKE. It 1899 embodies several critical functions: 1901 o identifies the peers or groups of peers that are authorized 1902 to communicate with this IPsec entity 1903 o specifies the protocol and method used to authenticate each 1904 peer 1905 o provides the authentication data for each peer 1906 o constrains the types and values of IDs that can be asserted 1907 by a peer with regard to child SA creation, to ensure that the 1908 peer does not assert identities for lookup in the SPD that it 1909 is not authorized to represent, when child SAs are created 1910 o peer gateway location info, e.g., IP address(es) or DNS names, 1911 MAY be included for peers that are known to be "behind" a 1912 security gateway 1913 The PAD provides these functions for an IKE peer when the peer acts 1914 as either the initiator or the responder. 1916 To perform these functions, the PAD contains an entry for each peer 1917 or group of peers with which the IPsec entity will communicate. An 1918 entry names an individual peer (a user, end system or security 1919 gateway) or specifies a group of peers (using ID matching rules 1920 defined below). The entry specifies the authentication protocol 1921 (e.g., IKE v1, IKE v2, KINK) method used (e.g., certificates or pre- 1922 shared secrets) and the authentication data (e.g., the pre-shared 1923 secret or the trust anchor relative to which the peer's certificate 1924 will be validated). For certificate-based authentication, the entry 1925 also may provide information to assist in verifying the revocation 1926 status of the peer, e.g., a pointer to a CRL repository or the name 1927 of an OSCP server associated with the peer or with the trust anchor 1928 associated with the peer. 1930 Each entry also specifies whether the IKE ID payload will be used as 1931 a symbolic name for SPD lookup, or whether the remote IP address 1932 provided in traffic selector payloads will be used for SPD lookups 1933 when child SAs are created. 1935 Note that the PAD information MAY be used to support creation of more 1936 than one tunnel mode SA at a time between two peers, e.g., two 1937 tunnels to protect the same addresses/hosts, but with different 1938 tunnel endpoints. 1940 4.4.3.1 PAD Entry IDs and Matching Rules 1942 The PAD is an ordered database, where the order is defined by an 1943 administrator (or a user in the case of a single-user end system). 1944 Usually, the same administrator will be responsible for both the PAD 1945 and SPD, since the two databases must be coordinated. The ordering 1946 requirement for the PAD arises for the same reason as for the SPD, 1947 i.e., because use of "star name" entries allows for overlaps in the 1948 set of IKE IDs that could match a specific entry. 1950 Six types of IDs are supported for entries in the PAD, consistent 1951 with the symbolic name types and IP addresses used to identify SPD 1952 entries. The ID for each entry acts as the index for the PAD, i.e., 1953 it is the value used to select an entry. All of these ID types can be 1954 used to match IKE ID payload types. The six types are: 1955 o DNS name (specific or partial) 1956 o Distinguished Name (complete or sub-tree constrained) 1957 o RFC822 email address (complete or partially qualified) 1958 o IPv4 address (range) 1959 o IPv6 address (range) 1960 o Key ID (exact match only) 1962 The first three name types can accommodate sub-tree matching as well 1963 as exact matches. A DNS name may be fully qualified and thus match 1964 exactly one name, e.g., foo.example.com. Alternatively, the name may 1965 encompass a group of peers by being partially specified, e.g., the 1966 string ".example.com" could be used to match any DNS name ending in 1967 these two domain name components. 1969 Similarly, a Distinguished Name may specify a complete DN to match 1970 exactly one entry, e.g., CN = Stephen, O = BBN Technologies, SP = MA, 1971 C = US. Alternatively, an entry may encompass a group of peers by 1972 specifying a sub-tree, e.g., an entry of the form "C = US, SP = MA" 1973 might be used to match all DNs that contain these two attributes as 1974 the top two RDNs. 1976 For an RFC822 e-mail addresses, the same options exist. A complete 1977 address such as foo@example.com matches one entity, but a sub-tree 1978 name such as "@example.com" could be used to match all the entities 1979 with names ending in those two domain names to the right of the @. 1981 The specific syntax used by an implementation to accommodate sub-tree 1982 matching for distinguished names, domain names or RFC822 e-mail 1983 addresses is a local matter. But, at a minimum, sub-tree matching of 1984 the sort described above MUST be supported. (Substring matching 1985 within a DN, DNS name or RFC822 address MAY be supported, but is not 1986 required.) 1988 For IPv4 and IPv6 addresses, the same address range syntax used for 1989 SPD entries MUST be supported. This allows specification of an 1990 individual address (via a trivial range), an address prefix (by 1991 choosing a range that adheres to CIDR-style prefixes), or an 1992 arbitrary address range. 1994 The Key ID field is defined as an OCTET string in IKE. For this name 1995 type, only exact match syntax MUST be supported (since there is no 1996 explicit structure for this ID type. Additional matching functions 1997 MAY be supported for this ID type. 1999 4.4.3.2 IKE Peer Authentication Data 2001 Once an entry is located based on an ordered search of the PAD based 2002 on ID field matching, it is necessary to verify the asserted 2003 identity, i.e., to authenticate the asserted ID. For each PAD entry 2004 there is an indication of the type of authentication to be performed. 2005 This document requires support for two required authentication data 2006 types: 2008 - X.509 certificate 2009 - pre-shared secret 2011 For authentication based on an X.509 certificate, the PAD entry 2012 contains a trust anchor via which the end entity (EE) certificate for 2013 the peer must be verifiable, either directly or via a certificate 2014 path. See RFC 3280 for the definition of a trust anchor. An entry 2015 used with certificate-based authentication MAY include additional 2016 data to facilitate certificate revocation status, e.g., a list of 2017 appropriate OCSP responders or CRL repositories, and associated 2018 authentication data. For authentication based on a pre-shared secret, 2019 the PAD contains the pre-shared secret to be used by IKE. 2021 This document does not require that the IKE ID asserted by a peer be 2022 syntactically related to a specific field in an end entity 2023 certificate that is employed to authenticate the identity of that 2024 peer. However, it often will be appropriate to impose such a 2025 requirement, e.g., when a single entry represents a set of peers each 2026 of whom may have a distinct SPD entry. Thus implementations MUST 2027 provide a means for an administrator to require a match between an 2028 asserted IKE ID and the subject name or subject alt name in a 2029 certificate. The former is applicable to IKE IDs expressed as 2030 distinguished names; the latter is appropriate for DNS names, RFC822 2031 e-mail addresses, and IP addresses. Since KEY ID is intended for 2032 identifying a peer authenticated via a pre-shred secret, there is no 2033 requirement to match this ID type to a certificate field. 2035 See IKE v1 [HarCar98] and IKE v2 [Kau05] for details of how IKE 2036 performs peer authentication using certificates or pre-shared 2037 secrets. 2039 This document does not mandate support for any other authentication 2040 methods, although such methods MAY be employed. 2042 4.4.3.3 Child SA Authorization Data 2044 Once an IKE peer is authenticated, child SAs may be created. Each PAD 2045 entry contains data to constrain the set of IDs that can be asserted 2046 by an IKE peer, for matching against the SPD. Each PAD entry 2047 indicates whether the IKE ID is to be used as a symbolic name for SPD 2048 matching, or whether an IP address asserted in a traffic selector 2049 payload is to be used. 2051 If the entry indicates that the IKE ID is to be used, then the PAD 2052 entry ID field defines the authorized set of IDs. If the entry 2053 indicates that child SAs traffic selectors are to be used, then an 2054 additional data element is required, in the form of IPv4 and/or IPv6 2055 address ranges. (A peer may be authorized for both address types, so 2056 there MUST be provision for both a v4 and a v6 address range.) 2058 4.4.3.4 How the PAD Is Used 2060 During the initial IKE exchange, the initiator and responder each 2061 assert their identity via the IKE ID payload, and send an AUTH 2062 payload to verify the asserted identity. One or more CERT payloads 2063 may be transmitted to facilitate the verification of each asserted 2064 identity. 2066 When an IKE entity receives an IKE ID payload, it uses the asserted 2067 ID to locate an entry in the PAD, using the matching rules described 2068 above. The PAD entry specifies the authentication method to be 2069 employed for the identified peer. This ensures that the right method 2070 is used for each peer and that different methods can be used for 2071 different peers. The entry also specifies the authentication data 2072 that will be used to verify the asserted identity. This data is 2073 employed in conjunction with the specified method to authenticate the 2074 peer, before any CHILD SAs are created. 2076 Child SAs are created based on the exchange of traffic selector 2077 payloads, either at the end of the initial IKE exchange, or in 2078 subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now 2079 authenticated) IKE peer is used to constrain creation of child SAs, 2080 specifically the PAD entry specifies how the SPD is searched using a 2081 traffic selector proposal from a peer. There are two choices: either 2082 the IKE ID asserted by the peer is used to find an SPD entry via its 2083 symbolic name, or peer IP addresses asserted in traffic selector 2084 payloads are used for SPD lookups based on the remote IP address 2085 field portion of an SPD entry. It is necessary to impose these 2086 constraints on creation of child SAs, to prevent an authenticated 2087 peer from spoofing IDs associated with other, legitimate peers. 2089 Note that because the PAD is checked before searching for an SPD 2090 entry, this safeguard protects an initiator against spoofing attacks. 2091 For example, assume that IKE A receives an outbound packet destined 2092 for IP address X, a host served by a security gateway. RFC 2401 and 2093 2401bis do not specify how A determines the address of the IKE peer 2094 serving X. However, any peer contacted by A as the presumed 2095 representative for X must be registered in the PAD in order to allow 2096 the IKE exchange to be authenticated. Moreover, when the 2097 authenticated peer asserts that it represents X in its traffic 2098 selector exchange, the PAD will be consulted to determine if the peer 2099 in question is authorized to represent X. Thus the PAD provides a 2100 binding of address ranges (or name sub-spaces) to peers, to counter 2101 such attacks. 2103 4.5 SA and Key Management 2105 All IPsec implementations MUST support both manual and automated SA 2106 and cryptographic key management. The IPsec protocols, AH and ESP, 2107 are largely independent of the associated SA management techniques, 2108 although the techniques involved do affect some of the security 2109 services offered by the protocols. For example, the optional 2110 anti-replay service available for AH and ESP requires automated SA 2111 management. Moreover, the granularity of key distribution employed 2112 with IPsec determines the granularity of authentication provided. In 2113 general, data origin authentication in AH and ESP is limited by the 2114 extent to which secrets used with the integrity algorithm (or with a 2115 key management protocol that creates such secrets) are shared among 2116 multiple possible sources. 2118 The following text describes the minimum requirements for both types 2119 of SA management. 2121 4.5.1 Manual Techniques 2123 The simplest form of management is manual management, in which a 2124 person manually configures each system with keying material and SA 2125 management data relevant to secure communication with other systems. 2126 Manual techniques are practical in small, static environments but 2127 they do not scale well. For example, a company could create a 2128 Virtual Private Network (VPN) using IPsec in security gateways at 2129 several sites. If the number of sites is small, and since all the 2130 sites come under the purview of a single administrative domain, this 2131 might be a feasible context for manual management techniques. In 2132 this case, the security gateway might selectively protect traffic to 2133 and from other sites within the organization using a manually 2134 configured key, while not protecting traffic for other destinations. 2135 It also might be appropriate when only selected communications need 2136 to be secured. A similar argument might apply to use of IPsec 2137 entirely within an organization for a small number of hosts and/or 2138 gateways. Manual management techniques often employ statically 2139 configured, symmetric keys, though other options also exist. 2141 4.5.2 Automated SA and Key Management 2143 Widespread deployment and use of IPsec requires an Internet-standard, 2144 scalable, automated, SA management protocol. Such support is required 2145 to facilitate use of the anti-replay features of AH and ESP, and to 2146 accommodate on-demand creation of SAs, e.g., for user- and 2147 session-oriented keying. (Note that the notion of "rekeying" an SA 2148 actually implies creation of a new SA with a new SPI, a process that 2149 generally implies use of an automated SA/key management protocol.) 2151 The default automated key management protocol selected for use with 2152 IPsec is IKE v2 [Kau05]. This document assumes the availability of 2153 certain functions from the key management protocol which are not 2154 supported by IKE v1. Other automated SA management protocols MAY be 2155 employed. 2157 When an automated SA/key management protocol is employed, the output 2158 from this protocol is used to generate multiple keys for a single SA. 2159 This also occurs because distinct keys are used for each of the two 2160 SAs created by IKE. If both integrity and confidentiality are 2161 employed, then a minimum of four keys are required. Additionally, 2162 some cryptographic algorithms may require multiple keys, e.g., 3DES. 2164 The Key Management System may provide a separate string of bits for 2165 each key or it may generate one string of bits from which all keys 2166 are extracted. If a single string of bits is provided, care needs to 2167 be taken to ensure that the parts of the system that map the string 2168 of bits to the required keys do so in the same fashion at both ends 2169 of the SA. To ensure that the IPsec implementations at each end of 2170 the SA use the same bits for the same keys, and irrespective of which 2171 part of the system divides the string of bits into individual keys, 2172 the encryption keys MUST be taken from the first (left-most, 2173 high-order) bits and the integrity keys MUST be taken from the 2174 remaining bits. The number of bits for each key is defined in the 2175 relevant cryptographic algorithm specification RFC. In the case of 2176 multiple encryption keys or multiple integrity keys, the 2177 specification for the cryptographic algorithm must specify the order 2178 in which they are to be selected from a single string of bits 2179 provided to the cryptographic algorithm. 2181 4.5.3 Locating a Security Gateway 2183 This section discusses issues relating to how a host learns about the 2184 existence of relevant security gateways and once a host has contacted 2185 these security gateways, how it knows that these are the correct 2186 security gateways. The details of where the required information is 2187 stored is a local matter, but the Peer Authorization Database 2188 described in Section 4.4 is the most likely candidate. (Note: S* 2189 indicates a system that is running IPsec, e.g., SH1 and SG2 below.) 2191 Consider a situation in which a remote host (SH1) is using the 2192 Internet to gain access to a server or other machine (H2) and there 2193 is a security gateway (SG2), e.g., a firewall, through which H1's 2194 traffic must pass. An example of this situation would be a mobile 2195 host crossing the Internet to his home organization's firewall (SG2). 2196 This situation raises several issues: 2198 1. How does SH1 know/learn about the existence of the security 2199 gateway SG2? 2201 2. How does it authenticate SG2, and once it has authenticated SG2, 2202 how does it confirm that SG2 has been authorized to represent H2? 2204 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to 2205 contact H2? 2207 4. How does SH1 know/learn about any additional gateways that provide 2208 alternate paths to H2? 2210 To address these problems, an IPsec-supporting host or security 2211 gateway MUST have an administrative interface that allows the 2212 user/administrator to configure the address of one or more security 2213 gateways for ranges of destination addresses that require its use. 2214 This includes the ability to configure information for locating and 2215 authenticating one or more security gateways and verifying the 2216 authorization of these gateways to represent the destination host. 2217 (The authorization function is implied in the PAD.) This document 2218 does not address the issue of how to automate the 2219 discovery/verification of security gateways. 2221 4.6 SAs and Multicast 2223 The receiver-orientation of the SA implies that, in the case of 2224 unicast traffic, the destination system will select the SPI value. 2225 By having the destination select the SPI value, there is no potential 2226 for manually configured SAs to conflict with automatically configured 2227 (e.g., via a key management protocol) SAs or for SAs from multiple 2228 sources to conflict with each other. For multicast traffic, there 2229 are multiple destination systems associated with a single SA. So 2230 some system or person will need to coordinate among all multicast 2231 groups to select an SPI or SPIs on behalf of each multicast group and 2232 then communicate the group's IPsec information to all of the 2233 legitimate members of that multicast group via mechanisms not defined 2234 here. 2236 Multiple senders to a multicast group SHOULD use a single Security 2237 Association (and hence SPI) for all traffic to that group when a 2238 symmetric key encryption or integrity algorithm is employed. In such 2239 circumstances, the receiver knows only that the message came from a 2240 system possessing the key for that multicast group. In such 2241 circumstances, a receiver generally will not be able to authenticate 2242 which system sent the multicast traffic. Specifications for other, 2243 more general multicast approaches are deferred to the IETF Multicast 2244 Security Working Group. 2246 5. IP Traffic Processing 2248 As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", 2249 the SPD (or associated caches) MUST be consulted during the 2250 processing of all traffic that crosses the IPsec protection boundary, 2251 including IPsec management traffic. If no policy is found in the SPD 2252 that matches a packet (for either inbound or outbound traffic), the 2253 packet MUST be discarded. To simplify processing, and to allow for 2254 very fast SA lookups (for SG/BITS/BITW), this document introduces the 2255 notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), 2256 and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As 2257 mentioned earlier, the SAD acts as a cache for checking the selectors 2258 of inbound IPsec-protected traffic arriving on SAs.) There is 2259 nominally one cache per SPD. For the purposes of this specification, 2260 it is assumed that each cached entry will map to exactly one SA. 2261 Note, however, exceptions arise when one uses multiple SAs to carry 2262 traffic of different priorities (e.g., as indicated by distinct DSCP 2263 values) but the same selectors. Note also, that there are a couple 2264 of situations in which the SAD can have entries for SAs that do not 2265 have corresponding entries in the SPD. Since 2401bis does not mandate 2266 that the SAD be selectively cleared when the SPD is changed, SAD 2267 entries can remain when the SPD entries that created them are changed 2268 or deleted. Also, if a manually keyed SA is created, there could be 2269 an SAD entry for this SA that does not correspond to any SPD entry. 2271 Since SPD entries may overlap, one cannot safely cache these entries 2272 in general. Simple caching might result in a match against a cache 2273 entry whereas an ordered search of the SPD would have resulted in a 2274 match against a different entry. But, if the SPD entries are first 2275 decorrelated, then the resulting entries can safely be cached. Each 2276 cached entry will indicate that matching traffic should be bypassed 2277 or discarded, appropriately. (Note: The original SPD entry might 2278 result in multiple SAs, e.g., because of PFP.) Unless otherwise 2279 noted, all references below to the "SPD" or "SPD cache" or "cache" 2280 are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache 2281 containing entries from the decorrelated SPD. 2283 Note: In a host IPsec implementation based on sockets, the SPD will 2284 be consulted whenever a new socket is created, to determine what, if 2285 any, IPsec processing will be applied to the traffic that will flow 2286 on that socket. This provides an implicit caching mechanism and the 2287 portions of the preceding discussion that address caching can be 2288 ignored in such implementations. 2290 Note: It is assumed that one starts with a correlated SPD because 2291 that is how users and administrators are accustomed to managing these 2292 sorts of access control lists or firewall filter rules. Then the 2293 decorrelation algorithm is applied to build a list of cache-able SPD 2294 entries. The decorrelation is invisible at the management interface. 2296 For inbound IPsec traffic, the SAD entry selected by the SPI serves 2297 as the cache for the selectors to be matched against arriving IPsec 2298 packets, after AH or ESP processing has been performed. 2300 5.1 Outbound IP Traffic Processing (protected-to-unprotected) 2302 First consider the path for traffic entering the implementation via a 2303 protected interface and exiting via an unprotected interface. 2305 Unprotected Interface 2306 ^ 2307 | 2308 (nested SAs) +----------+ 2309 -------------------|Forwarding|<-----+ 2310 | +----------+ | 2311 | ^ | 2312 | | BYPASS | 2313 V +-----+ | 2314 +-------+ | SPD | +--------+ 2315 ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec 2316 | (*) | | (*) |---->|(AH/ESP)| boundary 2317 +-------+ +-----+ +--------+ 2318 | +-------+ / ^ 2319 | |DISCARD| <--/ | 2320 | +-------+ | 2321 | | 2322 | +-------------+ 2323 |---------------->|SPD Selection| 2324 +-------------+ 2325 ^ 2326 | +------+ 2327 | -->| ICMP | 2328 | / +------+ 2329 |/ 2330 | 2331 | 2332 Protected Interface 2334 Figure 2. Processing Model for Outbound Traffic 2335 (*) = The SPD caches are shown here. If there 2336 is a cache miss, then the SPD is checked. 2337 There is no requirement that an 2338 implementation buffer the packet if 2339 there is a cache miss. 2341 IPsec MUST perform the following steps when processing outbound 2342 packets: 2344 1. When a packet arrives from the subscriber (protected) interface, 2345 invoke the SPD selection function to obtain the SPD-ID needed to 2346 choose the appropriate SPD. (If the implementation uses only one 2347 SPD, this step is a no-op.) 2349 2. Match the packet headers against the cache for the SPD specified 2350 by the SPD-ID from step 1. Note that this cache contains entries 2351 from SPD-O and SPD-S. 2353 3a. If there is a match, then process the packet as specified by the 2354 matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH 2355 or ESP. If IPsec processing is applied, there is a link from the 2356 SPD cache entry to the relevant SAD entry (specifying the mode, 2357 cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec 2358 processing is as previously defined, for tunnel or transport modes 2359 and for AH or ESP, as specified in their respective RFCs [Ken05b 2360 and Ken05a]. Note that the SA PMTU value, plus the value of the 2361 stateful fragment checking flag (and the DF bit in the IP header 2362 of the outbound packet) determine whether the packet can (must) be 2363 fragmented prior to or after IPsec processing, or if it must be 2364 discarded and an ICMP PMTU message is sent. 2366 3b. If no match is found in the cache, search the SPD (SPD-S and 2367 SPD-O parts) specified by SPD-ID. If the SPD entry calls for 2368 BYPASS or DISCARD, create one or more new outbound SPD cache 2369 entries and if BYPASS, create one or more new inbound SPD cache 2370 entries. (More than one cache entry may be created since a 2371 decorrelated SPD entry may be linked to other such entries that 2372 were created as a side effect of the decorrelation process.) If 2373 the SPD entry calls for PROTECT, i.e., creation of an SA, the key 2374 management mechanism (e.g., IKE v2) is invoked to create the SA. 2375 If SA creation succeeds, a new outbound (SPD-S) cache entry is 2376 created, along with outbound and inbound SAD entries, otherwise 2377 the packet is discarded. (A packet that triggers an SPD lookup MAY 2378 be discarded by the implementation, or it MAY be processed against 2379 the newly created cache entry, if one is created.) Since SAs are 2380 created in pairs, an SAD entry for the corresponding inbound SA 2381 also is created, and it contains the selector values derived from 2382 the SPD entry (and packet, if any PFP flags were "true") used to 2383 create the inbound SA, for use in checking inbound traffic 2384 delivered via the SA. 2386 4. The packet is passed to the outbound forwarding function 2387 (operating outside of the IPsec implementation), to select the 2388 interface to which the packet will be directed. This function may 2389 cause the packet to be passed back across the IPsec boundary, for 2390 additional IPsec processing, e.g., in support of nested SAs. If 2391 so, there MUST be an entry in SPD-I database that permits inbound 2392 bypassing of the packet, otherwise the packet will be discarded. 2393 If necessary, i.e., if there is more than one SPD-I, the traffic 2394 being looped back MAY be tagged as coming from this internal 2395 interface. This would allow the use of a different SPD-I for 2396 "real" external traffic vs looped traffic, if needed. 2398 Note: With the exception of IPv4 and IPv6 transport mode, an SG, 2399 BITS, or BITW implementation MAY fragment packets before applying 2400 IPsec. (This applies only to IPv4. For IPv6 packets, only the 2401 originator is allowed to fragment them.) The device SHOULD have a 2402 configuration setting to disable this. The resulting fragments are 2403 evaluated against the SPD in the normal manner. Thus, fragments not 2404 containing port numbers (or ICMP message type and code, or Mobility 2405 Header type) will only match rules having port (or ICMP message type 2406 and code, or MH type) selectors of OPAQUE or ANY. (See section 7 for 2407 more details.) 2409 Note: With regard to determining and enforcing the PMTU of an SA, the 2410 IPsec system MUST follow the steps described in Section 8.2. 2412 5.1.1 Handling an Outbound Packet That Must Be Discarded 2414 If an IPsec system receives an outbound packet that it finds it must 2415 discard, it SHOULD be capable of generating and sending an ICMP 2416 message to indicate to the sender of the outbound packet that the 2417 packet was discarded. The type and code of the ICMP message will 2418 depend on the reason for discarding the packet, as specified below. 2419 The reason SHOULD be recorded in the audit log. The audit log entry 2420 for this event SHOULD include the reason, current date/time, and the 2421 selector values from the packet. 2423 a. The selectors of the packet matched an SPD entry requiring the 2424 packet to be discarded. 2426 IPv4 Type = 3 (destination unreachable) Code = 13 2427 (Communication Administratively Prohibited) 2429 IPv6 Type = 1 (destination unreachable) Code = 1 2430 (Communication with destination administratively 2431 prohibited) 2433 b1. The IPsec system successfully reached the remote peer but was 2434 unable to negotiate the SA required by the SPD entry matching the 2435 packet, e.g., because the remote peer is administratively 2436 prohibited from communicating with the initiator, or the 2437 initiating peer was unable to authenticate itself to the remote 2438 peer, or the remote peer was unable to authenticate itself to the 2439 initiating peer, or SPD at remote peer did not have a suitable 2440 entry, etc. 2442 IPv4 Type = 3 (destination unreachable) Code = 13 2443 (Communication Administratively Prohibited) 2445 IPv6 Type = 1 (destination unreachable) Code = 1 2446 (Communication with destination administratively 2447 prohibited) 2449 b2. The IPsec system was unable to set up the SA required by the SPD 2450 entry matching the packet because the IPsec peer at the other end 2451 of the exchange could not be contacted. 2453 IPv4 Type = 3 (destination unreachable) Code = 1 (host 2454 unreachable) 2456 IPv6 Type = 1 (destination unreachable) Code = 3 (address 2457 unreachable) 2459 Note that an attacker behind a security gateway could send packets 2460 with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it 2461 to send ICMP messages to W.X.Y.Z. This creates an opportunity for a 2462 DoS attack among hosts behind a security gateway. To address this, a 2463 security gateway SHOULD include a management control to allow an 2464 administrator to configure an IPsec implementation to send or not 2465 send the ICMP messages under these circumstances, and if this 2466 facility is selected, to rate limit the transmission of such ICMP 2467 responses. 2469 5.1.2 Header Construction for Tunnel Mode 2471 This section describes the handling of the inner and outer IP 2472 headers, extension headers, and options for AH and ESP tunnels, with 2473 regard to outbound traffic processing. This includes how to 2474 construct the encapsulating (outer) IP header, how to process fields 2475 in the inner IP header, and what other actions should be taken for 2476 outbound, tunnel mode traffic. The general processing described here 2477 is modeled after RFC 2003, "IP Encapsulation with IP" [Per96]: 2479 o The outer IP header Source Address and Destination Address 2480 identify the "endpoints" of the tunnel (the encapsulator and 2481 decapsulator). The inner IP header Source Address and Destination 2482 Addresses identify the original sender and recipient of the 2483 datagram, (from the perspective of this tunnel), respectively. 2484 (See footnote 3 after the table in 5.1.2.1 for more details on the 2485 encapsulating source IP address.) 2487 o The inner IP header is not changed except as noted below for TTL 2488 (or Hop Limit) and the DS/ECN Fields. The inner IP header 2489 otherwise remains unchanged during its delivery to the tunnel exit 2490 point. 2492 o No change to IP options or extension headers in the inner header 2493 occurs during delivery of the encapsulated datagram through the 2494 tunnel. 2496 Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC 2497 2003) in several ways: 2499 o IPsec offers certain controls to a security administrator to 2500 manage covert channels (which would not normally be a concern for 2501 tunneling) and to ensure that the receiver examines the right 2502 portions of the received packet re: application of access 2503 controls. An IPsec implementation MAY be configurable with regard 2504 to how it processes the outer DS field for tunnel mode for 2505 transmitted packets. For outbound traffic, one configuration 2506 setting for the outer DS field will operate as described in the 2507 following sections on IPv4 and IPv6 header processing for IPsec 2508 tunnels. Another will allow the outer DS field to be mapped to a 2509 fixed value, which MAY be configured on a per SA basis. (The value 2510 might really be fixed for all traffic outbound from a device, but 2511 per SA granularity allows that as well.) This configuration option 2512 allows a local administrator to decide whether the covert channel 2513 provided by copying these bits outweighs the benefits of copying. 2515 o IPsec describes how to handle ECN or DS and provides the ability 2516 to control propagation of changes in these fields between 2517 unprotected and protected domains. In general, propagation from a 2518 protected to an unprotected domain is a covert channel and thus 2519 controls are provided to manage the bandwidth of this channel. 2520 Propagation of ECN values in the other direction are controlled so 2521 that only legitimate ECN changes (indicating occurrence of 2522 congestion between the tunnel endpoints) are propagated. By 2523 default, DS propagation from an unprotected domain to a protected 2524 domain is not permitted. However, if the sender and receiver do 2525 not share the same DS code space, and the receiver has no way of 2526 learning how to map between the two spaces, then it may be 2527 appropriate to deviate from the default. Specifically, an IPsec 2528 implementation MAY be configurable in terms of how it processes 2529 the outer DS field for tunnel mode for received packets. It may be 2530 configured to either discard the outer DS value (the default) OR 2531 to overwrite the inner DS field with the outer DS field. If 2532 offered, the discard vs. overwrite behavior MAY be configured on a 2533 per SA basis. This configuration option allows a local 2534 administrator to decide whether the vulnerabilities created by 2535 copying these bits outweigh the benefits of copying. See [RFC 2536 2983] for further information on when each of these behaviors may 2537 be useful, and also for the possible need for diffserv traffic 2538 conditioning prior or subsequent to IPsec processing (including 2539 tunnel decapsulation). 2541 o IPsec allows the IP version of the encapsulating header to be 2542 different from that of the inner header. 2544 The tables in the following sub-sections show the handling for the 2545 different header/option fields ("constructed" means that the value in 2546 the outer field is constructed independently of the value in the 2547 inner). 2549 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode 2551 <-- How Outer Hdr Relates to Inner Hdr --> 2552 Outer Hdr at Inner Hdr at 2553 IPv4 Encapsulator Decapsulator 2554 Header fields: -------------------- ------------ 2555 version 4 (1) no change 2556 header length constructed no change 2557 DS Field copied from inner hdr (5) no change 2558 ECN Field copied from inner hdr constructed (6) 2559 total length constructed no change 2560 ID constructed no change 2561 flags (DF,MF) constructed, DF (4) no change 2562 fragment offset constructed no change 2563 TTL constructed (2) decrement (2) 2564 protocol AH, ESP no change 2565 checksum constructed constructed (2)(6) 2566 src address constructed (3) no change 2567 dest address constructed (3) no change 2568 Options never copied no change 2569 1. The IP version in the encapsulating header can be 2570 different from the value in the inner header. 2572 2. The TTL in the inner header is decremented by the 2573 encapsulator prior to forwarding and by the decapsulator 2574 if it forwards the packet. (The IPv4 checksum changes 2575 when the TTL changes.) 2577 Note: Decrementing the TTL value is a normal part of 2578 forwarding a packet. Thus, a packet originating from 2579 the same node as the encapsulator does not have its TTL 2580 decremented, since the sending node is originating the 2581 packet rather than forwarding it. 2583 3. Local and Remote addresses depend on the SA, which is 2584 used to determine the Remote address which in turn 2585 determines which Local address (net interface) is used 2586 to forward the packet. 2588 Note: For multicast traffic, the destination address, or 2589 source and destination addresses, may be required for 2590 demuxing. In that case, it is important to ensure 2591 consistency over the lifetime of the SA by ensuring that 2592 the source address that appears in the encapsulating 2593 tunnel header is the same as the one that was negotiated 2594 during the SA establishment process. There is an 2595 exception to this general rule, i.e., a mobile IPsec 2596 implementation will update its source address as it 2597 moves. 2599 4. Configuration determines whether to copy from the inner 2600 header (IPv4 only), clear, or set the DF. 2602 5. If the packet will immediately enter a domain for which 2603 the DSCP value in the outer header is not appropriate, 2604 that value MUST be mapped to an appropriate value for 2605 the domain [RFC 2474]. See RFC 2475[BBCDWW98] for 2606 further information. 2608 6. If the ECN field in the inner header is set to ECT(0) or 2609 ECT(1) and the ECN field in the outer header is set to 2610 CE, then set the ECN field in the inner header to CE, 2611 otherwise make no change to the ECN field in the inner 2612 header. (The IPv4 checksum changes when the ECN 2613 changes.) 2615 Note: IPsec does not copy the options from the inner header into the 2616 outer header, nor does IPsec construct the options in the outer 2617 header. However, post-IPsec code MAY insert/construct options for the 2618 outer header. 2620 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode 2622 See previous section 5.1.2.1 for notes 1-6 indicated by (footnote 2623 number). 2625 <-- How Outer Hdr Relates Inner Hdr ---> 2626 Outer Hdr at Inner Hdr at 2627 IPv6 Encapsulator Decapsulator 2628 Header fields: -------------------- ------------ 2629 version 6 (1) no change 2630 DS Field copied from inner hdr (5) no change (9) 2631 ECN Field copied from inner hdr constructed (6) 2632 flow label copied or configured (8) no change 2633 payload length constructed no change 2634 next header AH,ESP,routing hdr no change 2635 hop limit constructed (2) decrement (2) 2636 src address constructed (3) no change 2637 dest address constructed (3) no change 2638 Extension headers never copied (7) no change 2640 7. IPsec does not copy the extension headers from the inner 2641 packet into outer headers, nor does IPsec construct 2642 extension headers in the outer header. However, 2643 post-IPsec code MAY insert/construct extension headers 2644 for the outer header. 2646 8. See [RaCoCaDe04]. Copying is acceptable only for end 2647 systems, not SGs. If an SG copied flow labels from the 2648 inner header to the outer header, collisions might 2649 result. 2651 9. An implementation MAY choose to provide a facility to 2652 pass the DS value from the outer header to the inner 2653 header, on a per SA basis, for received tunnel mode 2654 packets. The motivation for providing this feature is to 2655 accommodate situations in which the DS code space at the 2656 receiver is different from that of the sender and the 2657 receiver has no way of knowing how to translate from the 2658 sender's space. There is a danger in copying this value 2659 from the outer header to the inner header, since it 2660 enables an attacker to modify the outer DSCP value in a 2661 fashion that may adversely affect other traffic at the 2662 receiver. Hence the default behavior for IPsec 2663 implementations is NOT to permit such copying. 2665 5.2 Processing Inbound IP Traffic (unprotected-to-protected) 2667 Inbound processing is somewhat different from outbound processing, 2668 because of the use of SPIs to map IPsec protected traffic to SAs. The 2669 inbound SPD cache (SPD-I) is applied only to bypassed or discarded 2670 traffic. If an arriving packet appears to be an IPsec fragment from 2671 an unprotected interface, reassembly is performed prior to IPsec 2672 processing. The intent for any SPD cache is that a packet that fails 2673 to match any entry is then referred to the corresponding SPD. Every 2674 SPD SHOULD have a nominal, final entry that catches anything that is 2675 otherwise unmatched, and discards it. This ensures that non-IPsec 2676 protected traffic that arrives and does not match any SPD-I entry 2677 will be discarded. 2679 Unprotected Interface 2680 | 2681 V 2682 +-----+ IPsec protected 2683 ------------------->|Demux|-------------------+ 2684 | +-----+ | 2685 | | | 2686 | Not IPsec | | 2687 | | | 2688 | V | 2689 | +-------+ +---------+ | 2690 | |DISCARD|<---|SPD-I (*)| | 2691 | +-------+ +---------+ | 2692 | | | 2693 | |-----+ | 2694 | | | | 2695 | | V | 2696 | | +------+ | 2697 | | | ICMP | | 2698 | | +------+ | 2699 | | V 2700 +---------+ | +---------+ 2701 ....|SPD-O (*)|............|...................|PROCESS**|...IPsec 2702 +---------+ | |(AH/ESP) | Boundary 2703 ^ | +---------+ 2704 | | +---+ | 2705 | BYPASS | +-->|IKE| | 2706 | | | +---+ | 2707 | V | V 2708 | +----------+ +---------+ +----+ 2709 |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| 2710 nested SAs +----------+ | (***) | +----+ 2711 | +---------+ 2712 V 2713 Protected Interface 2715 Figure 3. Inbound Traffic Processing Model 2716 (*) = The caches are shown here. If there is 2717 a cache miss, then the SPD is checked. 2718 There is no requirement that an 2719 implementation buffer the packet if 2720 there is a cache miss. 2721 (**) = This processing includes using the 2722 packet's SPI, etc to look up the SA 2723 in the SAD, which forms a cache of the 2724 SPD for inbound packets (except for 2725 cases noted in Sections 4.4.2 and 5) - 2726 see step 3a below. 2728 (***) = This SAD check refers to step 4 below. 2730 Prior to performing AH or ESP processing, any IP fragments that 2731 arrive via the unprotected interface are reassembled (by IP). Each 2732 inbound IP datagram to which IPsec processing will be applied is 2733 identified by the appearance of the AH or ESP values in the IP Next 2734 Protocol field (or of AH or ESP as a next layer protocol in the IPv6 2735 context). 2737 IPsec MUST perform the following steps: 2739 1. When a packet arrives, it may be tagged with the ID of the 2740 interface (physical or virtual) via which it arrived, if necessary 2741 to support multiple SPDs and associated SPD-I caches. (The 2742 interface ID is mapped to a corresponding SPD-ID.) 2744 2. The packet is examined and demuxed into one of two categories: 2745 - If the packet appears to be IPsec protected and it is addressed 2746 to this device, an attempt is made to map it to an active SA 2747 via the SAD. Note that the device may have multiple IP 2748 addresses that may be used in the SAD lookup, e.g., in the case 2749 of protocols such as SCTP. 2750 - Traffic not addressed to this device, or addressed to this 2751 device and not AH or ESP, is directed to SPD-I lookup. (This 2752 implies that IKE traffic MUST have an explicit BYPASS entry in 2753 the SPD.) If multiple SPDs are employed, the tag assigned to 2754 the packet in step 1 is used to select the appropriate SPD-I 2755 (and cache) to search. SPD-I lookup determines whether the 2756 action is DISCARD or BYPASS. 2758 3a. If the packet is addressed to the IPsec device and AH or ESP is 2759 specified as the protocol, the packet is looked up in the SAD. For 2760 unicast traffic, use only the SPI (or SPI plus protocol). For 2761 multicast traffic, use the SPI plus the destination or SPI plus 2762 destination and source addresses, as specified in section 4.1. In 2763 either case (unicast or multicast), if there is no match, discard 2764 the traffic. This is an auditable event. The audit log entry for 2765 this event SHOULD include the current date/time, SPI, source and 2766 destination of the packet, IPsec protocol, and any other selector 2767 values of the packet that are available. If the packet is found 2768 in the SAD, process it accordingly (see step 4). 2770 3b. If the packet is not addressed to the device or is addressed to 2771 this device and is not AH or ESP, look up the packet header in the 2772 (appropriate) SPD-I cache. If there is a match and the packet is 2773 to be discarded or bypassed, do so. If there is no cache match, 2774 look up the packet in the corresponding SPD-I and create a cache 2775 entry as appropriate. (No SAs are created in response to receipt 2776 of a packet that requires IPsec protection; only BYPASS or DISCARD 2777 cache entries can be created this way.) If there is no match, 2778 discard the traffic. This is an auditable event. The audit log 2779 entry for this event SHOULD include the current date/time, SPI if 2780 available, IPsec protocol if available, source and destination of 2781 the packet, and any other selector values of the packet that are 2782 available. 2784 3c. Processing of ICMP messages is assumed to take place on the 2785 unprotected side of the IPsec boundary. Unprotected ICMP messages 2786 are examined and local policy is applied to determine whether to 2787 accept or reject these messages and, if accepted, what action to 2788 take as a result. For example, if an ICMP unreachable message is 2789 received, the implementation must decide whether to act on it, 2790 reject it, or act on it with constraints. (See Section 6.) 2792 4. Apply AH or ESP processing as specified, using the SAD entry 2793 selected in step 3a above. Then match the packet against the 2794 inbound selectors identified by the SAD entry to verify that the 2795 received packet is appropriate for the SA via which it was 2796 received. 2798 5. If an IPsec system receives an inbound packet on an SA and the 2799 packet's header fields are not consistent with the selectors for 2800 the SA, it MUST discard the packet. This is an auditable event. 2801 The audit log entry for this event SHOULD include the current 2802 date/time, SPI, IPsec protocol(s), source and destination of the 2803 packet, and any other selector values of the packet that are 2804 available, and the selector values from the relevant SAD entry. 2805 The system SHOULD also be capable of generating and sending an IKE 2806 notification of INVALID_SELECTORS to the sender (IPsec peer), 2807 indicating that the received packet was discarded because of 2808 failure to pass selector checks. 2810 To minimize the impact of a DoS attack, or a mis-configured peer, the 2811 IPsec system SHOULD include a management control to allow an 2812 administrator to configure the IPsec implementation to send or not 2813 send this IKE notification, and if this facility is selected, to rate 2814 limit the transmission of such notifications. 2816 After traffic is bypassed or processed through IPsec, it is handed to 2817 the inbound forwarding function for disposition. This function may 2818 cause the packet to be sent (outbound) across the IPsec boundary for 2819 additional inbound IPsec processing, e.g., in support of nested SAs. 2820 If so, then as with ALL outbound traffic that is to be bypassed, the 2821 packet MUST be matched against an SPD-O entry. Ultimately, the packet 2822 should be forwarded to the destination host or process for 2823 disposition. 2825 6. ICMP Processing 2827 This section describes IPsec handling of ICMP traffic. There are two 2828 categories of ICMP traffic: error messages (e.g., type = destination 2829 unreachable) and non-error messages (e.g., type = echo). This section 2830 applies exclusively to error messages. Disposition of non-error, 2831 ICMP messages (that are not addressed to the IPsec implementation 2832 itself) MUST be explicitly accounted for using SPD entries. 2834 The discussion in this section applies to ICMPv6 as well as to 2835 ICMPv4. Also, a mechanism SHOULD be provided to allow an 2836 administrator to cause ICMP error messages (selected, all, or none) 2837 to be logged as an aid to problem diagnosis. 2839 6.1 Processing ICMP Error Messages Directed to an IPsec Implementation 2841 6.1.1 ICMP Error Messages Received on the Unprotected Side of the 2842 Boundary 2844 Figure 3 in Section 5.2 shows a distinct ICMP processing module on 2845 the unprotected side of the IPsec boundary, for processing ICMP 2846 messages (error or otherwise) that are addressed to the IPsec device 2847 and that are not protected via AH or ESP. An ICMP message of this 2848 sort is unauthenticated and its processing may result in denial or 2849 degradation of service. This suggests that, in general, it would be 2850 desirable to ignore such messages. However, many ICMP messages will 2851 be received by hosts or security gateways from unauthenticated 2852 sources, e.g., routers in the public Internet. Ignoring these ICMP 2853 messages can degrade service, e.g., because of a failure to process 2854 PMTU message and redirection messages. Thus there is also a 2855 motivation for accepting and acting upon unauthenticated ICMP 2856 messages. 2858 To accommodate both ends of this spectrum, a compliant IPsec 2859 implementation MUST permit a local administrator to configure an 2860 IPsec implementation to accept or reject unauthenticated ICMP 2861 traffic. This control MUST be at the granularity of ICMP type and 2862 MAY be at the granularity of ICMP type and code. Additionally, an 2863 implementation SHOULD incorporate mechanisms and parameters for 2864 dealing with such traffic. For example, there could be the ability to 2865 establish a minimum PMTU for traffic (on a per destination basis), to 2866 prevent receipt of an unauthenticated ICMP from setting the PMTU to a 2867 trivial size. 2869 If an ICMP PMTU message passes the checks above and the system is 2870 configured to accept it, then there are two possibilities. If the 2871 implementation applies fragmentation on the ciphertext side of the 2872 boundary, then the accepted PMTU information is passed to the 2873 forwarding module (outside of the IPsec implementation) which uses it 2874 to manage outbound packet fragmentation. If the implementation is 2875 configured to effect plaintext side fragmentation, then the PMTU 2876 information is passed to the plaintext side and processed as 2877 described in Section 8.2. 2879 6.1.2 ICMP Error Messages Received on the Protected Side of the Boundary 2881 These ICMP messages are not authenticated, but they do come from 2882 sources on the protected side of the IPsec boundary. Thus these 2883 messages generally are viewed as more "trustworthy" than their 2884 counterparts arriving from sources on the unprotected side of the 2885 boundary. The major security concern here is that a compromised host 2886 or router might emit erroneous ICMP error messages that could degrade 2887 service for other devices "behind" the security gateway, or that 2888 could even result in violations of confidentiality. For example, if a 2889 bogus ICMP redirect were consumed by a security gateway, it could 2890 cause the forwarding table on the protected side of the boundary to 2891 be modified so as to deliver traffic to an inappropriate destination 2892 "behind" the gateway. Thus implementers MUST provide controls to 2893 allow local administrators to constrain the processing of ICMP error 2894 messages received on the protected side of the boundary, and directed 2895 to the IPsec implementation. These controls are of the same type as 2896 those employed on the unprotected side, described above in Section 2897 6.1.1. 2899 6.2 Processing Protected, Transit ICMP Error Messages 2901 When an ICMP error message is transmitted via an SA to a device 2902 "behind" an IPsec implementation, both the payload and the header of 2903 the ICMP message require checking from an access control perspective. 2904 If one of these messages is forwarded to a host behind a security 2905 gateway, the receiving host IP implementation will make decisions 2906 based on the payload, i.e., the header of the packet that purportedly 2907 triggered the error response. Thus an IPsec implementation MUST be 2908 configurable to check that this payload header information is 2909 consistent with the SA via which it arrives. (This means that the 2910 payload header, with source and destination address and port fields 2911 reversed, matches the traffic selectors for the SA.) If this sort of 2912 check is not performed, then for example, anyone with whom the 2913 receiving IPsec system (A) has an active SA could send an ICMP 2914 destination dead message that refers to any host/net with which A is 2915 currently communicating, and thus effect a highly efficient DoS 2916 attack re: communication with other peers of A. Normal IPsec 2917 receiver processing of traffic is not sufficient to protect against 2918 such attacks. However, not all contexts may require such checks, so 2919 it is also necessary to allow a local administrator to configure an 2920 implementation to NOT perform such checks. 2922 To accommodate both policies, the following convention is adopted. If 2923 an administrator wants to allow ICMP error messages to be carried by 2924 an SA without inspection of the payload, then configure an SPD entry 2925 that explicitly allows for carriage of such traffic. If an 2926 administrator wants IPsec to check the payload of ICMP error messages 2927 for consistency, then do not create any SPD entries that accommodate 2928 carriage of such traffic based on the ICMP packet header. This 2929 convention motivates the following processing description. 2931 IPsec senders and receivers MUST support the following processing for 2932 ICMP error messages that are sent and received via SAs. 2934 If an SA exists that accommodates an outbound ICMP error message, 2935 then the message is mapped to the SA and only the IP and ICMP headers 2936 are checked upon receipt, just as would be the case for other 2937 traffic. If no SA exists that matches the traffic selectors 2938 associated with an ICMP error message, then the SPD is searched to 2939 determine if such an SA can be created. If so, the SA is created and 2940 the ICMP error message is transmitted via that SA. Upon receipt, this 2941 message is subject to the usual traffic selector checks at the 2942 receiver. This processing is exactly what would happen for traffic in 2943 general, and thus does not represent any special processing for ICMP 2944 error messages. 2946 If no SA exists that would carry the outbound ICMP message in 2947 question, and if no SPD entry would allow carriage of this outbound 2948 ICMP error message, then an IPsec implementation MUST map the message 2949 to the SA that would carry the return traffic associated with the 2950 packet that triggered the ICMP error message. This requires an IPsec 2951 implementation to detect outbound ICMP error messages that map to no 2952 extant SA or SPD entry, and treat them specially with regard to SA 2953 creation and lookup. The implementation extracts the header for the 2954 packet that triggered the error (from the ICMP message payload), 2955 reverses the source and destination IP address fields, extracts the 2956 protocol field, and reverses the port fields (if accessible). It then 2957 uses this extracted information to locate an appropriate, active 2958 outbound SA, and transmits the error message via this SA. If no such 2959 SA exists, no SA will be created, and this is an auditable event. 2961 If an IPsec implementation receives an inbound ICMP error message on 2962 an SA, and the IP and ICMP headers of the message do not match the 2963 traffic selectors for the SA, the receiver MUST process the received 2964 message in a special fashion. Specifically, the receiver must extract 2965 the header of the triggering packet from the ICMP payload, and 2966 reverse fields as described above to determine if the packet is 2967 consistent with the selectors for the SA via which the ICMP error 2968 message was received. If the packet fails this check, the IPsec 2969 implementation MUST NOT forwarded the ICMP message to the 2970 destination. This is an auditable event. 2972 7. Handling Fragments (on the protected side of the IPsec boundary) 2974 Earlier sections of this document describe mechanisms for (a) 2975 fragmenting an outbound packet after IPsec processing has been 2976 applied and reassembling it at the receiver before IPsec processing 2977 and (b) handling inbound fragments received from the unprotected side 2978 of the IPsec boundary. This section describes how an implementation 2979 should handle the processing of outbound plaintext fragments on the 2980 protected side of the IPsec boundary. (See Appendix D for discussion 2981 of Fragment Handling Rationale.) In particular, it addresses: 2983 o mapping an outbound non-initial fragment to the right SA 2984 (or finding the right SPD entry) 2985 o verifying that a received non-initial fragment is 2986 authorized for the SA via which it was received 2987 o mapping outbound and inbound non-initial fragments to the 2988 right SPD-O/SPD-I entry or the relevant cache entry, for 2989 BYPASS/DISCARD traffic 2991 Note: In Section 4.1, transport mode SAs have been defined to not 2992 carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two 2993 special values, ANY and OPAQUE, were defined for selectors and that 2994 ANY includes OPAQUE. The term "non-trivial" is used to mean that the 2995 selector has a value other than OPAQUE or ANY. 2997 Note: The term "non-initial fragment" is used here to indicate a 2998 fragment that does not contain all the selector values that may be 2999 needed for access control. As observed in Section 4.4.1, depending 3000 on the Next Layer Protocol, in addition to Ports, the ICMP message 3001 type/code or Mobility Header type could be missing from non-initial 3002 fragments. Also, for IPv6, even the first fragment might NOT contain 3003 the Next Layer Protocol or Ports (or ICMP message type/code, or 3004 Mobility Header type) depending on the kind and number of extension 3005 headers present. If a non-initial fragment contains the Port (or 3006 ICMP type and code or Mobility header type) but not the Next Layer 3007 Protocol, then unless there is an SPD entry for the relevant 3008 Local/Remote addresses with ANY for Next Layer Protocol and Port (or 3009 ICMP type and code or Mobility header type), the fragment would not 3010 contain all the selector information needed for access control. 3012 To address the above issues, three approaches have been defined: 3014 o Tunnel mode SAs that carry initial and non-initial fragments 3015 (See Section 7.1) 3016 o Separate tunnel mode SAs for non-initial fragments (See 3017 Section 7.2) 3018 o Stateful fragment checking (See Section 7.3) 3020 7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments 3022 All implementations MUST support tunnel mode SAs that are configured 3023 to pass traffic without regard to port field (or ICMP type/code or 3024 Mobility Header type) values. If the SA will carry traffic for 3025 specified protocols, the selector set for the SA MUST specify the 3026 port fields (or ICMP type/code or Mobility Header type) as ANY. An SA 3027 defined in this fashion will carry all traffic including initial and 3028 non-initial fragments for the indicated Local/Remote addresses and 3029 specified Next Layer protocol(s). If the SA will carry traffic 3030 without regard to a specific protocol value (i.e., ANY is specified 3031 as the (Next Layer) protocol selector value), then the port field 3032 values are undefined and MUST be set to ANY as well. (As noted in 3033 4.4.1, ANY includes OPAQUE as well as all specific values.) 3035 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments 3037 An implementation MAY support tunnel mode SAs that will carry only 3038 non-initial fragments, separate from non-fragmented packets and 3039 initial fragments. The OPAQUE value will be used to specify port (or 3040 ICMP type/code or Mobility Header type) field selectors for an SA to 3041 carry such fragments. Receivers MUST perform a minimum offset check 3042 on IPv4 (non-initial) fragments to protect against overlapping 3043 fragment attacks when SAs of this type are employed. Because such 3044 checks cannot be performed on IPv6 non-initial fragments, users and 3045 administrators are advised that carriage of such fragments may be 3046 dangerous, and implementers may choose to NOT support such SAs for 3047 IPv6 traffic. Also, an SA of this sort will carry all non-initial 3048 fragments that match a specified Local/Remote address pair and 3049 protocol value, i.e., the fragments carried on this SA belong to 3050 packets that if not fragmented, might have gone on separate SAs of 3051 differing security. Therefore users and administrators are advised 3052 to protect such traffic using ESP (with integrity) and the 3053 "strongest" integrity and encryption algorithms in use between both 3054 peers. (Determination of the "strongest" algorithms requires 3055 imposing an ordering of the available algorithms, a local 3056 determination at the discretion of the initiator of the SA.) 3058 Specific port (or ICMP type/code or Mobility header type) selector 3059 values will be used to define SAs to carry initial fragments and 3060 non-fragmented packets. This approach can be used if a user or 3061 administrator wants to create one or more tunnel mode SAs between the 3062 same Local/Remote addresses that discriminate based on port (or ICMP 3063 type/code or Mobility header type) fields. These SAs MUST have 3064 non-trivial protocol selector values, otherwise approach #1 above 3065 MUST be used. 3067 Note: In general, for the approach described in this section, one 3068 needs only a single SA between two implementations to carry all 3069 non-initial fragments. However, if one chooses to have multiple SAs 3070 between the two implementations for QoS differentiation, then one 3071 might also want multiple SAs to carry fragments-without-ports, one 3072 for each supported QoS class. Since support for QoS via distinct SAs 3073 is a local matter, not mandated by this document, the choice to have 3074 multiple SAs to carry non-initial fragments should also be local. 3076 7.3 Stateful Fragment Checking 3078 An implementation MAY support some form of stateful fragment checking 3079 for a tunnel mode SA with non-trivial port (or ICMP type/code or MH 3080 type) field values (not ANY or OPAQUE). Implementations that will 3081 transmit non-initial fragments on a tunnel mode SA that makes use of 3082 non-trivial port (or ICMP type/code or MH type) selectors MUST notify 3083 a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. 3085 The peer MUST reject this proposal if it will not accept non-initial 3086 fragments in this context. If an implementation does not successfully 3087 negotiate transmission of non-initial fragments for such an SA, it 3088 MUST NOT send such fragments over the SA. This standard does not 3089 specify how peers will deal with such fragments, e.g., via reassembly 3090 or other means, at either sender or receiver. However, a receiver 3091 MUST discard non-initial fragments that arrive on an SA with 3092 non-trivial port (or ICMP type/code or MH type) selector values 3093 unless this feature has been negotiated. Also, the receiver MUST 3094 discard non-initial fragments that do not comply with the security 3095 policy applied to the overall packet. Discarding such packets is an 3096 auditable event. Note that in network configurations where fragments 3097 of a packet might be sent or received via different security gateways 3098 or BITW implementations, stateful strategies for tracking fragments 3099 may fail. 3101 7.4 BYPASS/DISCARD traffic 3103 All implementations MUST support DISCARDing of fragments using the 3104 normal SPD packet classification mechanisms. All implementations MUST 3105 support stateful fragment checking to accommodate BYPASS traffic for 3106 which a non-trivial port range is specified. The concern is that 3107 BYPASS of a cleartext, non-initial fragment arriving at an IPsec 3108 implementation could undermine the security afforded IPsec-protected 3109 traffic directed to the same destination. For example, consider an 3110 IPsec implementation configured with an SPD entry that calls for 3111 IPsec-protection of traffic between a specific source/destination 3112 address pair, and for a specific protocol and destination port, e.g., 3113 TCP traffic on port 23 (Telnet). Assume that the implementation also 3114 allows BYPASS of traffic from the same source/destination address 3115 pair and protocol, but for a different destination port, e.g., port 3116 119 (NNTP). An attacker could send a non-initial fragment (with a 3117 forged source address) that, if bypassed, could overlap with 3118 IPsec-protected traffic from the same source and thus violate the 3119 integrity of the IPsec-protected traffic. Requiring stateful fragment 3120 checking for BYPASS entries with non-trivial port ranges prevents 3121 attacks of this sort. As noted above, in network configurations where 3122 fragments of a packet might be sent or received via different 3123 security gateways or BITW implementations, stateful strategies for 3124 tracking fragments may fail. 3126 8. Path MTU/DF Processing 3128 The application of AH or ESP to an outbound packet increases the size 3129 of a packet and thus may cause a packet to exceed the PMTU for the SA 3130 via which the packet will travel. An IPsec implementation also may 3131 receive an unprotected ICMP PMTU message and, if it choose to act 3132 upon it, the result will affect outbound traffic processing. This 3133 section describes the processing required of an IPsec implementation 3134 to deal with these two PMTU issues. 3136 8.1 DF Bit 3138 All IPsec implementations MUST support the option of copying the DF 3139 bit from an outbound packet to the tunnel mode header that it emits, 3140 when traffic is carried via a tunnel mode SA. This means that it MUST 3141 be possible to configure the implementation's treatment of the DF bit 3142 (set, clear, copy from inner header) for each SA. This applies to SAs 3143 where both inner and outer headers are IPv4. 3145 8.2 Path MTU Discovery (PMTU) 3147 This section discusses IPsec handling for unprotected Path MTU 3148 Discovery messages. ICMP PMTU is used here to refer to an ICMP 3149 message for: 3151 IPv4 (RFC 792 [Pos81b]): 3152 - Type = 3 (Destination Unreachable) 3153 - Code = 4 (Fragmentation needed and DF set) 3154 - Next--Hop MTU in the low-order 16 bits of the 3155 second word of the ICMP header (labeled "unused" 3156 in RFC 792), with high-order 16 bits set to zero) 3158 IPv6 (RFC 2463 [CD98]): 3159 - Type = 2 (Packet Too Big) 3160 - Code = 0 (Fragmentation needed) 3161 - Next-Hop MTU in the 32 bit MTU field of the ICMP6 3162 message 3164 8.2.1 Propagation of PMTU 3166 When an IPsec implementation receives an unauthenticated PMTU 3167 message, and it is configured to process (vs. ignore) such messages, 3168 it maps the message to the SA to which it corresponds. This mapping 3169 is effected by extracting the header information from the payload of 3170 the PMTU message and applying the procedure described in Section 5.2. 3171 The PMTU determined by this message is used to update the SAD PMTU 3172 field, taking into account the size of the AH or ESP header that will 3173 be applied, any crypto synchronization data, and the overhead imposed 3174 by an additional IP header, in the case of a tunnel mode SA. 3176 In a native host implementation, it is possible to maintain PMTU data 3177 at the same granularity as for unprotected communication, so there is 3178 no loss of functionality. Signaling of the PMTU information is 3179 internal to the host. For all other IPsec implementation options, the 3180 PMTU data must be propagated via a synthesized ICMP PMTU. In these 3181 cases, the IPsec implementation SHOULD wait for outbound traffic to 3182 be mapped to the SAD entry. When such traffic arrives, if the traffic 3183 would exceed the updated PMTU value the traffic MUST be handled as 3184 follows: 3186 Case 1: Original (cleartext) packet is IPv4 and has the DF 3187 bit set. The implementation SHOULD discard the packet 3188 and send a PMTU ICMP message. 3190 Case 2: Original (cleartext) packet is IPv4 and has the DF 3191 bit clear. The implementation SHOULD fragment (before or 3192 after encryption per its configuration) and then forward 3193 the fragments. It SHOULD NOT send a PMTU ICMP message. 3195 Case 3: Original (cleartext) packet is IPv6. The implementation 3196 SHOULD discard the packet and send a PMTU ICMP message. 3198 8.2.2 PMTU Aging 3200 In all IPsec implementations the PMTU associated with an SA MUST be 3201 "aged" and some mechanism is required to update the PMTU in a timely 3202 manner, especially for discovering if the PMTU is smaller than 3203 required by current network conditions. A given PMTU has to remain 3204 in place long enough for a packet to get from the source of the SA to 3205 the peer, and to propagate an ICMP error message if the current PMTU 3206 is too big. 3208 Implementations SHOULD use the approach described in the Path MTU 3209 Discovery document (RFC 1191 [MD90], Section 6.3), which suggests 3210 periodically resetting the PMTU to the first-hop data-link MTU and 3211 then letting the normal PMTU Discovery processes update the PMTU as 3212 necessary. The period SHOULD be configurable. 3214 9. Auditing 3216 IPsec implementations are not required to support auditing. For the 3217 most part, the granularity of auditing is a local matter. However, 3218 several auditable events are identified in this document and for each 3219 of these events a minimum set of information that SHOULD be included 3220 in an audit log is defined. Additional information also MAY be 3221 included in the audit log for each of these events, and additional 3222 events, not explicitly called out in this specification, also MAY 3223 result in audit log entries. There is no requirement for the 3224 receiver to transmit any message to the purported transmitter in 3225 response to the detection of an auditable event, because of the 3226 potential to induce denial of service via such action. 3228 10. Conformance Requirements 3230 All IPv4 IPsec implementations MUST comply with all requirements of 3231 this document. All IPv6 implementations MUST comply with all 3232 requirements of this document. 3234 11. Security Considerations 3236 The focus of this document is security; hence security considerations 3237 permeate this specification. 3239 IPsec imposes stringent constraints on bypass of IP header data in 3240 both directions, across the IPsec barrier, especially when tunnel 3241 mode SAs are employed. Some constraints are absolute, while others 3242 are subject to local administrative controls, often on a per-SA 3243 basis. For outbound traffic, these constraints are designed to limit 3244 covert channel bandwidth. For inbound traffic, the constraints are 3245 designed to prevent an adversary who has the ability to tamper with 3246 one data stream (on the unprotected side of the IPsec barrier) from 3247 adversely affecting other data streams (on the protected side of the 3248 barrier). The discussion in Section 5 dealing with processing DSCP 3249 values for tunnel mode SAs illustrates this concern. 3251 If an IPsec implementation is configured to pass ICMP error messages 3252 over SAs based on the ICMP header values, without checking the header 3253 information from the ICMP message payload, serious vulnerabilities 3254 may arise. Consider a scenario in which several sites (A, B, and C) 3255 are connected to one another via ESP-protected tunnels: A-B, A-C, and 3256 B-C. Also assume that the traffic selectors for each tunnel specify 3257 ANY for protocol and port fields and IP source/destination address 3258 ranges that encompass the address range for the systems behind the 3259 security gateways serving each site. This would allow a host at site 3260 B to send an ICMP destination dead message to any host at site A, 3261 that declares all hosts on the net at site C to be unreachable. This 3262 is a very efficient DoS attack that could have been prevented if the 3263 ICMP error messages were subjected to the checks that IPsec provides, 3264 if the SPD is suitably configured, as described in Section 6.2. 3266 12. IANA Considerations 3268 Upon approval of this draft for publication as an RFC, this document 3269 requests that IANA fill in the number (xx) for the asn1-modules 3270 registry and assign the object identifier (yy) for the spd-module in 3271 Appendix C "ASN.1 for an SPD Entry". 3273 13. Differences from RFC 2401 3275 This architecture document differs substantially from RFC 2401 in 3276 detail and in organization, but the fundamental notions are 3277 unchanged. 3279 o The processing model has been revised to address new IPsec 3280 scenarios, improve performance and simplify implementation. This 3281 includes a separation between forwarding (routing) and SPD 3282 selection, several SPD changes, and the addition of an outbound 3283 SPD cache and an inbound SPD cache for bypassed or discarded 3284 traffic. There is also a new database, the Peer Authorization 3285 Database (PAD). This provides a link between an SA management 3286 protocol like IKE and the SPD. 3288 o There is no longer a requirement to support nested SAs or "SA 3289 bundles." Instead this functionality can be achieved through SPD 3290 and forwarding table configuration. An example of a configuration 3291 has been added in Appendix E. 3293 o SPD entries were redefined to provide more flexibility. Each SPD 3294 entry now consists of 1 to N sets of selectors, where each 3295 selector set contains one protocol and a "list of ranges" can now 3296 be specified for the Local IP address, Remote IP address, and 3297 whatever fields (if any) are associated with the Next Layer 3298 Protocol (Local Port, Remote Port, ICMP message type and code, and 3299 Mobility Header Type). An individual value for a selector is 3300 represented via a trivial range and ANY is represented via a range 3301 than spans all values for the selector. An example of an ASN.1 3302 description is included in Appendix C. 3304 o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and 3305 ECN. The tunnel section has been updated to explain how to handle 3306 DSCP and ECN bits. 3308 o For tunnel mode SAs, an SG, BITS, or BITW implementation is now 3309 allowed to fragment packets before applying IPsec. This applies 3310 only to IPv4. For IPv6 packets, only the originator is allowed to 3311 fragment them. 3313 o When security is desired between two intermediate systems along a 3314 path or between an intermediate system and an end system, 3315 transport mode may now be used between security gateways and 3316 between a security gateway and a host. 3318 o This document clarifies that for all traffic that crosses the IPsec 3319 boundary, including IPsec management traffic, the SPD or 3320 associated caches must be consulted. 3322 o This document defines how to handle the situation of a security 3323 gateway with multiple subscribers requiring separate IPsec 3324 contexts. 3326 o A definition of reserved SPIs has been added. 3328 o Text has been added explaining why ALL IP packets must be checked 3329 -- IPsec includes minimal firewall functionality to support access 3330 control at the IP layer. 3332 o The tunnel section has been updated to clarify how to handle the IP 3333 options field and IPv6 extension headers when constructing the 3334 outer header. 3336 o SA mapping for inbound traffic has been updated to be consistent 3337 with the changes made in AH and ESP for support of unicast and 3338 multicast SAs. 3340 o Guidance has been added re: how to handle the covert channel 3341 created in tunnel mode by copying the DSCP value to outer header. 3343 o Support for AH in both IPv4 and IPv6 is no longer required. 3345 o PMTU handling has been updated. The appendix on 3346 PMTU/DF/Fragmentation has been deleted. 3348 o Three approaches have been added for handling plaintext fragments 3349 on the protected side of the IPsec boundary. Appendix D documents 3350 the rationale behind them. 3352 o Added revised text describing how to derive selector values for SAs 3353 (from the SPD entry or from the packet, etc.) 3355 o Added a new table describing the relationship between selector 3356 values in an SPD entry, the PFP flag, and resulting selector 3357 values in the corresponding SAD entry. 3359 o Added Appendix B to describe decorrelation. 3361 o Added text describing how to handle an outbound packet which must 3362 be discarded. 3364 o Added text describing how to handle a DISCARDED inbound packet, 3365 i.e., one that does not match the SA upon which it arrived. 3367 o IPv6 mobility header has been added as a possible Next Layer 3368 Protocol. IPv6 mobility header message type has been added as a 3369 selector. 3371 o ICMP message type and code have been added as selectors. 3373 o The selector "data sensitivity level" has been removed to simplify 3374 things. 3376 o Updated text describing handling ICMP error messages. The appendix 3377 on "Categorization of ICMP messages" has been deleted. 3379 o The text for the selector name has been updated and clarified. 3381 o The "Next Layer Protocol" has been further explained and a default 3382 list of protocols to skip when looking for the Next Layer Protocol 3383 has been added. 3385 o The text has been amended to say that this document assumes use of 3386 IKE v2 or an SA management protocol with comparable features. 3388 o Text has been added clarifying the algorithm for mapping inbound 3389 IPsec datagrams to SAs in the presence of multicast SAs. 3391 o The appendix "Sequence Space Window Code Example" has been removed. 3393 o With respect to IP addresses and ports, the terms "Local" and 3394 "Remote" are used for policy rules (replacing source and 3395 destination). "Local" refers to the entity being protected by an 3396 IPsec implementation, i.e., the "source" address/port of outbound 3397 packets or the "destination" address/port of inbound packets. 3398 "Remote" refers to a peer entity or peer entities. The terms 3399 "source" and "destination" are still used for packet header 3400 fields. 3402 Acknowledgements 3404 The authors would like to acknowledge the contributions of Ran 3405 Atkinson, who played a critical role in initial IPsec activities, and 3406 who authored the first series of IPsec standards: RFCs 1825-1827; and 3407 Charlie Lynn, who made significant contributions to the second series 3408 of IPsec standards (RFCs 2401,2402,and 2406) and to the current 3409 versions, especially with regard to IPv6 issues. The authors also 3410 would like to thank the members of the IPsec and MSEC working groups 3411 who have contributed to the development of this protocol 3412 specification. 3414 Appendix A -- Glossary 3416 This section provides definitions for several key terms that are 3417 employed in this document. Other documents provide additional 3418 definitions and background information relevant to this technology, 3419 e.g., [Shi00, VK83, HA94]. Included in this glossary are generic 3420 security service and security mechanism terms, plus IPsec-specific 3421 terms. 3423 Access Control 3424 Access control is a security service that prevents unauthorized 3425 use of a resource, including the prevention of use of a resource 3426 in an unauthorized manner. In the IPsec context, the resource to 3427 which access is being controlled is often: 3428 o for a host, computing cycles or data 3429 o for a security gateway, a network behind the gateway 3430 or bandwidth on that network. 3432 Anti-replay 3433 [See "Integrity" below] 3435 Authentication 3436 This term is used informally to refer to the combination of two 3437 nominally distinct security services, data origin authentication 3438 and connectionless integrity. See the definitions below for each 3439 of these services. 3441 Availability 3442 Availability, when viewed as a security service, addresses the 3443 security concerns engendered by attacks against networks that deny 3444 or degrade service. For example, in the IPsec context, the use of 3445 anti-replay mechanisms in AH and ESP support availability. 3447 Confidentiality 3448 Confidentiality is the security service that protects data from 3449 unauthorized disclosure. The primary confidentiality concern in 3450 most instances is unauthorized disclosure of application level 3451 data, but disclosure of the external characteristics of 3452 communication also can be a concern in some circumstances. 3453 Traffic flow confidentiality is the service that addresses this 3454 latter concern by concealing source and destination addresses, 3455 message length, or frequency of communication. In the IPsec 3456 context, using ESP in tunnel mode, especially at a security 3457 gateway, can provide some level of traffic flow confidentiality. 3458 (See also traffic analysis, below.) 3460 Data Origin Authentication 3461 Data origin authentication is a security service that verifies the 3462 identity of the claimed source of data. This service is usually 3463 bundled with connectionless integrity service. 3465 Encryption 3466 Encryption is a security mechanism used to transform data from an 3467 intelligible form (plaintext) into an unintelligible form 3468 (ciphertext), to provide confidentiality. The inverse 3469 transformation process is designated "decryption". Oftimes the 3470 term "encryption" is used to generically refer to both processes. 3472 Integrity 3473 Integrity is a security service that ensures that modifications to 3474 data are detectable. Integrity comes in various flavors to match 3475 application requirements. IPsec supports two forms of integrity: 3476 connectionless and a form of partial sequence integrity. 3477 Connectionless integrity is a service that detects modification of 3478 an individual IP datagram, without regard to the ordering of the 3479 datagram in a stream of traffic. The form of partial sequence 3480 integrity offered in IPsec is referred to as anti-replay 3481 integrity, and it detects arrival of duplicate IP datagrams 3482 (within a constrained window). This is in contrast to 3483 connection-oriented integrity, which imposes more stringent 3484 sequencing requirements on traffic, e.g., to be able to detect 3485 lost or re-ordered messages. Although authentication and 3486 integrity services often are cited separately, in practice they 3487 are intimately connected and almost always offered in tandem. 3489 Protected vs Unprotected 3490 "Protected" refers to the systems or interfaces that are inside 3491 the IPsec protection boundary and "unprotected" refers to the 3492 systems or interfaces that are outside the IPsec protection 3493 boundary. IPsec provides a boundary through which traffic passes. 3494 There is an asymmetry to this barrier, which is reflected in the 3495 processing model. Outbound data, if not discarded or bypassed, is 3496 protected via the application of AH or ESP and the addition of the 3497 corresponding headers. Inbound data, if not discarded or 3498 bypassed, is processed via the removal of AH or ESP headers. In 3499 this document, inbound traffic enters an IPsec implementation from 3500 the "unprotected" interface. Outbound traffic enters the 3501 implementation via the "protected" interface, or is internally 3502 generated by the implementation on the "protected" side of the 3503 boundary and directed toward the "unprotected" interface. An IPsec 3504 implementation may support more than one interface on either or 3505 both sides of the boundary. The protected interface may be 3506 internal, e.g., in a host implementation of IPsec. The protected 3507 interface may link to a socket layer interface presented by the 3508 OS. 3510 Security Association (SA) 3511 A simplex (uni-directional) logical connection, created for 3512 security purposes. All traffic traversing an SA is provided the 3513 same security processing. In IPsec, an SA is an internet layer 3514 abstraction implemented through the use of AH or ESP. State data 3515 associated with an SA is represented in the SA Database (SAD). 3517 Security Gateway 3518 A security gateway is an intermediate system that acts as the 3519 communications interface between two networks. The set of hosts 3520 (and networks) on the external side of the security gateway is 3521 termed unprotected (they are generally at least less protected 3522 than those "behind" the SG), while the networks and hosts on the 3523 internal side are viewed as protected. The internal subnets and 3524 hosts served by a security gateway are presumed to be trusted by 3525 virtue of sharing a common, local, security administration. (See 3526 "Trusted Subnetwork" below.) In the IPsec context, a security 3527 gateway is a point at which AH and/or ESP is implemented in order 3528 to serve a set of internal hosts, providing security services for 3529 these hosts when they communicate with external hosts also 3530 employing IPsec (either directly or via another security gateway). 3532 SPI 3533 Acronym for "Security Parameters Index" (SPI). The SPI is an 3534 arbitrary 32-bit value that is used by a receiver to identify the 3535 SA to which an incoming packet should be bound. For a unicast SA, 3536 the SPI can be used by itself to specify an SA, or it may be used 3537 in conjunction with the IPsec protocol type. Additional IP 3538 address information is used to identify multicast SAs. The SPI is 3539 carried in AH and ESP protocols to enable the receiving system to 3540 select the SA under which a received packet will be processed. An 3541 SPI has only local significance, as defined by the creator of the 3542 SA (usually the receiver of the packet carrying the SPI); thus an 3543 SPI is generally viewed as an opaque bit string. However, the 3544 creator of an SA may choose to interpret the bits in an SPI to 3545 facilitate local processing. 3547 Traffic Analysis 3548 The analysis of network traffic flow for the purpose of deducing 3549 information that is useful to an adversary. Examples of such 3550 information are frequency of transmission, the identities of the 3551 conversing parties, sizes of packets, flow identifiers, etc. 3552 [Sch94] 3554 Appendix B - Decorrelation 3556 This appendix is based on work done for caching of policies in the IP 3557 Security Policy Working Group by Luis Sanchez, Matt Condell, and John 3558 Zao. 3560 Two SPD entries are correlated if there is a non-null intersection 3561 between the values of corresponding selectors in each entry. Caching 3562 correlated SPD entries can lead to incorrect policy enforcement. A 3563 solution to this problem, that still allows for caching, is to remove 3564 the ambiguities by decorrelating the entries. That is, the SPD 3565 entries must be rewritten so that for every pair of entries there 3566 exists a selector for which there is a null intersection between the 3567 values in both of the entries. Once the entries are decorrelated, 3568 there is no longer any ordering requirement on them, since only one 3569 entry will match any lookup. The next section describes 3570 decorrelation in more detail and presents an algorithm that may be 3571 used to implement decorrelation. 3573 B.1 Decorrelation Algorithm 3575 The basic decorrelation algorithm takes each entry in a correlated 3576 SPD and divides it up into a set of entries using a tree structure. 3577 The nodes of the tree are the selectors that may overlap between the 3578 policies. At each node, the algorithm creates a branch for each of 3579 the values of the selector. It also creates one branch for the 3580 complement of the union of all selector values. Policies are then 3581 formed by traversing the tree from the root to each leaf. The 3582 policies at the leaves are compared to the set of already 3583 decorrelated policy rules. Each policy at a leaf is either completely 3584 overridden by a policy in the already decorrelated set and is 3585 discarded or is decorrelated with all the policies in the 3586 decorrelated set and is added to it. 3588 The basic algorithm does not guarantee an optimal set of decorrelated 3589 entries. That is, the entries may be broken up into smaller sets 3590 than is necessary, though they will still provide all the necessary 3591 policy information. Some extensions to the basic algorithm are 3592 described later to improve this and improve the performance of the 3593 algorithm. 3595 C A set of ordered, correlated entries (a correlated SPD) 3596 Ci The ith entry in C. 3597 U The set of decorrelated entries being built from C 3598 Ui The ith entry in U. 3599 Sik The kth selection for policy Ci 3600 Ai The action for policy Ci 3602 A policy (SPD entry) P may be expressed as a sequence of selector 3603 values and an action (BYPASS, DISCARD, or PROTECT): 3605 Ci = Si1 x Si2 x ... x Sik -> Ai 3607 1) Put C1 in set U as U1 3609 For each policy Cj (j > 1) in C 3611 2) If Cj is decorrelated with every entry in U, then add it to U. 3613 3) If Cj is correlated with one or more entries in U, create a tree 3614 rooted at the policy Cj that partitions Cj into a set of decorrelated 3615 entries. The algorithm starts with a root node where no selectors 3616 have yet been chosen. 3618 A) Choose a selector in Cj, Sjn, that has not yet been chosen when 3619 traversing the tree from the root to this node. If there are no 3620 selectors not yet used, continue to the next unfinished branch 3621 until all branches have been completed. When the tree is 3622 completed, go to step D. 3624 T is the set of entries in U that are correlated with the entry 3625 at this node. 3627 The entry at this node is the entry formed by the selector 3628 values of each of the branches between the root and this node. 3629 Any selector values that are not yet represented by branches 3630 assume the corresponding selector value in Cj, since the values 3631 in Cj represent the maximum value for each selector. 3633 B) Add a branch to the tree for each value of the selector Sjn that 3634 appears in any of the entries in T. (If the value is a superset 3635 of the value of Sjn in Cj, then use the value in Cj, since that 3636 value represents the universal set.) Also add a branch for the 3637 complement of the union of all the values of the selector Sjn 3638 in T. When taking the complement, remember that the universal 3639 set is the value of Sjn in Cj. A branch need not be created 3640 for the null set. 3642 C) Repeat A and B until the tree is completed. 3644 D) The entry to each leaf now represents an entry that is a subset 3645 of Cj. The entries at the leaves completely partition Cj in 3646 such a way that each entry is either completely overridden by 3647 an entry in U, or is decorrelated with the entries in U. 3649 Add all the decorrelated entries at the leaves of the tree to U. 3651 4) Get next Cj and go to 2. 3653 5) When all entries in C have been processed, then U will contain an 3654 decorrelated version of C. 3656 There are several optimizations that can be made to this algorithm. 3657 A few of them are presented here. 3659 It is possible to optimize, or at least improve, the amount of 3660 branching that occurs by carefully choosing the order of the 3661 selectors used for the next branch. For example, if a selector Sjn 3662 can be chosen so that all the values for that selector in T are equal 3663 to or a superset of the value of Sjn in Cj, then only a single branch 3664 needs to be created (since the complement will be null). 3666 Branches of the tree do not have to proceed with the entire 3667 decorrelation algorithm. For example, if a node represents an entry 3668 that is decorrelated with all the entries in U, then there is no 3669 reason to continue decorrelating that branch. Also, if a branch is 3670 completely overridden by an entry in U, then there is no reason to 3671 continue decorrelating the branch. 3673 An additional optimization is to check to see if a branch is 3674 overridden by one of the CORRELATED entries in set C that has already 3675 been decorrelated. That is, if the branch is part of decorrelating 3676 Cj, then check to see if it was overridden by an entry Cm, m < j. 3677 This is a valid check, since all the entries Cm are already expressed 3678 in U. 3680 Along with checking if an entry is already decorrelated in step 2, 3681 check if Cj is overridden by any entry in U. If it is, skip it since 3682 it is not relevant. An entry x is overridden by another entry y if 3683 every selector in x is equal to or a subset of the corresponding 3684 selector in entry y. 3686 Appendix C -- ASN.1 for an SPD Entry 3688 This appendix is included as an additional way to describe SPD 3689 entries, as defined in Section 4.4.1. It uses ASN.1 syntax which has 3690 been successfully compiled. This syntax is merely illustrative and 3691 need not be employed in an implementation to achieve compliance. The 3692 SPD description in Section 4.4.1 is normative. 3694 SPDModule 3696 {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) 3697 asn1-modules (xx) spd-module (yy) } 3699 DEFINITIONS IMPLICIT TAGS ::= 3701 BEGIN 3703 IMPORTS 3704 RDNSequence FROM PKIX1Explicit88 3705 { iso(1) identified-organization(3) 3706 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3707 id-mod(0) id-pkix1-explicit(18) } ; 3709 -- An SPD is a list of policies in decreasing order of preference 3710 SPD ::= SEQUENCE OF SPDEntry 3712 SPDEntry ::= CHOICE { 3713 iPsecEntry IPsecEntry, -- PROTECT traffic 3714 bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS 3716 IPsecEntry ::= SEQUENCE { -- Each entry consists of 3717 name NameSets OPTIONAL, 3718 pFPs PacketFlags, -- Populate from packet flags 3719 -- Applies to ALL of the corresponding 3720 -- traffic selectors in the SelectorLists 3721 condition SelectorLists, -- Policy "condition" 3722 processing Processing -- Policy "action" 3723 } 3725 BypassOrDiscardEntry ::= SEQUENCE { 3726 bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD 3727 condition InOutBound } 3729 InOutBound ::= CHOICE { 3730 outbound [0] SelectorLists, 3731 inbound [1] SelectorLists, 3732 bothways [2] BothWays } 3734 BothWays ::= SEQUENCE { 3735 inbound SelectorLists, 3736 outbound SelectorLists } 3738 NameSets ::= SEQUENCE { 3739 passed SET OF Names-R, -- Matched to IKE ID by 3740 -- responder 3741 local SET OF Names-I } -- Used internally by IKE 3742 -- initiator 3744 Names-R ::= CHOICE { -- IKE v2 IDs 3745 dName RDNSequence, -- ID_DER_ASN1_DN 3746 fqdn FQDN, -- ID_FQDN 3747 rfc822 [0] RFC822Name, -- ID_RFC822_ADDR 3748 keyID OCTET STRING } -- KEY_ID 3750 Names-I ::= OCTET STRING -- Used internally by IKE 3751 -- initiator 3753 FQDN ::= IA5String 3755 RFC822Name ::= IA5String 3757 PacketFlags ::= BIT STRING { 3758 -- if set, take selector value from packet 3759 -- establishing SA 3760 -- else use value in SPD entry 3761 localAddr (0), 3762 remoteAddr (1), 3763 protocol (2), 3764 localPort (3), 3765 remotePort (4) } 3767 SelectorLists ::= SET OF SelectorList 3769 SelectorList ::= SEQUENCE { 3770 localAddr AddrList, 3771 remoteAddr AddrList, 3772 protocol ProtocolChoice } 3774 Processing ::= SEQUENCE { 3775 extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit 3776 seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit 3777 fragCheck BOOLEAN, -- TRUE stateful fragment checking, 3778 -- FALSE no stateful fragment checking 3779 lifetime SALifetime, 3780 spi ManualSPI, 3781 algorithms ProcessingAlgs, 3782 tunnel TunnelOptions OPTIONAL } -- if absent, use 3783 -- transport mode 3785 SALifetime ::= SEQUENCE { 3786 seconds [0] INTEGER OPTIONAL, 3787 bytes [1] INTEGER OPTIONAL } 3789 ManualSPI ::= SEQUENCE { 3790 spi INTEGER, 3791 keys KeyIDs } 3793 KeyIDs ::= SEQUENCE OF OCTET STRING 3795 ProcessingAlgs ::= CHOICE { 3796 ah [0] IntegrityAlgs, -- AH 3797 esp [1] ESPAlgs} -- ESP 3799 ESPAlgs ::= CHOICE { 3800 integrity [0] IntegrityAlgs, -- integrity only 3801 confidentiality [1] ConfidentialityAlgs, -- confidentiality 3802 -- only 3803 both [2] IntegrityConfidentialityAlgs, 3804 combined [3] CombinedModeAlgs } 3806 IntegrityConfidentialityAlgs ::= SEQUENCE { 3807 integrity IntegrityAlgs, 3808 confidentiality ConfidentialityAlgs } 3810 -- Integrity Algorithms, ordered by decreasing preference 3811 IntegrityAlgs ::= SEQUENCE OF IntegrityAlg 3813 -- Confidentiality Algorithms, ordered by decreasing preference 3814 ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg 3816 -- Integrity Algorithms 3817 IntegrityAlg ::= SEQUENCE { 3818 algorithm IntegrityAlgType, 3819 parameters ANY -- DEFINED BY algorithm -- OPTIONAL } 3821 IntegrityAlgType ::= INTEGER { 3822 none (0), 3823 auth-HMAC-MD5-96 (1), 3824 auth-HMAC-SHA1-96 (2), 3825 auth-DES-MAC (3), 3826 auth-KPDK-MD5 (4), 3827 auth-AES-XCBC-96 (5) 3828 -- tbd (6..65535) 3829 } 3831 -- Confidentiality Algorithms 3832 ConfidentialityAlg ::= SEQUENCE { 3833 algorithm ConfidentialityAlgType, 3834 parameters ANY -- DEFINED BY algorithm -- OPTIONAL } 3836 ConfidentialityAlgType ::= INTEGER { 3837 encr-DES-IV64 (1), 3838 encr-DES (2), 3839 encr-3DES (3), 3840 encr-RC5 (4), 3841 encr-IDEA (5), 3842 encr-CAST (6), 3843 encr-BLOWFISH (7), 3844 encr-3IDEA (8), 3845 encr-DES-IV32 (9), 3846 encr-RC4 (10), 3847 encr-NULL (11), 3848 encr-AES-CBC (12), 3849 encr-AES-CTR (13) 3850 -- tbd (14..65535) 3851 } 3853 CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg 3855 CombinedModeAlg ::= SEQUENCE { 3856 algorithm CombinedModeType, 3857 parameters ANY -- DEFINED BY algorithm} -- defined outside 3858 -- of this document for AES modes. 3860 CombinedModeType ::= INTEGER { 3861 comb-AES-CCM (1), 3862 comb-AES-GCM (2) 3863 -- tbd (3..65535) 3864 } 3866 TunnelOptions ::= SEQUENCE { 3867 dscp DSCP, 3868 ecn BOOLEAN, -- TRUE Copy CE to inner header 3869 df DF, 3870 addresses TunnelAddresses } 3872 TunnelAddresses ::= CHOICE { 3873 ipv4 IPv4Pair, 3874 ipv6 [0] IPv6Pair } 3876 IPv4Pair ::= SEQUENCE { 3877 local OCTET STRING (SIZE(4)), 3878 remote OCTET STRING (SIZE(4)) } 3880 IPv6Pair ::= SEQUENCE { 3881 local OCTET STRING (SIZE(16)), 3882 remote OCTET STRING (SIZE(16)) } 3884 DSCP ::= SEQUENCE { 3885 copy BOOLEAN, -- TRUE copy from inner header 3886 -- FALSE do not copy 3887 mapping OCTET STRING OPTIONAL} -- points to table 3888 -- if no copy 3890 DF ::= INTEGER { 3891 clear (0), 3892 set (1), 3893 copy (2) } 3895 ProtocolChoice::= CHOICE { 3896 anyProt AnyProtocol, -- for ANY protocol 3897 noNext [0] NoNextLayerProtocol, -- has no next layer 3898 -- items 3899 oneNext [1] OneNextLayerProtocol, -- has one next layer 3900 -- item 3901 twoNext [2] TwoNextLayerProtocol, -- has two next layer 3902 -- items 3903 fragment FragmentNoNext } -- has no next layer 3904 -- info 3906 AnyProtocol ::= SEQUENCE { 3907 id INTEGER (0), -- ANY protocol 3908 nextLayer AnyNextLayers } 3910 AnyNextLayers ::= SEQUENCE { -- with either 3911 first AnyNextLayer, -- ANY next layer selector 3912 second AnyNextLayer } -- ANY next layer selector 3914 NoNextLayerProtocol ::= INTEGER (2..254) 3916 FragmentNoNext ::= INTEGER (44) -- Fragment identifier 3918 OneNextLayerProtocol ::= SEQUENCE { 3919 id INTEGER (1..254), -- ICMP, MH, ICMPv6 3920 nextLayer NextLayerChoice } -- ICMP Type*256+Code 3921 -- MH Type*256 3923 TwoNextLayerProtocol ::= SEQUENCE { 3924 id INTEGER (2..254), -- Protocol 3925 local NextLayerChoice, -- Local and 3926 remote NextLayerChoice } -- Remote ports 3928 NextLayerChoice ::= CHOICE { 3929 any AnyNextLayer, 3930 opaque [0] OpaqueNextLayer, 3931 range [1] NextLayerRange } 3933 -- Representation of ANY in next layer field 3934 AnyNextLayer ::= SEQUENCE { 3935 start INTEGER (0), 3936 end INTEGER (65535) } 3938 -- Representation of OPAQUE in next layer field. 3939 -- Matches IKE convention 3940 OpaqueNextLayer ::= SEQUENCE { 3941 start INTEGER (65535), 3942 end INTEGER (0) } 3944 -- Range for a next layer field 3945 NextLayerRange ::= SEQUENCE { 3946 start INTEGER (0..65535), 3947 end INTEGER (0..65535) } 3949 -- List of IP addresses 3950 AddrList ::= SEQUENCE { 3951 v4List IPv4List OPTIONAL, 3952 v6List [0] IPv6List OPTIONAL } 3954 -- IPv4 address representations 3955 IPv4List ::= SEQUENCE OF IPv4Range 3957 IPv4Range ::= SEQUENCE { -- close, but not quite right ... 3958 ipv4Start OCTET STRING (SIZE (4)), 3959 ipv4End OCTET STRING (SIZE (4)) } 3961 -- IPv6 address representations 3962 IPv6List ::= SEQUENCE OF IPv6Range 3964 IPv6Range ::= SEQUENCE { -- close, but not quite right ... 3965 ipv6Start OCTET STRING (SIZE (16)), 3966 ipv6End OCTET STRING (SIZE (16)) } 3968 END 3970 Appendix D -- Fragment Handling Rationale 3972 There are three issues that must be resolved re processing of 3973 (plaintext) fragments in IPsec: 3975 - mapping a non-initial, outbound fragment to the right SA 3976 (or finding the right SPD entry) 3977 - verifying that a received, non-initial fragment is authorized 3978 for the SA via which it is received 3979 - mapping outbound and inbound non-initial fragments to the 3980 right SPD/cache entry, for BYPASS/DISCARD traffic. 3982 The first and third issues arise because we need a deterministic 3983 algorithm for mapping traffic to SAs (and SPD/cache entries). All 3984 three issues are important because we want to make sure that 3985 non-initial fragments that cross the IPsec boundary do not cause the 3986 access control policies in place at the receiver (or transmitter) to 3987 be violated. 3989 D.1 Transport Mode and Fragments 3991 First, we note that transport mode SAs have been defined to not carry 3992 fragments. This is a carryover from RFC 2401, where transport mode 3993 SAs always terminated at end points. This is a fundamental 3994 requirement because, in the worst case, an IPv4 fragment to which 3995 IPsec was applied, might then be fragmented (as a ciphertext packet), 3996 en route to the destination. IP fragment reassembly procedures at the 3997 IPsec receiver would not be able to distinguish between pre-IPsec 3998 fragments and fragments created after IPsec processing. 4000 For IPv6, only the sender is allowed to fragment a packet. As for 4001 IPv4, an IPsec implementation is allowed to fragment tunnel mode 4002 packets after IPsec processing, because it is the sender relative to 4003 the (outer) tunnel header. However, unlike IPv4, it would be feasible 4004 to carry a plaintext fragment on a transport mode SA, because the 4005 fragment header in IPv6 would appear after the AH or ESP header, and 4006 thus would not cause confusion at the receiver re reassembly. 4007 Specifically, the receiver would not attempt reassembly for the 4008 fragment until after IPsec processing. To keep things simple, this 4009 specification prohibits carriage of fragments on transport mode SAs 4010 for IPv6 traffic. 4012 When only end systems used transport mode SAs, the prohibition on 4013 carriage of fragments was not a problem, since we assumed that the 4014 end system could be configured to not offer a fragment to IPsec. For 4015 a native host implementation this seems reasonable, and, as someone 4016 already noted, RFC 2401 warned that a BITS implementation might have 4017 to reassemble fragments before performing an SA lookup. (It would 4018 then apply AH or ESP and could re-fragment the packet after IPsec 4019 processing.) Because a BITS implementation is assumed to be able to 4020 have access to all traffic emanating from its host, even if the host 4021 has multiple interfaces, this was deemed a reasonable mandate. 4023 In this specification, it is acceptable to use transport mode in 4024 cases where the IPsec implementation is not the ultimate destination, 4025 e.g., between two SGs. In principle, this creates a new opportunity 4026 for outbound, plaintext fragments to be mapped to a transport mode SA 4027 for IPsec processing. However, in these new contexts in which a 4028 transport mode SA is now approved for use, it seems likely that we 4029 can continue to prohibit transmission of fragments, as seen by IPsec, 4030 i.e., packets that have an "outer header" with a non-zero fragment 4031 offset field. For example, in an IP overlay network, packets being 4032 sent over transport mode SAs are IP-in-IP tunneled and thus have the 4033 necessary inner header to accommodate fragmentation prior to IPsec 4034 processing. When carried via a transport mode SA, IPsec would not 4035 examine the inner IP header for such traffic, and thus would not 4036 consider the packet to be a fragment. 4038 D.2 Tunnel Mode and Fragments 4040 For tunnel mode SAs, it has always been the case that outbound 4041 fragments might arrive for processing at an IPsec implementation. The 4042 need to accommodate fragmented outbound packets can pose a problem 4043 because a non-initial fragment generally will not contain the port 4044 fields associated with a next layer protocol such as TCP, UDP, or 4045 SCTP. Thus, depending on the SPD configuration for a given IPsec 4046 implementation, plaintext fragments might or might not pose a 4047 problem. 4049 For example, if the SPD requires that all traffic between two address 4050 ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries 4051 apply to this address range), then it should be easy to carry 4052 non-initial fragments on the SA defined for this address range, since 4053 the SPD entry implies an intent to carry ALL traffic between the 4054 address ranges. But, if there are multiple SPD entries that could 4055 match a fragment, and if these entries reference different subsets of 4056 port fields (vs. ANY), then it is not possible to map an outbound 4057 non-initial fragment to the right entry, unambiguously. (If we choose 4058 to allow carriage of fragments on transport mode SAs for IPv6, the 4059 problems arises in that context as well.) 4061 This problem largely, though not exclusively, motivated the 4062 definition of OPAQUE as a selector value for port fields in RFC 2401. 4063 The other motivation for OPAQUE is the observation that port fields 4064 might not be accessible due to the prior application of IPsec. For 4065 example, if a host applied IPsec to its traffic and that traffic 4066 arrived at an SG, these fields would be encrypted. The algorithm 4067 specified for locating the "next layer protocol" described in RFC 4068 2401 also motivated use of OPAQUE to accommodate an encrypted next 4069 layer protocol field in such circumstances. Nonetheless, the primary 4070 use of the OPAQUE value was to match traffic selector fields in 4071 packets that did not contain port fields (non-initial fragments), or 4072 packets in which the port fields were already encrypted (as a result 4073 of nested application of IPsec). RFC 2401 was ambiguous in discussing 4074 the use of OPAQUE vs. ANY, suggesting in some places that ANY might 4075 be an alternative to OPAQUE. 4077 We gain additional access control capability by defining both ANY and 4078 OPAQUE values. OPAQUE can be defined to match only fields that are 4079 not accessible. We could define ANY as the complement of OPAQUE, 4080 i.e., it would match all values but only for accessible port fields. 4081 We have therefore simplified the procedure employed to locate the 4082 next layer protocol in this document, so that we treat ESP and AH as 4083 next layer protocols. As a result, the notion of an encrypted next 4084 layer protocol field has vanished, and there is also no need to worry 4085 about encrypted port fields either. And accordingly, OPAQUE will be 4086 applicable only to non-initial fragments. 4088 Since we have adopted the definitions above for ANY and OPAQUE, we 4089 need to clarify how these values work when the specified protocol 4090 does not have port fields, and when ANY is used for the protocol 4091 selector. Accordingly, if a specific protocol value is used as a 4092 selector, and if that protocol has no port fields, then the port 4093 field selectors are to be ignored and ANY MUST be specified as the 4094 value for the port fields. (In this context, ICMP TYPE and CODE 4095 values are lumped together as a single port field (for IKE v2 4096 negotiation), as is the IPv6 Mobility Header TYPE value.) If the 4097 protocol selector is ANY, then this should be treated as equivalent 4098 to specifying a protocol for which no port fields are defined, and 4099 thus the port selectors should be ignored, and MUST be set to ANY. 4101 D.3. The Problem of Non-Initial Fragments 4103 For an SG implementation, it is obvious that fragments might arrive 4104 from end systems behind the SG. A BITW implementation also may 4105 encounter fragments from a host or gateway behind it. (As noted 4106 earlier, native host implementations and BITS implementations 4107 probably can avoid the problems described below.) In the worst case, 4108 fragments from a packet might arrive at distinct BITW or SG 4109 instantiations and thus preclude reassembly as a solution option. 4110 Hence, in RFC 2401 we adopted a general requirement that fragments 4111 must be accommodated in tunnel mode for all implementations. However, 4112 RFC 2401 did not provide a perfect solution. The use of OPAQUE as a 4113 selector value for port fields (a SHOULD in RFC 2401) allowed an SA 4114 to carry non-initial fragments. 4116 Using the features defined in RFC 2401, if one defined an SA between 4117 two IPsec (SG or BITW) implementations using the OPAQUE value for 4118 both port fields, then all non-initial fragments matching the S/D 4119 address and protocol values for the SA would be mapped to that SA. 4120 Initial fragments would NOT map to this SA, if we adopt a strict 4121 definition of OPAQUE. However, RFC 2401 did not provide detailed 4122 guidance on this and thus it may not have been apparent that use of 4123 this feature would essentially create a "non-initial fragment only" 4124 SA. 4126 In the course of discussing the "fragment-only" SA approach, it was 4127 noted that some subtle problems, problems not considered in RFC 2401, 4128 would have to be avoided. For example, an SA of this sort must be 4129 configured to offer the "highest quality" security services for any 4130 traffic between the indicated S/D addresses (for the specified 4131 protocol). This is necessary to ensure that any traffic captured by 4132 the fragment-only SA is not offered degraded security relative to 4133 what it would have been offered if the packet were not fragmented. A 4134 possible problem here is that we may not be able to identify the 4135 "highest quality" security services defined for use between two IPsec 4136 implementation, since the choice of security protocols, options, and 4137 algorithms is a lattice, not a totally ordered set. (We might safely 4138 say that BYPASS < AH < ESP w/integrity, but it gets complicated if we 4139 have multiple ESP encryption or integrity algorithm options.) So, one 4140 has to impose a total ordering on these security parameters to make 4141 this work, but this can be done locally. 4143 However, this conservative strategy has a possible performance down 4144 side; if most traffic traversing an IPsec implementation for a given 4145 S/D address pair (and specified protocol) is bypassed, then a 4146 fragment-only SA for that address pair might cause a dramatic 4147 increase in the volume of traffic afforded crypto processing. If the 4148 crypto implementation cannot support high traffic rates, this could 4149 cause problems. (An IPsec implementation that is capable of line rate 4150 or near line rate crypto performance would not be adversely affected 4151 by this SA configuration approach. Nonetheless, the performance 4152 impact is a potential concern, specific to implementation 4153 capabilities.) 4155 Another concern is that non-initial fragments sent over a dedicated 4156 SA might be used to effect overlapping reassembly attacks, when 4157 combined with an apparently acceptable initial fragment. (This sort 4158 of attack assumes creation of bogus fragments, and is not a side 4159 effect of normal fragmentation.) This concern is easily addressed in 4160 IPv4, by checking the fragment offset value to ensure that no 4161 non-initial fragments have a small enough offset to overlap port 4162 fields that should be contained in the initial fragment. Recall that 4163 the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 4164 bytes, so any ports should be present in the initial fragment. If we 4165 require all non-initial fragments to have an offset of say 128 or 4166 greater, just to be on the safe side, this should prevent successful 4167 attacks of this sort. If the intent is only to protect against this 4168 sort of reassembly attack, this check need be implemented only by a 4169 receiver. 4171 IPv6 also has a fragment offset, carried in the fragmentation 4172 extension header. However, IPv6 extension headers are variable in 4173 length and there is no analogous max header length value that we can 4174 use to check non-initial fragments, to reject ones that might be used 4175 for an attack of the sort noted above. A receiver would need to 4176 maintain state analogous to reassembly state, to provide equivalent 4177 protection. So, only for IPv4 it is feasible to impose a fragment 4178 offset check that would reject attacks designed to circumvent port 4179 field checks by IPsec (or firewalls) when passing non-initial 4180 fragments. 4182 Another possible concern is that in some topologies and SPD 4183 configurations this approach might result in an access control 4184 surprise. The notion is that if we create an SA to carry ALL 4185 (non-initial) fragments then that SA would carry some traffic that 4186 might otherwise arrive as plaintext via a separate path, e.g., a path 4187 monitored by a proxy firewall. But, this concern arises only if the 4188 other path allows initial fragments to traverse it without requiring 4189 reassembly, presumably a bad idea for a proxy firewall. Nonetheless, 4190 this does represent a potential problem in some topologies and under 4191 certain assumptions re: SPD and (other) firewall rule sets, and 4192 administrators need to be warned of this possibility. 4194 A less serious concern is that non-initial fragments sent over a 4195 non-initial fragment-only SA might represent a DoS opportunity, in 4196 that they could be sent when no valid, initial fragment will ever 4197 arrive. This might be used to attack hosts behind an SG or BITW 4198 device. However, the incremental risk posed by this sort of attack, 4199 which can be mounted only by hosts behind an SG or BITW device, seems 4200 small. 4202 If we interpret the ANY selector value as encompassing OPAQUE, then a 4203 single SA with ANY values for both port fields would be able to 4204 accommodate all traffic matching the S/D address and protocol traffic 4205 selectors, an alternative to using the OPAQUE value. But, using ANY 4206 here precludes multiple, distinct SAs between the same IPsec 4207 implementations for the same address pairs and protocol. So, it is 4208 not an exactly equivalent alternative. 4210 Fundamentally, fragment handling problems arise only when more than 4211 one SA is defined with the same S/D address and protocol selector 4212 values, but with different port field selector values. 4214 D.4 BYPASS/DISCARD Traffic 4216 We also have to address the non-initial fragment processing issue for 4217 BYPASS/DISCARD entries, independent of SA processing. This is largely 4218 a local matter for two reasons: 4219 1) We have no means for coordinating SPD entries for such 4220 traffic between IPsec implementations since IKE is not 4221 invoked. 4222 2) Many of these entries refer to traffic that is NOT 4223 directed to or received from a location that is using 4224 IPsec. So there is no peer IPsec implementation with 4225 which to coordinate via any means. 4227 However, this document should provide guidance here, consistent with 4228 our goal of offering a well-defined, access control function for all 4229 traffic, relative to the IPsec boundary. To that end, this document 4230 says that implementations MUST support fragment reassembly for 4231 BYPASS/DISCARD traffic when port fields are specified. An 4232 implementation also MUST permit a user or administrator to accept 4233 such traffic or reject such traffic using the SPD conventions 4234 described in Secion 4.4.1. The concern is that BYPASS of a 4235 cleartext, non-initial fragment arriving at an IPsec implementation 4236 could undermine the security afforded IPsec-protected traffic 4237 directed to the same destination. For example, consider an IPsec 4238 implementation configured with an SPD entry that calls for 4239 IPsec-protection of traffic between a specific source/destination 4240 address pair, and for a specific protocol and destination port, e.g., 4241 TCP traffic on port 23 (Telnet). Assume that the implementation also 4242 allows BYPASS of traffic from the same source/destination address 4243 pair and protocol, but for a different destination port, e.g., port 4244 119 (NNTP). An attacker could send a non-initial fragment (with a 4245 forged source address) that, if bypassed, could overlap with 4246 IPsec-protected traffic from the same source and thus violate the 4247 integrity of the IPsec-protected traffic. Requiring stateful fragment 4248 checking for BYPASS entries with non-trivial port ranges prevents 4249 attacks of this sort. 4251 D.5 Just say no to ports? 4253 It has been suggested that we could avoid the problems described 4254 above by not allowing port field selectors to be used in tunnel mode. 4255 But the discussion above shows this to be an unnecessarily stringent 4256 approach, i.e., since no problems arise for the native OS and BITS 4257 implementations. Moreover, some WG members have described scenarios 4258 where use of tunnel mode SAs with (non-trivial) port field selectors 4259 is appropriate. So the challenge is defining a strategy that can deal 4260 with this problem in BITW and SG contexts. Also note that 4261 BYPASS/DISCARD entries in the SPD that make use of ports pose the 4262 same problems, irrespective of tunnel vs. transport mode notions. 4264 Some folks have suggested that a firewall behind an SG or BITW should 4265 be left to enforce port level access controls, and the effects of 4266 fragmentation. However, this seems to be an incongruous suggestion in 4267 that elsewhere in IPsec (e.g., in IKE payloads) we are concerned 4268 about firewalls that always discard fragments. If many firewalls 4269 don't pass fragments in general, why should we expect them to deal 4270 with fragments in this case? So, this analysis rejects the suggestion 4271 of disallowing use of port field selectors with tunnel mode SAs. 4273 D.6 Other Suggested Solutions 4275 One suggestion is to reassemble fragments at the sending IPsec 4276 implementation, and thus avoid the problem entirely. This approach is 4277 invisible to a receiver and thus could be adopted as a purely local 4278 implementation option. 4280 A more sophisticated version of this suggestion calls for 4281 establishing and maintaining minimal state from each initial fragment 4282 encountered, to allow non-initial fragments to be matched to the 4283 right SAs or SPD/cache entries. This implies an extension to the 4284 current processing model (and the old one). The IPsec implementation 4285 would intercept all fragments, capture Source/Destination IP 4286 addresses, protocol, packet ID, and port fields from initial 4287 fragments and then use this data to map non-initial fragments to SAs 4288 that require port fields. If this approach is employed, the receiver 4289 needs to employ an equivalent scheme, as it too must verify that 4290 received fragments are consistent with SA selector values. A 4291 non-initial fragment that arrives prior to an initial fragment could 4292 be cached or discarded, awaiting arrival of the corresponding initial 4293 fragment. 4295 A downside of both approaches noted above is that they will not 4296 always work. When a BITW device or SG is configured in a topology 4297 that might allow some fragments for a packet to be processed at 4298 different SGs or BITW devices, then there is no guarantee that all 4299 fragments will ever arrive at the same IPsec device. This approach 4300 also raises possible processing problems. If the sender caches 4301 non-initial fragments until the corresponding initial fragment 4302 arrives, buffering problems might arise, especially at high speeds. 4303 If the non-initial fragments are discarded rather than cached, there 4304 is no guarantee that traffic will ever pass, e.g., retransmission 4305 will result in different packet IDs that cannot be matched with prior 4306 transmissions. In any case, housekeeping procedures will be needed to 4307 decide when to delete the fragment state data, adding some complexity 4308 to the system. Nonetheless, this is a viable solution in some 4309 topologies, and these are likely to be common topologies. 4311 The Working Group rejected an earlier version of the convention of 4312 creating an SA to carry only non-initial fragments, something that 4313 was supported implicitly under the RFC 2401 model via use of OPAQUE 4314 port fields, but never clearly articulated in RFC 2401. The 4315 (rejected) text called for each non-initial fragment to be treated as 4316 protocol 44 (the IPv6 fragment header protocol ID) by the sender and 4317 receiver. This approach has the potential to make IPv4 and IPv6 4318 fragment handling more uniform, but it does not fundamentally change 4319 the problem, nor does it address the issue of fragment handling for 4320 BYPASS/DISCARD traffic. Given the fragment overlap attack problem 4321 that IPv6 poses, it does not seem that it is worth the effort to 4322 adopt this strategy. 4324 D.7 Consistency 4326 Earlier the WG agreed to allow an IPsec BITS, BITW or SG to perform 4327 fragmentation prior to IPsec processing. If this fragmentation is 4328 performed after SA lookup at the sender, there is no "mapping to the 4329 right SA" problem. But, the receiver still needs to be able to verify 4330 that the non-initial fragments are consistent with the SA via which 4331 they are received. Since the initial fragment might be lost en route, 4332 the receiver encounters all of the potential problems noted above. 4333 Thus, if we are to be consistent in our decisions, we need to say how 4334 a receiver will deal with the non-initial fragments that arrive. 4336 D.8 Conclusions 4338 There is no simple, uniform way to handle fragments in all contexts. 4339 Different approaches work better in different contexts. Thus this 4340 document offers 3 choices -- one MUST and two MAYs. At some point in 4341 the future, if the community gains experience with the two MAYs, they 4342 may become SHOULDs or MUSTs or other approaches may be proposed. 4344 Appendix E - Example of Supporting Nested SAs via SPD and Forwarding 4345 Table Entries 4347 This appendix provides an example of how to configure the SPD and 4348 forwarding tables to support a nested pair of SAs, consistent with 4349 the new processing model. For simplicity, this example assumes just 4350 one SPD-I. 4352 The goal in this example is to support a transport mode SA from A to 4353 C, carried over a tunnel mode SA from A to B. For example, A might be 4354 a laptop connected to the public internet, B a firewall that protects 4355 a corporate network, and C a server on the corporate network that 4356 demands end-to-end authentication of A's traffic. 4358 +---+ +---+ +---+ 4359 | A |=====| B | | C | 4360 | |------------| | 4361 | |=====| | | | 4362 +---+ +---+ +---+ 4364 A's SPD contains entries of the form: 4366 Next Layer 4367 Rule Local Remote Protocol Action 4368 ---- ----- ------ ---------- ----------------------- 4369 1 C A ESP BYPASS 4370 2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf) 4371 3 A C ANY PROTECT(ESP,transport,integr-only) 4372 4 A B ICMP,IKE BYPASS 4374 A's unprotected-side forwarding table is set so that outbound packets 4375 destined for C are looped back to the protected side. A's protected 4376 side forwarding table is set so that inbound ESP packets are looped 4377 back to the unprotected side. A's forwarding tables contain entries 4378 of the form: 4380 Unprotected-side forwarding table 4382 Rule Local Remote Protocol Action 4383 ---- ----- ------ -------- --------------------------- 4384 1 A C ANY loop back to protected side 4385 2 A B ANY forward to B 4387 Protected-side forwarding table 4389 Rule Local Remote Protocol Action 4390 ---- ----- ------ -------- ----------------------------- 4391 1 A C ESP loop back to unprotected side 4393 An outbound TCP packet from A to C would match SPD rule 3 and have 4394 transport mode ESP applied to it. The unprotected-side forwarding 4395 table would then loop back the packet. The packet is compared against 4396 SPD-I (see Figure 2), matches SPD rule 1, and so it is BYPASSed. The 4397 packet is treated as an outbound packet and compared against the SPD 4398 for a third time. This time it matches SPD rule 2, so ESP is applied 4399 in tunnel mode. This time the forwarding table doesn't loop back the 4400 packet, because the outer destination address is B, so the packet 4401 goes out onto the wire. 4403 An inbound TCP packet from C to A, is wrapped in two ESP headers; the 4404 outer header (ESP in tunnel mode) shows B as the source whereas the 4405 inner header (ESP transport mode) shows C as the source. Upon arrival 4406 at A, the packet would be mapped to an SA based on the SPI, have the 4407 outer header removed, and be decrypted and integrity-checked. Then it 4408 would be matched against the SAD selectors for this SA, which would 4409 specify C as the source and A as the destination, derived from SPD 4410 rule 2. The protected-side forwarding function would then send it 4411 back to the unprotected side based on the addresses and the next 4412 layer protocol (ESP), indicative of nesting. It is compared against 4413 SPD-O (see figure 3) and found to match SPD rule 1, so it is 4414 BYPASSed. The packet is mapped to an SA based on the SPI, 4415 integrity-checked, and compared against the SAD selectors derived 4416 from SPD rule 3. The forwarding function then passes it up to the 4417 next layer, because it isn't an ESP packet. 4419 References 4421 Normative 4423 [BBCDWW98]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 4424 and W. Weiss, "An Architecture for Differentiated Service", 4425 RFC 2475, December 1998. 4427 [Bra97] Bradner, S., "Key words for use in RFCs to Indicate 4428 Requirement Level", BCP 14, RFC 2119, March 1997. 4430 [CD98] Conta, A. and S. Deering, "Internet Control Message 4431 Protocol (ICMPv6) for the Internet Protocol Version 6 4432 (IPv6) Specification", RFC 2463, December 1998. 4434 [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 4435 (IPv6) Specification", RFC 2460, December 1998. 4437 [Eas05] Eastlake, D., "Cryptographic Algorithm Implementation 4438 Requirements For ESP And AH", ???, ???? 200?. 4440 [RFC Editor: Please update reference [Eas05] "Cryptographic 4441 Algorithm Implementation Requirements For ESP And AH" 4442 (draft-ietf-ipsec-esp-ah-algorithms-02.txt) with the RFC 4443 number and month and year when it is issued.] 4445 [HarCar98]Harkins, D., and Carrel, D., "The Internet Key Exchange 4446 (IKE)", RFC 2409, November 1998. 4448 [Kau05] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", 4449 RFC ???, ???? 200?. 4451 [RFC Editor: Please update the reference [Kau05] "The 4452 Internet Key Exchange (IKEv2) Protocol" 4453 (draft-ietf-ipsec-ikev2-17.txt) with the RFC number and 4454 month and year when it is issued.] 4456 [Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4457 ???, ???? 200?. 4459 [RFC Editor: Please update the reference [Ken05a] "IP 4460 Encapsulating Security Payload (ESP)" 4461 (draft-ietf-ipsec-esp-v3-09.txt) with the RFC number and 4462 month and year when it is issued.] 4464 [Ken05b] Kent, S., "IP Authentication Header", RFC ???, ??? 200?. 4466 [RFC Editor: Please update the reference [Ken05b] "IP 4467 Authentication Header" (draft-ietf-ipsec-rfc2402bis-09.txt) 4468 with the RFC number and month and year when it is issued.] 4470 [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 4471 November 1990. 4473 [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 4474 1981 4476 [Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, 4477 September 1981 4479 [Sch05] Schiller, J., "Cryptographic Algorithms for use in the 4480 Internet Key Exchange Version 2", RFC ???, ???? 200? 4482 [RFC Editor: Please update the reference [Sch05] 4483 "Cryptographic Algorithms for use in the Internet Key 4484 Exchange Version 2" 4485 (draft-ietf-ipsec-ikev2-algorithms-05.txt) with the RFC 4486 number and month and year when it is issued.] 4488 [WaKiHo97]Wahl, M., Kille, S., Howes, T., "Lightweight Directory 4489 Access Protocol (v3): UTF-8 String Representation of 4490 Distinguished Names", RFC 2253, December 1997 4492 Informative 4494 [CoSa04] Condell, M., and Sanchez, L. On the Deterministic 4495 Enforcement of Un-ordered Security Policies", BBN Technical 4496 Memo 1346, March 2004 4498 [FaLiHaMeTr00]Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, 4499 P., "Generic Routing Encapsulation (GRE), RFC 2784, March 4500 2000. 4502 [Gro02] Grossman, D., "New Terminology and Clarifications for 4503 Diffserv", RFC 3260, April 2002. 4504 [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for 4505 IP", WWork in Progress, November 3, 2002. 4507 [HA94] Haller, N., and Atkinson, R., "On Internet Authentication", 4508 RFC 1704, October 1994 4510 [Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 4511 IPv6", RFC 3775, June 2004 4513 [NiBlBaBL98]Nichols, K., Blake, S., Baker, F., Black, D., "Definition 4514 of the Differentiated Services Field (DS Field) in the IPv4 4515 and IPv6 Headers", RFC2474, December 1998. 4517 [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 4518 October 1996. 4520 [RaFlBl01]Ramakrishnan, K., Floyd, S., Black, D., "The Addition of 4521 Explicit Congestion Notification (ECN) to IP", RFC 3168, 4522 September 2001. 4524 [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group 4525 Domain of Interpretation", RFC 3547, July 2003. 4527 [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security 4528 Architecture", RFC 3740, March 2004. 4530 [RaCoCaDe04]Rajahalme, J., Conta, A., Carpenter, B., Deering, S., 4531 "IPv6 Flow Label Specification, RFC 3697, March 2004. 4533 [Sch94] Schneier, B., Applied Cryptography, Section 8.6, John 4534 Wiley & Sons, New York, NY, 1994. 4536 [Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May 4537 2000. 4539 [SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP 4540 Payload Compression Protocol (IPComp)", RFC 3173, September 4541 2001. 4543 [ToEgWa04]Touch, J., Eggert, L., Wang, Y., Use of IPsec Transport 4544 Mode for Dynamic Routing, RFC 3884, September 2004. 4546 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in 4547 High-level Networks", ACM Computing Surveys, Vol. 15, No. 4548 2, June 1983. 4550 Author Information 4552 Stephen Kent 4553 BBN Technologies 4554 10 Moulton Street 4555 Cambridge, MA 02138 4556 USA 4557 Phone: +1 (617) 873-3988 4558 EMail: kent@bbn.com 4560 Karen Seo 4561 BBN Technologies 4562 10 Moulton Street 4563 Cambridge, MA 02138 4564 USA 4565 Phone: +1 (617) 873-3152 4566 EMail: kseo@bbn.com 4568 Notices 4570 Intellectual Property 4572 The IETF takes no position regarding the validity or scope of any 4573 Intellectual Property Rights or other rights that might be claimed to 4574 pertain to the implementation or use of the technology described in 4575 this document or the extent to which any license under such rights 4576 might or might not be available; nor does it represent that it has 4577 made any independent effort to identify any such rights. Information 4578 on the procedures with respect to rights in RFC documents can be 4579 found in BCP 78 and BCP 79. 4581 Copies of IPR disclosures made to the IETF Secretariat and any 4582 assurances of licenses to be made available, or the result of an 4583 attempt made to obtain a general license or permission for the use of 4584 such proprietary rights by implementers or users of this 4585 specification can be obtained from the IETF on-line IPR repository at 4586 http://www.ietf.org/ipr. 4588 The IETF invites any interested party to bring to its attention any 4589 copyrights, patents or patent applications, or other proprietary 4590 rights that may cover technology that may be required to implement 4591 this standard. Please address the information to the IETF at ietf- 4592 ipr@ietf.org. 4594 Full Copyright Statement 4596 Copyright (C) The Internet Society (2005). This document is subject 4597 to the rights, licenses and restrictions contained in BCP 78, and 4598 except as set forth therein, the authors retain all their rights. 4600 This document and translations of it may be copied and furnished to 4601 others, and derivative works that comment on or otherwise explain it 4602 or assist in its implmentation may be prepared, copied, published and 4603 distributed, in whole or in part, without restriction of any kind, 4604 provided that the above copyright notice and this paragraph are 4605 included on all such copies and derivative works. However, this 4606 document itself may not be modified in any way, such as by removing 4607 the copyright notice or references to the Internet Society or other 4608 Internet organizations, except as needed for the purpose of 4609 developing Internet standards in which case the procedures for 4610 copyrights defined in the Internet Standards process must be 4611 followed, or as required to translate it into languages other than 4612 English. The limited permissions granted above are perpetual and 4613 will not be revoked by the Internet Society or its successors or 4614 assigns. 4616 This document and the information contained herein are provided on an 4617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4619 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4620 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4621 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4624 Expires September 2005