idnits 2.17.1 draft-ietf-ipsec-arch-sec-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 232 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 734 has weird spacing: '...for the examp...' == Line 914 has weird spacing: '...c value speci...' == Line 916 has weird spacing: '...c value speci...' == Line 943 has weird spacing: '...IP addr singl...' == Line 944 has weird spacing: '...IP addr singl...' == (8 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA that can be used. For the receiver, these values are used to check that the selector values in an inbound packet match those for the SA (and thus indirectly those for the matching policy). For the receiver, this is part of verifying that the SA was appropriate for this packet. (See Section 6 for rules for ICMP messages.) These fields can have the form of specific values, ranges, wildcards, or "OPAQUE" as described in section 4.4.2, "Selectors". Note that for an ESP SA, the encryption algorithm or the authentication algorithm could be "NULL". However they MUST not both be "NULL". == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: NOTE: A compliant implementation MUST not allow instantiation of an ESP SA that employs both a NULL encryption and a NULL authentication algorithm. An attempt to negotiate such an SA is an auditable event. -- 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 (July 1998) is 9410 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IP1' is mentioned on line 1166, but not defined == Missing Reference: 'AH' is mentioned on line 1165, but not defined == Missing Reference: 'IP2' is mentioned on line 1166, but not defined == Missing Reference: 'ESP' is mentioned on line 1166, but not defined -- Looks like a reference, but probably isn't: '512' on line 2671 == Missing Reference: 'RFC792' is mentioned on line 2753, but not defined == Missing Reference: 'RFC1812' is mentioned on line 2741, but not defined == Missing Reference: 'RFC1256' is mentioned on line 2729, but not defined == Missing Reference: 'RFC950' is mentioned on line 2754, but not defined == Missing Reference: 'JBP' is mentioned on line 2775, but not defined == Missing Reference: 'RFC1108' is mentioned on line 2749, but not defined == Missing Reference: 'RFC1393' is mentioned on line 2755, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1475' is mentioned on line 2756, but not defined ** Obsolete undefined reference: RFC 1475 (Obsoleted by RFC 6814) == Missing Reference: 'Johnson' is mentioned on line 2757, but not defined == Missing Reference: 'Markson' is mentioned on line 2758, but not defined == Missing Reference: 'Simpson' is mentioned on line 2774, but not defined == Missing Reference: 'Solo' is mentioned on line 2767, but not defined == Missing Reference: 'ZSu' is mentioned on line 2768, but not defined == Missing Reference: 'RFC 1885' is mentioned on line 2781, but not defined ** Obsolete undefined reference: RFC 1885 (Obsoleted by RFC 2463) == Missing Reference: 'RFC1885' is mentioned on line 2801, but not defined ** Obsolete undefined reference: RFC 1885 (Obsoleted by RFC 2463) -- Possible downref: Non-RFC (?) normative reference: ref. 'BL73' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD85' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD87' ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. 'HA94') -- Possible downref: Non-RFC (?) normative reference: ref. 'HC98' ** Downref: Normative reference to an Experimental RFC: RFC 2094 (ref. 'HM97') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'IBK93' -- Possible downref: Non-RFC (?) normative reference: ref. 'KA98a' -- Possible downref: Non-RFC (?) normative reference: ref. 'KA98b' ** Downref: Normative reference to an Historic RFC: RFC 1108 (ref. 'Ken91') -- Possible downref: Non-RFC (?) normative reference: ref. 'MSST97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Orm97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pip98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPT98' -- Possible downref: Non-RFC (?) normative reference: ref. 'TDG97' -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' Summary: 18 errors (**), 0 flaws (~~), 32 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Stephen Kent, BBN Corp 3 draft-ietf-ipsec-arch-sec-06.txt Randall Atkinson, @Home Network 4 Obsoletes RFC 1825 July 1998 6 Security Architecture for the Internet Protocol 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of 6 months. 16 Internet Drafts may be updated, replaced, or obsoleted by other 17 documents at any time. It is not appropriate to use Internet Drafts 18 as reference material or to cite them other than as "work in 19 progress". Please check the I-D abstract listing contained in each 20 Internet Draft directory to learn the current status of this or any 21 other Internet Draft. 23 This particular Internet Draft is a product of the IETF's IP Security 24 (IPsec) working group. It is intended that a future version of this 25 draft be submitted to the IESG for publication as a Draft Standard 26 RFC. Comments about this draft may be sent to the authors or to the 27 IPsec WG mailing list . Distribution of this document 28 is unlimited. 30 Copyright (C) The Internet Society (July 1998). All Rights Reserved. 32 Table of Contents 34 1. Introduction............................................................4 35 1.1 Summary of Contents of Document.....................................4 36 1.2 Audience............................................................4 37 1.3 Related Documents...................................................5 38 2. Design Objectives.......................................................5 39 2.1 Goals/Objectives/Requirements/Problem Description...................5 40 2.2 Caveats and Assumptions.............................................6 41 3. System Overview ........................................................6 42 3.1 What IPsec Does.....................................................7 43 3.2 How IPsec Works.....................................................7 44 3.3 Where IPsec May Be Implemented......................................8 45 4. Security Associations...................................................9 46 4.1 Definition and Scope................................................9 47 4.2 Security Association Functionality.................................11 48 4.3 Combining Security Associations....................................12 49 4.4 Security Association Databases.....................................14 50 4.4.1 The Security Policy Database (SPD)............................15 51 4.4.2 Selectors.....................................................18 52 4.4.3 Security Association Database (SAD)...........................22 53 4.5 Basic Combinations of Security Associations........................25 54 4.6 SA and Key Management..............................................28 55 4.6.1 Manual Techniques.............................................28 56 4.6.2 Automated SA and Key Management...............................29 57 4.6.3 Locating a Security Gateway...................................29 58 4.7 Security Associations and Multicast................................30 59 5. IP Traffic Processing..................................................31 60 5.1 Outbound IP Traffic Processing.....................................31 61 5.1.1 Selecting and Using an SA or SA Bundle........................31 62 5.1.2 Header Construction for Tunnel Mode...........................32 63 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..............33 64 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..............34 65 5.2 Processing Inbound IP Traffic......................................34 66 5.2.1 Selecting and Using an SA or SA Bundle........................35 67 5.2.2 Handling of AH and ESP tunnels................................36 68 6. ICMP Processing (relevant to IPsec)....................................36 69 6.1 PMTU/DF Processing.................................................37 70 6.1.1 DF Bit........................................................37 71 6.1.2 Path MTU Discovery (PMTU).....................................37 72 6.1.2.1 Propagation of PMTU......................................38 73 6.1.2.2 Calculation of PMTU......................................38 74 6.1.2.3 Granularity of PMTU Processing...........................39 75 6.1.2.4 PMTU Aging...............................................39 76 7. Auditing...............................................................40 77 8. Use in Systems Supporting Information Flow Security....................40 78 8.1 Relationship Between Security Associations and Data Sensitivity....41 79 8.2 Sensitivity Consistency Checking...................................42 80 8.3 Additional MLS Attributes for Security Association Databases.......42 81 8.4 Additional Inbound Processing Steps for MLS Networking.............42 82 8.5 Additional Outbound Processing Steps for MLS Networking............43 83 8.6 Additional MLS Processing for Security Gateways....................43 84 9. Performance Issues.....................................................43 85 10. Conformance Requirements..............................................44 86 11. Security Considerations...............................................44 87 12. Differences from RFC 1825.............................................45 88 Acknowledgements..........................................................45 89 Appendix A -- Glossary....................................................46 90 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.........49 91 B.1 DF bit.............................................................49 92 B.2 Fragmentation......................................................49 93 B.3 Path MTU Discovery.................................................53 94 B.3.1 Identifying the Originating Host(s)...........................54 95 B.3.2 Calculation of PMTU...........................................56 96 B.3.3 Granularity of Maintaining PMTU Data..........................57 97 B.3.4 Per Socket Maintenance of PMTU Data...........................58 98 B.3.5 Delivery of PMTU Data to the Transport Layer..................58 99 B.3.6 Aging of PMTU Data............................................58 100 Appendix C -- Sequence Space Window Code Example..........................59 101 Appendix D -- Categorization of ICMP messages.............................61 102 References................................................................64 103 Disclaimer................................................................65 104 Author Information........................................................66 106 1. Introduction 108 1.1 Summary of Contents of Document 110 This memo specifies the base architecture for IPsec compliant 111 systems. The goal of the architecture is to provide various security 112 services for traffic at the IP layer, in both the IPv4 and IPv6 113 environments. This document describes the goals of such systems, 114 their components and how they fit together with each other and into 115 the IP environment. It also describes the security services offered 116 by the IPsec protocols, and how these services can be employed in the 117 IP environment. This document does not address all aspects of IPsec 118 architecture. Subsequent documents will address additional 119 architectural details of a more advanced nature, e.g., use of IPsec 120 in NAT environments and more complete support for IP multicast. The 121 following fundamental components of the IPsec security architecture 122 are discussed in terms of their underlying, required functionality. 123 Additional RFCs (see Section 1.3 for pointers to other documents) 124 define the protocols in (a), (c), and (d). 126 a. Security Protocols -- Authentication Header (AH) and 127 Encapsulating Security Payload (ESP) 128 b. Security Associations -- what they are and how they work, 129 how they are managed, associated processing 130 c. Key Management -- manual and automatic (The Internet Key 131 Exchange (IKE)) 132 d. Algorithms for authentication and encryption 134 This document is not an overall Security Architecture for the 135 Internet; it addresses security only at the IP layer, provided 136 through the use of a combination of cryptographic and protocol 137 security mechanisms. 139 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 140 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 141 document, are to be interpreted as described in RFC 2119 [Bra97]. 143 1.2 Audience 145 The target audience for this document includes implementers of this 146 IP security technology and others interested in gaining a general 147 background understanding of this system. In particular, prospective 148 users of this technology (end users or system administrators) are 149 part of the target audience. A glossary is provided as an appendix 150 to help fill in gaps in background/vocabulary. This document assumes 151 that the reader is familiar with the Internet Protocol, related 152 networking technology, and general security terms and concepts. 154 1.3 Related Documents 156 As mentioned above, other documents provide detailed definitions of 157 some of the components of IPsec and of their inter-relationship. 158 They include RFCs on the following topics: 160 a. "IP Security Document Roadmap" [TDG97] -- a document 161 providing guidelines for specifications describing encryption 162 and authentication algorithms used in this system. 163 b. security protocols -- RFCs describing the Authentication 164 Header (AH) [KA98a] and Encapsulating Security Payload (ESP) 165 [KA98b] protocols. 166 c. algorithms for authentication and encryption -- a separate 167 RFC for each algorithm. 168 d. automatic key management -- RFCs on "The Internet Key 169 Exchange (IKE)" [HC98], "Internet Security Association and 170 Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key 171 Determination Protocol" [Orm97], and "The Internet IP 172 Security Domain of Interpretation for ISAKMP" [Pip98]. 174 2. Design Objectives 176 2.1 Goals/Objectives/Requirements/Problem Description 178 IPsec is designed to provide interoperable, high quality, 179 cryptographically-based security for IPv4 and IPv6. The set of 180 security services offered includes access control, connectionless 181 integrity, data origin authentication, protection against replays (a 182 form of partial sequence integrity), confidentiality (encryption), 183 and limited traffic flow confidentiality. These services are 184 provided at the IP layer, offering protection for IP and/or upper 185 layer protocols. 187 These objectives are met through the use of two traffic security 188 protocols, the Authentication Header (AH) and the Encapsulating 189 Security Payload (ESP), and through the use of cryptographic key 190 management procedures and protocols. The set of IPsec protocols 191 employed in any context, and the ways in which they are employed, 192 will be determined by the security and system requirements of users, 193 applications, and/or sites/organizations. 195 When these mechanisms are correctly implemented and deployed, they 196 ought not to adversely affect users, hosts, and other Internet 197 components that do not employ these security mechanisms for 198 protection of their traffic. These mechanisms also are designed to 199 be algorithm-independent. This modularity permits selection of 200 different sets of algorithms without affecting the other parts of the 201 implementation. For example, different user communities may select 202 different sets of algorithms (creating cliques) if required. 204 A standard set of default algorithms is specified to facilitate 205 interoperability in the global Internet. The use of these 206 algorithms, in conjunction with IPsec traffic protection and key 207 management protocols, is intended to permit system and application 208 developers to deploy high quality, Internet layer, cryptographic 209 security technology. 211 2.2 Caveats and Assumptions 213 The suite of IPsec protocols and associated default algorithms are 214 designed to provide high quality security for Internet traffic. 215 However, the security offered by use of these protocols ultimately 216 depends on the quality of the their implementation, which is outside 217 the scope of this set of standards. Moreover, the security of a 218 computer system or network is a function of many factors, including 219 personnel, physical, procedural, compromising emanations, and 220 computer security practices. Thus IPsec is only one part of an 221 overall system security architecture. 223 Finally, the security afforded by the use of IPsec is critically 224 dependent on many aspects of the operating environment in which the 225 IPsec implementation executes. For example, defects in OS security, 226 poor quality of random number sources, sloppy system management 227 protocols and practices, etc. can all degrade the security provided 228 by IPsec. As above, none of these environmental attributes are 229 within the scope of this or other IPsec standards. 231 3. System Overview 233 This section provides a high level description of how IPsec works, 234 the components of the system, and how they fit together to provide 235 the security services noted above. The goal of this description is 236 to enable the reader to "picture" the overall process/system, see how 237 it fits into the IP environment, and to provide context for later 238 sections of this document, which describe each of the components in 239 more detail. 241 An IPsec implementation operates in a host or a security gateway 242 environment, affording protection to IP traffic. The protection 243 offered is based on requirements defined by a Security Policy 244 Database (SPD) established and maintained by a user or system 245 administrator, or by an application operating within constraints 246 established by either of the above. In general, packets are selected 247 for one of three processing modes based on IP and transport layer 248 header information (Selectors, Section 4.4.2) matched against entries 249 in the database (SPD). Each packet is either afforded IPsec security 250 services, discarded, or allowed to bypass IPsec, based on the 251 applicable database policies identified by the Selectors. 253 3.1 What IPsec Does 255 IPsec provides security services at the IP layer by enabling a system 256 to select required security protocols, determine the algorithm(s) to 257 use for the service(s), and put in place any cryptographic keys 258 required to provide the requested services. IPsec can be used to 259 protect one or more "paths" between a pair of hosts, between a pair 260 of security gateways, or between a security gateway and a host. (The 261 term "security gateway" is used throughout the IPsec documents to 262 refer to an intermediate system that implements IPsec protocols. For 263 example, a router or a firewall implementing IPsec is a security 264 gateway.) 266 The set of security services that IPsec can provide includes access 267 control, connectionless integrity, data origin authentication, 268 rejection of replayed packets (a form of partial sequence integrity), 269 confidentiality (encryption), and limited traffic flow 270 confidentiality. Because these services are provided at the IP 271 layer, they can be used by any higher layer protocol, e.g., TCP, UDP, 272 ICMP, BGP, etc. 274 The IPsec DOI also supports negotiation of IP compression [SMPT98], 275 motivated in part by the observation that when encryption is employed 276 within IPsec, it prevents effective compression by lower protocol 277 layers. 279 3.2 How IPsec Works 281 IPsec uses two protocols to provide traffic security -- 282 Authentication Header (AH) and Encapsulating Security Payload (ESP). 283 Both protocols are described in more detail in their respective RFCs 284 [KA98a, KA98b]. 286 o The IP Authentication Header (AH) [KA98a] provides 287 connectionless integrity, data origin authentication, and an 288 optional anti-replay service. 289 o The Encapsulating Security Payload (ESP) protocol [KA98b] may 290 provide confidentiality (encryption), and limited traffic flow 291 confidentiality. It also may provide connectionless 292 integrity, data origin authentication, and an anti-replay 293 service. (One or the other set of these security services 294 must be applied whenever ESP is invoked.) 295 o Both AH and ESP are vehicles for access control, based on 296 the distribution of cryptographic keys and the management of 297 traffic flows relative to these security protocols. 299 These protocols may be applied alone or in combination with each 300 other to provide a desired set of security services in IPv4 and IPv6. 301 Each protocol supports two modes of use: transport mode and tunnel 302 mode. In transport mode the protocols provide protection primarily 303 for upper layer protocols; in tunnel mode, the protocols are applied 304 to tunneled IP packets. The differences between the two modes are 305 discussed in Section 4. 307 IPsec allows the user (or system administrator) to control the 308 granularity at which a security service is offered. For example, one 309 can create a single encrypted tunnel to carry all the traffic between 310 two security gateways or a separate encrypted tunnel can be created 311 for each TCP connection between each pair of hosts communicating 312 across these gateways. IPsec management must incorporate facilities 313 for specifying: 315 o which security services to use and in what combinations 316 o the granularity at which a given security protection should be 317 applied 318 o the algorithms used to effect cryptographic-based security 320 Because these security services use shared secret values 321 (cryptographic keys), IPsec relies on a separate set of mechanisms 322 for putting these keys in place. (The keys are used for 323 authentication/integrity and encryption services.) This document 324 requires support for both manual and automatic distribution of keys. 325 It specifies a specific public-key based approach (IKE -- [MSST97, 326 Orm97, HC98]) for automatic key management, but other automated key 327 distribution techniques MAY be used. For example, KDC-based systems 328 such as Kerberos and other public-key systems such as SKIP could be 329 employed. 331 3.3 Where IPsec May Be Implemented 333 There are several ways in which IPsec may be implemented in a host or 334 in conjunction with a router or firewall (to create a security 335 gateway). Several common examples are provided below: 337 a. Integration of IPsec into the native IP implementation. This 338 requires access to the IP source code and is applicable to 339 both hosts and security gateways. 341 b. "Bump-in-the-stack" (BITS) implementations, where IPsec is 342 implemented "underneath" an existing implementation of an IP 343 protocol stack, between the native IP and the local network 344 drivers. Source code access for the IP stack is not required 345 in this context, making this implementation approach 346 appropriate for use with legacy systems. This approach, when 347 it is adopted, is usually employed in hosts. 349 c. The use of an outboard crypto processor is a common design 350 feature of network security systems used by the military, and 351 of some commercial systems as well. It is sometimes referred 352 to as a "Bump-in-the-wire" (BITW) implementation. Such 353 implementations may be designed to serve either a host or a 354 gateway (or both). Usually the BITW device is IP 355 addressable. When supporting a single host, it may be quite 356 analogous to a BITS implementation, but in supporting a 357 router or firewall, it must operate like a security gateway. 359 4. Security Associations 361 This section defines Security Association management requirements for 362 all IPv6 implementations and for those IPv4 implementations that 363 implement AH, ESP, or both. The concept of a "Security Association" 364 (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a 365 major function of IKE is the establishment and maintenance of 366 Security Associations. All implementations of AH or ESP MUST support 367 the concept of a Security Association as described below. The 368 remainder of this section describes various aspects of Security 369 Association management, defining required characteristics for SA 370 policy management, traffic processing, and SA management techniques. 372 4.1 Definition and Scope 374 A Security Association (SA) is a simplex "connection" that affords 375 security services to the traffic carried by it. Security services 376 are afforded to an SA by the use of AH, or ESP, but not both. If 377 both AH and ESP protection is applied to a traffic stream, then two 378 (or more) SAs are created to afford protection to the traffic stream. 379 To secure typical, bi-directional communication between two hosts, or 380 between two security gateways, two Security Associations (one in each 381 direction) are required. 383 A security association is uniquely identified by a triple consisting 384 of a Security Parameter Index (SPI), an IP Destination Address, and a 385 security protocol (AH or ESP) identifier. In principle, the 386 Destination Address may be a unicast address, an IP broadcast 387 address, or a multicast group address. However, IPsec SA management 388 mechanisms currently are defined only for unicast SAs. Hence, in the 389 discussions that follow, SAs will be described in the context of 390 point-to-point communication, even though the concept is applicable 391 in the point-to-multipoint case as well. 393 As noted above, two types of SAs are defined: transport mode and 394 tunnel mode. A transport mode SA is a security association between 395 two hosts. In IPv4, a transport mode security protocol header 396 appears immediately after the IP header and any options, and before 397 any higher layer protocols (e.g., TCP or UDP). In IPv6, the security 398 protocol header appears after the base IP header and extensions, but 399 may appear before or after destination options, and before higher 400 layer protocols. In the case of ESP, a transport mode SA provides 401 security services only for these higher layer protocols, not for the 402 IP header or any extension headers preceding the ESP header. In the 403 case of AH, the protection is also extended to selected portions of 404 the IP header, selected portions of extension headers, and selected 405 options (contained in the IPv4 header, IPv6 Hop-by-Hop extension 406 header, or IPv6 Destination extension headers). For more details on 407 the coverage afforded by AH, see the AH specification [KA98a]. 409 A tunnel mode SA is essentially an SA applied to an IP tunnel. 410 Whenever either end of a security association is a security gateway, 411 the SA MUST be tunnel mode. Thus an SA between two security gateways 412 is always a tunnel mode SA, as is an SA between a host and a security 413 gateway. Note that for the case where traffic is destined for a 414 security gateway, e.g., SNMP commands, the security gateway is acting 415 as a host and transport mode is allowed. But in that case, the 416 security gateway is not acting as a gateway, i.e., not transiting 417 traffic. Two hosts MAY establish a tunnel mode SA between 418 themselves. The requirement for any (transit traffic) SA involving a 419 security gateway to be a tunnel SA arises due to the need to avoid 420 potential problems with regard to fragmentation and reassembly of 421 IPsec packets, and in circumstances where multiple paths (e.g., via 422 different security gateways) exist to the same destination behind the 423 security gateways. 425 For a tunnel mode SA, there is an "outer" IP header that specifies 426 the IPsec processing destination, plus an "inner" IP header that 427 specifies the (apparently) ultimate destination for the packet. The 428 security protocol header appears after the outer IP header, and 429 before the inner IP header. If AH is employed in tunnel mode, 430 portions of the outer IP header are afforded protection (as above), 431 as well as all of the tunneled IP packet (i.e., all of the inner IP 432 header is protected, as well as higher layer protocols). If ESP is 433 employed, the protection is afforded only to the tunneled packet, not 434 to the outer header. 436 In summary, 437 a) A host MUST support both transport and tunnel mode. 438 b) A security gateway is required to support only tunnel 439 mode. If it supports transport mode, that should be 440 used only when the security gateway is acting as a 441 host, e.g., for network management. 443 4.2 Security Association Functionality 445 The set of security services offered by an SA depends on the security 446 protocol selected, the SA mode, the endpoints of the SA, and on the 447 election of optional services within the protocol. For example, AH 448 provides data origin authentication and connectionless integrity for 449 IP datagrams (hereafter referred to as just "authentication"). The 450 "precision" of the authentication service is a function of the 451 granularity of the security association with which AH is employed, as 452 discussed in Section 4.4.2, "Selectors". 454 AH also offers an anti-replay (partial sequence integrity) service at 455 the discretion of the receiver, to help counter denial of service 456 attacks. AH is an appropriate protocol to employ when 457 confidentiality is not required (or is not permitted, e.g , due to 458 government restrictions on use of encryption). AH also provides 459 authentication for selected portions of the IP header, which may be 460 necessary in some contexts. For example, if the integrity of an IPv4 461 option or IPv6 extension header must be protected en route between 462 sender and receiver, AH can provide this service (except for the 463 non-predictable but mutable parts of the IP header.) 465 ESP optionally provides confidentiality for traffic. (The strength 466 of the confidentiality service depends in part, on the encryption 467 algorithm employed.) ESP also may optionally provide authentication 468 (as defined above). If authentication is negotiated for an ESP SA, 469 the receiver also may elect to enforce an anti-replay service with 470 the same features as the AH anti-replay service. The scope of the 471 authentication offered by ESP is narrower than for AH, i.e., the IP 472 header(s) "outside" the ESP header is(are) not protected. If only 473 the upper layer protocols need to be authenticated, then ESP 474 authentication is an appropriate choice and is more space efficient 475 than use of AH encapsulating ESP. Note that although both 476 confidentiality and authentication are optional, they cannot both be 477 omitted. At least one of them MUST be selected. 479 If confidentiality service is selected, then an ESP (tunnel mode) SA 480 between two security gateways can offer partial traffic flow 481 confidentiality. The use of tunnel mode allows the inner IP headers 482 to be encrypted, concealing the identities of the (ultimate) traffic 483 source and destination. Moreover, ESP payload padding also can be 484 invoked to hide the size of the packets, further concealing the 485 external characteristics of the traffic. Similar traffic flow 486 confidentiality services may be offered when a mobile user is 487 assigned a dynamic IP address in a dialup context, and establishes a 488 (tunnel mode) ESP SA to a corporate firewall (acting as a security 489 gateway). Note that fine granularity SAs generally are more 490 vulnerable to traffic analysis than coarse granularity ones which are 491 carrying traffic from many subscribers. 493 4.3 Combining Security Associations 495 The IP datagrams transmitted over an individual SA are afforded 496 protection by exactly one security protocol, either AH or ESP, but 497 not both. Sometimes a security policy may call for a combination of 498 services for a particular traffic flow that is not achievable with a 499 single SA. In such instances it will be necessary to employ multiple 500 SAs to implement the required security policy. The term "security 501 association bundle" or "SA bundle" is applied to a sequence of SAs 502 through which traffic must be processed to satisfy a security policy. 503 The order of the sequence is defined by the policy. (Note that the 504 SAs that comprise a bundle may terminate at different endpoints. For 505 example, one SA may extend between a mobile host and a security 506 gateway and a second, nested SA may extend to a host behind the 507 gateway.) 509 Security associations may be combined into bundles in two ways: 510 transport adjacency and iterated tunneling. 512 o Transport adjacency refers to applying more than one security 513 protocol to the same IP datagram, without invoking tunneling. 514 This approach to combining AH and ESP allows for only one 515 level of combination; further nesting yields no added benefit 516 (assuming use of adequately strong algorithms in each 517 protocol) since the processing is performed at one IPsec 518 instance at the (ultimate) destination. 520 Host 1 --- Security ---- Internet -- Security --- Host 2 521 | | Gwy 1 Gwy 2 | | 522 | | | | 523 | -----Security Association 1 (ESP transport)------- | 524 | | 525 -------Security Association 2 (AH transport)---------- 527 o Iterated tunneling refers to the application of multiple 528 layers of security protocols effected through IP tunneling. 529 This approach allows for multiple levels of nesting, since 530 each tunnel can originate or terminate at a different IPsec 531 site along the path. No special treatment is expected for 532 ISAKMP traffic at intermediate security gateways other than 533 what can be specified through appropriate SPD entries (See 534 Case 3 in Section 4.5) 535 There are 3 basic cases of iterated tunneling -- support is 536 required only for cases 2 and 3.: 538 1. both endpoints for the SAs are the same -- The inner and 539 outer tunnels could each be either AH or ESP, though it is 540 unlikely that Host 1 would specify both to be the same, 541 i.e., AH inside of AH or ESP inside of ESP. 543 Host 1 --- Security ---- Internet -- Security --- Host 2 544 | | Gwy 1 Gwy 2 | | 545 | | | | 546 | -------Security Association 1 (tunnel)---------- | | 547 | | 548 ---------Security Association 2 (tunnel)-------------- 550 2. one endpoint of the SAs is the same -- The inner and 551 outer tunnels could each be either AH or ESP. 553 Host 1 --- Security ---- Internet -- Security --- Host 2 554 | | Gwy 1 Gwy 2 | 555 | | | | 556 | ----Security Association 1 (tunnel)---- | 557 | | 558 ---------Security Association 2 (tunnel)------------- 560 3. neither endpoint is the same -- The inner and outer tunnels 561 could each be either AH or ESP. 563 Host 1 --- Security ---- Internet -- Security --- Host 2 564 | Gwy 1 Gwy 2 | 565 | | | | 566 | --Security Assoc 1 (tunnel)- | 567 | | 568 -----------Security Association 2 (tunnel)----------- 570 These two approaches also can be combined, e.g., an SA bundle could 571 be constructed from one tunnel mode SA and one or two transport mode 572 SAs, applied in sequence. (See Section 4.5 "Basic Combinations of 573 Security Associations.") Note that nested tunnels can also occur 574 where neither the source nor the destination endpoints of any of the 575 tunnels are the same. In that case, there would be no host or 576 security gateway with a bundle corresponding to the nested tunnels. 578 For transport mode SAs, only one ordering of security protocols seems 579 appropriate. AH is applied to both the upper layer protocols and 580 (parts of) the IP header. Thus if AH is used in a transport mode, in 581 conjunction with ESP, AH SHOULD appear as the first header after IP, 582 prior to the appearance of ESP. In that context, AH is applied to 583 the ciphertext output of ESP. In contrast, for tunnel mode SAs, one 584 can imagine uses for various orderings of AH and ESP. The required 585 set of SA bundle types that MUST be supported by a compliant IPsec 586 implementation is described in Section 4.5. 588 4.4 Security Association Databases 590 Many of the details associated with processing IP traffic in an IPsec 591 implementation are largely a local matter, not subject to 592 standardization. However, some external aspects of the processing 593 must be standardized, to ensure interoperability and to provide a 594 minimum management capability that is essential for productive use of 595 IPsec. This section describes a general model for processing IP 596 traffic relative to security associations, in support of these 597 interoperability and functionality goals. The model described below 598 is nominal; compliant implementations need not match details of this 599 model as presented, but the external behavior of such implementations 600 must be mappable to the externally observable characteristics of this 601 model. 603 There are two nominal databases in this model: the Security Policy 604 Database and the Security Association Database. The former specifies 605 the policies that determine the disposition of all IP traffic inbound 606 or outbound from a host, security gateway, or BITS or BITW IPsec 607 implementation. The latter database contains parameters that are 608 associated with each (active) security association. This section 609 also defines the concept of a Selector, a set of IP and upper layer 610 protocol field values that is used by the Security Policy Database to 611 map traffic to a policy, i.e., an SA (or SA bundle). 613 Each interface for which IPsec is enabled requires nominally separate 614 inbound vs. outbound databases (SAD and SPD), because of the 615 directionality of many of the fields that are used as selectors. 616 Typically there is just one such interface, for a host or security 617 gateway (SG). Note that an SG would always have at least 2 618 interfaces, but the "internal" one to the corporate net, usually 619 would not have IPsec enabled and so only one pair of SADs and one 620 pair of SPDs would be needed. On the other hand, if a host had 621 multiple interfaces or an SG had multiple external interfaces, it 622 might be necessary to have separate SAD and SPD pairs for each 623 interface. 625 4.4.1 The Security Policy Database (SPD) 627 Ultimately, a security association is a management construct used to 628 enforce a security policy in the IPsec environment. Thus an 629 essential element of SA processing is an underlying Security Policy 630 Database (SPD) that specifies what services are to be offered to IP 631 datagrams and in what fashion. The form of the database and its 632 interface are outside the scope of this specification. However, this 633 section does specify certain minimum management functionality that 634 must be provided, to allow a user or system administrator to control 635 how IPsec is applied to traffic transmitted or received by a host or 636 transiting a security gateway. 638 The SPD must be consulted during the processing of all traffic 639 (INBOUND and OUTBOUND), including non-IPsec traffic. In order to 640 support this, the SPD requires distinct entries for inbound and 641 outbound traffic. One can think of this as separate SPDs (inbound 642 vs. outbound). In addition, a nominally separate SPD must be 643 provided for each IPsec-enabled interface. 645 An SPD must discriminate among traffic that is afforded IPsec 646 protection and traffic that is allowed to bypass IPsec. This applies 647 to the IPsec protection to be applied by a sender and to the IPsec 648 protection that must be present at the receiver. For any outbound or 649 inbound datagram, three processing choices are possible: discard, 650 bypass IPsec, or apply IPsec. The first choice refers to traffic 651 that is not allowed to exit the host, traverse the security gateway, 652 or be delivered to an application at all. The second choice refers 653 to traffic that is allowed to pass without additional IPsec 654 protection. The third choice refers to traffic that is afforded 655 IPsec protection, and for such traffic the SPD must specify the 656 security services to be provided, protocols to be employed, 657 algorithms to be used, etc. 659 For every IPsec implementation, there MUST be an administrative 660 interface that allows a user or system administrator to manage the 661 SPD. Specifically, every inbound or outbound packet is subject to 662 processing by IPsec and the SPD must specify what action will be 663 taken in each case. Thus the administrative interface must allow the 664 user (or system administrator) to specify the security processing to 665 be applied to any packet entering or exiting the system, on a packet 666 by packet basis. (In a host IPsec implementation making use of a 667 socket interface, the SPD may not need to be consulted on a per 668 packet basis, but the effect is still the same.) The management 669 interface for the SPD MUST allow creation of entries consistent with 670 the selectors defined in Section 4.4.2, and MUST support (total) 671 ordering of these entries. It is expected that through the use of 672 wildcards in various selector fields, and because all packets on a 673 single UDP or TCP connection will tend to match a single SPD entry, 674 this requirement will not impose an unreasonably detailed level of 675 SPD specification. The selectors are analogous to what are found in 676 a stateless firewall or filtering router and which are currently 677 manageable this way. 679 In host systems, applications MAY be allowed to select what security 680 processing is to be applied to the traffic they generate and consume. 681 (Means of signalling such requests to the IPsec implementation are 682 outside the scope of this standard.) However, the system 683 administrator MUST be able to specify whether or not a user or 684 application can override (default) system policies. Note that 685 application specified policies may satisfy system requirements, so 686 that the system may not need to do additional IPsec processing beyond 687 that needed to meet an application's requirements. The form of the 688 management interface is not specified by this document and may differ 689 for hosts vs. security gateways, and within hosts the interface may 690 differ for socket-based vs. BITS implementations. However, this 691 document does specify a standard set of SPD elements that all IPsec 692 implementations MUST support. 694 The SPD contains an ordered list of policy entries. Each policy 695 entry is keyed by one or more selectors that define the set of IP 696 traffic encompassed by this policy entry. (The required selector 697 types are defined in Section 4.4.2.) These define the granularity of 698 policies or SAs. Each entry includes an indication of whether 699 traffic matching this policy will be bypassed, discarded, or subject 700 to IPsec processing. If IPsec processing is to be applied, the entry 701 includes an SA (or SA bundle) specification, listing the IPsec 702 protocols, modes, and algorithms to be employed, including any 703 nesting requirements. For example, an entry may call for all 704 matching traffic to be protected by ESP in transport mode using 705 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode 706 using HMAC/SHA-1. For each selector, the policy entry specifies how 707 to derive the corresponding values for a new Security Association 708 Database (SAD, see Section 4.4.3) entry from those in the SPD and the 709 packet (Note that at present, ranges are only supported for IP 710 addresses; but wildcarding can be expressed for all selectors): 712 a. use the value in the packet itself -- This will limit use of 713 the SA to those packets which have this packet's value for 714 the selector even if the selector for the policy entry has a 715 range of allowed values or a wildcard for this selector. 716 b. use the value associated with the policy entry -- If this 717 were to be just a single value, then there would be no 718 difference between (b) and (a). However, if the allowed 719 values for the selector are a range (for IP addresses) or 720 wildcard, then in the case of a range,(b) would enable use of 721 the SA by any packet with a selector value within the range 722 not just by packets with the selector value of the packet 723 that triggered the creation of the SA. In the case of a 724 wildcard, (b) would allow use of the SA by packets with any 725 value for this selector. 727 For example, suppose there is an SPD entry where the allowed value 728 for source address is any of a range of hosts (192.168.2.1 to 729 192.168.2.10). And suppose that a packet is to be sent that has a 730 source address of 192.168.2.3. The value to be used for the SA could 731 be any of the sample values below depending on what the policy entry 732 for this selector says is the source of the selector value: 734 source for the example of 735 value to be new SAD 736 used in the SA selector value 737 --------------- ------------ 738 a. packet 192.168.2.3 (one host) 739 b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) 741 Note that if the SPD entry had an allowed value of wildcard for the 742 source address, then the SAD selector value could be wildcard (any 743 host). Case (a) can be used to prohibit sharing, even among packets 744 that match the same SPD entry. 746 As described below in Section 4.4.3, selectors may include "wildcard" 747 entries and hence the selectors for two entries may overlap. (This 748 is analogous to the overlap that arises with ACLs or filter entries 749 in routers or packet filtering firewalls.) Thus, to ensure 750 consistent, predictable processing, SPD entries MUST be ordered and 751 the SPD MUST always be searched in the same order, so that the first 752 matching entry is consistently selected. (This requirement is 753 necessary as the effect of processing traffic against SPD entries 754 must be deterministic, but there is no way to canonicalize SPD 755 entries given the use of wildcards for some selectors.) More detail 756 on matching of packets against SPD entries is provided in Section 5. 758 Note that if ESP is specified, either (but not both) authentication 759 or encryption can be omitted. So it MUST be possible to configure 760 the SPD value for the authentication or encryption algorithms to be 761 "NULL". However, at least one of these services MUST be selected, 762 i.e., it MUST NOT be possible to configure both of them as "NULL". 764 The SPD can be used to map traffic to specific SAs or SA bundles. 765 Thus it can function both as the reference database for security 766 policy and as the map to existing SAs (or SA bundles). (To 767 accommodate the bypass and discard policies cited above, the SPD also 768 MUST provide a means of mapping traffic to these functions, even 769 though they are not, per se, IPsec processing.) The way in which the 770 SPD operates is different for inbound vs. outbound traffic and it 771 also may differ for host vs. security gateway, BITS, and BITW 772 implementations. Sections 5.1 and 5.2 describe the use of the SPD 773 for outbound and inbound processing, respectively. 775 Because a security policy may require that more than one SA be 776 applied to a specified set of traffic, in a specific order, the 777 policy entry in the SPD must preserve these ordering requirements, 778 when present. Thus, it must be possible for an IPsec implementation 779 to determine that an outbound or inbound packet must be processed 780 thorough a sequence of SAs. Conceptually, for outbound processing, 781 one might imagine links (to the SAD) from an SPD entry for which 782 there are active SAs, and each entry would consist of either a single 783 SA or an ordered list of SAs that comprise an SA bundle. When a 784 packet is matched against an SPD entry and there is an existing SA or 785 SA bundle that can be used to carry the traffic, the processing of 786 the packet is controlled by the SA or SA bundle entry on the list. 787 For an inbound IPsec packet for which multiple IPsec SAs are to be 788 applied, the lookup based on destination address, IPsec protocol, and 789 SPI should identify a single SA. 791 The SPD is used to control the flow of ALL traffic through an IPsec 792 system, including security and key management traffic (e.g., ISAKMP) 793 from/to entities behind a security gateway. This means that ISAKMP 794 traffic must be explicitly accounted for in the SPD, else it will be 795 discarded. Note that a security gateway could prohibit traversal of 796 encrypted packets in various ways, e.g., having a DISCARD entry in 797 the SPD for ESP packets or providing proxy key exchange. In the 798 latter case, the traffic would be internally routed to the key 799 management module in the security gateway. 801 4.4.2 Selectors 803 An SA (or SA bundle) may be fine-grained or coarse-grained, depending 804 on the selectors used to define the set of traffic for the SA. For 805 example, all traffic between two hosts may be carried via a single 806 SA, and afforded a uniform set of security services. Alternatively, 807 traffic between a pair of hosts might be spread over multiple SAs, 808 depending on the applications being used (as defined by the Next 809 Protocol and Port fields), with different security services offered 810 by different SAs. Similarly, all traffic between a pair of security 811 gateways could be carried on a single SA, or one SA could be assigned 812 for each communicating host pair. The following selector parameters 813 MUST be supported for SA management to facilitate control of SA 814 granularity. Note that in the case of receipt of a packet with an 815 ESP header, e.g., at an encapsulating security gateway or BITW 816 implementation, the transport layer protocol, source/destination 817 ports, and Name (if present) may be "OPAQUE", i.e., inaccessible 818 because of encryption or fragmentation. Note also that both Source 819 and Destination addresses should either be IPv4 or IPv6. 821 - Destination IP Address (IPv4 or IPv6): this may be a single IP 822 address (unicast, anycast, broadcast (IPv4 only), or multicast 823 group), a range of addresses (high and low values (inclusive), 824 address + mask, or a wildcard address. The last three are used 825 to support more than one destination system sharing the same SA 826 (e.g., behind a security gateway). Note that this selector is 827 conceptually different from the "Destination IP Address" field 828 in the tuple used 829 to uniquely identify an SA. When a tunneled packet arrives at 830 the tunnel endpoint, its SPI/Destination address/Protocol are 831 used to look up the SA for this packet in the SAD. This 832 destination address comes from the encapsulating IP header. 833 Once the packet has been processed according to the tunnel SA 834 and has come out of the tunnel, its selectors are "looked up" in 835 the Inbound SPD. The Inbound SPD has a selector called 836 destination address. This IP destination address is the one in 837 the inner (encapsulated) IP header. In the case of a 838 transport'd packet, there will be only one IP header and this 839 ambiguity does not exist. 840 [REQUIRED for all implementations] 842 - Source IP Address(es) (IPv4 or IPv6): this may be a single IP 843 address (unicast, anycast, broadcast (IPv4 only), or multicast 844 group), range of addresses (high and low values inclusive), 845 address + mask, or a wildcard address. The last three are used 846 to support more than one source system sharing the same SA 847 (e.g., behind a security gateway or in a multihomed host). 848 [REQUIRED for all implementations] 850 - Name: There are 2 cases (Note that these name forms are supported in 851 the IPsec DOI.) 852 1. User ID 853 a. a fully qualified user name string (DNS), e.g., 854 mozart@foo.bar.com 855 b. X.500 distinguished name, e.g., C = US, SP = MA, 856 O = GTE Internetworking, CN = Stephen T. Kent. 857 2. System name (host, security gateway, etc.) 858 a. a fully qualified DNS name, e.g., foo.bar.com 859 b. X.500 distinguished name 860 c. X.500 general name 862 NOTE: One of the possible values of this selector is "OPAQUE". 864 [REQUIRED for the following cases. Note that support for name forms 865 other than addresses is not required for manually keyed SAs. 866 o User ID 867 - native host implementations 868 - BITW and BITS implementations acting as HOSTS with only 869 one user 870 - security gateway implementations for INBOUND processing. 871 o System names -- all implementations] 873 - Data sensitivity level: (IPSO/CIPSO labels) 874 [REQUIRED for all systems providing information flow security as 875 per Section 8, OPTIONAL for all other systems.] 877 - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or 878 the IPv6 "Next Header" fields. This may be an individual 879 protocol number. These packet fields may not contain the 880 Transport Protocol due to the presence of IP extension headers, 881 e.g., a Routing Header, AH, ESP, Fragmentation Header, 882 Destination Options, Hop-by-hop options, etc. Note that the 883 Transport Protocol may not be available in the case of receipt 884 of a packet with an ESP header, thus a value of "OPAQUE" SHOULD 885 be supported. 886 [REQUIRED for all implementations] 888 NOTE: To locate the transport protocol, a system has to chain 889 through the packet headers checking the "Protocol" or "Next 890 Header" field until it encounters either one it recognizes as a 891 transport protocol, or until it reaches one that isn't on its 892 list of extension headers, or until it encounters an ESP header 893 that renders the transport protocol opaque. 895 - Source and Destination (e.g., TCP/UDP) Ports: These may be 896 individual UDP or TCP port values or a wildcard port. (The use 897 of the Next Protocol field and the Source and/or Destination 898 Port fields (in conjunction with the Source and/or Destination 899 Address fields), as an SA selector is sometimes referred to as 900 "session-oriented keying."). Note that the source and 901 destination ports may not be available in the case of receipt of 902 a packet with an ESP header, thus a value of "OPAQUE" SHOULD be 903 supported. 905 The following table summarizes the relationship between the 906 "Next Header" value in the packet and SPD and the derived Port 907 Selector value for the SPD and SAD. 909 Next Hdr Transport Layer Derived Port Selector Field 910 in Packet Protocol in SPD Value in SPD and SAD 911 -------- --------------- --------------------------- 912 ESP ESP or ANY ANY (i.e., don't look at it) 913 -don't care- ANY ANY (i.e., don't look at it) 914 specific value specific value NOT ANY (i.e., drop packet) 915 fragment 916 specific value specific value actual port selector field 917 not fragment 919 If the packet has been fragmented, then the port information may 920 not be available in the current fragment. If so, discard the 921 fragment. An ICMP PMTU should be sent for the first fragment, 922 which will have the port information. 923 [MAY be supported] 925 The IPsec implementation context determines how selectors are used. 926 For example, a host implementation integrated into the stack may make 927 use of a socket interface. When a new connection is established the 928 SPD can be consulted and an SA (or SA bundle) bound to the socket. 929 Thus traffic sent via that socket need not result in additional 930 lookups to the SPD/SAD. In contrast, a BITS, BITW, or security 931 gateway implementation needs to look at each packet and perform an 932 SPD/SAD lookup based on the selectors. The allowable values for the 933 selector fields differ between the traffic flow, the security 934 association, and the security policy. 936 The following table summarizes the kinds of entries that one needs to 937 be able to express in the SPD and SAD. It shows how they relate to 938 the fields in data traffic being subjected to IPsec screening. 939 (Note: the "wild" or "wildcard" entry for src and dst addresses 940 includes a mask, range, etc.) 941 Field Traffic Value SAD Entry SPD Entry 942 -------- ------------- ---------------- -------------------- 943 src addr single IP addr single,range,wild single,range,wildcard 944 dst addr single IP addr single,range,wild single,range,wildcard 945 xpt protocol* xpt protocol single,wildcard single,wildcard 946 src port* single src port single,wildcard single,wildcard 947 dst port* single dst port single,wildcard single,wildcard 948 user id* single user id single,wildcard single,wildcard 949 sec. labels single value single,wildcard single,wildcard 951 * The SAD and SPD entries for these fields could be "OPAQUE" 952 because the traffic value is encrypted. 954 NOTE: In principle, one could have selectors and/or selector values 955 in the SPD which cannot be negotiated for an SA or SA bundle. 956 Examples might include selector values used to select traffic for 957 discarding or enumerated lists which cause a separate SA to be 958 created for each item on the list. For now, this is left for future 959 versions of this document and the list of required selectors and 960 selector values is the same for the SPD and the SAD. However, it is 961 acceptable to have an administrative interface that supports use of 962 selector values which cannot be negotiated provided that it does not 963 mislead the user into believing it is creating an SA with these 964 selector values. For example, the interface may allow the user to 965 specify an enumerated list of values but would result in the creation 966 of a separate policy and SA for each item on the list. A vendor 967 might support such an interface to make it easier for its customers 968 to specify clear and concise policy specifications. 970 4.4.3 Security Association Database (SAD) 972 In each IPsec implementation there is a nominal Security Association 973 Database, in which each entry defines the parameters associated with 974 one SA. Each SA has an entry in the SAD. For outbound processing, 975 entries are pointed to by entries in the SPD. Note that if an SPD 976 entry does not currently point to an SA that is appropriate for the 977 packet, the implementation creates an appropriate SA (or SA Bundle) 978 and links the SPD entry to the SAD entry (see Section 5.1.1). For 979 inbound processing, each entry in the SAD is indexed by a destination 980 IP address, IPsec protocol type, and SPI. The following parameters 981 are associated with each entry in the SAD. This description does not 982 purport to be a MIB, but only a specification of the minimal data 983 items required to support an SA in an IPsec implementation. 985 For inbound processing: The following packet fields are used to look 986 up the SA in the SAD: 988 o Outer Header's Destination IP address: the IPv4 or IPv6 989 Destination address. 990 [REQUIRED for all implementations] 991 o IPsec Protocol: AH or ESP, used as an index for SA lookup in 992 this database. Specifies the IPsec protocol to be applied to 993 the traffic on this SA. 994 [REQUIRED for all implementations] 995 o SPI: the 32-bit value used to distinguish among different SAs 996 terminating at the same destination and using the same IPsec 997 protocol. 998 [REQUIRED for all implementations] 1000 For each of the selectors defined in Section 4.4.2, the SA entry in 1001 the SAD MUST contain the value or values which were negotiated at the 1002 time the SA was created. For the sender, these values are used to 1003 decide whether a given SA is appropriate for use with an outbound 1004 packet. This is part of checking to see if there is an existing SA 1005 that can be used. For the receiver, these values are used to check 1006 that the selector values in an inbound packet match those for the SA 1007 (and thus indirectly those for the matching policy). For the 1008 receiver, this is part of verifying that the SA was appropriate for 1009 this packet. (See Section 6 for rules for ICMP messages.) These 1010 fields can have the form of specific values, ranges, wildcards, or 1011 "OPAQUE" as described in section 4.4.2, "Selectors". Note that for 1012 an ESP SA, the encryption algorithm or the authentication algorithm 1013 could be "NULL". However they MUST not both be "NULL". 1015 The following SAD fields are used in doing IPsec processing: 1017 o Sequence Number Counter: a 32-bit value used to generate the 1018 Sequence Number field in AH or ESP headers. 1019 [REQUIRED for all implementations, but used only for outbound 1020 traffic.] 1021 o Sequence Counter Overflow: a flag indicating whether overflow of 1022 the Sequence Number Counter should generate an auditable event 1023 and prevent transmission of additional packets on the SA. 1024 [REQUIRED for all implementations, but used only for outbound 1025 traffic.] 1026 o Anti-Replay Window: a 32-bit counter and a bit-map (or 1027 equivalent) used to determine whether an inbound AH or ESP 1028 packet is a replay. 1029 [REQUIRED for all implementations but used only for inbound 1030 traffic. NOTE: If anti-replay has been disabled by the receiver, 1031 e.g., in the case of a manually keyed SA, then the Anti-Replay 1032 Window is not used.] 1033 o AH Authentication algorithm, keys, etc. 1034 [REQUIRED for AH implementations] 1036 o ESP Encryption algorithm, keys, IV mode, IV, etc. 1037 [REQUIRED for ESP implementations] 1038 o ESP authentication algorithm, keys, etc. If the authentication 1039 service is not selected, this field will be null. 1040 [REQUIRED for ESP implementations] 1041 o Lifetime of this Security Association: a time interval after 1042 which an SA must be replaced with a new SA (and new SPI) or 1043 terminated, plus an indication of which of these actions should 1044 occur. This may be expressed as a time or byte count. If time 1045 is employed, and if IKE employs X.509 certificates for SA 1046 establishment, the SA lifetime must be constrained by the 1047 validity intervals of the certificates, and the NextIssueDate of 1048 the CRLs used in the IKE exchange for the SA. Both initiator 1049 and responder are responsible for constraining SA lifetime in 1050 this fashion. 1051 [REQUIRED for all implementations] 1053 NOTE: The details of how to handle the refreshing of keys when 1054 SAs expire is a local matter. However, one reasonable approach 1055 is: 1056 (a) If byte count is used, then the implementation 1057 SHOULD count the number of bytes to which the IPsec 1058 algorithm is applied. For ESP, this is the encryption 1059 algorithm (including Null encryption) and for AH, 1060 this is the authentication algorithm. This includes 1061 pad bytes, etc. Note that implementations SHOULD be 1062 able to handle having the counters at the ends of an 1063 SA get out of synch, e.g., because of packet loss or 1064 because the implementations at each end of the SA 1065 aren't doing things the same way. 1066 (b) There SHOULD be two kinds of lifetime -- a soft 1067 lifetime which warns the implementation to initiate 1068 action such as setting up a replacement SA and a 1069 hard lifetime when the current SA ends. 1070 (c) If the entire packet does not get delivered during 1071 the SAs lifetime, the packet SHOULD be discarded. 1073 o IPsec protocol mode: tunnel, transport or wildcard. Indicates 1074 which mode of AH or ESP is applied to traffic on this SA. Note 1075 that if this field is "wildcard" at the sending end of the SA, 1076 then the application has to specify the mode to the IPsec 1077 implementation. This use of wildcard allows the same SA to be 1078 used for either tunnel or transport mode traffic on a per packet 1079 basis, e.g., by different sockets. The receiver does not need 1080 to know the mode in order to properly process the packet's IPsec 1081 headers. 1083 [REQUIRED as follows, unless implicitly defined by context: 1085 - host implementations must support all modes 1086 - gateway implementations must support tunnel mode] 1088 NOTE: The use of wildcard for the protocol mode of an inbound SA 1089 may add complexity to the situation in the receiver (host only). 1090 Since the packets on such an SA could be delivered in either 1091 tunnel or transport mode, the security of an incoming packet 1092 could depend in part on which mode had been used to deliver it. 1093 If, as a result, an application cared about the SA mode of a 1094 given packet, then the application would need a mechanism to 1095 obtain this mode information. 1097 o Path MTU: any observed path MTU and aging variables. See 1098 Section 6.1.2.4 1099 [REQUIRED for all implementations but used only for outbound 1100 traffic] 1102 4.5 Basic Combinations of Security Associations 1104 This section describes four examples of combinations of security 1105 associations that MUST be supported by compliant IPsec hosts or 1106 security gateways. Additional combinations of AH and/or ESP in 1107 tunnel and/or transport modes MAY be supported at the discretion of 1108 the implementor. Compliant implementations MUST be capable of 1109 generating these four combinations and on receipt, of processing 1110 them, but SHOULD be able to receive and process any combination. The 1111 diagrams and text below describe the basic cases. The legend for the 1112 diagrams is: 1114 ==== = one or more security associations (AH or ESP, transport 1115 or tunnel) 1116 ---- = connectivity (or if so labelled, administrative boundary) 1117 Hx = host x 1118 SGx = security gateway x 1119 X* = X supports IPsec 1121 NOTE: The security associations below can be either AH or ESP. The 1122 mode (tunnel vs transport) is determined by the nature of the 1123 endpoints. For host-to-host SAs, the mode can be either transport or 1124 tunnel. 1126 Case 1. The case of providing end-to-end security between 2 hosts 1127 across the Internet (or an Intranet). 1129 ==================================== 1130 | | 1131 H1* ------ (Inter/Intranet) ------ H2* 1133 Note that either transport or tunnel mode can be selected by the 1134 hosts. So the headers in a packet between H1 and H2 could look 1135 like any of the following: 1137 Transport Tunnel 1138 ----------------- --------------------- 1139 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 1140 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 1141 3. [IP1][AH][ESP][upper] 1143 Note that there is no requirement to support general nesting, 1144 but in transport mode, both AH and ESP can be applied to the 1145 packet. In this event, the SA establishment procedure MUST 1146 ensure that first ESP, then AH are applied to the packet. 1148 Case 2. This case illustrates simple virtual private networks 1149 support. 1151 =========================== 1152 | | 1153 ---------------------|---- ---|----------------------- 1154 | | | | | | 1155 | H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 | 1156 | Intranet) | | Intranet) | 1157 -------------------------- --------------------------- 1158 admin. boundary admin. boundary 1160 Only tunnel mode is required here. So the headers in a packet 1161 between SG1 and SG2 could look like either of the following: 1163 Tunnel 1164 --------------------- 1165 4. [IP2][AH][IP1][upper] 1166 5. [IP2][ESP][IP1][upper] 1168 Case 3. This case combines cases 1 and 2, adding end-to-end security 1169 between the sending and receiving hosts. It imposes no new 1170 requirements on the hosts or security gateways, other than a 1171 requirement for a security gateway to be configurable to pass 1172 IPsec traffic (including ISAKMP traffic) for hosts behind it. 1174 =============================================================== 1175 | | 1176 | ========================= | 1177 | | | | 1178 ---|-----------------|---- ---|-------------------|--- 1179 | | | | | | | | 1180 | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | 1181 | Intranet) | | Intranet) | 1182 -------------------------- --------------------------- 1183 admin. boundary admin. boundary 1185 Case 4. This covers the situation where a remote host (H1) uses the 1186 Internet to reach an organization's firewall (SG2) and to then 1187 gain access to some server or other machine (H2). The remote 1188 host could be a mobile host (H1) dialing up to a local PPP/ARA 1189 server (not shown) on the Internet and then crossing the 1190 Internet to the home organization's firewall (SG2), etc. The 1191 details of support for this case, (how H1 locates SG2, 1192 authenticates it, and verifies its authorization to represent 1193 H2) are discussed in Section 4.6.3, "Locating a Security 1194 Gateway". 1196 ====================================================== 1197 | | 1198 |============================== | 1199 || | | 1200 || ---|----------------------|--- 1201 || | | | | 1202 H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | 1203 ^ | Intranet) | 1204 | ------------------------------ 1205 could be dialup admin. boundary (optional) 1206 to PPP/ARA server 1208 Only tunnel mode is required between H1 and SG2. So the choices 1209 for the SA between H1 and SG2 would be one of the ones in case 1210 2. The choices for the SA between H1 and H2 would be one of the 1211 ones in case 1. 1213 Note that in this case, the sender MUST apply the transport 1214 header before the tunnel header. Therefore the management 1215 interface to the IPsec implementation MUST support configuration 1216 of the SPD and SAD to ensure this ordering of IPsec header 1217 application. 1219 As noted above, support for additional combinations of AH and ESP is 1220 optional. Use of other, optional combinations may adversely affect 1221 interoperability. 1223 4.6 SA and Key Management 1225 IPsec mandates support for both manual and automated SA and 1226 cryptographic key management. The IPsec protocols, AH and ESP, are 1227 largely independent of the associated SA management techniques, 1228 although the techniques involved do affect some of the security 1229 services offered by the protocols. For example, the optional anti- 1230 replay services available for AH and ESP require automated SA 1231 management. Moreover, the granularity of key distribution employed 1232 with IPsec determines the granularity of authentication provided. 1233 (See also a discussion of this issue in Section 4.7.) In general, 1234 data origin authentication in AH and ESP is limited by the extent to 1235 which secrets used with the authentication algorithm (or with a key 1236 management protocol that creates such secrets) are shared among 1237 multiple possible sources. 1239 The following text describes the minimum requirements for both types 1240 of SA management. 1242 4.6.1 Manual Techniques 1244 The simplest form of management is manual management, in which a 1245 person manually configures each system with keying material and 1246 security association management data relevant to secure communication 1247 with other systems. Manual techniques are practical in small, static 1248 environments but they do not scale well. For example, a company 1249 could create a Virtual Private Network (VPN) using IPsec in security 1250 gateways at several sites. If the number of sites is small, and 1251 since all the sites come under the purview of a single administrative 1252 domain, this is likely to be a feasible context for manual management 1253 techniques. In this case, the security gateway might selectively 1254 protect traffic to and from other sites within the organization using 1255 a manually configured key, while not protecting traffic for other 1256 destinations. It also might be appropriate when only selected 1257 communications need to be secured. A similar argument might apply to 1258 use of IPsec entirely within an organization for a small number of 1259 hosts and/or gateways. Manual management techniques often employ 1260 statically configured, symmetric keys, though other options also 1261 exist. 1263 4.6.2 Automated SA and Key Management 1265 Widespread deployment and use of IPsec requires an Internet-standard, 1266 scalable, automated, SA management protocol. Such support is 1267 required to facilitate use of the anti-replay features of AH and ESP, 1268 and to accommodate on-demand creation of SAs, e.g., for user- and 1269 session-oriented keying. (Note that the notion of "rekeying" an SA 1270 actually implies creation of a new SA with a new SPI, a process that 1271 generally implies use of an automated SA/key management protocol.) 1273 The default automated key management protocol selected for use with 1274 IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of 1275 interpretation [Pip98]. Other automated SA management protocols MAY 1276 be employed. 1278 When an automated SA/key management protocol is employed, the output 1279 from this protocol may be used to generate multiple keys, e.g., for a 1280 single ESP SA. This may arise because: 1282 o the encryption algorithm uses multiple keys (e.g., triple DES) 1283 o the authentication algorithm uses multiple keys 1284 o both encryption and authentication algorithms are employed 1286 The Key Management System may provide a separate string of bits for 1287 each key or it may generate one string of bits from which all of them 1288 are extracted. If a single string of bits is provided, care needs to 1289 be taken to ensure that the parts of the system that map the string 1290 of bits to the required keys do so in the same fashion at both ends 1291 of the SA. To ensure that the IPsec implementations at each end of 1292 the SA use the same bits for the same keys, and irrespective of which 1293 part of the system divides the string of bits into individual keys, 1294 the encryption key(s) MUST be taken from the first (left-most, high- 1295 order) bits and the authentication key(s) MUST be taken from the 1296 remaining bits. The number of bits for each key is defined in the 1297 relevant algorithm specification RFC. In the case of multiple 1298 encryption keys or multiple authentication keys, the specification 1299 for the algorithm must specify the order in which they are to be 1300 selected from a single string of bits provided to the algorithm. 1302 4.6.3 Locating a Security Gateway 1304 This section discusses issues relating to how a host learns about the 1305 existence of relevant security gateways and once a host has contacted 1306 these security gateways, how it knows that these are the correct 1307 security gateways. The details of where the required information is 1308 stored is a local matter. 1310 Consider a situation in which a remote host (H1) is using the 1311 Internet to gain access to a server or other machine (H2) and there 1312 is a security gateway (SG2), e.g., a firewall, through which H1's 1313 traffic must pass. An example of this situation would be a mobile 1314 host (Road Warrior) crossing the Internet to the home organization's 1315 firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of 1316 Security Associations.) This situation raises several issues: 1318 1. How does H1 know/learn about the existence of the security 1319 gateway SG2? 1320 2. How does it authenticate SG2, and once it has authenticated 1321 SG2, how does it confirm that SG2 has been authorized to 1322 represent H2? 1323 3. How does SG2 authenticate H1 and verify that H1 is authorized 1324 to contact H2? 1325 4. How does H1 know/learn about backup gateways which provide 1326 alternate paths to H2? 1328 To address these problems, a host or security gateway MUST have an 1329 administrative interface that allows the user/administrator to 1330 configure the address of a security gateway for any sets of 1331 destination addresses that require its use. This includes the ability 1332 to configure: 1334 o the requisite information for locating and authenticating the 1335 security gateway and verifying its authorization to represent 1336 the destination host. 1337 o the requisite information for locating and authenticating any 1338 backup gateways and verifying their authorization to represent 1339 the destination host. 1341 It is assumed that the SPD is also configured with policy information 1342 that covers any other IPsec requirements for the path to the security 1343 gateway and the destination host. 1345 This document does not address the issue of how to automate the 1346 discovery/verification of security gateways. 1348 4.7 Security Associations and Multicast 1350 The receiver-orientation of the Security Association implies that, in 1351 the case of unicast traffic, the destination system will normally 1352 select the SPI value. By having the destination select the SPI 1353 value, there is no potential for manually configured Security 1354 Associations to conflict with automatically configured (e.g., via a 1355 key management protocol) Security Associations or for Security 1356 Associations from multiple sources to conflict with each other. For 1357 multicast traffic, there are multiple destination systems per 1358 multicast group. So some system or person will need to coordinate 1359 among all multicast groups to select an SPI or SPIs on behalf of each 1360 multicast group and then communicate the group's IPsec information to 1361 all of the legitimate members of that multicast group via mechanisms 1362 not defined here. 1364 Multiple senders to a multicast group SHOULD use a single Security 1365 Association (and hence Security Parameter Index) for all traffic to 1366 that group when a symmetric key encryption or authentication 1367 algorithm is employed. In such circumstances, the receiver knows only 1368 that the message came from a system possessing the key for that 1369 multicast group. In such circumstances, a receiver generally will 1370 not be able to authenticate which system sent the multicast traffic. 1371 Specifications for other, more general multicast cases are deferred 1372 to later IPsec documents. 1374 At the time this specification was published, automated protocols for 1375 multicast key distribution were not considered adequately mature for 1376 standardization. For multicast groups having relatively few members, 1377 manual key distribution or multiple use of existing unicast key 1378 distribution algorithms such as modified Diffie-Hellman appears 1379 feasible. For very large groups, new scalable techniques will be 1380 needed. An example of current work in this area is the Group Key 1381 Management Protocol (GKMP) [HM97]. 1383 5. IP Traffic Processing 1385 As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", 1386 the SPD must be consulted during the processing of all traffic 1387 (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is 1388 found in the SPD that matches the packet (for either inbound or 1389 outbound traffic), the packet MUST be discarded. 1391 NOTE: All of the cryptographic algorithms used in IPsec expect their 1392 input in canonical network byte order (see Appendix in RFC 791) and 1393 generate their output in canonical network byte order. IP packets 1394 are also transmitted in network byte order. 1396 5.1 Outbound IP Traffic Processing 1398 5.1.1 Selecting and Using an SA or SA Bundle 1400 In a security gateway or BITW implementation (and in many BITS 1401 implementations), each outbound packet is compared against the SPD to 1402 determine what processing is required for the packet. If the packet 1403 is to be discarded, this is an auditable event. If the traffic is 1404 allowed to bypass IPsec processing, the packet continues through 1405 "normal" processing for the environment in which the IPsec processing 1406 is taking place. If IPsec processing is required, the packet is 1407 either mapped to an existing SA (or SA bundle), or a new SA (or SA 1408 bundle) is created for the packet. Since a packet's selectors might 1409 match multiple policies or multiple extant SAs and since the SPD is 1410 ordered, but the SAD is not, IPsec MUST: 1412 1. Match the packet's selector fields against the outbound 1413 policies in the SPD to locate the first appropriate policy, 1414 which will point to zero or more SA bundles in the SAD. 1416 2. Match the packet's selector fields against those in the SA 1417 bundles found in (1) to locate the first SA bundle that 1418 matches. If no SAs were found or none match, create an 1419 appropriate SA bundle and link the SPD entry to the SAD 1420 entry. If no key management entity is found, drop the 1421 packet. 1423 3. Use the SA bundle found/created in (2) to do the required 1424 IPsec processing, e.g., authenticate and encrypt. 1426 In a host IPsec implementation based on sockets, the SPD will be 1427 consulted whenever a new socket is created, to determine what, if 1428 any, IPsec processing will be applied to the traffic that will flow 1429 on that socket. 1431 NOTE: A compliant implementation MUST not allow instantiation of an 1432 ESP SA that employs both a NULL encryption and a NULL authentication 1433 algorithm. An attempt to negotiate such an SA is an auditable event. 1435 5.1.2 Header Construction for Tunnel Mode 1437 This section describes the handling of the inner and outer IP 1438 headers, extension headers, and options for AH and ESP tunnels. This 1439 includes how to construct the encapsulating (outer) IP header, how to 1440 handle fields in the inner IP header, and what other actions should 1441 be taken. The general idea is modeled after the one used in RFC 1442 2003, "IP Encapsulation with IP": 1444 o The outer IP header Source Address and Destination Address 1445 identify the "endpoints" of the tunnel (the encapsulator and 1446 decapsulator). The inner IP header Source Address and 1447 Destination Addresses identify the original sender and recipient 1448 of the datagram, (from the perspective of this tunnel), 1449 respectively. (see footnote 3 after the table in 5.1.2.1 for 1450 more details on the encapsulating source IP address.) 1451 o The inner IP header is not changed except to decrement the TTL 1452 as noted below, and remains unchanged during its delivery to the 1453 tunnel exit point. 1454 o No change to IP options or extension headers in the inner header 1455 occurs during delivery of the encapsulated datagram through the 1456 tunnel. 1457 o If need be, other protocol headers such as the IP Authentication 1458 header may be inserted between the outer IP header and the inner 1459 IP header. 1461 The tables in the following sub-sections show the handling for the 1462 different header/option fields (constructed = the value in the outer 1463 field is constructed independently of the value in the inner). 1465 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode 1467 <-- How Outer Hdr Relates to Inner Hdr --> 1468 Outer Hdr at Inner Hdr at 1469 IPv4 Encapsulator Decapsulator 1470 Header fields: -------------------- ------------ 1471 version 4 (1) no change 1472 header length constructed no change 1473 TOS copied from inner hdr (5) no change 1474 total length constructed no change 1475 ID constructed no change 1476 flags (DF,MF) constructed, DF (4) no change 1477 fragmt offset constructed no change 1478 TTL constructed (2) decrement (2) 1479 protocol AH, ESP, routing hdr no change 1480 checksum constructed constructed (2) 1481 src address constructed (3) no change 1482 dest address constructed (3) no change 1483 Options never copied no change 1485 1. The IP version in the encapsulating header can be different 1486 from the value in the inner header. 1488 2. The TTL in the inner header is decremented by the 1489 encapsulator prior to forwarding and by the decapsulator if 1490 it forwards the packet. (The checksum changes when the TTL 1491 changes.) 1493 Note: The decrementing of the TTL is one of the usual actions 1494 that takes place when forwarding a packet. Packets 1495 originating from the same node as the encapsulator do not 1496 have their TTL's decremented, as the sending node is 1497 originating the packet rather than forwarding it. 1499 3. src and dest addresses depend on the SA, which is used to 1500 determine the dest address which in turn determines which src 1501 address (net interface) is used to forward the packet. 1503 NOTE: In principle, the encapsulating IP source address can 1504 be any of the encapsulator's interface addresses or even an 1505 address different from any of the encapsulator's IP 1506 addresses, (e.g., if it's acting as a NAT box) so long as the 1507 address is reachable through the encapsulator from the 1508 environment into which the packet is sent. This does not 1509 cause a problem because IPsec does not currently have any 1510 INBOUND processing requirement that involves the Source 1511 Address of the encapsulating IP header. So while the 1512 receiving tunnel endpoint looks at the Destination Address in 1513 the encapsulating IP header, it only looks at the Source 1514 Address in the inner (encapsulated) IP header. 1516 4. configuration determines whether to copy from the inner 1517 header (IPv4 only), clear or set the DF. 1519 5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner 1520 Hdr is IPv6 (Protocol = 41), map the Class to TOS. 1522 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode 1524 See previous section 5.1.2 for notes 1-5 indicated by (footnote number). 1526 <-- How Outer Hdr Relates Inner Hdr ---> 1527 Outer Hdr at Inner Hdr at 1528 IPv6 Encapsulator Decapsulator 1529 Header fields: -------------------- ------------ 1530 version 6 (1) no change 1531 class copied or configured (6) no change 1532 flow id copied or configured no change 1533 len constructed no change 1534 next header AH,ESP,routing hdr no change 1535 hop limit constructed (2) decrement (2) 1536 src address constructed (3) no change 1537 dest address constructed (3) no change 1538 Extension headers never copied no change 1540 6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If 1541 Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class. 1543 5.2 Processing Inbound IP Traffic 1545 Prior to performing AH or ESP processing, any IP fragments are 1546 reassembled. Each inbound IP datagram to which IPsec processing will 1547 be applied is identified by the appearance of the AH or ESP values in 1548 the IP Next Protocol field (or of AH or ESP as an extension header in 1549 the IPv6 context). 1551 Note: Appendix C contains sample code for a bitmask check for a 32 1552 packet window that can be used for implementing anti-replay service. 1554 5.2.1 Selecting and Using an SA or SA Bundle 1556 Mapping the IP datagram to the appropriate SA is simplified because 1557 of the presence of the SPI in the AH or ESP header. Note that the 1558 selector checks are made on the inner headers not the outer (tunnel) 1559 headers. The steps followed are: 1561 1. Use the packet's destination address (outer IP header), IPsec 1562 protocol, and SPI to look up the SA in the SAD. If the SA 1563 lookup fails, drop the packet and log/report the error. 1565 2. Use the SA found in (1) to do the IPsec processing, e.g., 1566 authenticate and decrypt. This step includes matching the 1567 packet's (Inner Header if tunneled) selectors to the 1568 selectors in the SA. Local policy determines the specificity 1569 of the SA selectors (single value, list, range, wildcard). 1570 In general, a packet's source address MUST match the SA 1571 selector value. However, an ICMP packet received on a tunnel 1572 mode SA MAY have a source address other than that bound to 1573 the SA and thus such packets should be permitted as 1574 exceptions to this check. For an ICMP packet, the selectors 1575 from the enclosed problem packet (the source and destination 1576 addresses and ports should be swapped) should be checked 1577 against the selectors for the SA. Note that some or all of 1578 these selectors may be inaccessible because of limitations on 1579 how many bits of the problem packet the ICMP packet is 1580 allowed to carry or due to encryption. See Section 6. 1582 Do (1) and (2) for every IPsec header until a Transport 1583 Protocol Header or an IP header that is NOT for this system 1584 is encountered. Keep track of what SAs have been used and 1585 their order of application. 1587 3. Find an incoming policy in the SPD that matches the packet. 1588 This could be done, for example, by use of backpointers from 1589 the SAs to the SPD or by matching the packet's selectors 1590 (Inner Header if tunneled) against those of the policy 1591 entries in the SPD. 1593 4. Check whether the required IPsec processing has been applied, 1594 i.e., verify that the SA's found in (1) and (2) match the 1595 kind and order of SAs required by the policy found in (3). 1597 NOTE: The correct "matching" policy will not necessarily be 1598 the first inbound policy found. If the check in (4) fails, 1599 steps (3) and (4) are repeated until all policy entries have 1600 been checked or until the check succeeds. 1602 At the end of these steps, pass the resulting packet to the Transport 1603 Layer or forward the packet. Note that any IPsec headers processed 1604 in these steps may have been removed, but that this information, 1605 i.e., what SAs were used and the order of their application, may be 1606 needed for subsequent IPsec or firewall processing. 1608 Note that in the case of a security gateway, if forwarding causes a 1609 packet to exit via an IPsec-enabled interface, then additional IPsec 1610 processing may be applied. 1612 5.2.2 Handling of AH and ESP tunnels 1614 The handling of the inner and outer IP headers, extension headers, 1615 and options for AH and ESP tunnels should be performed as described 1616 in the tables in Section 5.1. 1618 6. ICMP Processing (relevant to IPsec) 1620 The focus of this section is on the handling of ICMP error messages. 1621 Other ICMP traffic, e.g., Echo/Reply, should be treated like other 1622 traffic and can be protected on an end-to-end basis using SAs in the 1623 usual fashion. 1625 An ICMP error message protected by AH or ESP and generated by a 1626 router SHOULD be processed and forwarded in a tunnel mode SA. Local 1627 policy determines whether or not it is subjected to source address 1628 checks by the router at the destination end of the tunnel. Note that 1629 if the router at the originating end of the tunnel is forwarding an 1630 ICMP error message from another router, the source address check 1631 would fail. An ICMP message protected by AH or ESP and generated by 1632 a router MUST NOT be forwarded on a transport mode SA (unless the SA 1633 has been established to the router acting as a host, e.g., a Telnet 1634 connection used to manage a router). An ICMP message generated by a 1635 host SHOULD be checked against the source IP address selectors bound 1636 to the SA in which the message arrives. Note that even if the source 1637 of an ICMP error message is authenticated, the returned IP header 1638 could be invalid. Accordingly, the selector values in the IP header 1639 SHOULD also be checked to be sure that they are consistent with the 1640 selectors for the SA over which the ICMP message was received. 1642 The table in Appendix D characterize ICMP messages as being either 1643 host generated, router generated, both, unknown/unassigned. ICMP 1644 messages falling into the last two categories should be handled as 1645 determined by the receiver's policy. 1647 An ICMP message not protected by AH or ESP is unauthenticated and its 1648 processing and/or forwarding may result in denial of service. This 1649 suggests that, in general, it would be desirable to ignore such 1650 messages. However, it is expected that many routers (vs. security 1651 gateways) will not implement IPsec for transit traffic and thus 1652 strict adherence to this rule would cause many ICMP messages to be 1653 discarded. The result is that some critical IP functions would be 1654 lost, e.g., redirection and PMTU processing. Thus it MUST be 1655 possible to configure an IPsec implementation to accept or reject 1656 (router) ICMP traffic as per local security policy. 1658 The remainder of this section addresses how PMTU processing MUST be 1659 performed at hosts and security gateways. It addresses processing of 1660 both authenticated and unauthenticated ICMP PMTU messages. However, 1661 as noted above, unauthenticated ICMP messages MAY be discarded based 1662 on local policy. 1664 6.1 PMTU/DF Processing 1666 6.1.1 DF Bit 1668 In cases where a system (host or gateway) adds an encapsulating 1669 header (ESP tunnel or AH tunnel), it MUST support the option of 1670 copying the DF bit from the original packet to the encapsulating 1671 header (and processing ICMP PMTU messages). This means that it MUST 1672 be possible to configure the system's treatment of the DF bit (set, 1673 clear, copy from encapsulated header) for each interface. (See 1674 Appendix B for rationale.) 1676 6.1.2 Path MTU Discovery (PMTU) 1678 This section discusses IPsec handling for Path MTU Discovery 1679 messages. ICMP PMTU is used here to refer to an ICMP message for: 1681 IPv4 (RFC 792): 1682 - Type = 3 (Destination Unreachable) 1683 - Code = 4 (Fragmentation needed and DF set) 1684 - Next-Hop MTU in the low-order 16 bits of the second 1685 word of the ICMP header (labelled "unused" in RFC 1686 792), with high-order 16 bits set to zero 1688 IPv6 (RFC 1885): 1689 - Type = 2 (Packet Too Big) 1690 - Code = 0 (Fragmentation needed) 1691 - Next-Hop MTU in the 32 bit MTU field of the ICMP6 1692 message 1694 6.1.2.1 Propagation of PMTU 1696 The amount of information returned with the ICMP PMTU message (IPv4 1697 or IPv6) is limited and this affects what selectors are available for 1698 use in further propagating the PMTU information. (See Appendix B for 1699 more detailed discussion of this topic.) 1701 o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU 1702 message contains only 64 bits of the IPsec header (minimum for 1703 IPv4), then a security gateway MUST support the following options 1704 on a per SPI/SA basis: 1706 a. if the originating host can be determined (or the possible 1707 sources narrowed down to a manageable number), send the PMTU 1708 information to all the possible originating hosts. 1709 b. if the originating host cannot be determined, store the PMTU 1710 with the SA and wait until the next packet(s) arrive from the 1711 originating host for the relevant security association. If 1712 the packet(s) are bigger than the PMTU, drop the packet(s), 1713 and compose ICMP PMTU message(s) with the new packet(s) and 1714 the updated PMTU, and send the ICMP message(s) about the 1715 problem to the originating host. Retain the PMTU information 1716 for any message that might arrive subsequently (see Section 1717 6.1.2.4, "PMTU Aging"). 1719 o PMTU message with >64 bits of IPsec header -- If the ICMP message 1720 contains more information from the original packet then there MAY 1721 be enough non-opaque information to immediately determine to which 1722 host to propagate the ICMP/PMTU message and to provide that system 1723 with the 5 fields (source address, destination address, source 1724 port, destination port, transport protocol) needed to determine 1725 where to store/update the PMTU. Under such circumstances, a 1726 security gateway MUST generate an ICMP PMTU message immediately 1727 upon receipt of an ICMP PMTU from further down the path. 1729 o Distributing the PMTU to the Transport Layer -- The host mechanism 1730 for getting the updated PMTU to the transport layer is unchanged, 1731 as specified in RFC 1191 (Path MTU Discovery). 1733 6.1.2.2 Calculation of PMTU 1735 The calculation of PMTU from an ICMP PMTU MUST take into account the 1736 addition of any IPsec header -- AH transport, ESP transport, AH/ESP 1737 transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of 1738 implementation issues.) 1740 Note: In some situations the addition of IPsec headers could result 1741 in an effective PMTU (as seen by the host or application) that is 1742 unacceptably small. To avoid this problem, the implementation may 1743 establish a threshold below which it will not report a reduced PMTU. 1744 In such cases, the implementation would apply IPsec and then fragment 1745 the resulting packet according to the PMTU. This would result in a 1746 more efficient use of the available bandwidth. 1748 6.1.2.3 Granularity of PMTU Processing 1750 In hosts, the granularity with which ICMP PMTU processing can be done 1751 differs depending on the implementation situation. Looking at a 1752 host, there are 3 situations that are of interest with respect to 1753 PMTU issues (See Appendix B for additional details on this topic.): 1755 a. Integration of IPsec into the native IP implementation 1756 b. Bump-in-the-stack implementations, where IPsec is implemented 1757 "underneath" an existing implementation of a TCP/IP protocol 1758 stack, between the native IP and the local network drivers 1759 c. No IPsec implementation -- This case is included because it 1760 is relevant in cases where a security gateway is sending PMTU 1761 information back to a host. 1763 Only in case (a) can the PMTU data be maintained at the same 1764 granularity as communication associations. In (b) and (c), the IP 1765 layer will only be able to maintain PMTU data at the granularity of 1766 source and destination IP addresses (and optionally TOS), as 1767 described in RFC 1191. This is an important difference, because more 1768 than one communication association may map to the same source and 1769 destination IP addresses, and each communication association may have 1770 a different amount of IPsec header overhead (e.g., due to use of 1771 different transforms or different algorithms). 1773 Implementation of the calculation of PMTU and support for PMTUs at 1774 the granularity of individual communication associations is a local 1775 matter. However, a socket-based implementation of IPsec in a host 1776 SHOULD maintain the information on a per socket basis. Bump in the 1777 stack systems MUST pass an ICMP PMTU to the host IP implementation, 1778 after adjusting it for any IPsec header overhead added by these 1779 systems. The calculation of the overhead SHOULD be determined by 1780 analysis of the SPI and any other selector information present in a 1781 returned ICMP PMTU message. 1783 6.1.2.4 PMTU Aging 1785 In all systems (host or gateway) implementing IPsec and maintaining 1786 PMTU information, the PMTU associated with a security association 1787 (transport or tunnel) MUST be "aged" and some mechanism put in place 1788 for updating the PMTU in a timely manner, especially for discovering 1789 if the PMTU is smaller than it needs to be. A given PMTU has to 1790 remain in place long enough for a packet to get from the source end 1791 of the security association to the system at the other end of the 1792 security association and propagate back an ICMP error message if the 1793 current PMTU is too big. Note that if there are nested tunnels, 1794 multiple packets and round trip times might be required to get an 1795 ICMP message back to an encapsulator or originating host. 1797 Systems SHOULD use the approach described in the Path MTU Discovery 1798 document (RFC 1191, Section 6.3), which suggests periodically 1799 resetting the PMTU to the first-hop data-link MTU and then letting 1800 the normal PMTU Discovery processes update the PMTU as necessary. 1801 The period SHOULD be configurable. 1803 7. Auditing 1805 Not all systems that implement IPsec will implement auditing. For 1806 the most part, the granularity of auditing is a local matter. 1807 However, several auditable events are identified in the AH and ESP 1808 specifications and for each of these events a minimum set of 1809 information that SHOULD be included in an audit log is defined. 1810 Additional information also MAY be included in the audit log for each 1811 of these events, and additional events, not explicitly called out in 1812 this specification, also MAY result in audit log entries. There is 1813 no requirement for the receiver to transmit any message to the 1814 purported transmitter in response to the detection of an auditable 1815 event, because of the potential to induce denial of service via such 1816 action. 1818 8. Use in Systems Supporting Information Flow Security 1820 Information of various sensitivity levels may be carried over a 1821 single network. Information labels (e.g., Unclassified, Company 1822 Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish 1823 such information. The use of labels facilitates segregation of 1824 information, in support of information flow security models, e.g., 1825 the Bell-LaPadula model [BL73]. Such models, and corresponding 1826 supporting technology, are designed to prevent the unauthorized flow 1827 of sensitive information, even in the face of Trojan Horse attacks. 1828 Conventional, discretionary access control (DAC) mechanisms, e.g., 1829 based on access control lists, generally are not sufficient to 1830 support such policies, and thus facilities such as the SPD do not 1831 suffice in such environments. 1833 In the military context, technology that supports such models is 1834 often referred to as multi-level security (MLS). Computers and 1835 networks often are designated "multi-level secure" if they support 1836 the separation of labelled data in conjunction with information flow 1837 security policies. Although such technology is more broadly 1838 applicable than just military applications, this document uses the 1839 acronym "MLS" to designate the technology, consistent with much 1840 extant literature. 1842 IPsec mechanisms can easily support MLS networking. MLS networking 1843 requires the use of strong Mandatory Access Controls (MAC), which 1844 unprivileged users or unprivileged processes are incapable of 1845 controlling or violating. This section pertains only to the use of 1846 these IP security mechanisms in MLS (information flow security 1847 policy) environments. Nothing in this section applies to systems not 1848 claiming to provide MLS. 1850 As used in this section, "sensitivity information" might include 1851 implementation-defined hierarchic levels, categories, and/or 1852 releasability information. 1854 AH can be used to provide strong authentication in support of 1855 mandatory access control decisions in MLS environments. If explicit 1856 IP sensitivity information (e.g., IPSO [Ken91]) is used and 1857 confidentiality is not considered necessary within the particular 1858 operational environment, AH can be used to authenticate the binding 1859 between sensitivity labels in the IP header and the IP payload 1860 (including user data). This is a significant improvement over 1861 labeled IPv4 networks where the sensitivity information is trusted 1862 even though there is no authentication or cryptographic binding of 1863 the information to the IP header and user data. IPv4 networks might 1864 or might not use explicit labelling. IPv6 will normally use implicit 1865 sensitivity information that is part of the IPsec Security 1866 Association but not transmitted with each packet instead of using 1867 explicit sensitivity information. All explicit IP sensitivity 1868 information MUST be authenticated using either ESP, AH, or both. 1870 Encryption is useful and can be desirable even when all of the hosts 1871 are within a protected environment, for example, behind a firewall or 1872 disjoint from any external connectivity. ESP can be used, in 1873 conjunction with appropriate key management and encryption 1874 algorithms, in support of both DAC and MAC. (The choice of 1875 encryption and authentication algorithms, and the assurance level of 1876 an IPsec implementation will determine the environments in which an 1877 implementation may be deemed sufficient to satisfy MLS requirements.) 1878 Key management can make use of sensitivity information to provide 1879 MAC. IPsec implementations on systems claiming to provide MLS SHOULD 1880 be capable of using IPsec to provide MAC for IP-based communications. 1882 8.1 Relationship Between Security Associations and Data Sensitivity 1884 Both the Encapsulating Security Payload and the Authentication Header 1885 can be combined with appropriate Security Association policies to 1886 provide multi-level secure networking. In this case each SA (or SA 1887 bundle) is normally used for only a single instance of sensitivity 1888 information. For example, "PROPRIETARY - Internet Engineering" must 1889 be associated with a different SA (or SA bundle) from "PROPRIETARY - 1890 Finance". 1892 8.2 Sensitivity Consistency Checking 1894 An MLS implementation (both host and router) MAY associate 1895 sensitivity information, or a range of sensitivity information with 1896 an interface, or a configured IP address with its associated prefix 1897 (the latter is sometimes referred to as a logical interface, or an 1898 interface alias). If such properties exist, an implementation SHOULD 1899 compare the sensitivity information associated with the packet 1900 against the sensitivity information associated with the interface or 1901 address/prefix from which the packet arrived, or through which the 1902 packet will depart. This check will either verify that the 1903 sensitivities match, or that the packet's sensitivity falls within 1904 the range of the interface or address/prefix. 1906 The checking SHOULD be done on both inbound and outbound processing. 1908 8.3 Additional MLS Attributes for Security Association Databases 1910 Section 4.4 discussed two Security Association databases (the 1911 Security Policy Database (SPD) and the Security Association Database 1912 (SAD)) and the associated policy selectors and SA attributes. MLS 1913 networking introduces an additional selector/attribute: 1915 - Sensitivity information. 1917 The Sensitivity information aids in selecting the appropriate 1918 algorithms and key strength, so that the traffic gets a level of 1919 protection appropriate to its importance or sensitivity as described 1920 in section 8.1. The exact syntax of the sensitivity information is 1921 implementation defined. 1923 8.4 Additional Inbound Processing Steps for MLS Networking 1925 After an inbound packet has passed through IPsec processing, an MLS 1926 implementation SHOULD first check the packet's sensitivity (as 1927 defined by the SA (or SA bundle) used for the packet) with the 1928 interface or address/prefix as described in section 8.2 before 1929 delivering the datagram to an upper-layer protocol or forwarding it. 1931 The MLS system MUST retain the binding between the data received in 1932 an IPsec protected packet and the sensitivity information in the SA 1933 or SAs used for processing, so appropriate policy decisions can be 1934 made when delivering the datagram to an application or forwarding 1935 engine. The means for maintaining this binding are implementation 1936 specific. 1938 8.5 Additional Outbound Processing Steps for MLS Networking 1940 An MLS implementation of IPsec MUST perform two additional checks 1941 besides the normal steps detailed in section 5.1.1. When consulting 1942 the SPD or the SAD to find an outbound security association, the MLS 1943 implementation MUST use the sensitivity of the data to select an 1944 appropriate outbound SA or SA bundle. The second check comes before 1945 forwarding the packet out to its destination, and is the sensitivity 1946 consistency checking described in section 8.2. 1948 8.6 Additional MLS Processing for Security Gateways 1950 An MLS security gateway MUST follow the previously mentioned inbound 1951 and outbound processing rules as well as perform some additional 1952 processing specific to the intermediate protection of packets in an 1953 MLS environment. 1955 A security gateway MAY act as an outbound proxy, creating SAs for MLS 1956 systems that originate packets forwarded by the gateway. These MLS 1957 systems may explicitly label the packets to be forwarded, or the 1958 whole originating network may have sensitivity characteristics 1959 associated with it. The security gateway MUST create and use 1960 appropriate SAs for AH, ESP, or both, to protect such traffic it 1961 forwards. 1963 Similarly such a gateway SHOULD accept and process inbound AH and/or 1964 ESP packets and forward appropriately, using explicit packet 1965 labeling, or relying on the sensitivity characteristics of the 1966 destination network. 1968 9. Performance Issues 1970 The use of IPsec imposes computational performance costs on the hosts 1971 or security gateways that implement these protocols. These costs are 1972 associated with the memory needed for IPsec code and data structures, 1973 and the computation of integrity check values, encryption and 1974 decryption, and added per-packet handling. The per-packet 1975 computational costs will be manifested by increased latency and, 1976 possibly, reduced throughout. Use of SA/key management protocols, 1977 especially ones that employ public key cryptography, also adds 1978 computational performance costs to use of IPsec. These per- 1979 association computational costs will be manifested in terms of 1980 increased latency in association establishment. For many hosts, it 1981 is anticipated that software-based cryptography will not appreciably 1982 reduce throughput, but hardware may be required for security gateways 1983 (since they represent aggregation points), and for some hosts. 1985 The use of IPsec also imposes bandwidth utilization costs on 1986 transmission, switching, and routing components of the Internet 1987 infrastructure, components not implementing IPsec. This is due to 1988 the increase in the packet size resulting from the addition of AH 1989 and/or ESP headers, AH and ESP tunneling (which adds a second IP 1990 header), and the increased packet traffic associated with key 1991 management protocols. It is anticipated that, in most instances, 1992 this increased bandwidth demand will not noticeably affect the 1993 Internet infrastructure. However, in some instances, the effects may 1994 be significant, e.g., transmission of ESP encrypted traffic over a 1995 dialup link that otherwise would have compressed the traffic. 1997 Note: The initial SA establishment overhead will be felt in the first 1998 packet. This delay could impact the transport layer and application. 1999 For example, it could cause TCP to retransmit the SYN before the 2000 ISAKMP exchange is done. The effect of the delay would be different 2001 on UDP than TCP because TCP shouldn't transmit anything other than 2002 the SYN until the connection is set up whereas UDP will go ahead and 2003 transmit data beyond the first packet. 2005 Note: As discussed earlier, compression can still be employed at 2006 layers above IP. There is an IETF working group (IP Payload 2007 Compression Protocol (ippcp)) working on "protocol specifications 2008 that make it possible to perform lossless compression on individual 2009 payloads before the payload is processed by a protocol that encrypts 2010 it. These specifications will allow for compression operations to be 2011 performed prior to the encryption of a payload by IPsec protocols." 2013 10. Conformance Requirements 2015 All IPv4 systems that claim to implement IPsec MUST comply with all 2016 requirements of the Security Architecture document. All IPv6 systems 2017 MUST comply with all requirements of the Security Architecture 2018 document. 2020 11. Security Considerations 2022 The focus of this document is security; hence security considerations 2023 permeate this specification. 2025 12. Differences from RFC 1825 2027 This architecture document differs substantially from RFC 1825 in 2028 detail and in organization, but the fundamental notions are 2029 unchanged. This document provides considerable additional detail in 2030 terms of compliance specifications. It introduces the SPD and SAD, 2031 and the notion of SA selectors. It is aligned with the new versions 2032 of AH and ESP, which also differ from their predecessors. Specific 2033 requirements for supported combinations of AH and ESP are newly 2034 added, as are details of PMTU management. 2036 Acknowledgements 2038 Many of the concepts embodied in this specification were derived from 2039 or influenced by the US Government's SP3 security protocol, ISO/IEC's 2040 NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], 2041 and the work done for SNMP Security and SNMPv2 Security. 2043 For over 3 years (although it sometimes seems *much* longer), this 2044 document has evolved through multiple versions and iterations. 2045 During this time, many people have contributed significant ideas and 2046 energy to the process and the documents themselves. The authors 2047 would like to thank Karen Seo for providing extensive help in the 2048 review, editing, background research, and coordination for this 2049 version of the specification. The authors would also like to thank 2050 the members of the IPsec and IPng working groups, with special 2051 mention of the efforts of (in alphabetic order): Steve Bellovin, 2052 Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry 2053 Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William 2054 Simpson, Harry Varnis, and Nina Yuan. 2056 Appendix A -- Glossary 2058 This section provides definitions for several key terms that are 2059 employed in this document. Other documents provide additional 2060 definitions and background information relevant to this technology, 2061 e.g., [VK83, HA94]. Included in this glossary are generic security 2062 service and security mechanism terms, plus IPsec-specific terms. 2064 Access Control 2065 Access control is a security service that prevents unauthorized 2066 use of a resource, including the prevention of use of a resource 2067 in an unauthorized manner. In the IPsec context, the resource to 2068 which access is being controlled is often: 2069 o for a host, computing cycles or data 2070 o for a security gateway, a network behind the gateway or 2071 bandwidth on that network. 2073 Anti-replay 2074 [See "Integrity" below] 2076 Authentication 2077 This term is used informally to refer to the combination of two 2078 nominally distinct security services, data origin authentication 2079 and connectionless integrity. See the definitions below for each 2080 of these services. 2082 Availability 2083 Availability, when viewed as a security service, addresses the 2084 security concerns engendered by attacks against networks that deny 2085 or degrade service. For example, in the IPsec context, the use of 2086 anti-replay mechanisms in AH and ESP support availability. 2088 Confidentiality 2089 Confidentiality is the security service that protects data from 2090 unauthorized disclosure. The primary confidentiality concern in 2091 most instances is unauthorized disclosure of application level 2092 data, but disclosure of the external characteristics of 2093 communication also can be a concern in some circumstances. 2094 Traffic flow confidentiality is the service that addresses this 2095 latter concern by concealing source and destination addresses, 2096 message length, or frequency of communication. In the IPsec 2097 context, using ESP in tunnel mode, especially at a security 2098 gateway, can provide some level of traffic flow confidentiality. 2099 (See also traffic analysis, below.) 2101 Encryption 2102 Encryption is a security mechanism used to transform data from an 2103 intelligible form (plaintext) into an unintelligible form 2104 (ciphertext), to provide confidentiality. The inverse 2105 transformation process is designated "decryption". Oftimes the 2106 term "encryption" is used to generically refer to both processes. 2108 Data Origin Authentication 2109 Data origin authentication is a security service that verifies the 2110 identity of the claimed source of data. This service is usually 2111 bundled with connectionless integrity service. 2113 Integrity 2114 Integrity is a security service that ensures that modifications to 2115 data are detectable. Integrity comes in various flavors to match 2116 application requirements. IPsec supports two forms of integrity: 2117 connectionless and a form of partial sequence integrity. 2118 Connectionless integrity is a service that detects modification of 2119 an individual IP datagram, without regard to the ordering of the 2120 datagram in a stream of traffic. The form of partial sequence 2121 integrity offered in IPsec is referred to as anti-replay 2122 integrity, and it detects arrival of duplicate IP datagrams 2123 (within a constrained window). This is in contrast to 2124 connection-oriented integrity, which imposes more stringent 2125 sequencing requirements on traffic, e.g., to be able to detect 2126 lost or re-ordered messages. Although authentication and 2127 integrity services often are cited separately, in practice they 2128 are intimately connected and almost always offered in tandem. 2130 Security Association (SA) 2131 A simplex (uni-directional) logical connection, created for 2132 security purposes. All traffic traversing an SA is provided the 2133 same security processing. In IPsec, an SA is an internet layer 2134 abstraction implemented through the use of AH or ESP. 2136 Security Gateway 2137 A security gateway is an intermediate system that acts as the 2138 communications interface between two networks. The set of hosts 2139 (and networks) on the external side of the security gateway is 2140 viewed as untrusted (or less trusted), while the networks and 2141 hosts and on the internal side are viewed as trusted (or more 2142 trusted). The internal subnets and hosts served by a security 2143 gateway are presumed to be trusted by virtue of sharing a common, 2144 local, security administration. (See "Trusted Subnetwork" below.) 2145 In the IPsec context, a security gateway is a point at which AH 2146 and/or ESP is implemented in order to serve a set of internal 2147 hosts, providing security services for these hosts when they 2148 communicate with external hosts also employing IPsec (either 2149 directly or via another security gateway). 2151 SPI 2152 Acronym for "Security Parameters Index". The combination of a 2153 destination address, a security protocol, and an SPI uniquely 2154 identifies a security association (SA, see above). The SPI is 2155 carried in AH and ESP protocols to enable the receiving system to 2156 select the SA under which a received packet will be processed. An 2157 SPI has only local significance, as defined by the creator of the 2158 SA (usually the receiver of the packet carrying the SPI); thus an 2159 SPI is generally viewed as an opaque bit string. However, the 2160 creator of an SA may choose to interpret the bits in an SPI to 2161 facilitate local processing. 2163 Traffic Analysis 2164 The analysis of network traffic flow for the purpose of deducing 2165 information that is useful to an adversary. Examples of such 2166 information are frequency of transmission, the identities of the 2167 conversing parties, sizes of packets, flow identifiers, etc. 2168 [Sch94] 2170 Trusted Subnetwork 2171 A subnetwork containing hosts and routers that trust each other 2172 not to engage in active or passive attacks. There also is an 2173 assumption that the underlying communications channel (e.g., a LAN 2174 or CAN) isn't being attacked by other means. 2176 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues 2178 B.1 DF bit 2180 In cases where a system (host or gateway) adds an encapsulating 2181 header (e.g., ESP tunnel), should/must the DF bit in the original 2182 packet be copied to the encapsulating header? 2184 Fragmenting seems correct for some situations, e.g., it might be 2185 appropriate to fragment packets over a network with a very small MTU, 2186 e.g., a packet radio network, or a cellular phone hop to mobile node, 2187 rather than propagate back a very small PMTU for use over the rest of 2188 the path. In other situations, it might be appropriate to set the DF 2189 bit in order to get feedback from later routers about PMTU 2190 constraints which require fragmentation. The existence of both of 2191 these situations argues for enabling a system to decide whether or 2192 not to fragment over a particular network "link", i.e., for requiring 2193 an implementation to be able to copy the DF bit (and to process ICMP 2194 PMTU messages), but making it an option to be selected on a per 2195 interface basis. In other words, an administrator should be able to 2196 configure the router's treatment of the DF bit (set, clear, copy from 2197 encapsulated header) for each interface. 2199 Note: If a bump-in-the-stack implementation of IPsec attempts to 2200 apply different IPsec algorithms based on source/destination ports, 2201 it will be difficult to apply Path MTU adjustments. 2203 B.2 Fragmentation 2205 Fragmentation MUST be done after outbound IPsec processing. 2206 Reassembly MUST be done before inbound IPsec processing. The general 2207 reasoning is shown below (delimited by the ****'s). 2209 NOTE: IPsec always has to figure out what the encapsulating IP header 2210 fields are. This is independent of where you insert IPsec and is 2211 intrinsic to the definition of IPsec. Therefore any IPsec 2212 implementation that is not integrated into an IP implementation must 2213 include code to construct the necessary IP headers (e.g., IP2): 2215 o AH-tunnel --> IP2-AH-IP1-Transport-Data 2216 o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer 2218 ********************************************************************** 2220 Overall, the fragmentation/reassembly approach described above works 2221 for all cases examined. 2223 AH Xport AH Tunnel ESP Xport ESP Tunnel 2224 Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 2225 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- 2226 Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y 2227 Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y 2228 S. Gwy (integr w/ IP stack) Y Y Y Y 2229 Outboard crypto processor * 2231 * If the crypto processor system has its own IP address, then it 2232 is covered by the security gateway case. This box receives 2233 the packet from the host and performs IPsec processing. It 2234 has to be able to handle the same AH, ESP, and related 2235 IPv4/IPv6 tunnel processing that a security gateway would have 2236 to handle. If it doesn't have it's own address, then it is 2237 similar to the bump-in-the stack implementation between IP and 2238 the network drivers. 2240 The following analysis assumes that: 2242 1. There is only one IPsec module in a given system's stack. 2243 There isn't an IPsec module A (adding ESP/encryption and 2244 thus) hiding the transport protocol, SRC port, and DEST port 2245 from IPsec module B. 2246 2. There are several places where IPsec could be implemented 2247 (as shown in the table above). 2248 a. Hosts with integration of IPsec into the native IP 2249 implementation. Implementer has access to the source 2250 for the stack. 2251 b. Hosts with bump-in-the-stack implementations, where 2252 IPsec is implemented between IP and the local network 2253 drivers. Source access for stack is not available; 2254 but there are well-defined interfaces that allows the 2255 IPsec code to be incorporated into the system. 2256 c. Security gateways and outboard crypto processors with 2257 integration of IPsec into the stack. 2258 3. Not all of the above approaches are feasible in all hosts. 2259 But it was assumed that for each approach, there are some 2260 hosts for whom the approach is feasible. 2262 For each of the above 3 categories, there are IPv4 and IPv6, AH 2263 transport and tunnel modes, and ESP transport and tunnel modes -- for 2264 a total of 24 cases (3 x 2 x 4). 2266 Some header fields and interface fields are listed here for ease of 2267 reference -- they're not in the header order, but instead listed to 2268 allow comparison between the columns. (* = not covered by AH 2269 authentication. ESP authentication doesn't cover any headers that 2270 precede it.) 2271 IP/Transport Interface 2272 IPv4 IPv6 (RFC 1122 -- Sec 3.4) 2273 ---- ---- ---------------------- 2274 Version = 4 Version = 6 2275 Header Len 2276 *TOS Class,Flow Lbl TOS 2277 Packet Len Payload Len Len 2278 ID ID (optional) 2279 *Flags DF 2280 *Offset 2281 *TTL *Hop Limit TTL 2282 Protocol Next Header 2283 *Checksum 2284 Src Address Src Address Src Address 2285 Dst Address Dst Address Dst Address 2286 Options? Options? Opt 2288 ? = AH covers Option-Type and Option-Length, but 2289 might not cover Option-Data. 2291 The results for each of the 20 cases is shown below ("works" = will 2292 work if system fragments after outbound IPsec processing, reassembles 2293 before inbound IPsec processing). Notes indicate implementation 2294 issues. 2296 a. Hosts (integrated into IP stack) 2297 o AH-transport --> (IP1-AH-Transport-Data) 2298 - IPv4 -- works 2299 - IPv6 -- works 2300 o AH-tunnel --> (IP2-AH-IP1-Transport-Data) 2301 - IPv4 -- works 2302 - IPv6 -- works 2303 o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) 2304 - IPv4 -- works 2305 - IPv6 -- works 2306 o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) 2307 - IPv4 -- works 2308 - IPv6 -- works 2310 b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and 2311 network drivers. In this case, the IPsec module would have to 2312 do something like one of the following for fragmentation and 2313 reassembly. 2314 - do the fragmentation/reassembly work itself and 2315 send/receive the packet directly to/from the network 2316 layer. In AH or ESP transport mode, this is fine. In AH 2317 or ESP tunnel mode where the tunnel end is at the ultimate 2318 destination, this is fine. But in AH or ESP tunnel modes 2319 where the tunnel end is different from the ultimate 2320 destination and where the source host is multi-homed, this 2321 approach could result in sub-optimal routing because the 2322 IPsec module may be unable to obtain the information 2323 needed (LAN interface and next-hop gateway) to direct the 2324 packet to the appropriate network interface. This is not 2325 a problem if the interface and next-hop gateway are the 2326 same for the ultimate destination and for the tunnel end. 2327 But if they are different, then IPsec would need to know 2328 the LAN interface and the next-hop gateway for the tunnel 2329 end. (Note: The tunnel end (security gateway) is highly 2330 likely to be on the regular path to the ultimate 2331 destination. But there could also be more than one path 2332 to the destination, e.g., the host could be at an 2333 organization with 2 firewalls. And the path being used 2334 could involve the less commonly chosen firewall.) OR 2335 - pass the IPsec'd packet back to the IP layer where an 2336 extra IP header would end up being pre-pended and the 2337 IPsec module would have to check and let IPsec'd fragments 2338 go by. 2339 OR 2340 - pass the packet contents to the IP layer in a form such 2341 that the IP layer recreates an appropriate IP header 2343 At the network layer, the IPsec module will have access to the 2344 following selectors from the packet -- SRC address, DST address, 2345 Next Protocol, and if there's a transport layer header --> SRC 2346 port and DST port. One cannot assume IPsec has access to the 2347 Name. It is assumed that the available selector information is 2348 sufficient to figure out the relevant Security Policy entry and 2349 Security Association(s). 2351 o AH-transport --> (IP1-AH-Transport-Data) 2352 - IPv4 -- works 2353 - IPv6 -- works 2354 o AH-tunnel --> (IP2-AH-IP1-Transport-Data) 2355 - IPv4 -- works 2356 - IPv6 -- works 2357 o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) 2358 - IPv4 -- works 2359 - IPv6 -- works 2360 o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) 2361 - IPv4 -- works 2362 - IPv6 -- works 2364 c. Security gateways -- integrate IPsec into the IP stack 2366 NOTE: The IPsec module will have access to the following 2367 selectors from the packet -- SRC address, DST address, Next 2368 Protocol, and if there's a transport layer header --> SRC port 2369 and DST port. It won't have access to the User ID (only Hosts 2370 have access to User ID information.) Unlike some 2371 Bump-in-the-stack implementations, security gateways may be able 2372 to look up the Source Address in the DNS to provide a System 2373 Name, e.g., in situations involving use of dynamically assigned 2374 IP addresses in conjunction with dynamically updated DNS entries. 2375 It also won't have access to the transport layer information if 2376 there is an ESP header, or if it's not the first fragment of a 2377 fragmented message. It is assumed that the available selector 2378 information is sufficient to figure out the relevant Security 2379 Policy entry and Security Association(s). 2381 o AH-tunnel --> (IP2-AH-IP1-Transport-Data) 2382 - IPv4 -- works 2383 - IPv6 -- works 2384 o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) 2385 - IPv4 -- works 2386 - IPv6 -- works 2388 ********************************************************************** 2390 B.3 Path MTU Discovery 2392 As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for 2393 Path MTU Discovery. 2395 The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) 2396 is: 2398 ==== = security association (AH or ESP, transport or tunnel) 2399 ---- = connectivity (or if so labelled, administrative boundary) 2400 .... = ICMP message (hereafter referred to as ICMP PMTU) for 2402 IPv4: 2403 - Type = 3 (Destination Unreachable) 2404 - Code = 4 (Fragmentation needed and DF set) 2405 - Next-Hop MTU in the low-order 16 bits of the second 2406 word of the ICMP header (labelled unused in RFC 792), 2407 with high-order 16 bits set to zero 2409 IPv6 (RFC 1885): 2410 - Type = 2 (Packet Too Big) 2411 - Code = 0 (Fragmentation needed and DF set) 2412 - Next-Hop MTU in the 32 bit MTU field of the ICMP6 2414 Hx = host x 2415 Rx = router x 2416 SGx = security gateway x 2417 X* = X supports IPsec 2419 B.3.1 Identifying the Originating Host(s) 2421 The amount of information returned with the ICMP message is limited 2422 and this affects what selectors are available to identify security 2423 associations, originating hosts, etc. for use in further propagating 2424 the PMTU information. 2426 In brief... An ICMP message must contain the following information 2427 from the "offending" packet: 2428 - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits 2430 Accordingly, in the IPv4 context, an ICMP PMTU may identify only the 2431 first (outermost) security association. This is because the ICMP 2432 PMTU may contain only 64 bits of the "offending" packet beyond the IP 2433 header, which would capture only the first SPI from AH or ESP. In 2434 the IPv6 context, an ICMP PMTU will probably provide all the SPIs and 2435 the selectors in the IP header, but maybe not the SRC/DST ports (in 2436 the transport header) or the encapsulated (TCP, UDP, etc.) protocol. 2437 Moreover, if ESP is used, the transport ports and protocol selectors 2438 may be encrypted. 2440 Looking at the diagram below of a security gateway tunnel (as 2441 mentioned elsewhere, security gateways do not use transport mode)... 2443 H1 =================== H3 2444 \ | | / 2445 H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 2446 / ^ | \ 2447 H2 |........| H4 2449 Suppose that the security policy for SG1 is to use a single SA to SG2 2450 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, 2451 and H5. And suppose H0 sends a data packet to H5 which causes R1 to 2452 send an ICMP PMTU message to SG1. If the PMTU message has only the 2453 SPI, SG1 will be able to look up the SA and find the list of possible 2454 hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out 2455 that H0 sent the traffic that triggered the ICMP PMTU message. 2457 original after IPsec ICMP 2458 packet processing packet 2459 -------- ----------- ------ 2460 IP-3 header (S = R1, D = SG1) 2461 ICMP header (includes PMTU) 2462 IP-2 header IP-2 header (S = SG1, D = SG2) 2463 ESP header minimum of 64 bits of ESP hdr (*) 2464 IP-1 header IP-1 header 2465 TCP header TCP header 2466 TCP data TCP data 2467 ESP trailer 2469 (*) The 64 bits will include enough of the ESP (or AH) header to 2470 include the SPI. 2471 - ESP -- SPI (32 bits), Seq number (32 bits) 2472 - AH -- Next header (8 bits), Payload Len (8 bits), 2473 Reserved (16 bits), SPI (32 bits) 2475 This limitation on the amount of information returned with an ICMP 2476 message creates a problem in identifying the originating hosts for 2477 the packet (so as to know where to further propagate the ICMP PMTU 2478 information). If the ICMP message contains only 64 bits of the IPsec 2479 header (minimum for IPv4), then the IPsec selectors (e.g., Source and 2480 Destination addresses, Next Protocol, Source and Destination ports, 2481 etc.) will have been lost. But the ICMP error message will still 2482 provide SG1 with the SPI, the PMTU information and the source and 2483 destination gateways for the relevant security association. 2485 The destination security gateway and SPI uniquely define a security 2486 association which in turn defines a set of possible originating 2487 hosts. At this point, SG1 could: 2489 a. send the PMTU information to all the possible originating hosts. 2490 This would not work well if the host list is a wild card or if 2491 many/most of the hosts weren't sending to SG1; but it might work 2492 if the SPI/destination/etc mapped to just one or a small number of 2493 hosts. 2494 b. store the PMTU with the SPI/etc and wait until the next packet(s) 2495 arrive from the originating host(s) for the relevant security 2496 association. If it/they are bigger than the PMTU, drop the 2497 packet(s), and compose ICMP PMTU message(s) with the new 2498 packet(s) and the updated PMTU, and send the originating host(s) 2499 the ICMP message(s) about the problem. This involves a delay in 2500 notifying the originating host(s), but avoids the problems of (a). 2502 Since only the latter approach is feasible in all instances, a 2503 security gateway MUST provide such support, as an option. However, 2504 if the ICMP message contains more information from the original 2505 packet, then there MAY be enough information to immediately determine 2506 to which host to propagate the ICMP/PMTU message and to provide that 2507 system with the 5 fields (source address, destination address, source 2508 port, destination port, and transport protocol) needed to determine 2509 where to store/update the PMTU. Under such circumstances, a security 2510 gateway MUST generate an ICMP PMTU message immediately upon receipt 2511 of an ICMP PMTU from further down the path. NOTE: The Next Protocol 2512 field MAY not be contained in the ICMP message and the use of ESP 2513 encryption MAY hide the selector fields that have been encrypted. 2515 B.3.2 Calculation of PMTU 2517 The calculation of PMTU from an ICMP PMTU has to take into account 2518 the addition of any IPsec header by H1 -- AH and/or ESP transport, or 2519 ESP or AH tunnel. Within a single host, multiple applications may 2520 share an SPI and nesting of security associations may occur. (See 2521 Section 4.5 Basic Combinations of Security Associations for 2522 description of the combinations that MUST be supported). The diagram 2523 below illustrates an example of security associations between a pair 2524 of hosts (as viewed from the perspective of one of the hosts.) (ESPx 2525 or AHx = transport mode) 2527 Socket 1 -------------------------| 2528 | 2529 Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet 2531 In order to figure out the PMTU for each socket that maps to SPI-B, 2532 it will be necessary to have backpointers from SPI-B to each of the 2 2533 paths that lead to it -- Socket 1 and Socket 2/SPI-A. 2535 B.3.3 Granularity of Maintaining PMTU Data 2537 In hosts, the granularity with which PMTU ICMP processing can be done 2538 differs depending on the implementation situation. Looking at a 2539 host, there are three situations that are of interest with respect to 2540 PMTU issues: 2542 a. Integration of IPsec into the native IP implementation 2543 b. Bump-in-the-stack implementations, where IPsec is implemented 2544 "underneath" an existing implementation of a TCP/IP protocol 2545 stack, between the native IP and the local network drivers 2546 c. No IPsec implementation -- This case is included because it is 2547 relevant in cases where a security gateway is sending PMTU 2548 information back to a host. 2550 Only in case (a) can the PMTU data be maintained at the same 2551 granularity as communication associations. In the other cases, the 2552 IP layer will maintain PMTU data at the granularity of Source and 2553 Destination IP addresses (and optionally TOS/Class), as described in 2554 RFC 1191. This is an important difference, because more than one 2555 communication association may map to the same source and destination 2556 IP addresses, and each communication association may have a different 2557 amount of IPsec header overhead (e.g., due to use of different 2558 transforms or different algorithms). The examples below illustrate 2559 this. 2561 In cases (a) and (b)... Suppose you have the following situation. 2562 H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds 2563 the PMTU of the network hop between them. 2565 ================================== 2566 | | 2567 H1* --- R1 ----- R2 ---- R3 ---- H2* 2568 ^ | 2569 |.......| 2571 If R1 is configured to not fragment subscriber traffic, then R1 sends 2572 an ICMP PMTU message with the appropriate PMTU to H1. H1's 2573 processing would vary with the nature of the implementation. In case 2574 (a) (native IP), the security services are bound to sockets or the 2575 equivalent. Here the IP/IPsec implementation in H1 can store/update 2576 the PMTU for the associated socket. In case (b), the IP layer in H1 2577 can store/update the PMTU but only at the granularity of Source and 2578 Destination addresses and possibly TOS/Class, as noted above. So the 2579 result may be sub-optimal, since the PMTU for a given 2580 SRC/DST/TOS/Class will be the subtraction of the largest amount of 2581 IPsec header used for any communication association between a given 2582 source and destination. 2584 In case (c), there has to be a security gateway to have any IPsec 2585 processing. So suppose you have the following situation. H1 is 2586 sending to H2 and the packet to be sent from SG1 to R exceeds the 2587 PMTU of the network hop between them. 2589 ================ 2590 | | 2591 H1 ---- SG1* --- R --- SG2* ---- H2 2592 ^ | 2593 |.......| 2595 As described above for case (b), the IP layer in H1 can store/update 2596 the PMTU but only at the granularity of Source and Destination 2597 addresses, and possibly TOS/Class. So the result may be sub-optimal, 2598 since the PMTU for a given SRC/DST/TOS/Class will be the subtraction 2599 of the largest amount of IPsec header used for any communication 2600 association between a given source and destination. 2602 B.3.4 Per Socket Maintenance of PMTU Data 2604 Implementation of the calculation of PMTU (Section B.3.2) and support 2605 for PMTUs at the granularity of individual "communication 2606 associations" (Section B.3.3) is a local matter. However, a socket- 2607 based implementation of IPsec in a host SHOULD maintain the 2608 information on a per socket basis. Bump in the stack systems MUST 2609 pass an ICMP PMTU to the host IP implementation, after adjusting it 2610 for any IPsec header overhead added by these systems. The 2611 determination of the overhead SHOULD be determined by analysis of the 2612 SPI and any other selector information present in a returned ICMP 2613 PMTU message. 2615 B.3.5 Delivery of PMTU Data to the Transport Layer 2617 The host mechanism for getting the updated PMTU to the transport 2618 layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). 2620 B.3.6 Aging of PMTU Data 2622 This topic is covered in Section 6.1.2.4. 2624 Appendix C -- Sequence Space Window Code Example 2626 This appendix contains a routine that implements a bitmask check for 2627 a 32 packet window. It was provided by James Hughes 2628 (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) 2629 and is intended as an implementation example. Note that this code 2630 both checks for a replay and updates the window. Thus the algorithm, 2631 as shown, should only be called AFTER the packet has been 2632 authenticated. Implementers might wish to consider splitting the 2633 code to do the check for replays before computing the ICV. If the 2634 packet is not a replay, the code would then compute the ICV, (discard 2635 any bad packets), and if the packet is OK, update the window. 2637 #include 2638 #include 2639 typedef unsigned long u_long; 2641 enum { 2642 ReplayWindowSize = 32 2643 }; 2645 u_long bitmap = 0; /* session state - must be 32 bits */ 2646 u_long lastSeq = 0; /* session state */ 2648 /* Returns 0 if packet disallowed, 1 if packet permitted */ 2649 int ChkReplayWindow(u_long seq); 2651 int ChkReplayWindow(u_long seq) { 2652 u_long diff; 2654 if (seq == 0) return 0; /* first == 0 or wrapped */ 2655 if (seq > lastSeq) { /* new larger sequence number */ 2656 diff = seq - lastSeq; 2657 if (diff < ReplayWindowSize) { /* In window */ 2658 bitmap <<= diff; 2659 bitmap |= 1; /* set bit for this packet */ 2660 } else bitmap = 1; /* This packet has a "way larger" */ 2661 lastSeq = seq; 2662 return 1; /* larger is good */ 2663 } 2664 diff = lastSeq - seq; 2665 if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ 2666 if (bitmap & ((u_long)1 << diff)) return 0; /* this packet already seen */ 2667 bitmap |= ((u_long)1 << diff); /* mark as seen */ 2668 return 1; /* out of order but good */ 2669 } 2671 char string_buffer[512]; 2672 #define STRING_BUFFER_SIZE sizeof(string_buffer) 2674 int main() { 2675 int result; 2676 u_long last, current, bits; 2678 printf("Input initial state (bits in hex, last msgnum):\n"); 2679 if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); 2680 sscanf(string_buffer, "%lx %lu", &bits, &last); 2681 if (last != 0) 2682 bits |= 1; 2683 bitmap = bits; 2684 lastSeq = last; 2685 printf("bits:%08lx last:%lu\n", bitmap, lastSeq); 2686 printf("Input value to test (current):\n"); 2688 while (1) { 2689 if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; 2690 sscanf(string_buffer, "%lu", ¤t); 2691 result = ChkReplayWindow(current); 2692 printf("%-3s", result ? "OK" : "BAD"); 2693 printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); 2694 } 2695 return 0; 2696 } 2697 Appendix D -- Categorization of ICMP messages 2699 The tables below characterize ICMP messages as being either host 2700 generated, router generated, both, unassigned/unknown. The first set 2701 are IPv4. The second set are IPv6. 2703 IPv4 2705 Type Name/Codes Reference 2706 ========================================================================= 2707 HOST GENERATED: 2708 3 Destination Unreachable 2709 2 Protocol Unreachable [RFC792] 2710 3 Port Unreachable [RFC792] 2711 8 Source Host Isolated [RFC792] 2712 14 Host Precedence Violation [RFC1812] 2713 10 Router Selection [RFC1256] 2715 Type Name/Codes Reference 2716 ========================================================================= 2717 ROUTER GENERATED: 2718 3 Destination Unreachable 2719 0 Net Unreachable [RFC792] 2720 4 Fragmentation Needed, Don't Fragment was Set [RFC792] 2721 5 Source Route Failed [RFC792] 2722 6 Destination Network Unknown [RFC792] 2723 7 Destination Host Unknown [RFC792] 2724 9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792] 2725 11 Destination Network Unreachable for Type of Service [RFC792] 2726 5 Redirect 2727 0 Redirect Datagram for the Network (or subnet) [RFC792] 2728 2 Redirect Datagram for the Type of Service & Network [RFC792] 2729 9 Router Advertisement [RFC1256] 2730 18 Address Mask Reply [RFC950] 2731 IPv4 2732 Type Name/Codes Reference 2733 ========================================================================= 2734 BOTH ROUTER AND HOST GENERATED: 2735 0 Echo Reply [RFC792] 2736 3 Destination Unreachable 2737 1 Host Unreachable [RFC792] 2738 10 Comm. w/Dest. Host is Administratively Prohibited [RFC792] 2739 12 Destination Host Unreachable for Type of Service [RFC792] 2740 13 Communication Administratively Prohibited [RFC1812] 2741 15 Precedence cutoff in effect [RFC1812] 2742 4 Source Quench [RFC792] 2743 5 Redirect 2744 1 Redirect Datagram for the Host [RFC792] 2745 3 Redirect Datagram for the Type of Service and Host [RFC792] 2746 6 Alternate Host Address [JBP] 2747 8 Echo [RFC792] 2748 11 Time Exceeded [RFC792] 2749 12 Parameter Problem [RFC792,RFC1108] 2750 13 Timestamp [RFC792] 2751 14 Timestamp Reply [RFC792] 2752 15 Information Request [RFC792] 2753 16 Information Reply [RFC792] 2754 17 Address Mask Request [RFC950] 2755 30 Traceroute [RFC1393] 2756 31 Datagram Conversion Error [RFC1475] 2757 32 Mobile Host Redirect [Johnson] 2758 39 SKIP [Markson] 2759 40 Photuris [Simpson] 2761 Type Name/Codes Reference 2762 ========================================================================= 2763 UNASSIGNED TYPE OR UNKNOWN GENERATOR: 2764 1 Unassigned [JBP] 2765 2 Unassigned [JBP] 2766 7 Unassigned [JBP] 2767 19 Reserved (for Security) [Solo] 2768 20-29 Reserved (for Robustness Experiment) [ZSu] 2769 33 IPv6 Where-Are-You [Simpson] 2770 34 IPv6 I-Am-Here [Simpson] 2771 35 Mobile Registration Request [Simpson] 2772 36 Mobile Registration Reply [Simpson] 2773 37 Domain Name Request [Simpson] 2774 38 Domain Name Reply [Simpson] 2775 41-255 Reserved [JBP] 2776 IPv6 2778 Type Name/Codes Reference 2779 ========================================================================= 2780 HOST GENERATED: 2781 1 Destination Unreachable [RFC 1885] 2782 4 Port Unreachable 2784 Type Name/Codes Reference 2785 ========================================================================= 2786 ROUTER GENERATED: 2787 1 Destination Unreachable [RFC1885] 2788 0 No Route to Destination 2789 1 Comm. w/Destination is Administratively Prohibited 2790 2 Not a Neighbor 2791 3 Address Unreachable 2792 2 Packet Too Big [RFC1885] 2793 0 2794 3 Time Exceeded [RFC1885] 2795 0 Hop Limit Exceeded in Transit 2796 1 Fragment reassembly time exceeded 2798 Type Name/Codes Reference 2799 ========================================================================= 2800 BOTH ROUTER AND HOST GENERATED: 2801 4 Parameter Problem [RFC1885] 2802 0 Erroneous Header Field Encountered 2803 1 Unrecognized Next Header Type Encountered 2804 2 Unrecognized IPv6 Option Encountered 2806 References 2808 [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: 2809 Mathematical Foundations and Model", Technical Report M74- 2810 244, The MITRE Corporation, Bedford, MA, May 1973. 2812 [Bra97] S. Bradner, "Key words for use in RFCs to Indicate 2813 Requirement Level," RFC-2119, March 1997. 2815 [DoD85] US National Computer Security Center, "Department of 2816 Defense Trusted Computer System Evaluation Criteria", DoD 2817 5200.28-STD, US Department of Defense, Ft. Meade, MD., 2818 December 1985. 2820 [DoD87] US National Computer Security Center, "Trusted Network 2821 Interpretation of the Trusted Computer System Evaluation 2822 Criteria", NCSC-TG-005, Version 1, US Department of 2823 Defense, Ft. Meade, MD., 31 July 1987. 2825 [HA94] N. Haller & R. Atkinson, "On Internet Authentication", 2826 RFC-1704, DDN Network Information Center, October 1994. 2828 [HC98] D. Harkins & D. Carrel, "The Internet Key Exchange (IKE)", 2829 Internet Draft, June 1998. 2831 [HM97] H. Harney, C. Muckenhirn, "Group Key Management Protocol 2832 (GKMP) Architecture", RFC 2094, July 1997. 2834 [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 2835 DIS 11577, International Standards Organisation, Geneva, 2836 Switzerland, 29 November 1992. 2838 [IB93] John Ioannidis and Matt Blaze, "Architecture and 2839 Implementation of Network-layer Security Under Unix", 2840 Proceedings of USENIX Security Symposium, Santa Clara, CA, 2841 October 1993. 2843 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- 2844 Layer Security for IP", presentation at the Spring 1993 2845 IETF Meeting, Columbus, Ohio 2847 [KA98a] Steve Kent, Randall Atkinson, "IP Authentication Header", 2848 Internet Draft, July 1998. 2850 [KA98b] Steve Kent, Randall Atkinson, "IP Encapsulating Security 2851 Payload (ESP)", Internet Draft, July 1998. 2853 [Ken91] Steve Kent, "US DoD Security Options for the Internet 2854 Protocol", RFC-1108, DDN Network Information Center, 2855 November 1991. 2857 [MSST97] D Maughan, M. Schertler, M. Schneider, & J. Turner, 2858 "Internet Security Association and Key Management Protocol 2859 (ISAKMP)", Internet Draft, March 1998. 2861 [Orm97] H. K. Orman, "The OAKLEY Key Determination Protocol", 2862 Internet Draft, July 1997. 2864 [Pip98] D. Piper, "The Internet IP Security Domain of 2865 Interpretation for ISAKMP", Internet Draft, May 1998. 2867 [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John 2868 Wiley & Sons, New York, NY, 1994. 2870 [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, 2871 Document SDN.301, Revision 1.5, 15 May 1989, published in 2872 NIST Publication NIST-IR-90-4250, February 1990. 2874 [SMPT98] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload 2875 Compression Protocol (IPComp)", Internet Draft, May 1998. 2877 [TDG97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 2878 Roadmap", Internet Draft, December 1997. 2880 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- 2881 level Networks", ACM Computing Surveys, Vol. 15, No. 2, 2882 June 1983. 2884 Disclaimer 2886 The views and specification expressed in this document are those of 2887 the authors and are not necessarily those of their employers. The 2888 authors and their employers specifically disclaim responsibility for 2889 any problems arising from correct or incorrect implementation or use 2890 of this design. 2892 Author Information 2894 Stephen Kent 2895 BBN Corporation 2896 70 Fawcett Street 2897 Cambridge, MA 02140 2898 USA 2899 E-mail: kent@bbn.com 2900 Telephone: +1 (617) 873-3988 2902 Randall Atkinson 2903 @Home Network 2904 425 Broadway 2905 Redwood City, CA 94063 2906 USA 2907 E-mail: rja@corp.home.net 2908 Telephone: +1 (415) 569-5000 2910 Copyright (C) The Internet Society (July 1998). All Rights Reserved. 2912 This document and translations of it may be copied and furnished to 2913 others, and derivative works that comment on or otherwise explain it 2914 or assist in its implementation may be prepared, copied, published 2915 and distributed, in whole or in part, without restriction of any 2916 kind, provided that the above copyright notice and this paragraph are 2917 included on all such copies and derivative works. However, this 2918 document itself may not be modified in any way, such as by removing 2919 the copyright notice or references to the Internet Society or other 2920 Internet organizations, except as needed for the purpose of 2921 developing Internet standards in which case the procedures for 2922 copyrights defined in the Internet Standards process must be 2923 followed, or as required to translate it into languages other than 2924 English. 2926 The limited permissions granted above are perpetual and will not be 2927 revoked by the Internet Society or its successors or assigns. 2929 This document and the information contained herein is provided on an 2930 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2931 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2932 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2933 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2934 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.