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