idnits 2.17.1 draft-ietf-ipsec-arch-sec-02.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 208 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 138: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 139: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 329: '...ution techniques MAY be used. For exa...' RFC 2119 keyword, line 368: '... All implementations of AH or ESP MUST...' RFC 2119 keyword, line 411: '... the SA MUST be tunnel mode. Thus a...' (77 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 806 has weird spacing: '...IP addr singl...' == Line 807 has weird spacing: '...IP addr singl...' == Line 808 has weird spacing: '...rotocol sin...' == Line 809 has weird spacing: '...st,wild sing...' == Line 810 has weird spacing: '...st,wild sing...' == (8 more instances...) -- 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 (November 1997) is 9659 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: 'Bra97' is mentioned on line 141, but not defined == Missing Reference: 'IP1' is mentioned on line 963, but not defined == Missing Reference: 'AH' is mentioned on line 962, but not defined == Missing Reference: 'IP2' is mentioned on line 963, but not defined == Missing Reference: 'ESP' is mentioned on line 963, but not defined -- Looks like a reference, but probably isn't: '512' on line 2389 == Missing Reference: 'RFC792' is mentioned on line 2473, but not defined == Missing Reference: 'RFC1812' is mentioned on line 2461, but not defined == Missing Reference: 'RFC1256' is mentioned on line 2449, but not defined == Missing Reference: 'RFC950' is mentioned on line 2474, but not defined == Missing Reference: 'JBP' is mentioned on line 2495, but not defined == Missing Reference: 'RFC1108' is mentioned on line 2469, but not defined == Missing Reference: 'RFC1393' is mentioned on line 2475, but not defined ** Obsolete undefined reference: RFC 1393 (Obsoleted by RFC 6814) == Missing Reference: 'RFC1475' is mentioned on line 2476, but not defined ** Obsolete undefined reference: RFC 1475 (Obsoleted by RFC 6814) == Missing Reference: 'Johnson' is mentioned on line 2477, but not defined == Missing Reference: 'Markson' is mentioned on line 2478, but not defined == Missing Reference: 'Simpson' is mentioned on line 2494, but not defined == Missing Reference: 'Solo' is mentioned on line 2487, but not defined == Missing Reference: 'ZSu' is mentioned on line 2488, but not defined == Missing Reference: 'RFC 1885' is mentioned on line 2501, but not defined ** Obsolete undefined reference: RFC 1885 (Obsoleted by RFC 2463) == Missing Reference: 'RFC1885' is mentioned on line 2521, but not defined ** Obsolete undefined reference: RFC 1885 (Obsoleted by RFC 2463) == Unused Reference: 'BCCH94' is defined on line 2528, but no explicit reference was found in the text == Unused Reference: 'Bel89' is defined on line 2532, but no explicit reference was found in the text == Unused Reference: 'Bel95' is defined on line 2536, but no explicit reference was found in the text == Unused Reference: 'Bel96' is defined on line 2541, but no explicit reference was found in the text == Unused Reference: 'CB94' is defined on line 2549, but no explicit reference was found in the text == Unused Reference: 'CG96' is defined on line 2552, but no explicit reference was found in the text == Unused Reference: 'DIA' is defined on line 2555, but no explicit reference was found in the text == Unused Reference: 'DoD85' is defined on line 2559, but no explicit reference was found in the text == Unused Reference: 'DoD87' is defined on line 2564, but no explicit reference was found in the text == Unused Reference: 'DH76' is defined on line 2569, but no explicit reference was found in the text == Unused Reference: 'DH95' is defined on line 2573, but no explicit reference was found in the text == Unused Reference: 'EK96' is defined on line 2576, but no explicit reference was found in the text == Unused Reference: 'GM93' is defined on line 2579, but no explicit reference was found in the text == Unused Reference: 'Hugh96' is defined on line 2592, but no explicit reference was found in the text == Unused Reference: 'Ken93' is defined on line 2618, but no explicit reference was found in the text == Unused Reference: 'KB93' is defined on line 2622, but no explicit reference was found in the text == Unused Reference: 'NS78' is defined on line 2630, but no explicit reference was found in the text == Unused Reference: 'NS81' is defined on line 2635, but no explicit reference was found in the text == Unused Reference: 'OG96' is defined on line 2638, but no explicit reference was found in the text == Unused Reference: 'OTA94' is defined on line 2644, but no explicit reference was found in the text == Unused Reference: 'STD-1' is defined on line 2658, but no explicit reference was found in the text == Unused Reference: 'ZDESZ93' is defined on line 2668, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1636 (ref. 'BCCH94') -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel89' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bel96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BL73' -- Possible downref: Non-RFC (?) normative reference: ref. 'CB94' -- Possible downref: Non-RFC (?) normative reference: ref. 'CG96' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD85' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD87' -- Possible downref: Non-RFC (?) normative reference: ref. 'DH76' ** Obsolete normative reference: RFC 1883 (ref. 'DH95') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'EK96' ** Downref: Normative reference to an Historic RFC: RFC 1446 (ref. 'GM93') ** Downref: Normative reference to an Informational RFC: RFC 1704 (ref. 'HA94') -- Possible downref: Non-RFC (?) normative reference: ref. 'HC97' ** Downref: Normative reference to an Experimental RFC: RFC 2094 (ref. 'HM97') -- Possible downref: Non-RFC (?) normative reference: ref. 'Hugh96' -- 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. 'KA97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'KA97b' ** Downref: Normative reference to an Historic RFC: RFC 1108 (ref. 'Ken91') ** Downref: Normative reference to an Historic RFC: RFC 1422 (ref. 'Ken93') ** Obsolete normative reference: RFC 1510 (ref. 'KB93') (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. 'MSST97' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS78' -- Possible downref: Non-RFC (?) normative reference: ref. 'NS81' -- Possible downref: Non-RFC (?) normative reference: ref. 'OG96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Orm97' -- Possible downref: Non-RFC (?) normative reference: ref. 'OTA94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pip97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sch94' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDNS' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'TDG97' -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZDESZ93' Summary: 24 errors (**), 0 flaws (~~), 50 warnings (==), 35 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Stephen Kent, BBN Corp 2 draft-ietf-ipsec-arch-sec-02.txt Randall Atkinson, @Home Network 3 Obsoletes RFC 1825 November 1997 5 Security Architecture for the Internet Protocol 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of 6 months. 15 Internet Drafts may be updated, replaced, or obsoleted by other 16 documents at any time. It is not appropriate to use Internet Drafts 17 as reference material or to cite them other than as "work in 18 progress". Please check the I-D abstract listing contained in each 19 Internet Draft directory to learn the current status of this or any 20 other Internet Draft. 22 This particular Internet Draft is a product of the IETF's IP Security 23 (IPsec) working group. It is intended that a future version of this 24 draft be submitted to the IESG for publication as a Draft Standard 25 RFC. Comments about this draft may be sent to the authors or to the 26 IPsec WG mailing list . Distribution of this document 27 is unlimited. 29 Copyright (C) The Internet Society (November 1997). All Rights 30 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.....................................13 50 4.4.1 The Security Policy Database (SPD)............................13 51 4.4.2 Selectors.....................................................16 52 4.4.3 Security Association Database (SAD)...........................19 53 4.5 Basic Combinations of Security Associations........................21 54 4.6 SA and Key Management..............................................23 55 4.6.1 Manual Techniques.............................................24 56 4.6.2 Automated SA and Key Management...............................24 57 4.6.3 Locating a Security Gateway...................................25 58 4.7 Security Associations and Multicast................................26 59 5. IPsec Traffic Processing...............................................27 60 5.1 Outbound IPsec Traffic Processing..................................27 61 5.1.1 Selecting and Using an SA or SA Bundle........................27 62 5.1.2 Header Construction for Tunnel Mode...........................28 63 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..............29 64 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..............30 65 5.2 Processing Inbound IPsec Traffic...................................30 66 5.2.1 Selecting and Using an SA or SA Bundle...........................30 67 5.2.2 Handling of AH and ESP tunnels...................................31 68 6. ICMP Processing (relevant to IPsec)....................................31 69 6.1 PMTU/DF Processing.................................................32 70 6.1.1 DF Bit........................................................32 71 6.1.2 Path MTU Discovery (PMTU).....................................32 72 6.1.2.1 Propagation of PMTU......................................33 73 6.1.2.2 Calculation of PMTU......................................34 74 6.1.2.3 Granularity of PMTU Processing...........................34 75 6.1.2.4 PMTU Aging...............................................34 76 7. Auditing...............................................................35 77 8. Use in Systems Supporting Information Flow Security....................35 78 8.1 Relationship Between Security Associations and Data Sensitivity....36 79 8.2 Sensitivity Consistency Checking...................................36 80 8.3 Additional MLS Attributes for Security Association Databases.......37 81 8.4 Additional Inbound Processing Steps for MLS Networking.............37 82 8.5 Additional Outbound Processing Steps for MLS Networking............37 83 8.6 Additional MLS Processing for Security Gateways....................38 84 9. Performance Issues.....................................................38 85 10. Conformance Requirements..............................................39 86 11. Security Considerations...............................................39 87 12. Differences from RFC 1825.............................................39 88 Acknowledgements..........................................................39 89 Appendix A -- Glossary....................................................40 90 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.........44 91 B.1 DF bit.............................................................44 92 B.2 Fragmentation......................................................44 93 B.3 Path MTU Discovery.................................................48 94 B.3.1 Identifying the Originating Host(s)...........................49 95 B.3.2 Calculation of PMTU...........................................51 96 B.3.3 Granularity of Maintaining PMTU Data..........................51 97 B.3.4 Per Socket Maintenance of PMTU Data...........................53 98 B.3.5 Delivery of PMTU Data to the Transport Layer..................53 99 B.3.6 Aging of PMTU Data............................................53 100 Appendix C -- Sequence Space Window Code Example..........................54 101 Appendix D -- Categorization of ICMP messages.............................56 102 References................................................................59 103 Disclaimer................................................................62 104 Author Information........................................................62 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 (ISAKMP/Oakley) 131 d. Algorithms for authentication and encryption 133 This document is not an overall Security Architecture for the 134 Internet; it addresses security only at the IP layer, provided 135 through the use of a combination of cryptographic and protocol 136 security mechanisms. 138 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 139 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 140 document, are to be interpreted as described in RFC 2119 [Bra97]. 142 1.2 Audience 144 The target audience for this document includes implementers of this 145 IP security technology and others interested in gaining a general 146 background understanding of this system. In particular, prospective 147 users of this technology (end users or system administrators) are 148 part of the target audience. A glossary is provided as an appendix 149 to help fill in gaps in background/vocabulary. This document assumes 150 that the reader is familiar with the Internet Protocol, related 151 networking technology, and general security terms and concepts. 153 1.3 Related Documents 155 As mentioned above, other documents provide detailed definitions of 156 some of the components of IPsec and of their inter-relationship. 157 They include RFCs on the following topics: 159 a. "IP Security Document Roadmap" [TDG97] -- a document 160 providing guidelines for specifications describing encryption 161 and authentication algorithms used in this system. 162 b. security protocols -- RFCs describing the Authentication 163 Header (AH) [KA97a] and Encapsulating Security Payload (ESP) 164 [KA97b] protocols. 165 c. algorithms for authentication and encryption -- a separate 166 RFC for each algorithm. 167 d. automatic key management, e.g., an RFC on ISAKMP/Oakley and 168 "The Internet IP Security Domain of Interpretation for 169 ISAKMP" [Pip97]. 171 2. Design Objectives 173 2.1 Goals/Objectives/Requirements/Problem Description 175 IPsec is designed to provide interoperable, high quality, 176 cryptographically-based security for IPv4 and IPv6. The set of 177 security services offered includes access control, connectionless 178 integrity, data origin authentication, protection against replays (a 179 form of partial sequence integrity), confidentiality (encryption), 180 and limited traffic flow confidentiality. These services are 181 provided at the IP layer, offering protection for IP and/or upper 182 layer protocols. 184 These objectives are met through the use of two traffic security 185 protocols, the Authentication Header (AH) and the Encapsulating 186 Security Payload (ESP), and through the use of cryptographic key 187 management procedures and protocols. The set of IPsec protocols 188 employed in any context, and the ways in which they are employed, 189 will be determined by the security and system requirements of users, 190 applications, and/or sites/organizations. 192 When these mechanisms are correctly implemented and deployed, they 193 ought not to adversely affect users, hosts, and other Internet 194 components that do not employ these security mechanisms for 195 protection of their traffic. These mechanisms also are designed to 196 be algorithm-independent. This modularity permits selection of 197 different sets of algorithms without affecting the other parts of the 198 implementation. For example, different user communities may select 199 different sets of algorithms (creating cliques) if required. 201 A standard set of default algorithms is specified to facilitate 202 interoperability in the global Internet. The use of these 203 algorithms, in conjunction with IPsec traffic protection and key 204 management protocols, is intended to permit system and application 205 developers to deploy high quality, Internet layer, cryptographic 206 security technology. 208 2.2 Caveats and Assumptions 210 The suite of IPsec protocols and associated default algorithms are 211 designed to provide high quality security for Internet traffic. 212 However, the security offered by use of these protocols ultimately 213 depends on the quality of the their implementation, which is outside 214 the scope of this set of standards. Moreover, the security of a 215 computer system or network is a function of many factors, including 216 personnel, physical, procedural, compromising emanations, and 217 computer security practices. Thus IPsec is only one part of an 218 overall system security architecture. 220 Finally, the security afforded by the use of IPsec is critically 221 dependent on many aspects of the operating environment in which the 222 IPsec implementation executes. For example, defects in OS security, 223 poor quality of random number sources, sloppy system management 224 protocols and practices, etc. can all degrade the security provided 225 by IPsec. As above, none of these environmental attributes are 226 within the scope of this or other IPsec standards. 228 3. System Overview 230 This section provides a high level description of how IPsec works, 231 the components of the system, and how they fit together to provide 232 the security services noted above. The goal of this description is 233 to enable the reader to "picture" the overall process/system, see how 234 it fits into the IP environment, and to provide context for later 235 sections of this document, which describe each of the components in 236 more detail. 238 An IPsec implementation operates in a host or a security gateway 239 environment, affording protection to IP traffic. The protection 240 offered is based on requirements defined by a Security Policy 241 Database (SPD) established and maintained by a user or system 242 administrator, or by an application operating within constraints 243 established by either of the above. In general, packets are selected 244 for one of three processing modes based on IP and transport layer 245 header information (Selectors, Section 4.4.2) matched against entries 246 in the database (SPD). Each packet is either afforded IPsec security 247 services, discarded, or allowed to bypass IPsec, based on the 248 applicable database policies identified by the Selectors. 250 3.1 What IPsec Does 252 IPsec provides security services at the IP layer by enabling a system 253 to select required security protocols, determine the algorithm(s) to 254 use for the service(s), and put in place any cryptographic keys 255 required to provide the requested services. IPsec can be used to 256 protect one or more "paths" between a pair of hosts, between a pair 257 of security gateways, or between a security gateway and a host. (The 258 term "security gateway" is used throughout the IPsec documents to 259 refer to an intermediate system that implements IPsec protocols. For 260 example, a router or a firewall implementing IPsec is a security 261 gateway.) 263 The set of security services that IPsec can provide includes access 264 control, connectionless integrity, data origin authentication, 265 rejection of replayed packets (a form of partial sequence integrity), 266 confidentiality (encryption), and limited traffic flow 267 confidentiality. Because these services are provided at the IP 268 layer, they can be used by any higher layer protocol, e.g., TCP, UDP, 269 ICMP, BGP, etc. 271 NOTE: When encryption is employed within IPsec, it prevents effective 272 compression by lower protocol layers. However, IPsec does not 273 provide its own compression services. Such services may be provided 274 by existing higher layer protocols, or, in the future, in IP itself. 275 The IETF working group, "IP Payload Compression Protocol (ippcp)" has 276 the charter to "develop protocol specifications that make it possible 277 to perform lossless compression on individual payloads before the 278 payload is processed by a protocol that encrypts it. These 279 specifications will allow for compression operations to be performed 280 prior to the encryption of a payload by such protocols as IPsec." 282 3.2 How IPsec Works 284 IPsec uses two protocols to provide traffic security -- 285 Authentication Header (AH) and Encapsulating Security Payload (ESP). 286 Both protocols are described in more detail in their respective RFCs 287 [KA97a, KA97b]. 289 o The IP Authentication Header (AH) [KA97a] provides 290 connectionless integrity, data origin authentication, and an 291 optional anti-replay service. 292 o The Encapsulating Security Payload (ESP) protocol [KA97b] 293 provides confidentiality (encryption), and limited traffic 294 flow confidentiality. It also may provide connectionless 295 integrity, data origin authentication, and an anti-replay 296 service. 297 o Both AH and ESP are vehicles for access control, based on 298 the distribution of cryptographic keys and the management of 299 traffic flows relative to these security protocols. 301 These protocols may be applied alone or in combination with each 302 other to provide a desired set of security services in IPv4 and IPv6. 303 Each protocol supports two modes of use: transport mode and tunnel 304 mode. In transport mode the protocols provide protection primarily 305 for upper layer protocols; in tunnel mode, the protocols are applied 306 to tunneled IP packets. The differences between the two modes are 307 discussed in Section 4. 309 IPsec allows the user (or system administrator) to control the 310 granularity at which a security service is offered. For example, one 311 can create a single encrypted tunnel to carry all the traffic between 312 two security gateways or a separate encrypted tunnel can be created 313 for each TCP connection between each pair of hosts communicating 314 across these gateways. IPsec management must incorporate facilities 315 for specifying: 317 o which security services to use and in what combinations 318 o the granularity at which a given security protection should be 319 applied 320 o the algorithms used to effect cryptographic-based security 322 Because these security services use shared secret values 323 (cryptographic keys), IPsec relies on a separate set of mechanisms 324 for putting these keys in place. (The keys are used for 325 authentication/integrity and encryption services.) This document 326 requires support for both manual and automatic distribution of keys. 327 It specifies a specific public-key based approach (ISAKMP/Oakley -- 328 [MSST97, Orm97, HC97]) for automatic key management, but other 329 automated key distribution techniques MAY be used. For example, 330 KDC-based systems such as Kerberos and other public-key systems such 331 as SKIP could be employed. 333 3.3 Where IPsec May Be Implemented 335 There are several ways in which IPsec may be implemented in a host or 336 in conjunction with a router or firewall (to create a security 337 gateway). Several common examples are provided below: 339 a. Integration of IPsec into the native IP implementation. This 340 requires access to the IP source code and is applicable to 341 both hosts and security gateways. 343 b. "Bump-in-the-stack" (BITS) implementations, where IPsec is 344 implemented "underneath" an existing implementation of an IP 345 protocol stack, between the native IP and the local network 346 drivers. Source code access for the IP stack is not required 347 in this context, making this implementation approach 348 appropriate for use with legacy systems. This approach, when 349 it is adopted, is usually employed in hosts. 351 c. The use of an outboard crypto processor is a common design 352 feature of network security systems used by the military, and 353 of some commercial systems as well. It is sometimes referred 354 to as a "Bump-in-the-wire" (BITW) implementation. Such 355 implementations may be designed to serve either a host or a 356 gateway (or both). Usually the BITW device is IP 357 addressable. When supporting a single host, it may be quite 358 analogous to a BITS implementation, but in supporting a 359 router or firewall, it must operate like a security gateway. 361 4. Security Associations 363 This section defines Security Association management requirements for 364 all IPv6 implementations and for those IPv4 implementations that 365 implement AH, ESP, or both. The concept of a "Security Association" 366 (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a 367 major function of ISAKMP/Oakley is the establishment and maintenance 368 of Security Associations. All implementations of AH or ESP MUST 369 support the concept of a Security Association as described below. 370 The remainder of this section describes various aspects of Security 371 Association management, defining required characteristics for SA 372 policy management, traffic processing, and SA management techniques. 374 4.1 Definition and Scope 376 A Security Association (SA) is a simplex "connection" that affords 377 security services to the traffic carried by it. Security services 378 are afforded to an SA by the use of AH, or ESP, but not both. If 379 both AH and ESP protection is applied to a traffic stream, then two 380 (or more) SAs are created to afford protection to the traffic stream. 381 To secure typical, bi-directional communication between two hosts, or 382 between two security gateways, two Security Associations (one in each 383 direction) are required. 385 A security association is uniquely identified by a triple consisting 386 of a Security Parameter Index (SPI), an IP Destination Address, and a 387 security protocol (AH or ESP) identifier. In principle, the 388 Destination Address may be a unicast address, an IP broadcast 389 address, or a multicast group address. However, IPsec SA management 390 mechanisms currently are defined only for unicast SAs. Hence, in the 391 discussions that follow, SAs will be described in the context of 392 point-to-point communication, even though the concept is applicable 393 in the point-to-multipoint case as well. 395 As noted above, two types of SAs are defined: transport mode and 396 tunnel mode. A transport mode SA is a security association between 397 two hosts. In IPv4, a transport mode security protocol header 398 appears immediately after the IP header and any options, and before 399 any higher layer protocols (e.g., TCP or UDP). In IPv6, the security 400 protocol header appears after the base IP header and extensions, but 401 may appear before or after destination options, and before higher 402 layer protocols. In the case of ESP, a transport mode SA provides 403 security services only for these higher layer protocols, not for the 404 IP header or any extension headers preceding the ESP header. In the 405 case of AH, the protection is also extended to selected portions of 406 the IP header (and options). For more details on the coverage 407 afforded by AH, see the AH specification [KA97b]. 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 4.2 Security Association Functionality 438 The set of security services offered by an SA depends on the security 439 protocol selected, the SA mode, the endpoints of the SA, and on the 440 election of optional services within the protocol. For example, AH 441 provides data origin authentication and connectionless integrity for 442 IP datagrams (hereafter referred to as just "authentication"). The 443 "precision" of the authentication service is a function of the 444 granularity of the security association with which AH is employed, as 445 discussed in Section 4.4.2, "Selectors". 447 AH also offers an anti-replay (partial sequence integrity) service at 448 the discretion of the receiver, to help counter denial of service 449 attacks. AH is an appropriate protocol to employ when 450 confidentiality is not required (or is not permitted, e.g , due to 451 government restrictions on use of encryption). AH also provides 452 authentication for selected portions of the IP header, which may be 453 necessary in some contexts. For example, if the integrity of an IPv4 454 option or IPv6 extension header must be protected en route between 455 sender and receiver, AH can provide this service (except for the 456 non-predictable but mutable parts of the IP header.) 458 ESP always provides confidentiality for traffic. (However, the 459 strength of the confidentiality service will depend, in part, on the 460 encryption algorithm employed.) ESP also may optionally provide 461 authentication (as defined above). If authentication is negotiated 462 for an ESP SA, the receiver also may elect to enforce an anti-replay 463 service with the same features as the AH anti-replay service. The 464 scope of the authentication offered by ESP is narrower than for AH, 465 i.e., the IP header(s) "below" the ESP header is not protected. If 466 only the upper layer protocols need to be authenticated, then ESP 467 authentication is an appropriate choice and is more space efficient 468 than use of AH encapsulating ESP. 470 An ESP (tunnel mode) SA between two security gateways can offer 471 partial traffic flow confidentiality. The use of tunnel mode allows 472 the inner IP headers to be encrypted, concealing the identities of 473 the (ultimate) traffic source and destination. Moreover, ESP payload 474 padding also can be invoked to hide the size of the packets, further 475 concealing the external characteristics of the traffic. Similar 476 traffic flow confidentiality services may be offered when a mobile 477 user is assigned a dynamic IP address in a dialup context, and 478 establishes a (tunnel mode) ESP SA to a corporate firewall (acting as 479 a security gateway). 481 4.3 Combining Security Associations 483 The IP datagrams transmitted over an individual SA are afforded 484 protection by exactly one security protocol, either AH or ESP, but 485 not both. Sometimes a security policy may call for a combination of 486 services for a particular traffic flow that is not achievable with a 487 single SA. In such instances it will be necessary to employ multiple 488 SAs to implement the required security policy. The term "security 489 association bundle" or "SA bundle" is applied to a sequence of SAs 490 through which traffic must be processed to satisfy a security policy. 491 The order of the sequence is defined by the policy. (Note that the 492 SAs that comprise a bundle may terminate at different endpoints. For 493 example, one SA may extend between a mobile host and a security 494 gateway and a second, nested SA may extend to a host behind the 495 gateway.) 497 Security associations may be combined into bundles in two ways: 498 transport adjacency and iterated tunneling. 500 o Transport adjacency refers to applying more than one security 501 protocol to the same IP datagram, without invoking tunneling. 502 This approach to combining AH and ESP allows for only one 503 level of combination; further nesting yields no added benefit 504 since the processing is performed at one IPsec instance the 505 (ultimate) destination. 507 o Iterated tunneling refers to the application of multiple 508 layers of security protocols effected through IP tunneling. 509 This approach allows for multiple levels of nesting, since 510 each tunnel can originate or terminate at a different IPsec 511 site along the path. 513 These two approaches also can be combined, i.e., an SA bundle could 514 be constructed from one tunnel mode SA and one or two transport mode 515 SAs, applied in sequence. Note that nested tunnels can also occur 516 where neither the source nor the destination endpoints of any of the 517 tunnels are the same. In that case, there would be no host or 518 security gateway with a bundle corresponding to the nested tunnels. 520 For transport mode SAs, only one ordering of security protocols seems 521 appropriate. AH is applied to both the upper layer protocols and 522 (parts of) the IP header. Thus if AH is used in a transport mode, in 523 conjunction with ESP, AH SHOULD appear as the first header after IP, 524 prior to the appearance of ESP. In that context, AH is applied to 525 the ciphertext output of ESP. In contrast, for tunnel mode SAs, one 526 can imagine uses for various orderings of AH and ESP. The required 527 set of SA bundle types that MUST be supported by a compliant IPsec 528 implementation is described in Section 4.5. 530 4.4 Security Association Databases 532 Many of the details associated with processing IP traffic in an IPsec 533 implementation are largely a local matter, not subject to 534 standardization. However, some external aspects of the processing 535 must be standardized, to ensure interoperability and to provide a 536 minimum management capability that is essential for productive use of 537 IPsec. This section describes a general model for processing IP 538 traffic relative to security associations, in support of these 539 interoperability and functionality goals. The model described below 540 is nominal; compliant implementations need not match details of this 541 model as presented, but the external behavior of such implementations 542 must be mappable to the externally observable characteristics of this 543 model. 545 There are two nominal databases in this model: the Security Policy 546 Database and the Security Association Database. The former specifies 547 the policies that determine the disposition of all IP traffic inbound 548 or outbound from a host, security gateway, or BITS or BITW IPsec 549 implementation. The latter database contains parameters that are 550 associated with each (active) security association. This section 551 also defines the concept of a Selector, a set of IP and upper layer 552 protocol field values that is used by the Security Policy Database to 553 map traffic to a policy, i.e., an SA (or SA bundle). 555 4.4.1 The Security Policy Database (SPD) 557 Ultimately, a security association is a management construct used to 558 enforce a security policy in the IPsec environment. Thus an 559 essential element of SA processing is an underlying Security Policy 560 Database (SPD) that specifies what services are to be offered to IP 561 datagrams and in what fashion. The form of the database and its 562 interface are outside the scope of this specification. However, this 563 section does specify certain minimum management functionality that 564 must be provided, to allow a user or system administrator to control 565 how IPsec is applied to traffic transmitted or received by a host or 566 transiting a security gateway. 568 An SPD must discriminate among traffic that is afforded IPsec 569 protection and traffic that is allowed to bypass IPsec. This applies 570 to the IPsec protection to be applied by a sender and to the IPsec 571 protection that must be present at the receiver. For any outbound or 572 inbound datagram, three processing choices are possible: discard, 573 bypass IPsec, or apply IPsec. The first choice refers to traffic 574 that is not allowed to exit the host, traverse the security gateway, 575 or be delivered to an application at all. The second choice refers 576 to traffic that is allowed to pass without additional IPsec 577 protection. The third choice refers to traffic that is afforded 578 IPsec protection, and for such traffic the SPD must specify the 579 security services to be provided, protocols to be employed, 580 algorithms to be used, etc. 582 For every IPsec implementation, there MUST be an administrative 583 interface that allows a user or system administrator to manage the 584 SPD. This interface must allow the user (or system administrator) to 585 specify the security processing to be applied to each packet entering 586 or exiting the system, on a packet by packet basis. (In a host IPsec 587 implementation making use of a socket interface, the SPD may not need 588 to be consulted on a per packet basis, but the effect is still the 589 same.) The management interface for the SPD MUST allow creation of 590 entries consistent with the selectors defined in Section 4.4.2, and 591 MUST support ordering of these entries. 593 In host systems, applications MAY be allowed to select what security 594 processing is to be applied to the traffic they generate and consume. 595 (Means of signalling such requests to the IPsec implementation are 596 outside the scope of this standard.) However, the system 597 administrator MUST be able to specify whether or not a user or 598 application can override (default) system policies. Note that 599 application specified policies may satisfy system requirements, so 600 that the system may not need to do additional IPsec processing beyond 601 that needed to meet an application's requirements. The form of the 602 management interface is not specified by this document and may differ 603 for hosts vs. security gateways, and within hosts the interface may 604 differ for socket-based vs. BITS implementations. However, this 605 document does specify a standard set of SPD elements that all IPsec 606 implementations MUST support. 608 The SPD contains an ordered list of policy entries. Each policy 609 entry is keyed by one or more selectors that define the set of IP 610 traffic encompassed by this policy entry. (The required selector 611 types are defined in Section 4.4.2.) These define the granularity of 612 policies or SAs. Each entry includes an indication of whether 613 traffic matching this policy will be bypassed, discarded, or subject 614 to IPsec processing. If IPsec processing is to be applied, the entry 615 includes an SA (or SA bundle) specification, listing the IPsec 616 protocols, modes, and algorithms to be employed, including any 617 nesting requirements. For example, an entry may call for all 618 matching traffic to be protected by ESP in transport mode using 619 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode 620 using HMAC/SHA-1. For each selector, the policy entry specifies 621 which of the following values should used in the SA: (a) the value in 622 the packet, (b) the value associated with the policy, or (c) a 623 wildcard. 625 Case (c) permits the sharing of an SA (or SA bundle) by multiple SPD 626 entries. Case (a) can be used to prohibit sharing, even among 627 packets that match the same SPD entry. 629 As described below in Section 4.4.3, selectors may include "wildcard" 630 entries and hence the selectors for two entries may overlap. (This 631 is analogous to the overlap that arises with ACLs or filter entries 632 in routers or packet filtering firewalls.) Thus, to ensure 633 consistent, predictable processing, SPD entries MUST be ordered and 634 the SPD MUST always be searched in the same order, so that the first 635 matching entry is consistently selected. (This requirement is 636 necessary as the effect of processing traffic against SPD entries 637 must be deterministic, but there is no way to canonicalize SPD 638 entries given the use of wildcards and enumerated lists for some 639 selectors.) More detail on matching of packets against SPD entries 640 is provided in Section 5. 642 The SPD can be used to map traffic to specific SAs or SA bundles. 643 Thus it can function both as the reference database for security 644 policy and as the map to existing SAs (or SA bundles). (To 645 accommodate the bypass and discard policies cited above, the SPD also 646 MUST provide a means of mapping traffic to these functions, even 647 though they are not, per se, IPsec processing.) The way in which the 648 SPD operates is different for inbound vs. outbound traffic and it 649 also may differ for host vs. security gateway, BITS, and BITW 650 implementations. Sections 5.1 and 5.2 describe the use of the SPD 651 for outbound and inbound processing, respectively. 653 Because a security policy may require that more than one SA be 654 applied to a specified set of traffic, in a specific order, the 655 policy entry in the SPD must preserve these ordering requirements, 656 when present. Thus, it must be possible for an IPsec implementation 657 to determine that an outbound or inbound packet must be processed 658 thorough a sequence of SAs. Conceptually, for outbound processing, 659 one might imagine links (to the SAD) from an SPD entry for which 660 there are active SAs, and each entry would consist of either a single 661 SA or an ordered list of SAs that comprise an SA bundle. When a 662 packet is matched against an SPD entry and there is an existing SA or 663 SA bundle that can be used to carry the traffic, the processing of 664 the packet is controlled by the SA or SA bundle entry on the list. 665 For an inbound IPsec packet for which multiple IPsec SAs are to be 666 applied, the lookup based on destination address, IPsec protocol, and 667 SPI should identify a single SA. To allow minimization of the number 668 of SAs, the linkage between the SPD and the SAD (at both the sender 669 and the receiver) MUST allow an SA to be used in more than one 670 bundle. 672 The SPD also will be consulted when any IPsec implementation is the 673 target of an SA establishment request from another IPsec 674 implementation, e.g., using ISAKMP/Oakley. 676 4.4.2 Selectors 678 An SA (or SA bundle) may be fine-grained or coarse-grained, depending 679 on the selectors used to define the set of traffic for the SA. For 680 example, all traffic between two hosts may be carried via a single 681 SA, and afforded a uniform set of security services. Alternatively, 682 traffic between a pair of hosts might be spread over multiple SAs, 683 depending on the applications being used (as defined by the Next 684 Protocol and Port fields), with different security services offered 685 by different SAs. Similarly, all traffic between a pair of security 686 gateways could be carried on a single SA, or one SA could be assigned 687 for each communicating host pair. The following selector parameters 688 MUST be supported for SA management to facilitate control of SA 689 granularity. Note that in the case of receipt of a packet with an 690 ESP header, e.g., at an encapsulating security gateway or BITW 691 implementation, the transport layer protocol, source/destination 692 ports, and UserID (if present) may be opaque. 694 - Destination IP Address (IPv4 or IPv6): this may be a single IP 695 address (unicast, broadcast, or multicast group), an enumerated 696 list or range of addresses, or a wildcard (mask) address. The 697 latter two are required to support more than one destination 698 system sharing the same SA (e.g., behind a security gateway). 699 Note that this selector is conceptually different from the 700 "Destination IP Address" field in the used to uniquely identify an SA. It could 702 have the same value. 703 [REQUIRED for all implementations] 705 - Source IP Address(es) (IPv4 or IPv6): this may be a single IP 706 address, an enumerated list or range of addresses, or a wildcard 707 (mask) address. The latter two are required to support more 708 than one source system sharing the same SA (e.g., behind a 709 security gateway or in a multihomed host). 710 [REQUIRED for all implementations] 712 - UserID: a user identifier from the operating system. Note that 713 one of the possible values of this selector is "OPAQUE". (The 714 use of a User ID as an SA selector is sometimes referred to as 715 "user-oriented keying.") 716 [REQUIRED for host implementations, unless the layering of the 717 implementation precludes access to this information, e.g., a 718 BITS implementation need not support this selector.] 720 - Data sensitivity level: (IPSO/CIPSO labels) 721 [REQUIRED for all systems providing information flow security as 722 per Section 8, OPTIONAL for all other systems.] 724 - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or 725 the IPv6 "Next Header" fields. This may be an individual 726 protocol number, a list of protocol numbers, or a range of 727 protocol numbers. These packet fields may not contain the 728 Transport Protocol due to the presence of IP extension headers, 729 e.g., a Routing Header, AH, ESP, Fragmentation Header, 730 Destination Options, Hop-by-hop options, etc. Note that the 731 Transport Protocol may not be available in the case of receipt 732 of a packet with an ESP header, thus a value of "OPAQUE" SHOULD 733 be supported. 734 [REQUIRED for IPv6 implementations, MAY be supported in IPv4 735 implementations] 737 NOTE: To locate the transport protocol, a system has to chain 738 through the packet headers checking the "Protocol" or "Next 739 Header" field until it encounters either one it recognizes as a 740 transport protocol, or until it reaches one that isn't on its 741 list of extension headers, or until it encounters an ESP header 742 that renders the transport protocol opaque. 744 - IPsec protocol (AH or ESP or AH/ESP): If present, this is 745 obtained from the IPv4 "Protocol" field or the IPv6 "Next 746 Header" field. 747 [REQUIRED for all implementations] 749 NOTE: The "Protocol" or "Next Header" field could contain a 750 Transport Protocol, Routing Header, AH, ESP, Fragmentation 751 Header, Destination Options, Hop-by-hop options, etc. Although 752 IPv6 recommends a particular order for extension headers, it 753 also specifies that the implementation must be prepared to 754 accept them in any order. So to check for the existence of an 755 IPsec header, a system has to chain through the packet headers 756 checking the Protocol/Next Header field until it has checked all 757 that are not opaque. 759 - Source and Destination (e.g., TCP/UDP) Ports: These may be 760 individual UDP or TCP port values, an enumerated list of ports, 761 or a wildcard port. (The use of the Next Protocol field and the 762 Source and/or Destination Port fields (in conjunction with the 763 Source and/or Destination Address fields), as an SA selector is 764 sometimes referred to as "session-oriented keying."). Note that 765 the source and destination ports may not be available in the 766 case of receipt of a packet with an ESP header, thus a value of 767 "OPAQUE" SHOULD be supported. 768 [REQUIRED for all implementations] 770 - IPv6 Class (from IP header): This may be expressed as a wildcard 771 value or a specific IPv6 Class value. 772 [REQUIRED for all systems that implement IPv6] 774 - IPv6 Flow Label (from IP header): This may be expressed as a 775 wildcard value or a specific Flow Label. The IPv6 spec (RFC 776 1883) calls for all datagrams for a given IPv6 Flow Label to 777 have the same Source Address, Destination Address, Hop-by-hop 778 Options header, and Routing Header. The Flow Label may be 779 assigned on a per socket basis. It would then be correlated 780 with the Source/Destination and could be used to provide finer 781 granularity selection of security association(s). 782 [REQUIRED for all systems that implement IPv6] 784 - IPv4 Type of Service (TOS): Obtained from the IPv4 header. This 785 may be expressed as a wildcard or an explicit value. 786 [REQUIRED for all IPv4 systems that implement IPsec] 788 The IPsec implementation context determines how selectors are used. 789 For example, a host implementation integrated into the stack may make 790 use of a socket interface. When a new connection is established the 791 SPD can be consulted and an SA (or SA bundle) bound to the socket. 792 Thus traffic sent via that socket need not result in additional 793 lookups to the SPD/SAD. In contrast, a BITS, BITW, or security 794 gateway implementation needs to look at each packet and perform an 795 SPD/SAD lookup based on the selectors. The allowable values for the 796 selector fields differ between the traffic flow, the security 797 association, and the security policy. 799 The following table summarizes the kinds of entries that one needs to 800 be able to express in the SPD and SAD. It shows how they relate to 801 the fields in data traffic being subjected to IPsec screening. 802 (Note: the "wild" or "wildcard" entry for src and dst addresses 803 includes a mask, list, etc.) 804 Field Traffic Value SAD Entry SPD Entry 805 -------- ------------- ---------------- -------------------- 806 src addr single IP addr single,list,wild single,list,wildcard 807 dst addr single IP addr single IP addr single,list,wildcard 808 xpt protocol* xpt protocol single,list,wild single,list,wildcard 809 src port* single src port single,list,wild single,list,wildcard 810 dst port* single dst port single,list,wild single,list,wildcard 811 user id* single user id single,list,wild single,list,wildcard 812 IPsec prot AH,ESP,AH/ESP single or wild single or wildcard 813 IPv6 class IPv6 class single,list,wild single,list,wildcard 814 IPv6 flow IPv6 flow single,list,wild single,list,wildcard 815 IPv4 TOS IPv4 TOS single,list,wild single,list,wildcard 816 sec. labels single value single,list,wild single,list,wildcard 818 * The SAD and SPD entries for these fields could be "OPAQUE" 819 because the traffic value is encrypted. 821 4.4.3 Security Association Database (SAD) 823 In each IPsec implementation there is a nominal Security Association 824 Database, in which each entry defines the parameters associated with 825 one SA. Each SA has an entry in the SAD. For outbound processing, 826 entries are pointed to by entries in the SPD. Note that if an SPD 827 entry does not currently point to an SA that is appropriate for the 828 packet, before it creates an SA, the implementation should check to 829 see if the SAD already has an appropriate SA (created by some other 830 SPD entry). For inbound processing, each entry in the SAD is indexed 831 by a destination IP address, IPsec protocol type, and SPI. The 832 following parameters are associated with each entry in the SAD. This 833 description does not purport to be a MIB, but only a specification of 834 the minimal data items required to support an SA in an IPsec 835 implementation. 837 For inbound processing: The following packet fields are used to look 838 up the SA in the SAD: 840 o Outer Header's Destination IP address: the IPv4 or IPv6 841 Destination address. 842 [REQUIRED for all implementations] 843 o IPsec Protocol: AH or ESP, used as an index for SA lookup in 844 this database. Specifies the IPsec protocol to be applied to 845 the traffic on this SA. 846 [REQUIRED for all implementations] 847 o SPI: the 32-bit value used to distinguish among different SAs 848 terminating at the same destination and using the same IPsec 849 protocol. 850 [REQUIRED for all implementations] 852 For each of the selectors defined in Section 4.4.2, the SA entry 853 in the SAD MUST contain the value or values which were negotiated 854 at the time the SA was created. For the sender, these values are 855 used to decide whether a given SA is appropriate for use with an 856 outbound packet. This is part of checking to see if there is an 857 existing SA that can be used. For the receiver, these values are 858 used to check that the selector values in an inbound packet match 859 those for the SA (and thus indirectly those for the matching 860 policy). For the receiver, this is part of verifying that the SA 861 was appropriate for this packet. (See Section 6 for rules for 862 ICMP messages.) These fields can have the form of specific 863 values, lists, ranges, wildcards, or "OPAQUE" as described in 864 section 4.4.2, "Selectors". 866 The following SAD fields are used in doing IPsec processing: 868 o Sequence Number Counter: a 32-bit value used to generate the 869 Sequence Number field in AH or ESP headers. 870 [REQUIRED for all implementations, but used only for outbound 871 traffic.] 872 o Sequence Counter Overflow: a flag indicating whether overflow of 873 the Sequence Number Counter should generate an auditable event 874 and prevent transmission of additional packets on the SA. 875 [REQUIRED for all implementations, but used only for outbound 876 traffic.] 877 o Anti-Replay Window: a 32-bit counter and a bit-map (or 878 equivalent) used to determine whether an inbound AH or ESP 879 packet is a replay. 880 [REQUIRED for all implementations but used only for inbound 881 traffic.] 882 o AH Authentication algorithm, keys, etc. 883 [REQUIRED for AH implementations] 884 o ESP Encryption algorithm, keys, IV mode, IV, etc. 885 [REQUIRED for ESP implementations] 886 o ESP authentication algorithm, keys, etc. If the authentication 887 service is not selected, this field will be null. 888 [REQUIRED for ESP implementations] 889 o Lifetime of this Security Association: a time interval after 890 which an SA must be replaced with a new SA (and new SPI) or 891 terminated, plus an indication of which of these actions should 892 occur. This may be expressed as a time or byte count. 893 [REQUIRED for all implementations] 894 o IPsec protocol mode: tunnel, transport or wildcard. Indicates 895 which mode of AH or ESP is applied to traffic on this SA. 896 [REQUIRED for all implementations, unless implicitly defined by 897 context] 898 o Path MTU: any observed path MTU and aging variables. See 899 Section 6.1.2.4 900 [REQUIRED for all implementations but used only for outbound 901 traffic] 903 4.5 Basic Combinations of Security Associations 905 This section describes four examples of combinations of security 906 associations that MUST be supported by compliant IPsec hosts or 907 security gateways. Additional combinations of AH and/or ESP in 908 tunnel and/or transport modes MAY be supported at the discretion of 909 the implementor. Compliant implementations MUST be capable of 910 generating these four combinations and on receipt, of processing 911 them, but SHOULD be able to receive and process any combination. The 912 diagrams and text below describe the basic cases. The legend for the 913 diagrams is: 915 ==== = one or more security associations (AH or ESP, transport 916 or tunnel) 917 ---- = connectivity (or if so labelled, administrative boundary) 918 Hx = host x 919 SGx = security gateway x 920 X* = X supports IPsec 922 NOTE: The security associations below can be either AH or ESP. The 923 mode (tunnel vs transport) is determined by the nature of the 924 endpoints. For host-to-host SAs, the mode can be either transport or 925 tunnel. 927 Case 1. The case of providing end-to-end security between 2 hosts 928 across the Internet (or an Intranet). 930 ==================================== 931 | | 932 H1* ------ (Inter/Intranet) ------ H2* 934 Note that either transport or tunnel mode can be selected by the 935 hosts. Also, in transport mode at the sender, first ESP, then 936 AH can be applied to the packet. So the headers in a packet 937 between H1 and H2 could look like any of the following: 939 Transport Tunnel 940 ----------------- --------------------- 941 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] 942 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] 943 3. [IP1][AH][ESP][upper] 945 Case 2. This case illustrates simple virtual private networks 946 support. 948 =========================== 949 | | 950 ---------------------|---- ---|----------------------- 951 | | | | | | 952 | H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 | 953 | Intranet) | | Intranet) | 954 -------------------------- --------------------------- 955 admin. boundary admin. boundary 957 Only tunnel mode is required here. So the headers in a packet 958 between SG1 and SG2 could look like either of the following: 960 Tunnel 961 --------------------- 962 4. [IP2][AH][IP1][upper] 963 5. [IP2][ESP][IP1][upper] 965 Case 3. This case builds on case 2, adding end-to-end security 966 between the sending and receiving hosts. It imposes no new 967 requirements on the hosts or security gateways, other than a 968 requirement for a security gateway to be configurable to pass 969 IPsec traffic (including ISAKMP traffic) for hosts behind it. 971 =============================================================== 972 | | 973 | ========================= | 974 | | | | 975 ---|-----------------|---- ---|-------------------|--- 976 | | | | | | | | 977 | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | 978 | Intranet) | | Intranet) | 979 -------------------------- --------------------------- 980 admin. boundary admin. boundary 982 Case 4. This covers the situation where a remote host (H1) uses the 983 Internet to reach an organization's firewall (SG2) and to then 984 gain access to some server or other machine (H2). The remote 985 host could be a mobile host (H1) dialing up to a local PPP/ARA 986 server (not shown) on the Internet and then crossing the 987 Internet to the home organization's firewall (SG2), etc. The 988 details of support for this case, (how H1 locates SG2, 989 authenticates it, and verifies its authorization to represent 990 H2) are discussed in Section 4.4.3, "Locating a Security 991 Gateway". 993 ====================================================== 994 | | 995 |============================== | 996 || | | 997 || ---|----------------------|--- 998 || | | | | 999 H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | 1000 ^ | Intranet) | 1001 | ------------------------------ 1002 could be dialup admin. boundary (optional) 1003 to PPP/ARA server 1005 Only tunnel mode is required between H1 and SG2. So the headers 1006 in a packet between H1 and SG2 would look like one of the ones 1007 in case 2. 1009 The following combinations of AH and ESP MUST be supported in the 1010 indicated contexts: 1012 - Cases 1, 3, 4 (between H1 and H2): 1013 a. AH in transport mode 1014 b. ESP in transport mode 1015 b. AH followed by ESP in transport mode 1016 d. any one of a, b, or c above AH or ESP in tunnel mode 1017 - Cases 1, 2, 3, and 4 (all SAs shown): 1018 e. AH in tunnel mode 1019 f. ESP in tunnel mode 1021 As noted above, support for additional combinations of AH and ESP is 1022 optional. Use of other, optional combinations may adversely affect 1023 interoperability. 1025 4.6 SA and Key Management 1027 IPsec mandates support for both manual and automated SA and 1028 cryptographic key management. The IPsec protocols, AH and ESP, are 1029 largely independent of the associated SA management techniques, 1030 although the techniques involved do affect some of the security 1031 services offered by the protocols. For example, the optional anti- 1032 replay services available for AH and ESP require automated SA 1033 management. Moreover, the granularity of key distribution employed 1034 with IPsec determines the granularity of authentication provided. 1035 (See also a discussion of this issue in Section 4.7.) In general, 1036 data origin authentication in AH and ESP is limited by the extent to 1037 which secrets used with the authentication algorithm (or with a key 1038 management protocol that creates such secrets) are shared among 1039 multiple possible sources. 1041 The following text describes the minimum requirements for both types 1042 of SA management. 1044 4.6.1 Manual Techniques 1046 The simplest form of management is manual management, in which a 1047 person manually configures each system with keying material and 1048 security association management data relevant to secure communication 1049 with other systems. Manual techniques are practical in small, static 1050 environments but they do not scale well. For example, a company 1051 could create a Virtual Private Network (VPN) using IPsec in security 1052 gateways at several sites. If the number of sites is small, and 1053 since all the sites come under the purview of a single administrative 1054 domain, this is likely to be a feasible context for manual management 1055 techniques. In this case, the security gateway might selectively 1056 protect traffic to and from other sites within the organization using 1057 a manually configured key, while not protecting traffic for other 1058 destinations. It also might be appropriate when only selected 1059 communications need to be secured. A similar argument might apply to 1060 use of IPsec entirely within an organization for a small number of 1061 hosts and/or gateways. Manual management techniques often employ 1062 statically configured, symmetric keys, though other options also 1063 exist. 1065 4.6.2 Automated SA and Key Management 1067 Widespread deployment and use of IPsec requires an Internet-standard, 1068 scalable, automated, SA management protocol. Such support is 1069 required to facilitate use of the anti-replay features of AH and ESP, 1070 and to accommodate on-demand creation of SAs, e.g., for user- and 1071 session-oriented keying. (Note that the notion of "rekeying" an SA 1072 actually implies creation of a new SA with a new SPI, a process that 1073 generally implies use of an automated SA/key management protocol.) 1075 The default automated key management protocol selected for use with 1076 IPsec is ISAKMP/Oakley [MSST97, Orm97, HC97] under the IPsec domain 1077 of interpretation [Pip97]. Other automated SA management protocols 1078 MAY be employed. 1080 When an automated SA/key management protocol is employed, the output 1081 from this protocol may be used to generate multiple keys, e.g., for a 1082 single ESP SA. This may arise because: 1084 o the encryption algorithm uses multiple keys (e.g., triple DES) 1085 o the authentication algorithm uses multiple keys 1086 o both encryption and authentication algorithms are employed 1088 The Key Management System may provide a separate string of bits for 1089 each key or it may generate one string of bits from which all of them 1090 are extracted. If a single string of bits is provided, care needs to 1091 be taken to ensure that the parts of the system that map the string 1092 of bits to the required keys do so in the same fashion at both ends 1093 of the SA. To ensure that the IPsec implementations at each end of 1094 the SA use the same bits for the same keys, and irrespective of which 1095 part of the system divides the string of bits into individual keys, 1096 the encryption key(s) MUST be taken from the first (left-most, high- 1097 order) bits and the authentication key(s) MUST be taken from the 1098 remaining bits. The number of bits for each key is defined in the 1099 relevant algorithm specification RFC. In the case of multiple 1100 encryption keys or multiple authentication keys, the specification 1101 for the algorithm must specify the order in which they are to be 1102 selected from a single string of bits provided to the algorithm. 1104 4.6.3 Locating a Security Gateway 1106 This section discusses issues relating to how a host learns about the 1107 existence of relevant security gateways and once a host has contacted 1108 these security gateways, how it knows that these are the correct 1109 security gateways. The details of where the required information is 1110 stored is a local matter. 1112 Consider a situation in which a remote host (H1) is using the 1113 Internet to gain access to a server or other machine (H2) and there 1114 is a security gateway (SG2), e.g., a firewall, through which H1's 1115 traffic must pass. An example of this situation would be a mobile 1116 host (Road Warrior) crossing the Internet to the home organization's 1117 firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of 1118 Security Associations.) This situation raises several issues: 1120 1. How does H1 know/learn about the existence of the security 1121 gateway SG2? 1122 2. How does it authenticate SG2, and once it has authenticated 1123 SG2, how does it confirm that SG2 has been authorized to 1124 represent H2? 1125 3. How does SG2 authenticate H1 and verify that H1 is authorized 1126 to contact H2? 1127 4. How does H1 know/learn about backup gateways which provide 1128 alternate paths to H2? 1130 To address these problems, a host or security gateway MUST have an 1131 administrative interface that allows the user/administrator to 1132 configure the address of a security gateway for any sets of 1133 destination addresses that require its use. This includes the ability 1134 to configure: 1136 o the requisite information for locating and authenticating the 1137 security gateway and verifying its authorization to represent 1138 the destination host. 1139 o the requisite information for locating and authenticating any 1140 backup gateways and verifying their authorization to represent 1141 the destination host. 1143 It is assumed that the SPD is also configured with policy information 1144 that covers any other IPsec requirements for the path to the security 1145 gateway and the destination hos. 1147 This document does not address the issue of how to automate the 1148 discovery/verification of security gateways. 1150 4.7 Security Associations and Multicast 1152 The receiver-orientation of the Security Association implies that, in 1153 the case of unicast traffic, the destination system will normally 1154 select the SPI value. By having the destination select the SPI 1155 value, there is no potential for manually configured Security 1156 Associations to conflict with automatically configured (e.g., via a 1157 key management protocol) Security Associations or for Security 1158 Associations from multiple sources to conflict with each other. For 1159 multicast traffic, there are multiple destination systems per 1160 multicast group. So some system or person will need to coordinate 1161 among all multicast groups to select an SPI or SPIs on behalf of each 1162 multicast group and then communicate the group's IPsec information to 1163 all of the legitimate members of that multicast group via mechanisms 1164 not defined here. 1166 Multiple senders to a multicast group SHOULD use a single Security 1167 Association (and hence Security Parameter Index) for all traffic to 1168 that group when a symmetric key encryption or authentication 1169 algorithm is employed. In such circumstances, the receiver knows only 1170 that the message came from a system possessing the key for that 1171 multicast group. In such circumstances, a receiver generally will 1172 not be able to authenticate which system sent the multicast traffic. 1173 Specifications for other, more general multicast cases are deferred 1174 to later IPsec documents. 1176 At the time this specification was published, automated protocols for 1177 multicast key distribution were not considered adequately mature for 1178 standardization. For multicast groups having relatively few members, 1179 manual key distribution or multiple use of existing unicast key 1180 distribution algorithms such as modified Diffie-Hellman appears 1181 feasible. For very large groups, new scalable techniques will be 1182 needed. An example of current work in this area is the Group Key 1183 Management Protocol (GKMP) [HM97]. 1185 5. IPsec Traffic Processing 1187 5.1 Outbound IPsec Traffic Processing 1189 5.1.1 Selecting and Using an SA or SA Bundle 1191 In a security gateway or BITW implementation (and in many BITS 1192 implementations), each outbound packet is compared against the SPD to 1193 determine what processing is required for the packet. If the packet 1194 is to be discarded, this is an auditable event. If the traffic is 1195 allowed to bypass IPsec processing, the packet continues through 1196 "normal" processing for the environment in which the IPsec processing 1197 is taking place. If IPsec processing is required, the packet is 1198 either mapped to an existing SA (or SA bundle), or a new SA (or SA 1199 bundle) is created for the packet. Since a packet's selectors might 1200 match multiple policies or multiple extant SAs and since the SPD is 1201 ordered, but the SAD is not, IPsec MUST: 1203 1. Match the packet's selector fields against the outbound 1204 policies in the SPD to locate the first appropriate policy, 1205 which will point to zero or more SA bundles in the SAD. 1207 2. Match the packet's selector fields against those in the SA 1208 bundles found in (1) to locate the first SA bundle that 1209 matches. If no SAs were found or none match, search the SAD 1210 for an SA (created by other SPD entries) that matches. If 1211 none exist, create an appropriate SA bundle. 1213 3. Use the SA bundle found/created in (2) to do the required 1214 IPsec processing, e.g., authenticate and encrypt. 1216 In a host IPsec implementation based on sockets, the SPD will be 1217 consulted whenever a new socket is created, to determine what, if 1218 any, IPsec processing will be applied to the traffic that will flow 1219 on that socket. 1221 5.1.2 Header Construction for Tunnel Mode 1223 This section describes the handling of the inner and outer IP 1224 headers, extension headers, and options for AH and ESP tunnels. This 1225 includes how to construct the encapsulating (outer) IP header, how to 1226 handle fields in the inner IP header, and what other actions should 1227 be taken. The general idea is modeled after the one used in RFC 1228 2003, "IP Encapsulation with IP": 1230 o The outer IP header Source Address and Destination Address 1231 identify the "endpoints" of the tunnel (the encapsulator and 1232 decapsulator). The inner IP header Source Address and 1233 Destination Addresses identify the original sender and recipient 1234 of the datagram, respectively. 1235 o The inner IP header is not changed except to decrement the TTL 1236 as noted below, and remains unchanged during its delivery to the 1237 tunnel exit point. 1238 o No change to IP options or extension headers in the inner header 1239 occurs during delivery of the encapsulated datagram through the 1240 tunnel. 1241 o If need be, other protocol headers such as the IP Authentication 1242 header may be inserted between the outer IP header and the inner 1243 IP header. 1245 The tables in the following sub-sections show the handling for the 1246 different header/option fields (constructed = the value in the outer 1247 field is constructed independently of the value in the inner). 1249 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode 1251 <-- How Outer Hdr Relates Inner Hdr --> 1252 Outer Hdr at Inner Hdr at 1253 IPv4 Encapsulator Decapsulator 1254 Header fields: -------------------- ------------ 1255 version 4 (1) no change 1256 header length constructed no change 1257 TOS copied from inner hdr (5) no change 1258 total length constructed no change 1259 ID constructed no change 1260 flags (DF,MF) constructed, DF (4) no change 1261 fragmt offset constructed no change 1262 TTL constructed (2) decrement (2) 1263 protocol AH, ESP, routing hdr no change 1264 checksum constructed no change 1265 src address constructed (3) no change 1266 dest address constructed (3) no change 1267 Options never copied no change 1269 1. The IP version in the encapsulating header can be different 1270 from the value in the inner header. 1271 2. The TTL in the inner header is decremented by the 1272 encapsulator prior to forwarding and by the decapsulator if 1273 it forwards the packet. 1274 3. src and dest addresses depend on the SA, which is used to 1275 determine the dest address which in turn determines which src 1276 address (net interface) is used to forward the packet. 1277 4. configuration determines whether to copy from the inner 1278 header (IPv4 only), clear or set the DF. 1279 5. If Inner Hdr is IPv4, copy the TOS. If Inner Hdr is IPv6, 1280 map the Class to TOS. 1282 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode 1284 See previous section 5.1.2 for notes 1-5 indicated by (footnote number). 1286 <-- How Outer Hdr Relates Inner Hdr ---> 1287 Outer Hdr at Inner Hdr at 1288 IPv6 Encapsulator Decapsulator 1289 Header fields: -------------------- ------------ 1290 version 6 (1) no change 1291 class copied or configured (6) no change 1292 flow id copied or configured no change 1293 len constructed no change 1294 next header AH,ESP,routing hdr no change 1295 hop count constructed (2) decrement (2) 1296 src address constructed (3) no change 1297 dest address constructed (3) no change 1298 Extension headers never copied no change 1300 6. If Inner Hdr is IPv6, copy the Class. If Inner Hdr IPv4, 1301 map the TOS to Class. 1303 5.2 Processing Inbound IPsec Traffic 1305 Prior to performing AH or ESP processing, any IP fragments are 1306 reassembled. Each inbound IP datagram to which IPsec processing will 1307 be applied is identified by the appearance of the AH or ESP values in 1308 the IP Next Protocol field (or of AH or ESP as an extension header in 1309 the IPv6 context). 1311 Note: Appendix C contains sample code for a bitmask check for a 32 1312 packet window that can be used for implementing anti-replay service. 1314 5.2.1 Selecting and Using an SA or SA Bundle 1316 Mapping the IP datagram to the appropriate SA is simplified because 1317 of the presence of the SPI in the AH or ESP header. Note that the 1318 selector checks are made on the inner headers not the outer (tunnel) 1319 headers. The steps followed are: 1321 1. Use the packet's destination address (outer IP header), IPsec 1322 protocol, and SPI to look up the SA in the SAD. 1324 2. Use the SA found in (1) to do the IPsec processing, e.g., 1325 authenticate and decrypt. This step includes matching the 1326 packet's (Inner Header if tunneled) selectors to the 1327 selectors in the SA. Local policy determines the specificity 1328 of the SA selectors (single value, list, range, wildcard). 1329 In general, a packet's source address SHOULD match the SA 1330 selector value. (However, an AH or ESP-protected ICMP packet 1331 from a gateway may legitimately appear in a tunnel mode SA 1332 with a source IP address other than that bound to the SA, and 1333 thus such packets should be permitted as exceptions to this 1334 check. See Section 6.) Other packet fields MAY match the SA 1335 selector values as required by local policy. 1337 Do (1) and (2) for every IPsec header until a Transport 1338 Protocol Header or an IP header that is NOT for this system 1339 is encountered. Keep track of what SAs have been used and 1340 their order of application. 1342 3. Find an incoming policy in the SPD that matches the packet. 1343 This could be done, for example, by use of backpointers from 1344 the SAs to the SPD or by matching the packet's selectors 1345 (Inner Header if tunneled) against those of the policy 1346 entries in the SPD. 1348 4. Check whether the required IPsec processing has been applied, 1349 i.e., verify that the SA's found in (1) and (2) match the 1350 kind and order of SAs required by the policy found in (3). 1352 NOTE: The correct "matching" policy will not necessarily be 1353 the first inbound policy found. If the check in (4) fails, 1354 steps (3) and (4) are repeated until all policy entries have 1355 been checked or until the check succeeds. 1357 At the end of these steps, pass the resulting packet to the Transport 1358 Layer or forward the packet. Note that any IPsec headers processed 1359 in these steps may have been removed, but that this information, 1360 i.e., what SAs were used and the order of their application, may be 1361 needed for subsequent IPsec or firewall processing. 1363 5.2.2 Handling of AH and ESP tunnels 1365 The handling of the inner and outer IP headers, extension headers, 1366 and options for AH and ESP tunnels should be performed as described 1367 in the tables in Section 5.1. 1369 6. ICMP Processing (relevant to IPsec) 1371 An ICMP message protected by AH or ESP and generated by a router 1372 SHOULD be processed and forwarded in a tunnel mode SA, and MUST NOT 1373 be subjected to source address checks. An ICMP message protected by 1374 AH or ESP and generated by a router MUST NOT be forwarded on a 1375 transport mode SA (unless the SA has been established to the router 1376 acting as a host, e.g., a Telnet connection used to manage a router). 1377 An ICMP message generated by a host SHOULD be checked against the 1378 source IP address selectors bound to the SA in which the message 1379 arrives. 1381 The table in Appendix D characterize ICMP messages as being either 1382 host generated, router generated, both, unknown/unassigned. ICMP 1383 messages falling into the last two categories should be handled as 1384 determined by the receiver's policy. 1386 An ICMP message not protected by AH or ESP is unauthenticated and its 1387 processing and/or forwarding may result in denial of service. This 1388 suggests that, in general, it would be desirable to ignore such 1389 messages. However, it is expected that many routers (vs. security 1390 gateways) will not implement IPsec for transit traffic and thus 1391 strict adherence to this rule would cause many ICMP messages to be 1392 discarded. The result is that some critical IP functions would be 1393 lost, e.g., redirection and PMTU processing. Thus it MUST be 1394 possible to configure an IPsec implementation to accept or reject 1395 (router) ICMP traffic as per local security policy. 1397 The remainder of this section addresses how PMTU processing MUST be 1398 performed at hosts and security gateways. It addresses processing of 1399 both authenticated and unauthenticated ICMP PMTU messages. However, 1400 as noted above, unauthenticated ICMP messages MAY be discarded based 1401 on local policy. 1403 6.1 PMTU/DF Processing 1405 6.1.1 DF Bit 1407 In cases where a system (host or gateway) adds an encapsulating 1408 header (ESP tunnel or AH tunnel), it MUST support the option of 1409 copying the DF bit from the original packet to the encapsulating 1410 header (and processing ICMP PMTU messages). This means that it MUST 1411 be possible to configure the system's treatment of the DF bit (set, 1412 clear, copy from encapsulated header) for each interface. (See 1413 Appendix B for rationale.) 1415 6.1.2 Path MTU Discovery (PMTU) 1417 This section discusses IPsec handling for Path MTU Discovery 1418 messages. ICMP PMTU is used here to refer to an ICMP message for: 1420 IPv4 (RFC 792): 1421 - Type = 3 (Destination Unreachable) 1422 - Code = 4 (Fragmentation needed and DF set) 1423 - Next-Hop MTU in the low-order 16 bits of the second 1424 word of the ICMP header (labelled "unused" in RFC 1425 792), with high-order 16 bits set to zero 1427 IPv6 (RFC 1885): 1428 - Type = 2 (Packet Too Big) 1429 - Code = 0 (Fragmentation needed and DF set) 1430 - Next-Hop MTU in the 32 bit MTU field of the ICMP6 1431 message 1433 6.1.2.1 Propagation of PMTU 1435 The amount of information returned with the ICMP PMTU message (IPv4 1436 or IPv6) is limited and this affects what selectors are available for 1437 use in further propagating the PMTU information. (See Appendix B for 1438 more detailed discussion of this topic.) 1440 o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU 1441 message contains only 64 bits of the IPsec header (minimum for 1442 IPv4), then a security gateway MUST support the following options 1443 on a per SPI/SA basis: 1445 a. if the originating host can be determined (or the possible 1446 sources narrowed down to a manageable number), send the PMTU 1447 information to all the possible originating hosts. 1448 b. if the originating host cannot be determined, store the PMTU 1449 with the SA and wait until the next packet(s) arrive from the 1450 originating host for the relevant security association. If 1451 the packet(s) are bigger than the PMTU, drop the packet(s), 1452 and compose ICMP PMTU message(s) with the new packet(s) and 1453 the updated PMTU, and send the ICMP message(s) about the 1454 problem to the originating host. Retain the PMTU information 1455 for any message that might arrive subsequently (see Section 1456 6.1.2.4, "PMTU Aging"). 1458 o PMTU message with >64 bits of IPsec header -- If the ICMP message 1459 contains more information from the original packet, e.g., the 576 1460 byte minimum for IPv6, then there MAY be enough non-opaque 1461 information to immediately determine to which host to propagate the 1462 ICMP/PMTU message and to provide that system with the 5 fields 1463 (source address, destination address, source port, destination 1464 port, transport protocol) needed to determine where to store/update 1465 the PMTU. Under such circumstances, a security gateway MUST 1466 generate an ICMP PMTU message immediately upon receipt of an ICMP 1467 PMTU from further down the path. 1469 o Distributing the PMTU to the Transport Layer -- The host mechanism 1470 for getting the updated PMTU to the transport layer is unchanged, 1471 as specified in RFC 1191 (Path MTU Discovery). 1473 6.1.2.2 Calculation of PMTU 1475 The calculation of PMTU from an ICMP PMTU MUST take into account the 1476 addition of any IPsec header -- AH transport, ESP transport, AH/ESP 1477 transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of 1478 implementation issues.) 1480 6.1.2.3 Granularity of PMTU Processing 1482 In hosts, the granularity with which ICMP PMTU processing can be done 1483 differs depending on the implementation situation. Looking at a 1484 host, there are 3 situations that are of interest with respect to 1485 PMTU issues (See Appendix B for additional details on this topic.): 1487 a. Integration of IPsec into the native IP implementation 1488 b. Bump-in-the-stack implementations, where IPsec is implemented 1489 "underneath" an existing implementation of a TCP/IP protocol 1490 stack, between the native IP and the local network drivers 1491 c. No IPsec implementation -- This case is included because it 1492 is relevant in cases where a security gateway is sending PMTU 1493 information back to a host. 1495 Only in case (a) can the PMTU data be maintained at the same 1496 granularity as communication associations. In (b) and (c), the IP 1497 layer will only be able to maintain PMTU data at the granularity of 1498 source and destination IP addresses (and optionally ToS), as 1499 described in RFC 1191. This is an important difference, because more 1500 than one communication association may map to the same source and 1501 destination IP addresses, and each communication association may have 1502 a different amount of IPsec header overhead (e.g., due to use of 1503 different transforms or different algorithms). 1505 Implementation of the calculation of PMTU and support for PMTUs at 1506 the granularity of individual communication associations is a local 1507 matter. However, a socket-based implementation of IPsec in a host 1508 SHOULD maintain the information on a per socket basis. Bump in the 1509 stack systems MUST pass an ICMP PMTU to the host IP implementation, 1510 after adjusting it for any IPsec header overhead added by these 1511 systems. The calculation of the overhead SHOULD be determined by 1512 analysis of the SPI and any other selector information present in a 1513 returned ICMP PMTU message. 1515 6.1.2.4 PMTU Aging 1517 In all systems (host or gateway) implementing IPsec and maintaining 1518 PMTU information, the PMTU associated with a security association 1519 (transport or tunnel) MUST be "aged" and some mechanism put in place 1520 for updating the PMTU in a timely manner, especially for discovering 1521 if the PMTU is smaller than it needs to be. A given PMTU has to 1522 remain in place long enough for a packet to get from the source end 1523 of the security association to the system at the other end of the 1524 security association and propagate back an ICMP error message if the 1525 current PMTU is too big. Note that if there are nested tunnels, 1526 multiple packets and round trip times might be required to get an 1527 ICMP message back to an encapsulator or originating host. 1529 Systems SHOULD use the approach described in the Path MTU Discovery 1530 document (RFC 1191, Section 6.3), which suggests periodically 1531 resetting the PMTU to the first-hop data-link MTU and then letting 1532 the normal PMTU Discovery processes update the PMTU as necessary. 1533 The period SHOULD be configurable. 1535 7. Auditing 1537 Not all systems that implement IPsec will implement auditing. For 1538 the most part, the granularity of auditing is a local matter. 1539 However, several auditable events are identified in the AH and ESP 1540 specifications and for each of these events a minimum set of 1541 information that SHOULD be included in an audit log is defined. 1542 Additional information also MAY be included in the audit log for each 1543 of these events, and additional events, not explicitly called out in 1544 this specification, also MAY result in audit log entries. There is 1545 no requirement for the receiver to transmit any message to the 1546 purported transmitter in response to the detection of an auditable 1547 event, because of the potential to induce denial of service via such 1548 action. 1550 8. Use in Systems Supporting Information Flow Security 1552 A multi-level secure (MLS) network is one where a single network is 1553 used to communicate data with different sensitivity information 1554 labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85, 1555 DoD87]. The IP security mechanisms can easily support MLS 1556 networking. MLS networking requires the use of strong Mandatory 1557 Access Controls (MAC), which unprivileged users or unprivileged 1558 processes are incapable of controlling or violating [BL73]. This 1559 section pertains only to the use of these IP security mechanisms in 1560 MLS environments. Nothing in this section applies to systems not 1561 claiming to provide MLS. 1563 As used in this section, "sensitivity information" might include 1564 implementation-defined hierarchic levels, categories, and/or 1565 releasability information. 1567 The Authentication Header can be used to provide strong assurance for 1568 both mandatory access control decisions in multi-level networks and 1569 discretionary access control decisions in all kinds of networks. If 1570 explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and 1571 confidentiality is not considered necessary within the particular 1572 operational environment, the Authentication Header can be used to 1573 provide authentication for the entire packet, including cryptographic 1574 binding of the sensitivity information to the IP header and user 1575 data. This is a significant improvement over labeled IPv4 networks 1576 where the sensitivity information is trusted even though there is no 1577 authentication or cryptographic binding of the information to the IP 1578 header and user data. IPv4 networks might or might not use explicit 1579 labelling. IPv6 will normally use implicit sensitivity information 1580 that is part of the IPsec Security Association but not transmitted 1581 with each packet instead of using explicit sensitivity information. 1582 All explicit IP sensitivity information MUST be authenticated using 1583 either ESP, AH, or both. 1585 Encryption is useful and can be desirable even when all of the hosts 1586 are within a protected environment, for example, behind a firewall or 1587 disjoint from any external connectivity. The Internet-standard 1588 encryption algorithm could be used, in conjunction with appropriate 1589 key management, to provide strong Discretionary Access Controls 1590 (DAC). Key management could use sensitivity information to provide 1591 Mandatory Access Controls (MAC). Some environments, depending on 1592 their local policy, might consider the Internet-standard encryption 1593 algorithm sufficiently strong to provide MAC. IPsec implementations 1594 on systems claiming to provide MLS SHOULD be capable of using IPsec 1595 to provide MAC for IP-based communications. 1597 8.1 Relationship Between Security Associations and Data Sensitivity 1599 Both the Encapsulating Security Payload and the Authentication Header 1600 could be combined with appropriate Security Association policies to 1601 provide multi-level secure networking. In this case each SA (or SA 1602 bundle) is normally used for only a single instance of sensitivity 1603 information. For example, "PROPRIETARY - Internet Engineering" must 1604 be associated with a different SA (or SA bundle) from "PROPRIETARY - 1605 Finance". 1607 8.2 Sensitivity Consistency Checking 1609 An MLS implementation (both host and router) MAY associate 1610 sensitivity information, or a range of sensitivity information with 1611 an interface, or a configured IP address with its associated prefix 1612 (the latter is sometimes referred to as a logical interface, or an 1613 interface alias). If such properties exist, an implementation SHOULD 1614 compare the sensitivity information associated with the packet 1615 against the sensitivity information associated with the interface or 1616 address/prefix from which the packet arrived, or through which the 1617 packet will depart. This check will either verify that the 1618 sensitivities match, or that the packet's sensitivity falls within 1619 the range of the interface or address/prefix. 1621 The checking SHOULD be done on both inbound and outbound processing. 1623 8.3 Additional MLS Attributes for Security Association Databases 1625 Section 4.4 discussed two Security Association databases (the 1626 Security Policy Database (SPD) and the Security Association Database 1627 (SAD)) and the associated policy selectors and SA attributes. MLS 1628 networking introduces an additional selector/attribute: 1630 - Sensitivity information. 1632 The Sensitivity information aids in selecting the appropriate 1633 algorithms and key strength, so that the traffic gets a level of 1634 protection appropriate to its importance or sensitivity as described 1635 in section 8.1. The exact syntax of the sensitivity information is 1636 implementation defined. 1638 Sensitivity information is needed in the model shown in [BL73]. 1640 8.4 Additional Inbound Processing Steps for MLS Networking 1642 After an inbound packet has passed through IPsec processing, an MLS 1643 implementation SHOULD first check the packet's sensitivity (as 1644 defined by the SA (or SA bundle) used for the packet) with the 1645 interface or address/prefix as described in section 8.2 before 1646 delivering the datagram to an upper-layer protocol or forwarding it. 1648 The MLS system MUST retain the binding between the data received in 1649 an IPsec protected packet and the sensitivity information in the SA 1650 or SAs used for processing, so appropriate policy decisions can be 1651 made when delivering the datagram to an application or forwarding 1652 engine. The means for maintaining this binding are implementation 1653 specific. 1655 8.5 Additional Outbound Processing Steps for MLS Networking 1657 An MLS implementation of IPsec MUST perform two additional checks 1658 besides the normal steps detailed in section 5.1.1. When consulting 1659 the SPD or the SAD to find an outbound security association, the MLS 1660 implementation MUST use the sensitivity of the data to select an 1661 appropriate outbound SA or SA bundle. The second check comes before 1662 forwarding the packet out to its destination, and is the sensitivity 1663 consistency checking described in section 8.2. 1665 8.6 Additional MLS Processing for Security Gateways 1667 An MLS security gateway MUST follow the previously mentioned inbound 1668 and outbound processing rules as well as perform some additional 1669 processing specific to the intermediate protection of packets in an 1670 MLS environment. 1672 A security gateway MAY act as an outbound proxy for creating SAs for 1673 MLS systems that originate packets forwarded by the gateway. These 1674 MLS systems may explicitly label the packets to be forwarded, or the 1675 whole originating network may have sensitivity characteristics 1676 associated with it. The security gateway MUST create and use 1677 appropriate SAs for AH, ESP, or both, to protect such traffic it 1678 forwards. 1680 Similarly such a gateway SHOULD accept and process inbound AH and/or 1681 ESP packets and forward appropriately, using explicit packet 1682 labeling, or relying on the sensitivity characteristics of the 1683 destination network. 1685 9. Performance Issues 1687 The use of IPsec imposes computational performance costs on the hosts 1688 or security gateways that implement these protocols. These costs are 1689 associated with the memory needed for IPsec code and data structures, 1690 and the computation of integrity check values, encryption and 1691 decryption, and added per-packet handling. The per-packet 1692 computational costs will be manifested by increased latency and, 1693 possibly, reduced throughout. Use of SA/key management protocols, 1694 especially ones that employ public key cryptography, also adds 1695 computational performance costs to use of IPsec. These per- 1696 association computational costs will be manifested in terms of 1697 increased latency in association establishment. For many hosts, it 1698 is anticipated that software-based cryptography will not appreciably 1699 reduce throughput, but hardware may be required for security gateways 1700 (since they represent aggregation points), and for some hosts. 1702 The use of IPsec also imposes bandwidth utilization costs on 1703 transmission, switching, and routing components of the Internet 1704 infrastructure, components not implementing IPsec. This is due to 1705 the increase in the packet size resulting from the addition of AH 1706 and/or ESP headers, AH and ESP tunneling (which adds a second IP 1707 header), and the increased packet traffic associated with key 1708 management protocols. It is anticipated that, in most instances, 1709 this increased bandwidth demand will not noticeably affect the 1710 Internet infrastructure. However, in some instances, the effects may 1711 be significant, e.g., transmission of ESP encrypted traffic over a 1712 dialup link that otherwise would have compressed the traffic. 1714 Note: The initial SA establishment overhead will be felt in the first 1715 packet. This delay could impact the transport layer and application. 1716 For example, it could cause TCP to retransmit the SYN before the 1717 ISAKMP exchange is done. The effect of the delay would be different 1718 on UDP than TCP because TCP shouldn't transmit anything other than 1719 the SYN until the connection is set up whereas UDP will go ahead and 1720 transmit data beyond the first packet. 1722 Note: As discussed earlier, compression can still be employed at 1723 layers above IP. There is an IETF working group (IP Payload 1724 Compression Protocol (ippcp)) working on "protocol specifications 1725 that make it possible to perform lossless compression on individual 1726 payloads before the payload is processed by a protocol that encrypts 1727 it. These specifications will allow for compression operations to be 1728 performed prior to the encryption of a payload by IPsec protocols." 1730 10. Conformance Requirements 1732 All IPv4 systems that claim to implement IPsec MUST comply with all 1733 requirements of the Security Architecture document. All IPv6 systems 1734 MUST comply with all requirements of the Security Architecture 1735 document. 1737 11. Security Considerations 1739 The focus of this document is security; hence security considerations 1740 permeate this specification. 1742 12. Differences from RFC 1825 1744 This architecture document differs substantially from RFC 1825 in 1745 detail and in organization, but the fundamental notions are 1746 unchanged. This document provides considerable additional detail in 1747 terms of compliance specifications. It introduces the SPD and SAD, 1748 and the notion of SA selectors. It is aligned with the new versions 1749 of AH and ESP, which also differ from their predecessors. Specific 1750 requirements for supported combinations of AH and ESP are newly 1751 added, as are details of PMTU management. 1753 Acknowledgements 1755 Many of the concepts embodied in this specification were derived from 1756 or influenced by the US Government's SP3 security protocol, ISO/IEC's 1757 NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], 1758 and the work done for SNMP Security and SNMPv2 Security. 1760 For over 2 years (although it sometimes seems *much* longer) , this 1761 document has evolved through multiple versions and iterations. 1762 During this time, many people have contributed significant ideas and 1763 energy to the process and the documents themselves. The authors 1764 would like to thank Karen Seo for providing extensive help in the 1765 review, editing, background research, and coordination for this 1766 version of the specification. The authors would also like to thank 1767 the members of the IPsec and IPng working groups, with special 1768 mention of the efforts of (in alphabetic order): Steve Bellovin, 1769 Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry 1770 Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William 1771 Simpson, Harry Varnis, and Nina Yuan. 1773 Appendix A -- Glossary 1775 This section provides definitions for several key terms that are 1776 employed in this document. Other documents provide additional 1777 definitions and background information relevant to this technology, 1778 e.g., [VK83, HA94]. Included in this glossary are generic security 1779 service and security mechanism terms, plus IPsec-specific terms. 1781 Access Control 1782 Access control is a security service that prevents unauthorized 1783 use of a resource, including the prevention of use of a resource 1784 in an unauthorized manner. In the IPsec context, the resource to 1785 which access is being controlled is often: 1786 o for a host, computing cycles or data 1787 o for a security gateway, a network behind the gateway or 1788 bandwidth on that network. 1790 Anti-replay 1791 [See "Integrity" below] 1793 Authentication 1794 This term is used informally to refer to the combination of two 1795 nominally distinct security services, data origin authentication 1796 and connectionless integrity. See the definitions below for each 1797 of these services. 1799 Availability 1800 Availability, when viewed as a security service, addresses the 1801 security concerns engendered by attacks against networks that deny 1802 or degrade service. For example, in the IPsec context, the use of 1803 anti-replay mechanisms in AH and ESP support availability. 1805 Confidentiality 1806 Confidentiality is the security service that protects data from 1807 unauthorized disclosure. The primary confidentiality concern in 1808 most instances is unauthorized disclosure of application level 1809 data, but disclosure of the external characteristics of 1810 communication also can be a concern in some circumstances. 1811 Traffic flow confidentiality is the service that addresses this 1812 latter concern by concealing source and destination addresses, 1813 message length, or frequency of communication. In the IPsec 1814 context, using ESP in tunnel mode, especially at a security 1815 gateway, can provide some level of traffic flow confidentiality. 1816 (See also traffic analysis, below.) 1818 Encryption 1819 Encryption is a security mechanism used to transform data from an 1820 intelligible form (plaintext) into an unintelligible form 1821 (ciphertext), to provide confidentiality. The inverse 1822 transformation process is designated "decryption". Oftimes the 1823 term "encryption" is used to generically refer to both processes. 1825 Data Origin Authentication 1826 Data origin authentication is a security service that verifies the 1827 identity of the claimed source of data. This service is usually 1828 bundled with connectionless integrity service. 1830 Integrity 1831 Integrity is a security service that ensures that modifications to 1832 data are detectable. Integrity comes in various flavors to match 1833 application requirements. IPsec supports two forms of integrity: 1834 connectionless and a form of partial sequence integrity. 1835 Connectionless integrity is a service that detects modification of 1836 an individual IP datagram, without regard to the ordering of the 1837 datagram in a stream of traffic. The form of partial sequence 1838 integrity offered in IPsec is referred to as anti-replay 1839 integrity, and it detects arrival of duplicate IP datagrams 1840 (within a constrained window). This is in contrast to 1841 connection-oriented integrity, which imposes more stringent 1842 sequencing requirements on traffic, e.g., to be able to detect 1843 lost or re-ordered messages. Although authentication and 1844 integrity services often are cited separately, in practice they 1845 are intimately connected and almost always offered in tandem. 1847 Security Association (SA) 1848 A simplex (uni-directional) logical connection, created for 1849 security purposes. All traffic traversing an SA is provided the 1850 same security processing. In IPsec, an SA is an internet layer 1851 abstraction implemented through the use of AH or ESP. 1853 Security Gateway 1854 A security gateway is an intermediate system that acts as the 1855 communications interface between two networks. The set of hosts 1856 (and networks) on the external side of the security gateway is 1857 viewed as untrusted (or less trusted), while the networks and 1858 hosts and on the internal side are viewed as trusted (or more 1859 trusted). The internal subnets and hosts served by a security 1860 gateway are presumed to be trusted by virtue of sharing a common, 1861 local, security administration. (See "Trusted Subnetwork" below.) 1862 In the IPsec context, a security gateway is a point at which AH 1863 and/or ESP is implemented in order to serve a set of internal 1864 hosts, providing security services for these hosts when they 1865 communicate with external hosts also employing IPsec (either 1866 directly or via another security gateway). 1868 SPI 1869 Acronym for "Security Parameters Index". The combination of a 1870 destination address, a security protocol, and an SPI uniquely 1871 identifies a security association (SA, see above). The SPI is 1872 carried in AH and ESP protocols to enable the receiving system to 1873 select the SA under which a received packet will be processed. An 1874 SPI has only local significance, as defined by the creator of the 1875 SA (usually the receiver of the packet carrying the SPI); thus an 1876 SPI is generally viewed as an opaque bit string. However, the 1877 creator of an SA may choose to interpret the bits in an SPI to 1878 facilitate local processing. 1880 Traffic Analysis 1881 The analysis of network traffic flow for the purpose of deducing 1882 information that is useful to an adversary. Examples of such 1883 information are frequency of transmission, the identities of the 1884 conversing parties, sizes of packets, flow identifiers, etc. 1885 [Sch94] 1887 Trusted Subnetwork 1888 A subnetwork containing hosts and routers that trust each other 1889 not to engage in active or passive attacks. There also is an 1890 assumption that the underlying communications channel (e.g., a LAN 1891 or CAN) isn't being attacked by other means. 1893 Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues 1895 B.1 DF bit 1897 In cases where a system (host or gateway) adds an encapsulating 1898 header (e.g., ESP tunnel), should/must the DF bit in the original 1899 packet be copied to the encapsulating header? 1901 Fragmenting seems correct for some situations, e.g., it might be 1902 appropriate to fragment packets over a network with a very small MTU, 1903 e.g., a packet radio network, or a cellular phone hop to mobile node, 1904 rather than propagate back a very small PMTU for use over the rest of 1905 the path. In other situations, it might be appropriate to set the DF 1906 bit in order to get feedback from later routers about PMTU 1907 constraints which require fragmentation. The existence of both of 1908 these situations argues for enabling a system to decide whether or 1909 not to fragment over a particular network "link", i.e., for requiring 1910 an implementation to be able to copy the DF bit (and to process ICMP 1911 PMTU messages), but making it an option to be selected on a per 1912 interface basis. In other words, an administrator should be able to 1913 configure the router's treatment of the DF bit (set, clear, copy from 1914 encapsulated header) for each interface. 1916 Note: If a bump-in-the-stack implementation of IPsec attempts to 1917 apply different IPsec algorithms based on source/destination ports, 1918 it will be difficult to apply Path MTU adjustments. 1920 B.2 Fragmentation 1922 Fragmentation MUST be done after outbound IPsec processing. 1923 Reassembly MUST be done before inbound IPsec processing. The general 1924 reasoning is shown below (delimited by the ****'s). 1926 NOTE: IPsec always has to figure out what the encapsulating IP header 1927 fields are. This is independent of where you insert IPsec and is 1928 intrinsic to the definition of IPsec. Therefore any IPsec 1929 implementation that is not integrated into an IP implementation must 1930 include code to construct the necessary IP headers (e.g., IP2): 1932 o AH-tunnel --> IP2-AH-IP1-Transport-Data 1933 o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer 1935 ********************************************************************** 1937 Overall, the fragmentation/reassembly approach described above works 1938 for all cases examined. 1940 AH Xport AH Tunnel ESP Xport ESP Tunnel 1941 Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 1942 ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- 1943 Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y 1944 Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y 1945 S. Gwy (integr w/ IP stack) Y Y Y Y 1946 Outboard crypto processor * 1948 * If the crypto processor system has its own IP address, then it 1949 is covered by the security gateway case. This box receives 1950 the packet from the host and performs IPsec processing. It 1951 has to be able to handle the same AH, ESP, and related 1952 IPv4/IPv6 tunnel processing that a security gateway would have 1953 to handle. If it doesn't have it's own address, then it is 1954 similar to the bump-in-the stack implementation between IP and 1955 the network drivers. 1957 The following analysis assumes that: 1959 1. There is only one IPsec module in a given system's stack. 1960 There isn't an IPsec module A (adding ESP/encryption and 1961 thus) hiding the transport protocol, SRC port, and DEST port 1962 from IPsec module B. 1963 2. There are several places where IPsec could be implemented 1964 (as shown in the table above). 1965 a. Hosts with integration of IPsec into the native IP 1966 implementation. Implementer has access to the source 1967 for the stack. 1968 b. Hosts with bump-in-the-stack implementations, where 1969 IPsec is implemented between IP and the local network 1970 drivers. Source access for stack is not available; 1971 but there are well-defined interfaces that allows the 1972 IPsec code to be incorporated into the system. 1973 c. Security gateways and outboard crypto processors with 1974 integration of IPsec into the stack. 1975 3. Not all of the above approaches are feasible in all hosts. 1976 But it was assumed that for each approach, there are some 1977 hosts for whom the approach is feasible. 1979 For each of the above 3 categories, there are IPv4 and IPv6, AH 1980 transport and tunnel modes, and ESP transport and tunnel modes -- for 1981 a total of 24 cases (3 x 2 x 4). 1983 Some header fields and interface fields are listed here for ease of 1984 reference -- they're not in the header order, but instead listed to 1985 allow comparison between the columns. (* = not covered by AH 1986 authentication. ESP authentication doesn't cover any headers that 1987 precede it.) 1988 IP/Transport Interface 1989 IPv4 IPv6 (RFC 1122 -- Sec 3.4) 1990 ---- ---- ---------------------- 1991 Version = 4 Version = 6 1992 Header Len 1993 *TOS Class,Flow Lbl TOS 1994 Packet Len Payload Len Len 1995 ID ID (optional) 1996 *Flags DF 1997 *Offset 1998 *TTL *Hop Limit TTL 1999 Protocol Next Header 2000 *Checksum 2001 Src Address Src Address Src Address 2002 Dst Address Dst Address Dst Address 2003 Options? Options? Opt 2005 ? = AH covers Option-Type and Option-Length, but 2006 might not cover Option-Data. 2008 The results for each of the 24 cases is shown below ("works" = will 2009 work if system fragments after outbound IPsec processing, reassembles 2010 before inbound IPsec processing). Notes indicate implementation 2011 issues. 2013 a. Hosts (integrated into IP stack) 2014 o AH-transport --> (IP1-AH-Transport-Data) 2015 - IPv4 -- works 2016 - IPv6 -- works 2017 o AH-tunnel --> (IP2-AH-IP1-Transport-Data) 2018 - IPv4 -- works 2019 - IPv6 -- works 2020 o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) 2021 - IPv4 -- works 2022 - IPv6 -- works 2023 o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) 2024 - IPv4 -- works 2025 - IPv6 -- works 2027 b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and 2028 network drivers. In this case, the IPsec module would have to 2029 do something like one of the following for fragmentation and 2030 reassembly. 2031 - do the fragmentation/reassembly work itself and 2032 send/receive the packet directly to/from the network 2033 layer. In AH or ESP transport mode, this is fine. In AH 2034 or ESP tunnel mode where the tunnel is to the ultimate 2035 destination, this is fine. But in AH or ESP tunnel modes 2036 where the tunnel end is different from the ultimate 2037 destination and where the source host is multi-homed, this 2038 approach could result in sub-optimal routing because the 2039 IPsec module may be unable to obtain the information 2040 needed (LAN interface and next-hop gateway) to direct the 2041 packet to the appropriate network interface. This is not 2042 a problem if the interface and next-hop gateway are the 2043 same for the ultimate destination and for the tunnel end. 2044 But if they are different, then IPsec would need to know 2045 the LAN interface and the next-hop gateway for the tunnel 2046 end. (Note: The tunnel end (security gateway) is highly 2047 likely to be on the regular path to the ultimate 2048 destination. But there could also be more than one path 2049 to the destination, e.g., the host could be at an 2050 organization with 2 firewalls. And the path being used 2051 could involve the less commonly chosen firewall.) 2052 OR 2053 - pass the IPsec'd packet back to the IP layer where an 2054 extra IP header would end up being pre-pended and the 2055 IPsec module would have to check and let IPsec'd fragments 2056 go by. 2057 OR 2058 - pass the packet contents to the IP layer in a form such 2059 that the IP layer recreates an appropriate IP header 2061 At the network layer, the IPsec module will have access to the 2062 following selectors from the packet -- SRC address, DST address, 2063 TOS, Next Protocol, and if there's a transport layer header --> 2064 SRC port and DST port. One cannot assume IPsec has access to the 2065 User ID. It is assumed that the available selector information 2066 is sufficient to figure out the relevant Security Association(s). 2068 o AH-transport --> (IP1-AH-Transport-Data) 2069 - IPv4 -- works 2070 - IPv6 -- works 2071 o AH-tunnel --> (IP2-AH-IP1-Transport-Data) 2072 - IPv4 -- works 2073 - IPv6 -- works 2074 o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) 2075 - IPv4 -- works 2076 - IPv6 -- works 2077 o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) 2078 - IPv4 -- works 2079 - IPv6 -- works 2081 c. Security gateways -- integrate IPsec into the IP stack 2083 NOTE: The IPsec module will have access to the following 2084 selectors from the packet -- SRC address, DST address, TOS/Class, 2085 Next Protocol, and if there's a transport layer header --> SRC 2086 port and DST port. It won't have access to the User ID (only 2087 Hosts have access to User ID information.) It also won't have 2088 access to the transport layer information if there is an ESP 2089 header, or if it's not the first fragment of a fragmented 2090 message. It is assumed that the available selector information 2091 is sufficient to figure out the relevant Security Association(s). 2093 o AH-tunnel --> (IP2-AH-IP1-Transport-Data) 2094 - IPv4 -- works 2095 - IPv6 -- works 2096 o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) 2097 - IPv4 -- works 2098 - IPv6 -- works 2100 ********************************************************************** 2102 B.3 Path MTU Discovery 2104 As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for 2105 Path MTU Discovery. 2107 The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) 2108 is: 2110 ==== = security association (AH or ESP, transport or tunnel) 2111 ---- = connectivity (or if so labelled, administrative boundary) 2112 .... = ICMP message (hereafter referred to as ICMP PMTU) for 2114 IPv4: 2115 - Type = 3 (Destination Unreachable) 2116 - Code = 4 (Fragmentation needed and DF set) 2117 - Next-Hop MTU in the low-order 16 bits of the second 2118 word of the ICMP header (labelled unused in RFC 792), 2119 with high-order 16 bits set to zero 2121 IPv6 (RFC 1885): 2122 - Type = 2 (Packet Too Big) 2123 - Code = 0 (Fragmentation needed and DF set) 2124 - Next-Hop MTU in the 32 bit MTU field of the ICMP6 2126 Hx = host x 2127 Rx = router x 2128 SGx = security gateway x 2129 X* = X supports IPsec 2131 B.3.1 Identifying the Originating Host(s) 2133 The amount of information returned with the ICMP message is limited 2134 and this affects what selectors are available to identify security 2135 associations, originating hosts, etc. for use in further propagating 2136 the PMTU information. 2138 In brief... An ICMP message must contain the following information 2139 from the "offending" packet: 2140 - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits 2141 - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes 2143 Accordingly, in the IPv4 context, an ICMP PMTU may identify only the 2144 first (outermost) security association. This is because the ICMP 2145 PMTU may contain only 64 bits of the "offending" packet beyond the IP 2146 header, which would capture only the first SPI from AH or ESP. In 2147 the IPv6 context, an ICMP PMTU will probably provide all the SPIs and 2148 the selectors in the IP header, but maybe not the SRC/DST ports (in 2149 the transport header) or the encapsulated (TCP, UDP, etc.) protocol. 2150 Moreover, if ESP is used, the transport ports and protocol selectors 2151 may be encrypted. 2153 Looking at the diagram below of a security gateway tunnel (as 2154 mentioned elsewhere, security gateways do not use transport mode)... 2156 H1 =================== H3 2157 \ | | / 2158 H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 2159 / ^ | \ 2160 H2 |........| H4 2162 Suppose that the security policy for SG1 is to use a single SA to SG2 2163 for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, 2164 and H5. And suppose H0 sends a data packet to H5 which causes R1 to 2165 send an ICMP PMTU message to SG1. If the PMTU message has only the 2166 SPI, SG1 will be able to look up the SA and find the list of possible 2167 hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out 2168 that H0 sent the traffic that triggered the ICMP PMTU message. 2170 original after IPsec ICMP 2171 packet processing packet 2172 -------- ----------- ------ 2173 IP-3 header (S = R1, D = SG1) 2174 ICMP header (includes PMTU) 2175 IP-2 header IP-2 header (S = SG1, D = SG2) 2176 ESP header minimum of 64 bits of ESP hdr (*) 2177 IP-1 header IP-1 header 2178 TCP header TCP header 2179 TCP data TCP data 2180 ESP trailer 2182 (*) The 64 bits will include enough of the ESP (or AH) header to 2183 include the SPI. 2184 - ESP -- SPI (32 bits), Seq number (32 bits) 2185 - AH -- Next header (8 bits), Payload Len (8 bits), 2186 Reserved (16 bits), SPI (32 bits) 2188 This limitation on the amount of information returned with an ICMP 2189 message creates a problem in identifying the originating hosts for 2190 the packet (so as to know where to further propagate the ICMP PMTU 2191 information). If the ICMP message contains only 64 bits of the IPsec 2192 header (minimum for IPv4), then the IPsec selectors (e.g., Source and 2193 Destination addresses, Next Protocol, Source and Destination ports, 2194 etc.) will have been lost. But the ICMP error message will still 2195 provide SG1 with the SPI, the PMTU information and the source and 2196 destination gateways for the relevant security association. 2198 The destination security gateway and SPI uniquely define a security 2199 association which in turn defines a set of possible originating 2200 hosts. At this point, SG1 could: 2202 a. send the PMTU information to all the possible originating hosts. 2203 This would not work well if the host list is a wild card or if 2204 many/most of the hosts weren't sending to SG1; but it might work 2205 if the SPI/destination/etc mapped to just one or a small number of 2206 hosts. 2207 b. store the PMTU with the SPI/etc and wait until the next packet(s) 2208 arrive from the originating host(s) for the relevant security 2209 association. If it/they are bigger than the PMTU, drop the 2210 packet(s), and compose ICMP PMTU message(s) with the new 2211 packet(s) and the updated PMTU, and send the originating host(s) 2212 the ICMP message(s) about the problem. This involves a delay in 2213 notifying the originating host(s), but avoids the problems of (a). 2215 Since only the latter approach is feasible in all instances, a 2216 security gateway MUST provide such support, as an option. However, 2217 if the ICMP message contains more information from the original 2218 packet, e.g., the 576 byte minimum for IPv6, then there MAY be enough 2219 information to immediately determine to which host to propagate the 2220 ICMP/PMTU message and to provide that system with the 5 fields 2221 (source address, destination address, source port, destination port, 2222 and transport protocol) needed to determine where to store/update the 2223 PMTU. Under such circumstances, a security gateway MUST generate an 2224 ICMP PMTU message immediately upon receipt of an ICMP PMTU from 2225 further down the path. NOTE: The Next Protocol field MAY not be 2226 contained in the 576 bytes and the use of ESP encryption MAY hide the 2227 selector fields that have been encrypted. 2229 B.3.2 Calculation of PMTU 2231 The calculation of PMTU from an ICMP PMTU has to take into account 2232 the addition of any IPsec header by H1 -- AH and/or ESP transport, or 2233 ESP or AH tunnel. Within a single host, multiple applications may 2234 share an SPI and nesting of security associations may occur. The 2235 diagram below illustrates several possible combinations of security 2236 associations between a pair of hosts (as viewed from the perspective 2237 of one of the hosts.) (ESPt or AHt = tunnel mode; ESPx or AHx = 2238 transport mode) 2240 Socket 1 ----------------------------------------------- I 2241 | n 2242 Socket 2 (ESPt/SPI-A) ------------------------------- | t 2243 | | e 2244 Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r 2245 | n 2246 Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) --- e 2247 t 2249 In order to figure out the PMTU for each socket that maps to SPI-E, 2250 it will be necessary to have backpointers from SPI-E to each of the 2251 four paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H. 2253 B.3.3 Granularity of Maintaining PMTU Data 2255 In hosts, the granularity with which PMTU ICMP processing can be done 2256 differs depending on the implementation situation. Looking at a 2257 host, there are three situations that are of interest with respect to 2258 PMTU issues: 2260 a. Integration of IPsec into the native IP implementation 2261 b. Bump-in-the-stack implementations, where IPsec is implemented 2262 "underneath" an existing implementation of a TCP/IP protocol 2263 stack, between the native IP and the local network drivers 2264 c. No IPsec implementation -- This case is included because it is 2265 relevant in cases where a security gateway is sending PMTU 2266 information back to a host. 2268 Only in case (a) can the PMTU data be maintained at the same 2269 granularity as communication associations. In the other cases, the 2270 IP layer will maintain PMTU data at the granularity of Source and 2271 Destination IP addresses (and optionally TOS/Class), as described in 2272 RFC 1191. This is an important difference, because more than one 2273 communication association may map to the same source and destination 2274 IP addresses, and each communication association may have a different 2275 amount of IPsec header overhead (e.g., due to use of different 2276 transforms or different algorithms). The examples below illustrate 2277 this. 2279 In cases (a) and (b)... Suppose you have the following situation. 2280 H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds 2281 the PMTU of the network hop between them. 2283 ================================== 2284 | | 2285 H1* --- R1 ----- R2 ---- R3 ---- H2* 2286 ^ | 2287 |.......| 2289 If R1 is configured to not fragment subscriber traffic, then R1 sends 2290 an ICMP PMTU message with the appropriate PMTU to H1. H1's 2291 processing would vary with the nature of the implementation. In case 2292 (a) (native IP), the security services are bound to sockets or the 2293 equivalent. Here the IP/IPsec implementation in H1 can store/update 2294 the PMTU for the associated socket. In case (b), the IP layer in H1 2295 can store/update the PMTU but only at the granularity of Source and 2296 Destination addresses and possibly TOS/Class, as noted above. So the 2297 result may be sub-optimal, since the PMTU for a given 2298 SRC/DST/TOS/Class will be the subtraction of the largest amount of 2299 IPsec header used for any communication association between a given 2300 source and destination. 2302 In case (c), there has to be a security gateway to have any IPsec 2303 processing. So suppose you have the following situation. H1 is 2304 sending to H2 and the packet to be sent from SG1 to R exceeds the 2305 PMTU of the network hop between them. 2307 ================ 2308 | | 2309 H1 ---- SG1* --- R --- SG2* ---- H2 2310 ^ | 2311 |.......| 2313 As described above for case (b), the IP layer in H1 can store/update 2314 the PMTU but only at the granularity of Source and Destination 2315 addresses, and possibly TOS/Class. So the result may be sub-optimal, 2316 since the PMTU for a given SRC/DST/TOS/Class will be the subtraction 2317 of the largest amount of IPsec header used for any communication 2318 association between a given source and destination. 2320 B.3.4 Per Socket Maintenance of PMTU Data 2322 Implementation of the calculation of PMTU (Section B.2.2) and support 2323 for PMTUs at the granularity of individual "communication 2324 associations" (Section B.2.3) is a local matter. However, a socket- 2325 based implementation of IPsec in a host SHOULD maintain the 2326 information on a per socket basis. Bump in the stack systems MUST 2327 pass an ICMP PMTU to the host IP implementation, after adjusting it 2328 for any IPsec header overhead added by these systems. The 2329 determination of the overhead SHOULD be determined by analysis of the 2330 SPI and any other selector information present in a returned ICMP 2331 PMTU message. 2333 B.3.5 Delivery of PMTU Data to the Transport Layer 2335 The host mechanism for getting the updated PMTU to the transport 2336 layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). 2338 B.3.6 Aging of PMTU Data 2340 This topic is covered in Section 6.1.2.4. 2342 Appendix C -- Sequence Space Window Code Example 2344 This appendix contains a routine that implements a bitmask check for 2345 a 32 packet window. It was provided by James Hughes 2346 (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) 2347 and is intended as an implementation example. Note that this code 2348 both checks for a replay and updates the window. Thus the algorithm, 2349 as shown, should only be called AFTER the packet has been 2350 authenticated. Implementers might wish to consider splitting the 2351 code to do the check for replays before computing the ICV. If the 2352 packet is not a replay, the code would then compute the ICV, (discard 2353 any bad packets), and if the packet is OK, update the window. 2355 #include 2356 #include 2357 typedef unsigned long u_long; 2359 enum { 2360 ReplayWindowSize = 32 2361 }; 2363 u_long bitmap = 0; /* session state - must be 32 bits */ 2364 u_long lastSeq = 0; /* session state */ 2366 /* Returns 0 if packet disallowed, 1 if packet permitted */ 2367 int ChkReplayWindow(u_long seq); 2369 int ChkReplayWindow(u_long seq) { 2370 u_long diff; 2372 if (seq == 0) return 0; /* first == 0 or wrapped */ 2373 if (seq > lastSeq) { /* new larger sequence number */ 2374 diff = seq - lastSeq; 2375 if (diff < ReplayWindowSize) { /* In window */ 2376 bitmap <<= diff; 2377 bitmap |= 1; /* set bit for this packet */ 2378 } else bitmap = 1; /* This packet has a "way larger" */ 2379 lastSeq = seq; 2380 return 1; /* larger is good */ 2381 } 2382 diff = lastSeq - seq; 2383 if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ 2384 if (bitmap & (1 << diff)) return 0; /* this packet already seen */ 2385 bitmap |= (1 << diff); /* mark as seen */ 2386 return 1; /* out of order but good */ 2387 } 2389 char string_buffer[512]; 2390 #define STRING_BUFFER_SIZE sizeof(string_buffer) 2392 int main() { 2393 int result; 2394 u_long last, current, bits; 2396 printf("Input initial state (bits in hex, last msgnum):\n"); 2397 if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); 2398 sscanf(string_buffer, "%lx %lu", &bits, &last); 2399 if (last != 0) 2400 bits |= 1; 2401 bitmap = bits; 2402 lastSeq = last; 2403 printf("bits:%08lx last:%lu\n", bitmap, lastSeq); 2404 printf("Input value to test (current):\n"); 2406 while (1) { 2407 if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; 2408 sscanf(string_buffer, "%lu", ¤t); 2409 result = ChkReplayWindow(current); 2410 printf("%-3s", result ? "OK" : "BAD"); 2411 printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); 2412 } 2413 return 0; 2414 } 2415 Appendix D -- Categorization of ICMP messages 2417 The tables below characterize ICMP messages as being either host 2418 generated, router generated, both, unassigned/unknown. The first set 2419 are IPv4. The second set are IPv6. 2421 [Please let us know if any of these should re-categorized.] 2423 IPv4 2425 Type Name/Codes Reference 2426 ========================================================================= 2427 HOST GENERATED: 2428 3 Destination Unreachable 2429 2 Protocol Unreachable [RFC792] 2430 3 Port Unreachable [RFC792] 2431 8 Source Host Isolated [RFC792] 2432 14 Host Precedence Violation [RFC1812] 2433 10 Router Selection [RFC1256] 2435 Type Name/Codes Reference 2436 ========================================================================= 2437 ROUTER GENERATED: 2438 3 Destination Unreachable 2439 0 Net Unreachable [RFC792] 2440 4 Fragmentation Needed, Don't Fragment was Set [RFC792] 2441 5 Source Route Failed [RFC792] 2442 6 Destination Network Unknown [RFC792] 2443 7 Destination Host Unknown [RFC792] 2444 9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792] 2445 11 Destination Network Unreachable for Type of Service [RFC792] 2446 5 Redirect 2447 0 Redirect Datagram for the Network (or subnet) [RFC792] 2448 2 Redirect Datagram for the Type of Service & Network [RFC792] 2449 9 Router Advertisement [RFC1256] 2450 18 Address Mask Reply [RFC950] 2451 IPv4 2452 Type Name/Codes Reference 2453 ========================================================================= 2454 BOTH ROUTER AND HOST GENERATED: 2455 0 Echo Reply [RFC792] 2456 3 Destination Unreachable 2457 1 Host Unreachable [RFC792] 2458 10 Comm. w/Dest. Host is Administratively Prohibited [RFC792] 2459 12 Destination Host Unreachable for Type of Service [RFC792] 2460 13 Communication Administratively Prohibited [RFC1812] 2461 15 Precedence cutoff in effect [RFC1812] 2462 4 Source Quench [RFC792] 2463 5 Redirect 2464 1 Redirect Datagram for the Host [RFC792] 2465 3 Redirect Datagram for the Type of Service and Host [RFC792] 2466 6 Alternate Host Address [JBP] 2467 8 Echo [RFC792] 2468 11 Time Exceeded [RFC792] 2469 12 Parameter Problem [RFC792,RFC1108] 2470 13 Timestamp [RFC792] 2471 14 Timestamp Reply [RFC792] 2472 15 Information Request [RFC792] 2473 16 Information Reply [RFC792] 2474 17 Address Mask Request [RFC950] 2475 30 Traceroute [RFC1393] 2476 31 Datagram Conversion Error [RFC1475] 2477 32 Mobile Host Redirect [Johnson] 2478 39 SKIP [Markson] 2479 40 Photuris [Simpson] 2481 Type Name/Codes Reference 2482 ========================================================================= 2483 UNASSIGNED TYPE OR UNKNOWN GENERATOR: 2484 1 Unassigned [JBP] 2485 2 Unassigned [JBP] 2486 7 Unassigned [JBP] 2487 19 Reserved (for Security) [Solo] 2488 20-29 Reserved (for Robustness Experiment) [ZSu] 2489 33 IPv6 Where-Are-You [Simpson] 2490 34 IPv6 I-Am-Here [Simpson] 2491 35 Mobile Registration Request [Simpson] 2492 36 Mobile Registration Reply [Simpson] 2493 37 Domain Name Request [Simpson] 2494 38 Domain Name Reply [Simpson] 2495 41-255 Reserved [JBP] 2496 IPv6 2498 Type Name/Codes Reference 2499 ========================================================================= 2500 HOST GENERATED: 2501 1 Destination Unreachable [RFC 1885] 2502 4 Port Unreachable 2504 Type Name/Codes Reference 2505 ========================================================================= 2506 ROUTER GENERATED: 2507 1 Destination Unreachable [RFC1885] 2508 0 No Route to Destination 2509 1 Comm. w/Destination is Administratively Prohibited 2510 2 Not a Neighbor 2511 3 Address Unreachable 2512 2 Packet Too Big [RFC1885] 2513 0 2514 3 Time Exceeded [RFC1885] 2515 0 Hop Limit Exceeded in Transit 2516 1 Fragment reassembly time exceeded 2518 Type Name/Codes Reference 2519 ========================================================================= 2520 BOTH ROUTER AND HOST GENERATED: 2521 4 Parameter Problem [RFC1885] 2522 0 Erroneous Header Field Encountered 2523 1 Unrecognized Next Header Type Encountered 2524 2 Unrecognized IPv6 Option Encountered 2526 References 2528 [BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of 2529 IAB Workshop on Security in the Internet Architecture", 2530 RFC-1636, DDN Network Information Center, June 1994. 2532 [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP 2533 Protocol Suite", ACM Computer Communications Review, Vol. 2534 19, No. 2, March 1989. 2536 [Bel95] Steven M. Bellovin, Presentation at IP Security Working 2537 Group Meeting, Proceedings of the 32nd Internet Engineering 2538 Task Force, March 1995, Internet Engineering Task Force, 2539 Danvers, MA. 2541 [Bel96] Steven M. Bellovin, "Problem Areas for the IP Security 2542 Protocols", Proceedings of the Sixth Usenix Unix Security 2543 Symposium, July, 1996. 2545 [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: 2546 Mathematical Foundations and Model", Technical Report M74- 2547 244, The MITRE Corporation, Bedford, MA, May 1973. 2549 [CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & 2550 Internet Security, Addison-Wesley, Reading, MA, 1994. 2552 [CG96] Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with 2553 Replay Prevention", Internet Draft, 1 May 1996. 2555 [DIA] US Defense Intelligence Agency, "Compartmented Mode 2556 Workstation Specification", Technical Report DDS-2600- 2557 6243-87. 2559 [DoD85] US National Computer Security Center, "Department of 2560 Defense Trusted Computer System Evaluation Criteria", DoD 2561 5200.28-STD, US Department of Defense, Ft. Meade, MD., 2562 December 1985. 2564 [DoD87] US National Computer Security Center, "Trusted Network 2565 Interpretation of the Trusted Computer System Evaluation 2566 Criteria", NCSC-TG-005, Version 1, US Department of 2567 Defense, Ft. Meade, MD., 31 July 1987. 2569 [DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", 2570 IEEE Transactions on Information Theory, Vol. IT-22, No. 6, 2571 November 1976, pp. 644-654. 2573 [DH95] Steve Deering & Bob Hinden, Internet Protocol version 6 2574 (IPv6) Specification, RFC-1883, December 1995. 2576 [EK96] D. Eastlake III & C. Kaufman, "Domain Name System Protocol 2577 Security Extensions", Internet Draft, 30 January 1996. 2579 [GM93] J. Galvin & K. McCloghrie, "Security Protocols for version 2580 2 of the Simple Network Management Protocol (SNMPv2)", 2581 RFC-1446, DDN Network Information Center, April 1993. 2583 [HA94] N. Haller & R. Atkinson, "On Internet Authentication", 2584 RFC-1704, DDN Network Information Center, October 1994. 2586 [HC97] D. Harkins & D. Carrel, "The resolution of ISAKMP with 2587 Oakley", Internet Draft, February 1997. 2589 [HM97] H. Harney, C. Muckenhirn, "Group Key Management Protocol 2590 (GKMP) Architecture", RFC 2094, July 1997. 2592 [Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay 2593 Prevention Security Transform", Internet Draft, June 1996. 2595 [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC 2596 DIS 11577, International Standards Organisation, Geneva, 2597 Switzerland, 29 November 1992. 2599 [IB93] John Ioannidis and Matt Blaze, "Architecture and 2600 Implementation of Network-layer Security Under Unix", 2601 Proceedings of USENIX Security Symposium, Santa Clara, CA, 2602 October 1993. 2604 [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- 2605 Layer Security for IP", presentation at the Spring 1993 2606 IETF Meeting, Columbus, Ohio 2608 [KA97a] Steve Kent, Randall Atkinson, "IP Authentication Header", 2609 Internet Draft, October 1997. 2611 [KA97b] Steve Kent, Randall Atkinson, "IP Encapsulating Security 2612 Payload (ESP)", Internet Draft, October 1997. 2614 [Ken91] Steve Kent, "US DoD Security Options for the Internet 2615 Protocol", RFC-1108, DDN Network Information Center, 2616 November 1991. 2618 [Ken93] Steve Kent, Privacy Enhancement for Internet Electronic 2619 Mail: Part II: Certificate-Based Key Management, RFC-1422, 2620 DDN Network Information Center, 10 February 1993. 2622 [KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication 2623 Service (V5), RFC-1510, DDN Network Information Center, 10 2624 September 1993. 2626 [MSST97] D Maughan, M. Schertler, M. Schneider, & J. Turner, 2627 "Internet Security Association and Key Management Protocol 2628 (ISAKMP", Internet Draft, July 26, 1997. 2630 [NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for 2631 Authentication in Large Networks of Computers", 2632 Communications of the ACM, Vol. 21, No. 12, December 1978, 2633 pp. 993-999. 2635 [NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited", 2636 ACM Operating Systems Review, Vol. 21, No. 1., 1981. 2638 [OG96] Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with 2639 Replay Prevention", Internet Draft, 1 May 1996. 2641 [Orm97] H. K. Orman, "The OAKLEY Key Determination Protocol", 2642 Internet Draft, July 25, 1997. 2644 [OTA94] US Congress, Office of Technology Assessment, "Information 2645 Security & Privacy in Network Environments", OTA-TCT-606, 2646 Government Printing Office, Washington, DC, September 1994. 2648 [Pip97] D. Piper, "The Internet IP Security Domain of 2649 Interpretation for ISAKMP", Internet Draft, October 1997. 2651 [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John 2652 Wiley & Sons, New York, NY, 1994. 2654 [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, 2655 Document SDN.301, Revision 1.5, 15 May 1989, published in 2656 NIST Publication NIST-IR-90-4250, February 1990. 2658 [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1, 2659 March 1996. 2661 [TDG97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 2662 Roadmap", Internet Draft, July 1997. 2664 [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- 2665 level Networks", ACM Computing Surveys, Vol. 15, No. 2, 2666 June 1983. 2668 [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and 2669 Zappala, D., "RSVP: A New Resource ReSerVation Protocol", 2670 IEEE Network magazine, September 1993. 2672 Disclaimer 2674 The views and specification expressed in this document are those of 2675 the authors and are not necessarily those of their employers. The 2676 authors and their employers specifically disclaim responsibility for 2677 any problems arising from correct or incorrect implementation or use 2678 of this design. 2680 Author Information 2682 Stephen Kent 2683 BBN Corporation 2684 70 Fawcett Street 2685 Cambridge, MA 02140 2686 USA 2687 E-mail: kent@bbn.com 2688 Telephone: +1 (617) 873-3988 2690 Randall Atkinson 2691 @Home Network 2692 425 Broadway 2693 Redwood City, CA 94063 2694 USA 2695 E-mail: rja@inet.org 2697 Copyright (C) The Internet Society (November 1997). All Rights 2698 Reserved. 2700 This document and translations of it may be copied and furnished to 2701 others, and derivative works that comment on or otherwise explain it 2702 or assist in its implementation may be prepared, copied, published 2703 and distributed, in whole or in part, without restriction of any 2704 kind, provided that the above copyright notice and this paragraph are 2705 included on all such copies and derivative works. However, this 2706 document itself may not be modified in any way, such as by removing 2707 the copyright notice or references to the Internet Society or other 2708 Internet organizations, except as needed for the purpose of 2709 developing Internet standards in which case the procedures for 2710 copyrights defined in the Internet Standards process must be 2711 followed, or as required to translate it into languages other than 2712 English. 2714 The limited permissions granted above are perpetual and will not be 2715 revoked by the Internet Society or its successors or assigns. 2717 This document and the information contained herein is provided on an 2718 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2719 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2720 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2721 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2722 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.