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