diff options
Diffstat (limited to 'doc/rfc/rfc2401.txt')
-rw-r--r-- | doc/rfc/rfc2401.txt | 3699 |
1 files changed, 3699 insertions, 0 deletions
diff --git a/doc/rfc/rfc2401.txt b/doc/rfc/rfc2401.txt new file mode 100644 index 0000000..24fe2fa --- /dev/null +++ b/doc/rfc/rfc2401.txt @@ -0,0 +1,3699 @@ + + + + + + +Network Working Group S. Kent +Request for Comments: 2401 BBN Corp +Obsoletes: 1825 R. Atkinson +Category: Standards Track @Home Network + November 1998 + + + Security Architecture for the Internet Protocol + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Table of Contents + +1. Introduction........................................................3 + 1.1 Summary of Contents of Document..................................3 + 1.2 Audience.........................................................3 + 1.3 Related Documents................................................4 +2. Design Objectives...................................................4 + 2.1 Goals/Objectives/Requirements/Problem Description................4 + 2.2 Caveats and Assumptions..........................................5 +3. System Overview.....................................................5 + 3.1 What IPsec Does..................................................6 + 3.2 How IPsec Works..................................................6 + 3.3 Where IPsec May Be Implemented...................................7 +4. Security Associations...............................................8 + 4.1 Definition and Scope.............................................8 + 4.2 Security Association Functionality..............................10 + 4.3 Combining Security Associations.................................11 + 4.4 Security Association Databases..................................13 + 4.4.1 The Security Policy Database (SPD).........................14 + 4.4.2 Selectors..................................................17 + 4.4.3 Security Association Database (SAD)........................21 + 4.5 Basic Combinations of Security Associations.....................24 + 4.6 SA and Key Management...........................................26 + 4.6.1 Manual Techniques..........................................27 + 4.6.2 Automated SA and Key Management............................27 + 4.6.3 Locating a Security Gateway................................28 + 4.7 Security Associations and Multicast.............................29 + + + +Kent & Atkinson Standards Track [Page 1] + +RFC 2401 Security Architecture for IP November 1998 + + +5. IP Traffic Processing..............................................30 + 5.1 Outbound IP Traffic Processing..................................30 + 5.1.1 Selecting and Using an SA or SA Bundle.....................30 + 5.1.2 Header Construction for Tunnel Mode........................31 + 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode...........31 + 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode...........32 + 5.2 Processing Inbound IP Traffic...................................33 + 5.2.1 Selecting and Using an SA or SA Bundle.....................33 + 5.2.2 Handling of AH and ESP tunnels.............................34 +6. ICMP Processing (relevant to IPsec)................................35 + 6.1 PMTU/DF Processing..............................................36 + 6.1.1 DF Bit.....................................................36 + 6.1.2 Path MTU Discovery (PMTU)..................................36 + 6.1.2.1 Propagation of PMTU...................................36 + 6.1.2.2 Calculation of PMTU...................................37 + 6.1.2.3 Granularity of PMTU Processing........................37 + 6.1.2.4 PMTU Aging............................................38 +7. Auditing...........................................................39 +8. Use in Systems Supporting Information Flow Security................39 + 8.1 Relationship Between Security Associations and Data Sensitivity.40 + 8.2 Sensitivity Consistency Checking................................40 + 8.3 Additional MLS Attributes for Security Association Databases....41 + 8.4 Additional Inbound Processing Steps for MLS Networking..........41 + 8.5 Additional Outbound Processing Steps for MLS Networking.........41 + 8.6 Additional MLS Processing for Security Gateways.................42 +9. Performance Issues.................................................42 +10. Conformance Requirements..........................................43 +11. Security Considerations...........................................43 +12. Differences from RFC 1825.........................................43 +Acknowledgements......................................................44 +Appendix A -- Glossary................................................45 +Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.....48 + B.1 DF bit..........................................................48 + B.2 Fragmentation...................................................48 + B.3 Path MTU Discovery..............................................52 + B.3.1 Identifying the Originating Host(s)........................53 + B.3.2 Calculation of PMTU........................................55 + B.3.3 Granularity of Maintaining PMTU Data.......................56 + B.3.4 Per Socket Maintenance of PMTU Data........................57 + B.3.5 Delivery of PMTU Data to the Transport Layer...............57 + B.3.6 Aging of PMTU Data.........................................57 +Appendix C -- Sequence Space Window Code Example......................58 +Appendix D -- Categorization of ICMP messages.........................60 +References............................................................63 +Disclaimer............................................................64 +Author Information....................................................65 +Full Copyright Statement..............................................66 + + + + +Kent & Atkinson Standards Track [Page 2] + +RFC 2401 Security Architecture for IP November 1998 + + +1. Introduction + +1.1 Summary of Contents of Document + + This memo specifies the base architecture for IPsec compliant + systems. The goal of the architecture is to provide various security + services for traffic at the IP layer, in both the IPv4 and IPv6 + environments. This document describes the goals of such systems, + their components and how they fit together with each other and into + the IP environment. It also describes the security services offered + by the IPsec protocols, and how these services can be employed in the + IP environment. This document does not address all aspects of IPsec + architecture. Subsequent documents will address additional + architectural details of a more advanced nature, e.g., use of IPsec + in NAT environments and more complete support for IP multicast. The + following fundamental components of the IPsec security architecture + are discussed in terms of their underlying, required functionality. + Additional RFCs (see Section 1.3 for pointers to other documents) + define the protocols in (a), (c), and (d). + + a. Security Protocols -- Authentication Header (AH) and + Encapsulating Security Payload (ESP) + b. Security Associations -- what they are and how they work, + how they are managed, associated processing + c. Key Management -- manual and automatic (The Internet Key + Exchange (IKE)) + d. Algorithms for authentication and encryption + + This document is not an overall Security Architecture for the + Internet; it addresses security only at the IP layer, provided + through the use of a combination of cryptographic and protocol + security mechanisms. + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in RFC 2119 [Bra97]. + +1.2 Audience + + The target audience for this document includes implementers of this + IP security technology and others interested in gaining a general + background understanding of this system. In particular, prospective + users of this technology (end users or system administrators) are + part of the target audience. A glossary is provided as an appendix + + + + + + + +Kent & Atkinson Standards Track [Page 3] + +RFC 2401 Security Architecture for IP November 1998 + + + to help fill in gaps in background/vocabulary. This document assumes + that the reader is familiar with the Internet Protocol, related + networking technology, and general security terms and concepts. + +1.3 Related Documents + + As mentioned above, other documents provide detailed definitions of + some of the components of IPsec and of their inter-relationship. + They include RFCs on the following topics: + + a. "IP Security Document Roadmap" [TDG97] -- a document + providing guidelines for specifications describing encryption + and authentication algorithms used in this system. + b. security protocols -- RFCs describing the Authentication + Header (AH) [KA98a] and Encapsulating Security Payload (ESP) + [KA98b] protocols. + c. algorithms for authentication and encryption -- a separate + RFC for each algorithm. + d. automatic key management -- RFCs on "The Internet Key + Exchange (IKE)" [HC98], "Internet Security Association and + Key Management Protocol (ISAKMP)" [MSST97],"The OAKLEY Key + Determination Protocol" [Orm97], and "The Internet IP + Security Domain of Interpretation for ISAKMP" [Pip98]. + +2. Design Objectives + +2.1 Goals/Objectives/Requirements/Problem Description + + IPsec is designed to provide interoperable, high quality, + cryptographically-based security for IPv4 and IPv6. The set of + security services offered includes access control, connectionless + integrity, data origin authentication, protection against replays (a + form of partial sequence integrity), confidentiality (encryption), + and limited traffic flow confidentiality. These services are + provided at the IP layer, offering protection for IP and/or upper + layer protocols. + + These objectives are met through the use of two traffic security + protocols, the Authentication Header (AH) and the Encapsulating + Security Payload (ESP), and through the use of cryptographic key + management procedures and protocols. The set of IPsec protocols + employed in any context, and the ways in which they are employed, + will be determined by the security and system requirements of users, + applications, and/or sites/organizations. + + When these mechanisms are correctly implemented and deployed, they + ought not to adversely affect users, hosts, and other Internet + components that do not employ these security mechanisms for + + + +Kent & Atkinson Standards Track [Page 4] + +RFC 2401 Security Architecture for IP November 1998 + + + protection of their traffic. These mechanisms also are designed to + be algorithm-independent. This modularity permits selection of + different sets of algorithms without affecting the other parts of the + implementation. For example, different user communities may select + different sets of algorithms (creating cliques) if required. + + A standard set of default algorithms is specified to facilitate + interoperability in the global Internet. The use of these + algorithms, in conjunction with IPsec traffic protection and key + management protocols, is intended to permit system and application + developers to deploy high quality, Internet layer, cryptographic + security technology. + +2.2 Caveats and Assumptions + + The suite of IPsec protocols and associated default algorithms are + designed to provide high quality security for Internet traffic. + However, the security offered by use of these protocols ultimately + depends on the quality of the their implementation, which is outside + the scope of this set of standards. Moreover, the security of a + computer system or network is a function of many factors, including + personnel, physical, procedural, compromising emanations, and + computer security practices. Thus IPsec is only one part of an + overall system security architecture. + + Finally, the security afforded by the use of IPsec is critically + dependent on many aspects of the operating environment in which the + IPsec implementation executes. For example, defects in OS security, + poor quality of random number sources, sloppy system management + protocols and practices, etc. can all degrade the security provided + by IPsec. As above, none of these environmental attributes are + within the scope of this or other IPsec standards. + +3. System Overview + + This section provides a high level description of how IPsec works, + the components of the system, and how they fit together to provide + the security services noted above. The goal of this description is + to enable the reader to "picture" the overall process/system, see how + it fits into the IP environment, and to provide context for later + sections of this document, which describe each of the components in + more detail. + + An IPsec implementation operates in a host or a security gateway + environment, affording protection to IP traffic. The protection + offered is based on requirements defined by a Security Policy + Database (SPD) established and maintained by a user or system + administrator, or by an application operating within constraints + + + +Kent & Atkinson Standards Track [Page 5] + +RFC 2401 Security Architecture for IP November 1998 + + + established by either of the above. In general, packets are selected + for one of three processing modes based on IP and transport layer + header information (Selectors, Section 4.4.2) matched against entries + in the database (SPD). Each packet is either afforded IPsec security + services, discarded, or allowed to bypass IPsec, based on the + applicable database policies identified by the Selectors. + +3.1 What IPsec Does + + IPsec provides security services at the IP layer by enabling a system + to select required security protocols, determine the algorithm(s) to + use for the service(s), and put in place any cryptographic keys + required to provide the requested services. IPsec can be used to + protect one or more "paths" between a pair of hosts, between a pair + of security gateways, or between a security gateway and a host. (The + term "security gateway" is used throughout the IPsec documents to + refer to an intermediate system that implements IPsec protocols. For + example, a router or a firewall implementing IPsec is a security + gateway.) + + The set of security services that IPsec can provide includes access + control, connectionless integrity, data origin authentication, + rejection of replayed packets (a form of partial sequence integrity), + confidentiality (encryption), and limited traffic flow + confidentiality. Because these services are provided at the IP + layer, they can be used by any higher layer protocol, e.g., TCP, UDP, + ICMP, BGP, etc. + + The IPsec DOI also supports negotiation of IP compression [SMPT98], + motivated in part by the observation that when encryption is employed + within IPsec, it prevents effective compression by lower protocol + layers. + +3.2 How IPsec Works + + IPsec uses two protocols to provide traffic security -- + Authentication Header (AH) and Encapsulating Security Payload (ESP). + Both protocols are described in more detail in their respective RFCs + [KA98a, KA98b]. + + o The IP Authentication Header (AH) [KA98a] provides + connectionless integrity, data origin authentication, and an + optional anti-replay service. + o The Encapsulating Security Payload (ESP) protocol [KA98b] may + provide confidentiality (encryption), and limited traffic flow + confidentiality. It also may provide connectionless + + + + + +Kent & Atkinson Standards Track [Page 6] + +RFC 2401 Security Architecture for IP November 1998 + + + integrity, data origin authentication, and an anti-replay + service. (One or the other set of these security services + must be applied whenever ESP is invoked.) + o Both AH and ESP are vehicles for access control, based on the + distribution of cryptographic keys and the management of + traffic flows relative to these security protocols. + + These protocols may be applied alone or in combination with each + other to provide a desired set of security services in IPv4 and IPv6. + Each protocol supports two modes of use: transport mode and tunnel + mode. In transport mode the protocols provide protection primarily + for upper layer protocols; in tunnel mode, the protocols are applied + to tunneled IP packets. The differences between the two modes are + discussed in Section 4. + + IPsec allows the user (or system administrator) to control the + granularity at which a security service is offered. For example, one + can create a single encrypted tunnel to carry all the traffic between + two security gateways or a separate encrypted tunnel can be created + for each TCP connection between each pair of hosts communicating + across these gateways. IPsec management must incorporate facilities + for specifying: + + o which security services to use and in what combinations + o the granularity at which a given security protection should be + applied + o the algorithms used to effect cryptographic-based security + + Because these security services use shared secret values + (cryptographic keys), IPsec relies on a separate set of mechanisms + for putting these keys in place. (The keys are used for + authentication/integrity and encryption services.) This document + requires support for both manual and automatic distribution of keys. + It specifies a specific public-key based approach (IKE -- [MSST97, + Orm97, HC98]) for automatic key management, but other automated key + distribution techniques MAY be used. For example, KDC-based systems + such as Kerberos and other public-key systems such as SKIP could be + employed. + +3.3 Where IPsec May Be Implemented + + There are several ways in which IPsec may be implemented in a host or + in conjunction with a router or firewall (to create a security + gateway). Several common examples are provided below: + + a. Integration of IPsec into the native IP implementation. This + requires access to the IP source code and is applicable to + both hosts and security gateways. + + + +Kent & Atkinson Standards Track [Page 7] + +RFC 2401 Security Architecture for IP November 1998 + + + b. "Bump-in-the-stack" (BITS) implementations, where IPsec is + implemented "underneath" an existing implementation of an IP + protocol stack, between the native IP and the local network + drivers. Source code access for the IP stack is not required + in this context, making this implementation approach + appropriate for use with legacy systems. This approach, when + it is adopted, is usually employed in hosts. + + c. The use of an outboard crypto processor is a common design + feature of network security systems used by the military, and + of some commercial systems as well. It is sometimes referred + to as a "Bump-in-the-wire" (BITW) implementation. Such + implementations may be designed to serve either a host or a + gateway (or both). Usually the BITW device is IP + addressable. When supporting a single host, it may be quite + analogous to a BITS implementation, but in supporting a + router or firewall, it must operate like a security gateway. + +4. Security Associations + + This section defines Security Association management requirements for + all IPv6 implementations and for those IPv4 implementations that + implement AH, ESP, or both. The concept of a "Security Association" + (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a + major function of IKE is the establishment and maintenance of + Security Associations. All implementations of AH or ESP MUST support + the concept of a Security Association as described below. The + remainder of this section describes various aspects of Security + Association management, defining required characteristics for SA + policy management, traffic processing, and SA management techniques. + +4.1 Definition and Scope + + A Security Association (SA) is a simplex "connection" that affords + security services to the traffic carried by it. Security services + are afforded to an SA by the use of AH, or ESP, but not both. If + both AH and ESP protection is applied to a traffic stream, then two + (or more) SAs are created to afford protection to the traffic stream. + To secure typical, bi-directional communication between two hosts, or + between two security gateways, two Security Associations (one in each + direction) are required. + + A security association is uniquely identified by a triple consisting + of a Security Parameter Index (SPI), an IP Destination Address, and a + security protocol (AH or ESP) identifier. In principle, the + Destination Address may be a unicast address, an IP broadcast + address, or a multicast group address. However, IPsec SA management + mechanisms currently are defined only for unicast SAs. Hence, in the + + + +Kent & Atkinson Standards Track [Page 8] + +RFC 2401 Security Architecture for IP November 1998 + + + discussions that follow, SAs will be described in the context of + point-to-point communication, even though the concept is applicable + in the point-to-multipoint case as well. + + As noted above, two types of SAs are defined: transport mode and + tunnel mode. A transport mode SA is a security association between + two hosts. In IPv4, a transport mode security protocol header + appears immediately after the IP header and any options, and before + any higher layer protocols (e.g., TCP or UDP). In IPv6, the security + protocol header appears after the base IP header and extensions, but + may appear before or after destination options, and before higher + layer protocols. In the case of ESP, a transport mode SA provides + security services only for these higher layer protocols, not for the + IP header or any extension headers preceding the ESP header. In the + case of AH, the protection is also extended to selected portions of + the IP header, selected portions of extension headers, and selected + options (contained in the IPv4 header, IPv6 Hop-by-Hop extension + header, or IPv6 Destination extension headers). For more details on + the coverage afforded by AH, see the AH specification [KA98a]. + + A tunnel mode SA is essentially an SA applied to an IP tunnel. + Whenever either end of a security association is a security gateway, + the SA MUST be tunnel mode. Thus an SA between two security gateways + is always a tunnel mode SA, as is an SA between a host and a security + gateway. Note that for the case where traffic is destined for a + security gateway, e.g., SNMP commands, the security gateway is acting + as a host and transport mode is allowed. But in that case, the + security gateway is not acting as a gateway, i.e., not transiting + traffic. Two hosts MAY establish a tunnel mode SA between + themselves. The requirement for any (transit traffic) SA involving a + security gateway to be a tunnel SA arises due to the need to avoid + potential problems with regard to fragmentation and reassembly of + IPsec packets, and in circumstances where multiple paths (e.g., via + different security gateways) exist to the same destination behind the + security gateways. + + For a tunnel mode SA, there is an "outer" IP header that specifies + the IPsec processing destination, plus an "inner" IP header that + specifies the (apparently) ultimate destination for the packet. The + security protocol header appears after the outer IP header, and + before the inner IP header. If AH is employed in tunnel mode, + portions of the outer IP header are afforded protection (as above), + as well as all of the tunneled IP packet (i.e., all of the inner IP + header is protected, as well as higher layer protocols). If ESP is + employed, the protection is afforded only to the tunneled packet, not + to the outer header. + + + + + +Kent & Atkinson Standards Track [Page 9] + +RFC 2401 Security Architecture for IP November 1998 + + + In summary, + a) A host MUST support both transport and tunnel mode. + b) A security gateway is required to support only tunnel + mode. If it supports transport mode, that should be used + only when the security gateway is acting as a host, e.g., + for network management. + +4.2 Security Association Functionality + + The set of security services offered by an SA depends on the security + protocol selected, the SA mode, the endpoints of the SA, and on the + election of optional services within the protocol. For example, AH + provides data origin authentication and connectionless integrity for + IP datagrams (hereafter referred to as just "authentication"). The + "precision" of the authentication service is a function of the + granularity of the security association with which AH is employed, as + discussed in Section 4.4.2, "Selectors". + + AH also offers an anti-replay (partial sequence integrity) service at + the discretion of the receiver, to help counter denial of service + attacks. AH is an appropriate protocol to employ when + confidentiality is not required (or is not permitted, e.g , due to + government restrictions on use of encryption). AH also provides + authentication for selected portions of the IP header, which may be + necessary in some contexts. For example, if the integrity of an IPv4 + option or IPv6 extension header must be protected en route between + sender and receiver, AH can provide this service (except for the + non-predictable but mutable parts of the IP header.) + + ESP optionally provides confidentiality for traffic. (The strength + of the confidentiality service depends in part, on the encryption + algorithm employed.) ESP also may optionally provide authentication + (as defined above). If authentication is negotiated for an ESP SA, + the receiver also may elect to enforce an anti-replay service with + the same features as the AH anti-replay service. The scope of the + authentication offered by ESP is narrower than for AH, i.e., the IP + header(s) "outside" the ESP header is(are) not protected. If only + the upper layer protocols need to be authenticated, then ESP + authentication is an appropriate choice and is more space efficient + than use of AH encapsulating ESP. Note that although both + confidentiality and authentication are optional, they cannot both be + omitted. At least one of them MUST be selected. + + If confidentiality service is selected, then an ESP (tunnel mode) SA + between two security gateways can offer partial traffic flow + confidentiality. The use of tunnel mode allows the inner IP headers + to be encrypted, concealing the identities of the (ultimate) traffic + source and destination. Moreover, ESP payload padding also can be + + + +Kent & Atkinson Standards Track [Page 10] + +RFC 2401 Security Architecture for IP November 1998 + + + invoked to hide the size of the packets, further concealing the + external characteristics of the traffic. Similar traffic flow + confidentiality services may be offered when a mobile user is + assigned a dynamic IP address in a dialup context, and establishes a + (tunnel mode) ESP SA to a corporate firewall (acting as a security + gateway). Note that fine granularity SAs generally are more + vulnerable to traffic analysis than coarse granularity ones which are + carrying traffic from many subscribers. + +4.3 Combining Security Associations + + The IP datagrams transmitted over an individual SA are afforded + protection by exactly one security protocol, either AH or ESP, but + not both. Sometimes a security policy may call for a combination of + services for a particular traffic flow that is not achievable with a + single SA. In such instances it will be necessary to employ multiple + SAs to implement the required security policy. The term "security + association bundle" or "SA bundle" is applied to a sequence of SAs + through which traffic must be processed to satisfy a security policy. + The order of the sequence is defined by the policy. (Note that the + SAs that comprise a bundle may terminate at different endpoints. For + example, one SA may extend between a mobile host and a security + gateway and a second, nested SA may extend to a host behind the + gateway.) + + Security associations may be combined into bundles in two ways: + transport adjacency and iterated tunneling. + + o Transport adjacency refers to applying more than one + security protocol to the same IP datagram, without invoking + tunneling. This approach to combining AH and ESP allows + for only one level of combination; further nesting yields + no added benefit (assuming use of adequately strong + algorithms in each protocol) since the processing is + performed at one IPsec instance at the (ultimate) + destination. + + Host 1 --- Security ---- Internet -- Security --- Host 2 + | | Gwy 1 Gwy 2 | | + | | | | + | -----Security Association 1 (ESP transport)------- | + | | + -------Security Association 2 (AH transport)---------- + + o Iterated tunneling refers to the application of multiple + layers of security protocols effected through IP tunneling. + This approach allows for multiple levels of nesting, since + each tunnel can originate or terminate at a different IPsec + + + +Kent & Atkinson Standards Track [Page 11] + +RFC 2401 Security Architecture for IP November 1998 + + + site along the path. No special treatment is expected for + ISAKMP traffic at intermediate security gateways other than + what can be specified through appropriate SPD entries (See + Case 3 in Section 4.5) + + There are 3 basic cases of iterated tunneling -- support is + required only for cases 2 and 3.: + + 1. both endpoints for the SAs are the same -- The inner and + outer tunnels could each be either AH or ESP, though it + is unlikely that Host 1 would specify both to be the + same, i.e., AH inside of AH or ESP inside of ESP. + + Host 1 --- Security ---- Internet -- Security --- Host 2 + | | Gwy 1 Gwy 2 | | + | | | | + | -------Security Association 1 (tunnel)---------- | | + | | + ---------Security Association 2 (tunnel)-------------- + + 2. one endpoint of the SAs is the same -- The inner and + uter tunnels could each be either AH or ESP. + + Host 1 --- Security ---- Internet -- Security --- Host 2 + | | Gwy 1 Gwy 2 | + | | | | + | ----Security Association 1 (tunnel)---- | + | | + ---------Security Association 2 (tunnel)------------- + + 3. neither endpoint is the same -- The inner and outer + tunnels could each be either AH or ESP. + + Host 1 --- Security ---- Internet -- Security --- Host 2 + | Gwy 1 Gwy 2 | + | | | | + | --Security Assoc 1 (tunnel)- | + | | + -----------Security Association 2 (tunnel)----------- + + These two approaches also can be combined, e.g., an SA bundle could + be constructed from one tunnel mode SA and one or two transport mode + SAs, applied in sequence. (See Section 4.5 "Basic Combinations of + Security Associations.") Note that nested tunnels can also occur + where neither the source nor the destination endpoints of any of the + tunnels are the same. In that case, there would be no host or + security gateway with a bundle corresponding to the nested tunnels. + + + + +Kent & Atkinson Standards Track [Page 12] + +RFC 2401 Security Architecture for IP November 1998 + + + For transport mode SAs, only one ordering of security protocols seems + appropriate. AH is applied to both the upper layer protocols and + (parts of) the IP header. Thus if AH is used in a transport mode, in + conjunction with ESP, AH SHOULD appear as the first header after IP, + prior to the appearance of ESP. In that context, AH is applied to + the ciphertext output of ESP. In contrast, for tunnel mode SAs, one + can imagine uses for various orderings of AH and ESP. The required + set of SA bundle types that MUST be supported by a compliant IPsec + implementation is described in Section 4.5. + +4.4 Security Association Databases + + Many of the details associated with processing IP traffic in an IPsec + implementation are largely a local matter, not subject to + standardization. However, some external aspects of the processing + must be standardized, to ensure interoperability and to provide a + minimum management capability that is essential for productive use of + IPsec. This section describes a general model for processing IP + traffic relative to security associations, in support of these + interoperability and functionality goals. The model described below + is nominal; compliant implementations need not match details of this + model as presented, but the external behavior of such implementations + must be mappable to the externally observable characteristics of this + model. + + There are two nominal databases in this model: the Security Policy + Database and the Security Association Database. The former specifies + the policies that determine the disposition of all IP traffic inbound + or outbound from a host, security gateway, or BITS or BITW IPsec + implementation. The latter database contains parameters that are + associated with each (active) security association. This section + also defines the concept of a Selector, a set of IP and upper layer + protocol field values that is used by the Security Policy Database to + map traffic to a policy, i.e., an SA (or SA bundle). + + Each interface for which IPsec is enabled requires nominally separate + inbound vs. outbound databases (SAD and SPD), because of the + directionality of many of the fields that are used as selectors. + Typically there is just one such interface, for a host or security + gateway (SG). Note that an SG would always have at least 2 + interfaces, but the "internal" one to the corporate net, usually + would not have IPsec enabled and so only one pair of SADs and one + pair of SPDs would be needed. On the other hand, if a host had + multiple interfaces or an SG had multiple external interfaces, it + might be necessary to have separate SAD and SPD pairs for each + interface. + + + + + +Kent & Atkinson Standards Track [Page 13] + +RFC 2401 Security Architecture for IP November 1998 + + +4.4.1 The Security Policy Database (SPD) + + Ultimately, a security association is a management construct used to + enforce a security policy in the IPsec environment. Thus an + essential element of SA processing is an underlying Security Policy + Database (SPD) that specifies what services are to be offered to IP + datagrams and in what fashion. The form of the database and its + interface are outside the scope of this specification. However, this + section does specify certain minimum management functionality that + must be provided, to allow a user or system administrator to control + how IPsec is applied to traffic transmitted or received by a host or + transiting a security gateway. + + The SPD must be consulted during the processing of all traffic + (INBOUND and OUTBOUND), including non-IPsec traffic. In order to + support this, the SPD requires distinct entries for inbound and + outbound traffic. One can think of this as separate SPDs (inbound + vs. outbound). In addition, a nominally separate SPD must be + provided for each IPsec-enabled interface. + + An SPD must discriminate among traffic that is afforded IPsec + protection and traffic that is allowed to bypass IPsec. This applies + to the IPsec protection to be applied by a sender and to the IPsec + protection that must be present at the receiver. For any outbound or + inbound datagram, three processing choices are possible: discard, + bypass IPsec, or apply IPsec. The first choice refers to traffic + that is not allowed to exit the host, traverse the security gateway, + or be delivered to an application at all. The second choice refers + to traffic that is allowed to pass without additional IPsec + protection. The third choice refers to traffic that is afforded + IPsec protection, and for such traffic the SPD must specify the + security services to be provided, protocols to be employed, + algorithms to be used, etc. + + For every IPsec implementation, there MUST be an administrative + interface that allows a user or system administrator to manage the + SPD. Specifically, every inbound or outbound packet is subject to + processing by IPsec and the SPD must specify what action will be + taken in each case. Thus the administrative interface must allow the + user (or system administrator) to specify the security processing to + be applied to any packet entering or exiting the system, on a packet + by packet basis. (In a host IPsec implementation making use of a + socket interface, the SPD may not need to be consulted on a per + packet basis, but the effect is still the same.) The management + interface for the SPD MUST allow creation of entries consistent with + the selectors defined in Section 4.4.2, and MUST support (total) + ordering of these entries. It is expected that through the use of + wildcards in various selector fields, and because all packets on a + + + +Kent & Atkinson Standards Track [Page 14] + +RFC 2401 Security Architecture for IP November 1998 + + + single UDP or TCP connection will tend to match a single SPD entry, + this requirement will not impose an unreasonably detailed level of + SPD specification. The selectors are analogous to what are found in + a stateless firewall or filtering router and which are currently + manageable this way. + + In host systems, applications MAY be allowed to select what security + processing is to be applied to the traffic they generate and consume. + (Means of signalling such requests to the IPsec implementation are + outside the scope of this standard.) However, the system + administrator MUST be able to specify whether or not a user or + application can override (default) system policies. Note that + application specified policies may satisfy system requirements, so + that the system may not need to do additional IPsec processing beyond + that needed to meet an application's requirements. The form of the + management interface is not specified by this document and may differ + for hosts vs. security gateways, and within hosts the interface may + differ for socket-based vs. BITS implementations. However, this + document does specify a standard set of SPD elements that all IPsec + implementations MUST support. + + The SPD contains an ordered list of policy entries. Each policy + entry is keyed by one or more selectors that define the set of IP + traffic encompassed by this policy entry. (The required selector + types are defined in Section 4.4.2.) These define the granularity of + policies or SAs. Each entry includes an indication of whether + traffic matching this policy will be bypassed, discarded, or subject + to IPsec processing. If IPsec processing is to be applied, the entry + includes an SA (or SA bundle) specification, listing the IPsec + protocols, modes, and algorithms to be employed, including any + nesting requirements. For example, an entry may call for all + matching traffic to be protected by ESP in transport mode using + 3DES-CBC with an explicit IV, nested inside of AH in tunnel mode + using HMAC/SHA-1. For each selector, the policy entry specifies how + to derive the corresponding values for a new Security Association + Database (SAD, see Section 4.4.3) entry from those in the SPD and the + packet (Note that at present, ranges are only supported for IP + addresses; but wildcarding can be expressed for all selectors): + + a. use the value in the packet itself -- This will limit use + of the SA to those packets which have this packet's value + for the selector even if the selector for the policy entry + has a range of allowed values or a wildcard for this + selector. + b. use the value associated with the policy entry -- If this + were to be just a single value, then there would be no + difference between (b) and (a). However, if the allowed + values for the selector are a range (for IP addresses) or + + + +Kent & Atkinson Standards Track [Page 15] + +RFC 2401 Security Architecture for IP November 1998 + + + wildcard, then in the case of a range,(b) would enable use + of the SA by any packet with a selector value within the + range not just by packets with the selector value of the + packet that triggered the creation of the SA. In the case + of a wildcard, (b) would allow use of the SA by packets + with any value for this selector. + + For example, suppose there is an SPD entry where the allowed value + for source address is any of a range of hosts (192.168.2.1 to + 192.168.2.10). And suppose that a packet is to be sent that has a + source address of 192.168.2.3. The value to be used for the SA could + be any of the sample values below depending on what the policy entry + for this selector says is the source of the selector value: + + source for the example of + value to be new SAD + used in the SA selector value + --------------- ------------ + a. packet 192.168.2.3 (one host) + b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts) + + Note that if the SPD entry had an allowed value of wildcard for the + source address, then the SAD selector value could be wildcard (any + host). Case (a) can be used to prohibit sharing, even among packets + that match the same SPD entry. + + As described below in Section 4.4.3, selectors may include "wildcard" + entries and hence the selectors for two entries may overlap. (This + is analogous to the overlap that arises with ACLs or filter entries + in routers or packet filtering firewalls.) Thus, to ensure + consistent, predictable processing, SPD entries MUST be ordered and + the SPD MUST always be searched in the same order, so that the first + matching entry is consistently selected. (This requirement is + necessary as the effect of processing traffic against SPD entries + must be deterministic, but there is no way to canonicalize SPD + entries given the use of wildcards for some selectors.) More detail + on matching of packets against SPD entries is provided in Section 5. + + Note that if ESP is specified, either (but not both) authentication + or encryption can be omitted. So it MUST be possible to configure + the SPD value for the authentication or encryption algorithms to be + "NULL". However, at least one of these services MUST be selected, + i.e., it MUST NOT be possible to configure both of them as "NULL". + + The SPD can be used to map traffic to specific SAs or SA bundles. + Thus it can function both as the reference database for security + policy and as the map to existing SAs (or SA bundles). (To + accommodate the bypass and discard policies cited above, the SPD also + + + +Kent & Atkinson Standards Track [Page 16] + +RFC 2401 Security Architecture for IP November 1998 + + + MUST provide a means of mapping traffic to these functions, even + though they are not, per se, IPsec processing.) The way in which the + SPD operates is different for inbound vs. outbound traffic and it + also may differ for host vs. security gateway, BITS, and BITW + implementations. Sections 5.1 and 5.2 describe the use of the SPD + for outbound and inbound processing, respectively. + + Because a security policy may require that more than one SA be + applied to a specified set of traffic, in a specific order, the + policy entry in the SPD must preserve these ordering requirements, + when present. Thus, it must be possible for an IPsec implementation + to determine that an outbound or inbound packet must be processed + thorough a sequence of SAs. Conceptually, for outbound processing, + one might imagine links (to the SAD) from an SPD entry for which + there are active SAs, and each entry would consist of either a single + SA or an ordered list of SAs that comprise an SA bundle. When a + packet is matched against an SPD entry and there is an existing SA or + SA bundle that can be used to carry the traffic, the processing of + the packet is controlled by the SA or SA bundle entry on the list. + For an inbound IPsec packet for which multiple IPsec SAs are to be + applied, the lookup based on destination address, IPsec protocol, and + SPI should identify a single SA. + + The SPD is used to control the flow of ALL traffic through an IPsec + system, including security and key management traffic (e.g., ISAKMP) + from/to entities behind a security gateway. This means that ISAKMP + traffic must be explicitly accounted for in the SPD, else it will be + discarded. Note that a security gateway could prohibit traversal of + encrypted packets in various ways, e.g., having a DISCARD entry in + the SPD for ESP packets or providing proxy key exchange. In the + latter case, the traffic would be internally routed to the key + management module in the security gateway. + +4.4.2 Selectors + + An SA (or SA bundle) may be fine-grained or coarse-grained, depending + on the selectors used to define the set of traffic for the SA. For + example, all traffic between two hosts may be carried via a single + SA, and afforded a uniform set of security services. Alternatively, + traffic between a pair of hosts might be spread over multiple SAs, + depending on the applications being used (as defined by the Next + Protocol and Port fields), with different security services offered + by different SAs. Similarly, all traffic between a pair of security + gateways could be carried on a single SA, or one SA could be assigned + for each communicating host pair. The following selector parameters + MUST be supported for SA management to facilitate control of SA + granularity. Note that in the case of receipt of a packet with an + ESP header, e.g., at an encapsulating security gateway or BITW + + + +Kent & Atkinson Standards Track [Page 17] + +RFC 2401 Security Architecture for IP November 1998 + + + implementation, the transport layer protocol, source/destination + ports, and Name (if present) may be "OPAQUE", i.e., inaccessible + because of encryption or fragmentation. Note also that both Source + and Destination addresses should either be IPv4 or IPv6. + + - Destination IP Address (IPv4 or IPv6): this may be a single IP + address (unicast, anycast, broadcast (IPv4 only), or multicast + group), a range of addresses (high and low values (inclusive), + address + mask, or a wildcard address. The last three are used + to support more than one destination system sharing the same SA + (e.g., behind a security gateway). Note that this selector is + conceptually different from the "Destination IP Address" field + in the <Destination IP Address, IPsec Protocol, SPI> tuple used + to uniquely identify an SA. When a tunneled packet arrives at + the tunnel endpoint, its SPI/Destination address/Protocol are + used to look up the SA for this packet in the SAD. This + destination address comes from the encapsulating IP header. + Once the packet has been processed according to the tunnel SA + and has come out of the tunnel, its selectors are "looked up" in + the Inbound SPD. The Inbound SPD has a selector called + destination address. This IP destination address is the one in + the inner (encapsulated) IP header. In the case of a + transport'd packet, there will be only one IP header and this + ambiguity does not exist. [REQUIRED for all implementations] + + - Source IP Address(es) (IPv4 or IPv6): this may be a single IP + address (unicast, anycast, broadcast (IPv4 only), or multicast + group), range of addresses (high and low values inclusive), + address + mask, or a wildcard address. The last three are used + to support more than one source system sharing the same SA + (e.g., behind a security gateway or in a multihomed host). + [REQUIRED for all implementations] + + - Name: There are 2 cases (Note that these name forms are + supported in the IPsec DOI.) + 1. User ID + a. a fully qualified user name string (DNS), e.g., + mozart@foo.bar.com + b. X.500 distinguished name, e.g., C = US, SP = MA, + O = GTE Internetworking, CN = Stephen T. Kent. + 2. System name (host, security gateway, etc.) + a. a fully qualified DNS name, e.g., foo.bar.com + b. X.500 distinguished name + c. X.500 general name + + NOTE: One of the possible values of this selector is "OPAQUE". + + + + + +Kent & Atkinson Standards Track [Page 18] + +RFC 2401 Security Architecture for IP November 1998 + + + [REQUIRED for the following cases. Note that support for name + forms other than addresses is not required for manually keyed + SAs. + o User ID + - native host implementations + - BITW and BITS implementations acting as HOSTS + with only one user + - security gateway implementations for INBOUND + processing. + o System names -- all implementations] + + - Data sensitivity level: (IPSO/CIPSO labels) + [REQUIRED for all systems providing information flow security as + per Section 8, OPTIONAL for all other systems.] + + - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or + the IPv6 "Next Header" fields. This may be an individual + protocol number. These packet fields may not contain the + Transport Protocol due to the presence of IP extension headers, + e.g., a Routing Header, AH, ESP, Fragmentation Header, + Destination Options, Hop-by-hop options, etc. Note that the + Transport Protocol may not be available in the case of receipt + of a packet with an ESP header, thus a value of "OPAQUE" SHOULD + be supported. + [REQUIRED for all implementations] + + NOTE: To locate the transport protocol, a system has to chain + through the packet headers checking the "Protocol" or "Next + Header" field until it encounters either one it recognizes as a + transport protocol, or until it reaches one that isn't on its + list of extension headers, or until it encounters an ESP header + that renders the transport protocol opaque. + + - Source and Destination (e.g., TCP/UDP) Ports: These may be + individual UDP or TCP port values or a wildcard port. (The use + of the Next Protocol field and the Source and/or Destination + Port fields (in conjunction with the Source and/or Destination + Address fields), as an SA selector is sometimes referred to as + "session-oriented keying."). Note that the source and + destination ports may not be available in the case of receipt of + a packet with an ESP header, thus a value of "OPAQUE" SHOULD be + supported. + + The following table summarizes the relationship between the + "Next Header" value in the packet and SPD and the derived Port + Selector value for the SPD and SAD. + + + + + +Kent & Atkinson Standards Track [Page 19] + +RFC 2401 Security Architecture for IP November 1998 + + + Next Hdr Transport Layer Derived Port Selector Field + in Packet Protocol in SPD Value in SPD and SAD + -------- --------------- --------------------------- + ESP ESP or ANY ANY (i.e., don't look at it) + -don't care- ANY ANY (i.e., don't look at it) + specific value specific value NOT ANY (i.e., drop packet) + fragment + specific value specific value actual port selector field + not fragment + + If the packet has been fragmented, then the port information may + not be available in the current fragment. If so, discard the + fragment. An ICMP PMTU should be sent for the first fragment, + which will have the port information. [MAY be supported] + + The IPsec implementation context determines how selectors are used. + For example, a host implementation integrated into the stack may make + use of a socket interface. When a new connection is established the + SPD can be consulted and an SA (or SA bundle) bound to the socket. + Thus traffic sent via that socket need not result in additional + lookups to the SPD/SAD. In contrast, a BITS, BITW, or security + gateway implementation needs to look at each packet and perform an + SPD/SAD lookup based on the selectors. The allowable values for the + selector fields differ between the traffic flow, the security + association, and the security policy. + + The following table summarizes the kinds of entries that one needs to + be able to express in the SPD and SAD. It shows how they relate to + the fields in data traffic being subjected to IPsec screening. + (Note: the "wild" or "wildcard" entry for src and dst addresses + includes a mask, range, etc.) + + Field Traffic Value SAD Entry SPD Entry + -------- ------------- ---------------- -------------------- + src addr single IP addr single,range,wild single,range,wildcard + dst addr single IP addr single,range,wild single,range,wildcard + xpt protocol* xpt protocol single,wildcard single,wildcard + src port* single src port single,wildcard single,wildcard + dst port* single dst port single,wildcard single,wildcard + user id* single user id single,wildcard single,wildcard + sec. labels single value single,wildcard single,wildcard + + * The SAD and SPD entries for these fields could be "OPAQUE" + because the traffic value is encrypted. + + NOTE: In principle, one could have selectors and/or selector values + in the SPD which cannot be negotiated for an SA or SA bundle. + Examples might include selector values used to select traffic for + + + +Kent & Atkinson Standards Track [Page 20] + +RFC 2401 Security Architecture for IP November 1998 + + + discarding or enumerated lists which cause a separate SA to be + created for each item on the list. For now, this is left for future + versions of this document and the list of required selectors and + selector values is the same for the SPD and the SAD. However, it is + acceptable to have an administrative interface that supports use of + selector values which cannot be negotiated provided that it does not + mislead the user into believing it is creating an SA with these + selector values. For example, the interface may allow the user to + specify an enumerated list of values but would result in the creation + of a separate policy and SA for each item on the list. A vendor + might support such an interface to make it easier for its customers + to specify clear and concise policy specifications. + +4.4.3 Security Association Database (SAD) + + In each IPsec implementation there is a nominal Security Association + Database, in which each entry defines the parameters associated with + one SA. Each SA has an entry in the SAD. For outbound processing, + entries are pointed to by entries in the SPD. Note that if an SPD + entry does not currently point to an SA that is appropriate for the + packet, the implementation creates an appropriate SA (or SA Bundle) + and links the SPD entry to the SAD entry (see Section 5.1.1). For + inbound processing, each entry in the SAD is indexed by a destination + IP address, IPsec protocol type, and SPI. The following parameters + are associated with each entry in the SAD. This description does not + purport to be a MIB, but only a specification of the minimal data + items required to support an SA in an IPsec implementation. + + For inbound processing: The following packet fields are used to look + up the SA in the SAD: + + o Outer Header's Destination IP address: the IPv4 or IPv6 + Destination address. + [REQUIRED for all implementations] + o IPsec Protocol: AH or ESP, used as an index for SA lookup + in this database. Specifies the IPsec protocol to be + applied to the traffic on this SA. + [REQUIRED for all implementations] + o SPI: the 32-bit value used to distinguish among different + SAs terminating at the same destination and using the same + IPsec protocol. + [REQUIRED for all implementations] + + 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 + + + +Kent & Atkinson Standards Track [Page 21] + +RFC 2401 Security Architecture for IP November 1998 + + + 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 following SAD fields are used in doing IPsec processing: + + o Sequence Number Counter: a 32-bit value used to generate the + Sequence Number field in AH or ESP headers. + [REQUIRED for all implementations, but used only for outbound + traffic.] + o Sequence Counter Overflow: a flag indicating whether overflow + of the Sequence Number Counter should generate an auditable + event and prevent transmission of additional packets on the + SA. + [REQUIRED for all implementations, but used only for outbound + traffic.] + o Anti-Replay Window: a 32-bit counter and a bit-map (or + equivalent) used to determine whether an inbound AH or ESP + packet is a replay. + [REQUIRED for all implementations but used only for inbound + traffic. NOTE: If anti-replay has been disabled by the + receiver, e.g., in the case of a manually keyed SA, then the + Anti-Replay Window is not used.] + o AH Authentication algorithm, keys, etc. + [REQUIRED for AH implementations] + o ESP Encryption algorithm, keys, IV mode, IV, etc. + [REQUIRED for ESP implementations] + o ESP authentication algorithm, keys, etc. If the + authentication service is not selected, this field will be + null. + [REQUIRED for ESP implementations] + o Lifetime of this Security Association: a time interval after + which an SA must be replaced with a new SA (and new SPI) or + terminated, plus an indication of which of these actions + should occur. This may be expressed as a time or byte count, + or a simultaneous use of both, the first lifetime to expire + taking precedence. A compliant implementation MUST support + both types of lifetimes, and must support a simultaneous use + of both. If time is employed, and if IKE employs X.509 + certificates for SA establishment, the SA lifetime must be + constrained by the validity intervals of the certificates, + and the NextIssueDate of the CRLs used in the IKE exchange + + + +Kent & Atkinson Standards Track [Page 22] + +RFC 2401 Security Architecture for IP November 1998 + + + for the SA. Both initiator and responder are responsible for + constraining SA lifetime in this fashion. + [REQUIRED for all implementations] + + NOTE: The details of how to handle the refreshing of keys + when SAs expire is a local matter. However, one reasonable + approach is: + (a) If byte count is used, then the implementation + SHOULD count the number of bytes to which the IPsec + algorithm is applied. For ESP, this is the encryption + algorithm (including Null encryption) and for AH, + this is the authentication algorithm. This includes + pad bytes, etc. Note that implementations SHOULD be + able to handle having the counters at the ends of an + SA get out of synch, e.g., because of packet loss or + because the implementations at each end of the SA + aren't doing things the same way. + (b) There SHOULD be two kinds of lifetime -- a soft + lifetime which warns the implementation to initiate + action such as setting up a replacement SA and a + hard lifetime when the current SA ends. + (c) If the entire packet does not get delivered during + the SAs lifetime, the packet SHOULD be discarded. + + o IPsec protocol mode: tunnel, transport or wildcard. + Indicates which mode of AH or ESP is applied to traffic on + this SA. Note that if this field is "wildcard" at the + sending end of the SA, then the application has to specify + the mode to the IPsec implementation. This use of wildcard + allows the same SA to be used for either tunnel or transport + mode traffic on a per packet basis, e.g., by different + sockets. The receiver does not need to know the mode in + order to properly process the packet's IPsec headers. + + [REQUIRED as follows, unless implicitly defined by context: + - host implementations must support all modes + - gateway implementations must support tunnel mode] + + NOTE: The use of wildcard for the protocol mode of an inbound + SA may add complexity to the situation in the receiver (host + only). Since the packets on such an SA could be delivered in + either tunnel or transport mode, the security of an incoming + packet could depend in part on which mode had been used to + deliver it. If, as a result, an application cared about the + SA mode of a given packet, then the application would need a + mechanism to obtain this mode information. + + + + + +Kent & Atkinson Standards Track [Page 23] + +RFC 2401 Security Architecture for IP November 1998 + + + o Path MTU: any observed path MTU and aging variables. See + Section 6.1.2.4 + [REQUIRED for all implementations but used only for outbound + traffic] + +4.5 Basic Combinations of Security Associations + + This section describes four examples of combinations of security + associations that MUST be supported by compliant IPsec hosts or + security gateways. Additional combinations of AH and/or ESP in + tunnel and/or transport modes MAY be supported at the discretion of + the implementor. Compliant implementations MUST be capable of + generating these four combinations and on receipt, of processing + them, but SHOULD be able to receive and process any combination. The + diagrams and text below describe the basic cases. The legend for the + diagrams is: + + ==== = one or more security associations (AH or ESP, transport + or tunnel) + ---- = connectivity (or if so labelled, administrative boundary) + Hx = host x + SGx = security gateway x + X* = X supports IPsec + + NOTE: The security associations below can be either AH or ESP. The + mode (tunnel vs transport) is determined by the nature of the + endpoints. For host-to-host SAs, the mode can be either transport or + tunnel. + + Case 1. The case of providing end-to-end security between 2 hosts + across the Internet (or an Intranet). + + ==================================== + | | + H1* ------ (Inter/Intranet) ------ H2* + + Note that either transport or tunnel mode can be selected by the + hosts. So the headers in a packet between H1 and H2 could look + like any of the following: + + Transport Tunnel + ----------------- --------------------- + 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] + 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] + 3. [IP1][AH][ESP][upper] + + + + + + +Kent & Atkinson Standards Track [Page 24] + +RFC 2401 Security Architecture for IP November 1998 + + + Note that there is no requirement to support general nesting, + but in transport mode, both AH and ESP can be applied to the + packet. In this event, the SA establishment procedure MUST + ensure that first ESP, then AH are applied to the packet. + + Case 2. This case illustrates simple virtual private networks + support. + + =========================== + | | + ---------------------|---- ---|----------------------- + | | | | | | + | H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 | + | Intranet) | | Intranet) | + -------------------------- --------------------------- + admin. boundary admin. boundary + + Only tunnel mode is required here. So the headers in a packet + between SG1 and SG2 could look like either of the following: + + Tunnel + --------------------- + 4. [IP2][AH][IP1][upper] + 5. [IP2][ESP][IP1][upper] + + Case 3. This case combines cases 1 and 2, adding end-to-end security + between the sending and receiving hosts. It imposes no new + requirements on the hosts or security gateways, other than a + requirement for a security gateway to be configurable to pass + IPsec traffic (including ISAKMP traffic) for hosts behind it. + + =============================================================== + | | + | ========================= | + | | | | + ---|-----------------|---- ---|-------------------|--- + | | | | | | | | + | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* | + | Intranet) | | Intranet) | + -------------------------- --------------------------- + admin. boundary admin. boundary + + Case 4. This covers the situation where a remote host (H1) uses the + Internet to reach an organization's firewall (SG2) and to then + gain access to some server or other machine (H2). The remote + host could be a mobile host (H1) dialing up to a local PPP/ARA + server (not shown) on the Internet and then crossing the + Internet to the home organization's firewall (SG2), etc. The + + + +Kent & Atkinson Standards Track [Page 25] + +RFC 2401 Security Architecture for IP November 1998 + + + details of support for this case, (how H1 locates SG2, + authenticates it, and verifies its authorization to represent + H2) are discussed in Section 4.6.3, "Locating a Security + Gateway". + + ====================================================== + | | + |============================== | + || | | + || ---|----------------------|--- + || | | | | + H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | + ^ | Intranet) | + | ------------------------------ + could be dialup admin. boundary (optional) + to PPP/ARA server + + Only tunnel mode is required between H1 and SG2. So the choices + for the SA between H1 and SG2 would be one of the ones in case + 2. The choices for the SA between H1 and H2 would be one of the + ones in case 1. + + Note that in this case, the sender MUST apply the transport + header before the tunnel header. Therefore the management + interface to the IPsec implementation MUST support configuration + of the SPD and SAD to ensure this ordering of IPsec header + application. + + As noted above, support for additional combinations of AH and ESP is + optional. Use of other, optional combinations may adversely affect + interoperability. + +4.6 SA and Key Management + + IPsec mandates support for both manual and automated SA and + cryptographic key management. The IPsec protocols, AH and ESP, are + largely independent of the associated SA management techniques, + although the techniques involved do affect some of the security + services offered by the protocols. For example, the optional anti- + replay services available for AH and ESP require automated SA + management. Moreover, the granularity of key distribution employed + with IPsec determines the granularity of authentication provided. + (See also a discussion of this issue in Section 4.7.) In general, + data origin authentication in AH and ESP is limited by the extent to + which secrets used with the authentication algorithm (or with a key + management protocol that creates such secrets) are shared among + multiple possible sources. + + + + +Kent & Atkinson Standards Track [Page 26] + +RFC 2401 Security Architecture for IP November 1998 + + + The following text describes the minimum requirements for both types + of SA management. + +4.6.1 Manual Techniques + + The simplest form of management is manual management, in which a + person manually configures each system with keying material and + security association management data relevant to secure communication + with other systems. Manual techniques are practical in small, static + environments but they do not scale well. For example, a company + could create a Virtual Private Network (VPN) using IPsec in security + gateways at several sites. If the number of sites is small, and + since all the sites come under the purview of a single administrative + domain, this is likely to be a feasible context for manual management + techniques. In this case, the security gateway might selectively + protect traffic to and from other sites within the organization using + a manually configured key, while not protecting traffic for other + destinations. It also might be appropriate when only selected + communications need to be secured. A similar argument might apply to + use of IPsec entirely within an organization for a small number of + hosts and/or gateways. Manual management techniques often employ + statically configured, symmetric keys, though other options also + exist. + +4.6.2 Automated SA and Key Management + + Widespread deployment and use of IPsec requires an Internet-standard, + scalable, automated, SA management protocol. Such support is + required to facilitate use of the anti-replay features of AH and ESP, + and to accommodate on-demand creation of SAs, e.g., for user- and + session-oriented keying. (Note that the notion of "rekeying" an SA + actually implies creation of a new SA with a new SPI, a process that + generally implies use of an automated SA/key management protocol.) + + The default automated key management protocol selected for use with + IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of + interpretation [Pip98]. Other automated SA management protocols MAY + be employed. + + When an automated SA/key management protocol is employed, the output + from this protocol may be used to generate multiple keys, e.g., for a + single ESP SA. This may arise because: + + o the encryption algorithm uses multiple keys (e.g., triple DES) + o the authentication algorithm uses multiple keys + o both encryption and authentication algorithms are employed + + + + + +Kent & Atkinson Standards Track [Page 27] + +RFC 2401 Security Architecture for IP November 1998 + + + The Key Management System may provide a separate string of bits for + each key or it may generate one string of bits from which all of them + are extracted. If a single string of bits is provided, care needs to + be taken to ensure that the parts of the system that map the string + of bits to the required keys do so in the same fashion at both ends + of the SA. To ensure that the IPsec implementations at each end of + the SA use the same bits for the same keys, and irrespective of which + part of the system divides the string of bits into individual keys, + the encryption key(s) MUST be taken from the first (left-most, high- + order) bits and the authentication key(s) MUST be taken from the + remaining bits. The number of bits for each key is defined in the + relevant algorithm specification RFC. In the case of multiple + encryption keys or multiple authentication keys, the specification + for the algorithm must specify the order in which they are to be + selected from a single string of bits provided to the algorithm. + +4.6.3 Locating a Security Gateway + + This section discusses issues relating to how a host learns about the + existence of relevant security gateways and once a host has contacted + these security gateways, how it knows that these are the correct + security gateways. The details of where the required information is + stored is a local matter. + + Consider a situation in which a remote host (H1) is using the + Internet to gain access to a server or other machine (H2) and there + is a security gateway (SG2), e.g., a firewall, through which H1's + traffic must pass. An example of this situation would be a mobile + host (Road Warrior) crossing the Internet to the home organization's + firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of + Security Associations.) This situation raises several issues: + + 1. How does H1 know/learn about the existence of the security + gateway SG2? + 2. How does it authenticate SG2, and once it has authenticated + SG2, how does it confirm that SG2 has been authorized to + represent H2? + 3. How does SG2 authenticate H1 and verify that H1 is authorized + to contact H2? + 4. How does H1 know/learn about backup gateways which provide + alternate paths to H2? + + To address these problems, a host or security gateway MUST have an + administrative interface that allows the user/administrator to + configure the address of a security gateway for any sets of + destination addresses that require its use. This includes the ability + to configure: + + + + +Kent & Atkinson Standards Track [Page 28] + +RFC 2401 Security Architecture for IP November 1998 + + + o the requisite information for locating and authenticating the + security gateway and verifying its authorization to represent + the destination host. + o the requisite information for locating and authenticating any + backup gateways and verifying their authorization to represent + the destination host. + + It is assumed that the SPD is also configured with policy information + that covers any other IPsec requirements for the path to the security + gateway and the destination host. + + This document does not address the issue of how to automate the + discovery/verification of security gateways. + +4.7 Security Associations and Multicast + + The receiver-orientation of the Security Association implies that, in + the case of unicast traffic, the destination system will normally + select the SPI value. By having the destination select the SPI + value, there is no potential for manually configured Security + Associations to conflict with automatically configured (e.g., via a + key management protocol) Security Associations or for Security + Associations from multiple sources to conflict with each other. For + multicast traffic, there are multiple destination systems per + multicast group. So some system or person will need to coordinate + among all multicast groups to select an SPI or SPIs on behalf of each + multicast group and then communicate the group's IPsec information to + all of the legitimate members of that multicast group via mechanisms + not defined here. + + Multiple senders to a multicast group SHOULD use a single Security + Association (and hence Security Parameter Index) for all traffic to + that group when a symmetric key encryption or authentication + algorithm is employed. In such circumstances, the receiver knows only + that the message came from a system possessing the key for that + multicast group. In such circumstances, a receiver generally will + not be able to authenticate which system sent the multicast traffic. + Specifications for other, more general multicast cases are deferred + to later IPsec documents. + + At the time this specification was published, automated protocols for + multicast key distribution were not considered adequately mature for + standardization. For multicast groups having relatively few members, + manual key distribution or multiple use of existing unicast key + distribution algorithms such as modified Diffie-Hellman appears + feasible. For very large groups, new scalable techniques will be + needed. An example of current work in this area is the Group Key + Management Protocol (GKMP) [HM97]. + + + +Kent & Atkinson Standards Track [Page 29] + +RFC 2401 Security Architecture for IP November 1998 + + +5. IP Traffic Processing + + As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", + the SPD must be consulted during the processing of all traffic + (INBOUND and OUTBOUND), including non-IPsec traffic. If no policy is + found in the SPD that matches the packet (for either inbound or + outbound traffic), the packet MUST be discarded. + + NOTE: All of the cryptographic algorithms used in IPsec expect their + input in canonical network byte order (see Appendix in RFC 791) and + generate their output in canonical network byte order. IP packets + are also transmitted in network byte order. + +5.1 Outbound IP Traffic Processing + +5.1.1 Selecting and Using an SA or SA Bundle + + In a security gateway or BITW implementation (and in many BITS + implementations), each outbound packet is compared against the SPD to + determine what processing is required for the packet. If the packet + is to be discarded, this is an auditable event. If the traffic is + allowed to bypass IPsec processing, the packet continues through + "normal" processing for the environment in which the IPsec processing + is taking place. If IPsec processing is required, the packet is + either mapped to an existing SA (or SA bundle), or a new SA (or SA + bundle) is created for the packet. Since a packet's selectors might + match multiple policies or multiple extant SAs and since the SPD is + ordered, but the SAD is not, IPsec MUST: + + 1. Match the packet's selector fields against the outbound + policies in the SPD to locate the first appropriate + policy, which will point to zero or more SA bundles in the + SAD. + + 2. Match the packet's selector fields against those in the SA + bundles found in (1) to locate the first SA bundle that + matches. If no SAs were found or none match, create an + appropriate SA bundle and link the SPD entry to the SAD + entry. If no key management entity is found, drop the + packet. + + 3. Use the SA bundle found/created in (2) to do the required + IPsec processing, e.g., authenticate and encrypt. + + In a host IPsec implementation based on sockets, the SPD will be + consulted whenever a new socket is created, to determine what, if + any, IPsec processing will be applied to the traffic that will flow + on that socket. + + + +Kent & Atkinson Standards Track [Page 30] + +RFC 2401 Security Architecture for IP November 1998 + + + NOTE: A compliant implementation MUST not allow instantiation of an + ESP SA that employs both a NULL encryption and a NULL authentication + algorithm. An attempt to negotiate such an SA is an auditable event. + +5.1.2 Header Construction for Tunnel Mode + + This section describes the handling of the inner and outer IP + headers, extension headers, and options for AH and ESP tunnels. This + includes how to construct the encapsulating (outer) IP header, how to + handle fields in the inner IP header, and what other actions should + be taken. The general idea is modeled after the one used in RFC + 2003, "IP Encapsulation with IP": + + o The outer IP header Source Address and Destination Address + identify the "endpoints" of the tunnel (the encapsulator and + decapsulator). The inner IP header Source Address and + Destination Addresses identify the original sender and + recipient of the datagram, (from the perspective of this + tunnel), respectively. (see footnote 3 after the table in + 5.1.2.1 for more details on the encapsulating source IP + address.) + o The inner IP header is not changed except to decrement the TTL + as noted below, and remains unchanged during its delivery to + the tunnel exit point. + o No change to IP options or extension headers in the inner + header occurs during delivery of the encapsulated datagram + through the tunnel. + o If need be, other protocol headers such as the IP + Authentication header may be inserted between the outer IP + header and the inner IP header. + + The tables in the following sub-sections show the handling for the + different header/option fields (constructed = the value in the outer + field is constructed independently of the value in the inner). + +5.1.2.1 IPv4 -- Header Construction for Tunnel Mode + + <-- How Outer Hdr Relates to Inner Hdr --> + Outer Hdr at Inner Hdr at + IPv4 Encapsulator Decapsulator + Header fields: -------------------- ------------ + version 4 (1) no change + header length constructed no change + TOS copied from inner hdr (5) no change + total length constructed no change + ID constructed no change + flags (DF,MF) constructed, DF (4) no change + fragmt offset constructed no change + + + +Kent & Atkinson Standards Track [Page 31] + +RFC 2401 Security Architecture for IP November 1998 + + + TTL constructed (2) decrement (2) + protocol AH, ESP, routing hdr no change + checksum constructed constructed (2) + src address constructed (3) no change + dest address constructed (3) no change + Options never copied no change + + 1. The IP version in the encapsulating header can be different + from the value in the inner header. + + 2. The TTL in the inner header is decremented by the + encapsulator prior to forwarding and by the decapsulator if + it forwards the packet. (The checksum changes when the TTL + changes.) + + Note: The decrementing of the TTL is one of the usual actions + that takes place when forwarding a packet. Packets + originating from the same node as the encapsulator do not + have their TTL's decremented, as the sending node is + originating the packet rather than forwarding it. + + 3. src and dest addresses depend on the SA, which is used to + determine the dest address which in turn determines which src + address (net interface) is used to forward the packet. + + NOTE: In principle, the encapsulating IP source address can + be any of the encapsulator's interface addresses or even an + address different from any of the encapsulator's IP + addresses, (e.g., if it's acting as a NAT box) so long as the + address is reachable through the encapsulator from the + environment into which the packet is sent. This does not + cause a problem because IPsec does not currently have any + INBOUND processing requirement that involves the Source + Address of the encapsulating IP header. So while the + receiving tunnel endpoint looks at the Destination Address in + the encapsulating IP header, it only looks at the Source + Address in the inner (encapsulated) IP header. + + 4. configuration determines whether to copy from the inner + header (IPv4 only), clear or set the DF. + + 5. If Inner Hdr is IPv4 (Protocol = 4), copy the TOS. If Inner + Hdr is IPv6 (Protocol = 41), map the Class to TOS. + +5.1.2.2 IPv6 -- Header Construction for Tunnel Mode + + See previous section 5.1.2 for notes 1-5 indicated by (footnote + number). + + + +Kent & Atkinson Standards Track [Page 32] + +RFC 2401 Security Architecture for IP November 1998 + + + <-- How Outer Hdr Relates Inner Hdr ---> + Outer Hdr at Inner Hdr at + IPv6 Encapsulator Decapsulator + Header fields: -------------------- ------------ + version 6 (1) no change + class copied or configured (6) no change + flow id copied or configured no change + len constructed no change + next header AH,ESP,routing hdr no change + hop limit constructed (2) decrement (2) + src address constructed (3) no change + dest address constructed (3) no change + Extension headers never copied no change + + 6. If Inner Hdr is IPv6 (Next Header = 41), copy the Class. If + Inner Hdr is IPv4 (Next Header = 4), map the TOS to Class. + +5.2 Processing Inbound IP Traffic + + Prior to performing AH or ESP processing, any IP fragments are + reassembled. Each inbound IP datagram to which IPsec processing will + be applied is identified by the appearance of the AH or ESP values in + the IP Next Protocol field (or of AH or ESP as an extension header in + the IPv6 context). + + Note: Appendix C contains sample code for a bitmask check for a 32 + packet window that can be used for implementing anti-replay service. + +5.2.1 Selecting and Using an SA or SA Bundle + + Mapping the IP datagram to the appropriate SA is simplified because + of the presence of the SPI in the AH or ESP header. Note that the + selector checks are made on the inner headers not the outer (tunnel) + headers. The steps followed are: + + 1. Use the packet's destination address (outer IP header), + IPsec protocol, and SPI to look up the SA in the SAD. If + the SA lookup fails, drop the packet and log/report the + error. + + 2. Use the SA found in (1) to do the IPsec processing, e.g., + authenticate and decrypt. This step includes matching the + packet's (Inner Header if tunneled) selectors to the + selectors in the SA. Local policy determines the + specificity of the SA selectors (single value, list, + range, wildcard). In general, a packet's source address + MUST match the SA selector value. However, an ICMP packet + received on a tunnel mode SA may have a source address + + + +Kent & Atkinson Standards Track [Page 33] + +RFC 2401 Security Architecture for IP November 1998 + + + other than that bound to the SA and thus such packets + should be permitted as exceptions to this check. For an + ICMP packet, the selectors from the enclosed problem + packet (the source and destination addresses and ports + should be swapped) should be checked against the selectors + for the SA. Note that some or all of these selectors may + be inaccessible because of limitations on how many bits of + the problem packet the ICMP packet is allowed to carry or + due to encryption. See Section 6. + + Do (1) and (2) for every IPsec header until a Transport + Protocol Header or an IP header that is NOT for this + system is encountered. Keep track of what SAs have been + used and their order of application. + + 3. Find an incoming policy in the SPD that matches the + packet. This could be done, for example, by use of + backpointers from the SAs to the SPD or by matching the + packet's selectors (Inner Header if tunneled) against + those of the policy entries in the SPD. + + 4. Check whether the required IPsec processing has been + applied, i.e., verify that the SA's found in (1) and (2) + match the kind and order of SAs required by the policy + found in (3). + + NOTE: The correct "matching" policy will not necessarily + be the first inbound policy found. If the check in (4) + fails, steps (3) and (4) are repeated until all policy + entries have been checked or until the check succeeds. + + At the end of these steps, pass the resulting packet to the Transport + Layer or forward the packet. Note that any IPsec headers processed + in these steps may have been removed, but that this information, + i.e., what SAs were used and the order of their application, may be + needed for subsequent IPsec or firewall processing. + + Note that in the case of a security gateway, if forwarding causes a + packet to exit via an IPsec-enabled interface, then additional IPsec + processing may be applied. + +5.2.2 Handling of AH and ESP tunnels + + The handling of the inner and outer IP headers, extension headers, + and options for AH and ESP tunnels should be performed as described + in the tables in Section 5.1. + + + + + +Kent & Atkinson Standards Track [Page 34] + +RFC 2401 Security Architecture for IP November 1998 + + +6. ICMP Processing (relevant to IPsec) + + The focus of this section is on the handling of ICMP error messages. + Other ICMP traffic, e.g., Echo/Reply, should be treated like other + traffic and can be protected on an end-to-end basis using SAs in the + usual fashion. + + An ICMP error message protected by AH or ESP and generated by a + router SHOULD be processed and forwarded in a tunnel mode SA. Local + policy determines whether or not it is subjected to source address + checks by the router at the destination end of the tunnel. Note that + if the router at the originating end of the tunnel is forwarding an + ICMP error message from another router, the source address check + would fail. An ICMP message protected by AH or ESP and generated by + a router MUST NOT be forwarded on a transport mode SA (unless the SA + has been established to the router acting as a host, e.g., a Telnet + connection used to manage a router). An ICMP message generated by a + host SHOULD be checked against the source IP address selectors bound + to the SA in which the message arrives. Note that even if the source + of an ICMP error message is authenticated, the returned IP header + could be invalid. Accordingly, the selector values in the IP header + SHOULD also be checked to be sure that they are consistent with the + selectors for the SA over which the ICMP message was received. + + The table in Appendix D characterize ICMP messages as being either + host generated, router generated, both, unknown/unassigned. ICMP + messages falling into the last two categories should be handled as + determined by the receiver's policy. + + An ICMP message not protected by AH or ESP is unauthenticated and its + processing and/or forwarding may result in denial of service. This + suggests that, in general, it would be desirable to ignore such + messages. However, it is expected that many routers (vs. security + gateways) will not implement IPsec for transit traffic and thus + strict adherence to this rule would cause many ICMP messages to be + discarded. The result is that some critical IP functions would be + lost, e.g., redirection and PMTU processing. Thus it MUST be + possible to configure an IPsec implementation to accept or reject + (router) ICMP traffic as per local security policy. + + The remainder of this section addresses how PMTU processing MUST be + performed at hosts and security gateways. It addresses processing of + both authenticated and unauthenticated ICMP PMTU messages. However, + as noted above, unauthenticated ICMP messages MAY be discarded based + on local policy. + + + + + + +Kent & Atkinson Standards Track [Page 35] + +RFC 2401 Security Architecture for IP November 1998 + + +6.1 PMTU/DF Processing + +6.1.1 DF Bit + + In cases where a system (host or gateway) adds an encapsulating + header (ESP tunnel or AH tunnel), it MUST support the option of + copying the DF bit from the original packet to the encapsulating + header (and processing ICMP PMTU messages). This means that it MUST + be possible to configure the system's treatment of the DF bit (set, + clear, copy from encapsulated header) for each interface. (See + Appendix B for rationale.) + +6.1.2 Path MTU Discovery (PMTU) + + This section discusses IPsec handling for Path MTU Discovery + messages. ICMP PMTU is used here to refer to an ICMP message for: + + IPv4 (RFC 792): + - Type = 3 (Destination Unreachable) + - Code = 4 (Fragmentation needed and DF set) + - Next-Hop MTU in the low-order 16 bits of the second + word of the ICMP header (labelled "unused" in RFC + 792), with high-order 16 bits set to zero + + IPv6 (RFC 1885): + - Type = 2 (Packet Too Big) + - Code = 0 (Fragmentation needed) + - Next-Hop MTU in the 32 bit MTU field of the ICMP6 + message + +6.1.2.1 Propagation of PMTU + + The amount of information returned with the ICMP PMTU message (IPv4 + or IPv6) is limited and this affects what selectors are available for + use in further propagating the PMTU information. (See Appendix B for + more detailed discussion of this topic.) + + o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU + message contains only 64 bits of the IPsec header (minimum for + IPv4), then a security gateway MUST support the following options + on a per SPI/SA basis: + + a. if the originating host can be determined (or the possible + sources narrowed down to a manageable number), send the PM + information to all the possible originating hosts. + b. if the originating host cannot be determined, store the PMTU + with the SA and wait until the next packet(s) arrive from the + originating host for the relevant security association. If + + + +Kent & Atkinson Standards Track [Page 36] + +RFC 2401 Security Architecture for IP November 1998 + + + the packet(s) are bigger than the PMTU, drop the packet(s), + and compose ICMP PMTU message(s) with the new packet(s) and + the updated PMTU, and send the ICMP message(s) about the + problem to the originating host. Retain the PMTU information + for any message that might arrive subsequently (see Section + 6.1.2.4, "PMTU Aging"). + + o PMTU message with >64 bits of IPsec header -- If the ICMP message + contains more information from the original packet then there may + be enough non-opaque information to immediately determine to which + host to propagate the ICMP/PMTU message and to provide that system + with the 5 fields (source address, destination address, source + port, destination port, transport protocol) needed to determine + where to store/update the PMTU. Under such circumstances, a + security gateway MUST generate an ICMP PMTU message immediately + upon receipt of an ICMP PMTU from further down the path. + + o Distributing the PMTU to the Transport Layer -- The host mechanism + for getting the updated PMTU to the transport layer is unchanged, + as specified in RFC 1191 (Path MTU Discovery). + +6.1.2.2 Calculation of PMTU + + The calculation of PMTU from an ICMP PMTU MUST take into account the + addition of any IPsec header -- AH transport, ESP transport, AH/ESP + transport, ESP tunnel, AH tunnel. (See Appendix B for discussion of + implementation issues.) + + Note: In some situations the addition of IPsec headers could result + in an effective PMTU (as seen by the host or application) that is + unacceptably small. To avoid this problem, the implementation may + establish a threshold below which it will not report a reduced PMTU. + In such cases, the implementation would apply IPsec and then fragment + the resulting packet according to the PMTU. This would result in a + more efficient use of the available bandwidth. + +6.1.2.3 Granularity of PMTU Processing + + In hosts, the granularity with which ICMP PMTU processing can be done + differs depending on the implementation situation. Looking at a + host, there are 3 situations that are of interest with respect to + PMTU issues (See Appendix B for additional details on this topic.): + + a. Integration of IPsec into the native IP implementation + b. Bump-in-the-stack implementations, where IPsec is implemented + "underneath" an existing implementation of a TCP/IP protocol + stack, between the native IP and the local network drivers + + + + +Kent & Atkinson Standards Track [Page 37] + +RFC 2401 Security Architecture for IP November 1998 + + + c. No IPsec implementation -- This case is included because it + is relevant in cases where a security gateway is sending PMTU + information back to a host. + + Only in case (a) can the PMTU data be maintained at the same + granularity as communication associations. In (b) and (c), the IP + layer will only be able to maintain PMTU data at the granularity of + source and destination IP addresses (and optionally TOS), as + described in RFC 1191. This is an important difference, because more + than one communication association may map to the same source and + destination IP addresses, and each communication association may have + a different amount of IPsec header overhead (e.g., due to use of + different transforms or different algorithms). + + Implementation of the calculation of PMTU and support for PMTUs at + the granularity of individual communication associations is a local + matter. However, a socket-based implementation of IPsec in a host + SHOULD maintain the information on a per socket basis. Bump in the + stack systems MUST pass an ICMP PMTU to the host IP implementation, + after adjusting it for any IPsec header overhead added by these + systems. The calculation of the overhead SHOULD be determined by + analysis of the SPI and any other selector information present in a + returned ICMP PMTU message. + +6.1.2.4 PMTU Aging + + In all systems (host or gateway) implementing IPsec and maintaining + PMTU information, the PMTU associated with a security association + (transport or tunnel) MUST be "aged" and some mechanism put in place + for updating the PMTU in a timely manner, especially for discovering + if the PMTU is smaller than it needs to be. A given PMTU has to + remain in place long enough for a packet to get from the source end + of the security association to the system at the other end of the + security association and propagate back an ICMP error message if the + current PMTU is too big. Note that if there are nested tunnels, + multiple packets and round trip times might be required to get an + ICMP message back to an encapsulator or originating host. + + Systems SHOULD use the approach described in the Path MTU Discovery + document (RFC 1191, Section 6.3), which suggests periodically + resetting the PMTU to the first-hop data-link MTU and then letting + the normal PMTU Discovery processes update the PMTU as necessary. + The period SHOULD be configurable. + + + + + + + + +Kent & Atkinson Standards Track [Page 38] + +RFC 2401 Security Architecture for IP November 1998 + + +7. Auditing + + Not all systems that implement IPsec will implement auditing. For + the most part, the granularity of auditing is a local matter. + However, several auditable events are identified in the AH and ESP + specifications and for each of these events a minimum set of + information that SHOULD be included in an audit log is defined. + Additional information also MAY be included in the audit log for each + of these events, and additional events, not explicitly called out in + this specification, also MAY result in audit log entries. There is + no requirement for the receiver to transmit any message to the + purported transmitter in response to the detection of an auditable + event, because of the potential to induce denial of service via such + action. + +8. Use in Systems Supporting Information Flow Security + + Information of various sensitivity levels may be carried over a + single network. Information labels (e.g., Unclassified, Company + Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish + such information. The use of labels facilitates segregation of + information, in support of information flow security models, e.g., + the Bell-LaPadula model [BL73]. Such models, and corresponding + supporting technology, are designed to prevent the unauthorized flow + of sensitive information, even in the face of Trojan Horse attacks. + Conventional, discretionary access control (DAC) mechanisms, e.g., + based on access control lists, generally are not sufficient to + support such policies, and thus facilities such as the SPD do not + suffice in such environments. + + In the military context, technology that supports such models is + often referred to as multi-level security (MLS). Computers and + networks often are designated "multi-level secure" if they support + the separation of labelled data in conjunction with information flow + security policies. Although such technology is more broadly + applicable than just military applications, this document uses the + acronym "MLS" to designate the technology, consistent with much + extant literature. + + IPsec mechanisms can easily support MLS networking. MLS networking + requires the use of strong Mandatory Access Controls (MAC), which + unprivileged users or unprivileged processes are incapable of + controlling or violating. This section pertains only to the use of + these IP security mechanisms in MLS (information flow security + policy) environments. Nothing in this section applies to systems not + claiming to provide MLS. + + + + + +Kent & Atkinson Standards Track [Page 39] + +RFC 2401 Security Architecture for IP November 1998 + + + As used in this section, "sensitivity information" might include + implementation-defined hierarchic levels, categories, and/or + releasability information. + + AH can be used to provide strong authentication in support of + mandatory access control decisions in MLS environments. If explicit + IP sensitivity information (e.g., IPSO [Ken91]) is used and + confidentiality is not considered necessary within the particular + operational environment, AH can be used to authenticate the binding + between sensitivity labels in the IP header and the IP payload + (including user data). This is a significant improvement over + labeled IPv4 networks where the sensitivity information is trusted + even though there is no authentication or cryptographic binding of + the information to the IP header and user data. IPv4 networks might + or might not use explicit labelling. IPv6 will normally use implicit + sensitivity information that is part of the IPsec Security + Association but not transmitted with each packet instead of using + explicit sensitivity information. All explicit IP sensitivity + information MUST be authenticated using either ESP, AH, or both. + + Encryption is useful and can be desirable even when all of the hosts + are within a protected environment, for example, behind a firewall or + disjoint from any external connectivity. ESP can be used, in + conjunction with appropriate key management and encryption + algorithms, in support of both DAC and MAC. (The choice of + encryption and authentication algorithms, and the assurance level of + an IPsec implementation will determine the environments in which an + implementation may be deemed sufficient to satisfy MLS requirements.) + Key management can make use of sensitivity information to provide + MAC. IPsec implementations on systems claiming to provide MLS SHOULD + be capable of using IPsec to provide MAC for IP-based communications. + +8.1 Relationship Between Security Associations and Data Sensitivity + + Both the Encapsulating Security Payload and the Authentication Header + can be combined with appropriate Security Association policies to + provide multi-level secure networking. In this case each SA (or SA + bundle) is normally used for only a single instance of sensitivity + information. For example, "PROPRIETARY - Internet Engineering" must + be associated with a different SA (or SA bundle) from "PROPRIETARY - + Finance". + +8.2 Sensitivity Consistency Checking + + An MLS implementation (both host and router) MAY associate + sensitivity information, or a range of sensitivity information with + an interface, or a configured IP address with its associated prefix + (the latter is sometimes referred to as a logical interface, or an + + + +Kent & Atkinson Standards Track [Page 40] + +RFC 2401 Security Architecture for IP November 1998 + + + interface alias). If such properties exist, an implementation SHOULD + compare the sensitivity information associated with the packet + against the sensitivity information associated with the interface or + address/prefix from which the packet arrived, or through which the + packet will depart. This check will either verify that the + sensitivities match, or that the packet's sensitivity falls within + the range of the interface or address/prefix. + + The checking SHOULD be done on both inbound and outbound processing. + +8.3 Additional MLS Attributes for Security Association Databases + + Section 4.4 discussed two Security Association databases (the + Security Policy Database (SPD) and the Security Association Database + (SAD)) and the associated policy selectors and SA attributes. MLS + networking introduces an additional selector/attribute: + + - Sensitivity information. + + The Sensitivity information aids in selecting the appropriate + algorithms and key strength, so that the traffic gets a level of + protection appropriate to its importance or sensitivity as described + in section 8.1. The exact syntax of the sensitivity information is + implementation defined. + +8.4 Additional Inbound Processing Steps for MLS Networking + + After an inbound packet has passed through IPsec processing, an MLS + implementation SHOULD first check the packet's sensitivity (as + defined by the SA (or SA bundle) used for the packet) with the + interface or address/prefix as described in section 8.2 before + delivering the datagram to an upper-layer protocol or forwarding it. + + The MLS system MUST retain the binding between the data received in + an IPsec protected packet and the sensitivity information in the SA + or SAs used for processing, so appropriate policy decisions can be + made when delivering the datagram to an application or forwarding + engine. The means for maintaining this binding are implementation + specific. + +8.5 Additional Outbound Processing Steps for MLS Networking + + An MLS implementation of IPsec MUST perform two additional checks + besides the normal steps detailed in section 5.1.1. When consulting + the SPD or the SAD to find an outbound security association, the MLS + implementation MUST use the sensitivity of the data to select an + + + + + +Kent & Atkinson Standards Track [Page 41] + +RFC 2401 Security Architecture for IP November 1998 + + + appropriate outbound SA or SA bundle. The second check comes before + forwarding the packet out to its destination, and is the sensitivity + consistency checking described in section 8.2. + +8.6 Additional MLS Processing for Security Gateways + + An MLS security gateway MUST follow the previously mentioned inbound + and outbound processing rules as well as perform some additional + processing specific to the intermediate protection of packets in an + MLS environment. + + A security gateway MAY act as an outbound proxy, creating SAs for MLS + systems that originate packets forwarded by the gateway. These MLS + systems may explicitly label the packets to be forwarded, or the + whole originating network may have sensitivity characteristics + associated with it. The security gateway MUST create and use + appropriate SAs for AH, ESP, or both, to protect such traffic it + forwards. + + Similarly such a gateway SHOULD accept and process inbound AH and/or + ESP packets and forward appropriately, using explicit packet + labeling, or relying on the sensitivity characteristics of the + destination network. + +9. Performance Issues + + The use of IPsec imposes computational performance costs on the hosts + or security gateways that implement these protocols. These costs are + associated with the memory needed for IPsec code and data structures, + and the computation of integrity check values, encryption and + decryption, and added per-packet handling. The per-packet + computational costs will be manifested by increased latency and, + possibly, reduced throughout. Use of SA/key management protocols, + especially ones that employ public key cryptography, also adds + computational performance costs to use of IPsec. These per- + association computational costs will be manifested in terms of + increased latency in association establishment. For many hosts, it + is anticipated that software-based cryptography will not appreciably + reduce throughput, but hardware may be required for security gateways + (since they represent aggregation points), and for some hosts. + + The use of IPsec also imposes bandwidth utilization costs on + transmission, switching, and routing components of the Internet + infrastructure, components not implementing IPsec. This is due to + the increase in the packet size resulting from the addition of AH + and/or ESP headers, AH and ESP tunneling (which adds a second IP + header), and the increased packet traffic associated with key + management protocols. It is anticipated that, in most instances, + + + +Kent & Atkinson Standards Track [Page 42] + +RFC 2401 Security Architecture for IP November 1998 + + + this increased bandwidth demand will not noticeably affect the + Internet infrastructure. However, in some instances, the effects may + be significant, e.g., transmission of ESP encrypted traffic over a + dialup link that otherwise would have compressed the traffic. + + Note: The initial SA establishment overhead will be felt in the first + packet. This delay could impact the transport layer and application. + For example, it could cause TCP to retransmit the SYN before the + ISAKMP exchange is done. The effect of the delay would be different + on UDP than TCP because TCP shouldn't transmit anything other than + the SYN until the connection is set up whereas UDP will go ahead and + transmit data beyond the first packet. + + Note: As discussed earlier, compression can still be employed at + layers above IP. There is an IETF working group (IP Payload + Compression Protocol (ippcp)) working on "protocol specifications + that make it possible to perform lossless compression on individual + payloads before the payload is processed by a protocol that encrypts + it. These specifications will allow for compression operations to be + performed prior to the encryption of a payload by IPsec protocols." + +10. Conformance Requirements + + All IPv4 systems that claim to implement IPsec MUST comply with all + requirements of the Security Architecture document. All IPv6 systems + MUST comply with all requirements of the Security Architecture + document. + +11. Security Considerations + + The focus of this document is security; hence security considerations + permeate this specification. + +12. Differences from RFC 1825 + + This architecture document differs substantially from RFC 1825 in + detail and in organization, but the fundamental notions are + unchanged. This document provides considerable additional detail in + terms of compliance specifications. It introduces the SPD and SAD, + and the notion of SA selectors. It is aligned with the new versions + of AH and ESP, which also differ from their predecessors. Specific + requirements for supported combinations of AH and ESP are newly + added, as are details of PMTU management. + + + + + + + + +Kent & Atkinson Standards Track [Page 43] + +RFC 2401 Security Architecture for IP November 1998 + + +Acknowledgements + + Many of the concepts embodied in this specification were derived from + or influenced by the US Government's SP3 security protocol, ISO/IEC's + NLSP, the proposed swIPe security protocol [SDNS, ISO, IB93, IBK93], + and the work done for SNMP Security and SNMPv2 Security. + + For over 3 years (although it sometimes seems *much* longer), this + document has evolved through multiple versions and iterations. + During this time, many people have contributed significant ideas and + energy to the process and the documents themselves. The authors + would like to thank Karen Seo for providing extensive help in the + review, editing, background research, and coordination for this + version of the specification. The authors would also like to thank + the members of the IPsec and IPng working groups, with special + mention of the efforts of (in alphabetic order): Steve Bellovin, + Steve Deering, James Hughes, Phil Karn, Frank Kastenholz, Perry + Metzger, David Mihelcic, Hilarie Orman, Norman Shulman, William + Simpson, Harry Varnis, and Nina Yuan. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 44] + +RFC 2401 Security Architecture for IP November 1998 + + +Appendix A -- Glossary + + This section provides definitions for several key terms that are + employed in this document. Other documents provide additional + definitions and background information relevant to this technology, + e.g., [VK83, HA94]. Included in this glossary are generic security + service and security mechanism terms, plus IPsec-specific terms. + + Access Control + Access control is a security service that prevents unauthorized + use of a resource, including the prevention of use of a resource + in an unauthorized manner. In the IPsec context, the resource + to which access is being controlled is often: + o for a host, computing cycles or data + o for a security gateway, a network behind the gateway + or + bandwidth on that network. + + Anti-replay + [See "Integrity" below] + + Authentication + This term is used informally to refer to the combination of two + nominally distinct security services, data origin authentication + and connectionless integrity. See the definitions below for + each of these services. + + Availability + Availability, when viewed as a security service, addresses the + security concerns engendered by attacks against networks that + deny or degrade service. For example, in the IPsec context, the + use of anti-replay mechanisms in AH and ESP support + availability. + + Confidentiality + Confidentiality is the security service that protects data from + unauthorized disclosure. The primary confidentiality concern in + most instances is unauthorized disclosure of application level + data, but disclosure of the external characteristics of + communication also can be a concern in some circumstances. + Traffic flow confidentiality is the service that addresses this + latter concern by concealing source and destination addresses, + message length, or frequency of communication. In the IPsec + context, using ESP in tunnel mode, especially at a security + gateway, can provide some level of traffic flow confidentiality. + (See also traffic analysis, below.) + + + + + +Kent & Atkinson Standards Track [Page 45] + +RFC 2401 Security Architecture for IP November 1998 + + + Encryption + Encryption is a security mechanism used to transform data from + an intelligible form (plaintext) into an unintelligible form + (ciphertext), to provide confidentiality. The inverse + transformation process is designated "decryption". Oftimes the + term "encryption" is used to generically refer to both + processes. + + Data Origin Authentication + Data origin authentication is a security service that verifies + the identity of the claimed source of data. This service is + usually bundled with connectionless integrity service. + + Integrity + Integrity is a security service that ensures that modifications + to data are detectable. Integrity comes in various flavors to + match application requirements. IPsec supports two forms of + integrity: connectionless and a form of partial sequence + integrity. Connectionless integrity is a service that detects + modification of an individual IP datagram, without regard to the + ordering of the datagram in a stream of traffic. The form of + partial sequence integrity offered in IPsec is referred to as + anti-replay integrity, and it detects arrival of duplicate IP + datagrams (within a constrained window). This is in contrast to + connection-oriented integrity, which imposes more stringent + sequencing requirements on traffic, e.g., to be able to detect + lost or re-ordered messages. Although authentication and + integrity services often are cited separately, in practice they + are intimately connected and almost always offered in tandem. + + Security Association (SA) + A simplex (uni-directional) logical connection, created for + security purposes. All traffic traversing an SA is provided the + same security processing. In IPsec, an SA is an internet layer + abstraction implemented through the use of AH or ESP. + + Security Gateway + A security gateway is an intermediate system that acts as the + communications interface between two networks. The set of hosts + (and networks) on the external side of the security gateway is + viewed as untrusted (or less trusted), while the networks and + hosts and on the internal side are viewed as trusted (or more + trusted). The internal subnets and hosts served by a security + gateway are presumed to be trusted by virtue of sharing a + common, local, security administration. (See "Trusted + Subnetwork" below.) In the IPsec context, a security gateway is + a point at which AH and/or ESP is implemented in order to serve + + + + +Kent & Atkinson Standards Track [Page 46] + +RFC 2401 Security Architecture for IP November 1998 + + + a set of internal hosts, providing security services for these + hosts when they communicate with external hosts also employing + IPsec (either directly or via another security gateway). + + SPI + Acronym for "Security Parameters Index". The combination of a + destination address, a security protocol, and an SPI uniquely + identifies a security association (SA, see above). The SPI is + carried in AH and ESP protocols to enable the receiving system + to select the SA under which a received packet will be + processed. An SPI has only local significance, as defined by + the creator of the SA (usually the receiver of the packet + carrying the SPI); thus an SPI is generally viewed as an opaque + bit string. However, the creator of an SA may choose to + interpret the bits in an SPI to facilitate local processing. + + Traffic Analysis + The analysis of network traffic flow for the purpose of deducing + information that is useful to an adversary. Examples of such + information are frequency of transmission, the identities of the + conversing parties, sizes of packets, flow identifiers, etc. + [Sch94] + + Trusted Subnetwork + A subnetwork containing hosts and routers that trust each other + not to engage in active or passive attacks. There also is an + assumption that the underlying communications channel (e.g., a + LAN or CAN) isn't being attacked by other means. + + + + + + + + + + + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 47] + +RFC 2401 Security Architecture for IP November 1998 + + +Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues + +B.1 DF bit + + In cases where a system (host or gateway) adds an encapsulating + header (e.g., ESP tunnel), should/must the DF bit in the original + packet be copied to the encapsulating header? + + Fragmenting seems correct for some situations, e.g., it might be + appropriate to fragment packets over a network with a very small MTU, + e.g., a packet radio network, or a cellular phone hop to mobile node, + rather than propagate back a very small PMTU for use over the rest of + the path. In other situations, it might be appropriate to set the DF + bit in order to get feedback from later routers about PMTU + constraints which require fragmentation. The existence of both of + these situations argues for enabling a system to decide whether or + not to fragment over a particular network "link", i.e., for requiring + an implementation to be able to copy the DF bit (and to process ICMP + PMTU messages), but making it an option to be selected on a per + interface basis. In other words, an administrator should be able to + configure the router's treatment of the DF bit (set, clear, copy from + encapsulated header) for each interface. + + Note: If a bump-in-the-stack implementation of IPsec attempts to + apply different IPsec algorithms based on source/destination ports, + it will be difficult to apply Path MTU adjustments. + +B.2 Fragmentation + + If required, IP fragmentation occurs after IPsec processing within an + IPsec implementation. Thus, transport mode AH or ESP is applied only + to whole IP datagrams (not to IP fragments). An IP packet to which + AH or ESP has been applied may itself be fragmented by routers en + route, and such fragments MUST be reassembled prior to IPsec + processing at a receiver. In tunnel mode, AH or ESP is applied to an + IP packet, the payload of which may be a fragmented IP packet. For + example, a security gateway, "bump-in-the-stack" (BITS), or "bump- + in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to + such fragments. Note that BITS or BITW implementations are examples + of where a host IPsec implementation might receive fragments to which + tunnel mode is to be applied. However, if transport mode is to be + applied, then these implementations MUST reassemble the fragments + prior to applying IPsec. + + + + + + + + +Kent & Atkinson Standards Track [Page 48] + +RFC 2401 Security Architecture for IP November 1998 + + + NOTE: IPsec always has to figure out what the encapsulating IP header + fields are. This is independent of where you insert IPsec and is + intrinsic to the definition of IPsec. Therefore any IPsec + implementation that is not integrated into an IP implementation must + include code to construct the necessary IP headers (e.g., IP2): + + o AH-tunnel --> IP2-AH-IP1-Transport-Data + o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer + + ********************************************************************* + + Overall, the fragmentation/reassembly approach described above works + for all cases examined. + + AH Xport AH Tunnel ESP Xport ESP Tunnel + Implementation approach IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 + ----------------------- ---- ---- ---- ---- ---- ---- ---- ---- + Hosts (integr w/ IP stack) Y Y Y Y Y Y Y Y + Hosts (betw/ IP and drivers) Y Y Y Y Y Y Y Y + S. Gwy (integr w/ IP stack) Y Y Y Y + Outboard crypto processor * + + * If the crypto processor system has its own IP address, then it + is covered by the security gateway case. This box receives + the packet from the host and performs IPsec processing. It + has to be able to handle the same AH, ESP, and related + IPv4/IPv6 tunnel processing that a security gateway would have + to handle. If it doesn't have it's own address, then it is + similar to the bump-in-the stack implementation between IP and + the network drivers. + + The following analysis assumes that: + + 1. There is only one IPsec module in a given system's stack. + There isn't an IPsec module A (adding ESP/encryption and + thus) hiding the transport protocol, SRC port, and DEST port + from IPsec module B. + 2. There are several places where IPsec could be implemented (as + shown in the table above). + a. Hosts with integration of IPsec into the native IP + implementation. Implementer has access to the source + for the stack. + b. Hosts with bump-in-the-stack implementations, where + IPsec is implemented between IP and the local network + drivers. Source access for stack is not available; + but there are well-defined interfaces that allows the + IPsec code to be incorporated into the system. + + + + +Kent & Atkinson Standards Track [Page 49] + +RFC 2401 Security Architecture for IP November 1998 + + + c. Security gateways and outboard crypto processors with + integration of IPsec into the stack. + 3. Not all of the above approaches are feasible in all hosts. + But it was assumed that for each approach, there are some + hosts for whom the approach is feasible. + + For each of the above 3 categories, there are IPv4 and IPv6, AH + transport and tunnel modes, and ESP transport and tunnel modes -- for + a total of 24 cases (3 x 2 x 4). + + Some header fields and interface fields are listed here for ease of + reference -- they're not in the header order, but instead listed to + allow comparison between the columns. (* = not covered by AH + authentication. ESP authentication doesn't cover any headers that + precede it.) + + IP/Transport Interface + IPv4 IPv6 (RFC 1122 -- Sec 3.4) + ---- ---- ---------------------- + Version = 4 Version = 6 + Header Len + *TOS Class,Flow Lbl TOS + Packet Len Payload Len Len + ID ID (optional) + *Flags DF + *Offset + *TTL *Hop Limit TTL + Protocol Next Header + *Checksum + Src Address Src Address Src Address + Dst Address Dst Address Dst Address + Options? Options? Opt + + ? = AH covers Option-Type and Option-Length, but + might not cover Option-Data. + + The results for each of the 20 cases is shown below ("works" = will + work if system fragments after outbound IPsec processing, reassembles + before inbound IPsec processing). Notes indicate implementation + issues. + + a. Hosts (integrated into IP stack) + o AH-transport --> (IP1-AH-Transport-Data) + - IPv4 -- works + - IPv6 -- works + o AH-tunnel --> (IP2-AH-IP1-Transport-Data) + - IPv4 -- works + - IPv6 -- works + + + +Kent & Atkinson Standards Track [Page 50] + +RFC 2401 Security Architecture for IP November 1998 + + + o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) + - IPv4 -- works + - IPv6 -- works + o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) + - IPv4 -- works + - IPv6 -- works + + b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and + network drivers. In this case, the IPsec module would have to do + something like one of the following for fragmentation and + reassembly. + - do the fragmentation/reassembly work itself and + send/receive the packet directly to/from the network + layer. In AH or ESP transport mode, this is fine. In AH + or ESP tunnel mode where the tunnel end is at the ultimate + destination, this is fine. But in AH or ESP tunnel modes + where the tunnel end is different from the ultimate + destination and where the source host is multi-homed, this + approach could result in sub-optimal routing because the + IPsec module may be unable to obtain the information + needed (LAN interface and next-hop gateway) to direct the + packet to the appropriate network interface. This is not + a problem if the interface and next-hop gateway are the + same for the ultimate destination and for the tunnel end. + But if they are different, then IPsec would need to know + the LAN interface and the next-hop gateway for the tunnel + end. (Note: The tunnel end (security gateway) is highly + likely to be on the regular path to the ultimate + destination. But there could also be more than one path + to the destination, e.g., the host could be at an + organization with 2 firewalls. And the path being used + could involve the less commonly chosen firewall.) OR + - pass the IPsec'd packet back to the IP layer where an + extra IP header would end up being pre-pended and the + IPsec module would have to check and let IPsec'd fragments + go by. + OR + - pass the packet contents to the IP layer in a form such + that the IP layer recreates an appropriate IP header + + At the network layer, the IPsec module will have access to the + following selectors from the packet -- SRC address, DST address, + Next Protocol, and if there's a transport layer header --> SRC + port and DST port. One cannot assume IPsec has access to the + Name. It is assumed that the available selector information is + sufficient to figure out the relevant Security Policy entry and + Security Association(s). + + + + +Kent & Atkinson Standards Track [Page 51] + +RFC 2401 Security Architecture for IP November 1998 + + + o AH-transport --> (IP1-AH-Transport-Data) + - IPv4 -- works + - IPv6 -- works + o AH-tunnel --> (IP2-AH-IP1-Transport-Data) + - IPv4 -- works + - IPv6 -- works + o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer) + - IPv4 -- works + - IPv6 -- works + o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) + - IPv4 -- works + - IPv6 -- works + + c. Security gateways -- integrate IPsec into the IP stack + + NOTE: The IPsec module will have access to the following + selectors from the packet -- SRC address, DST address, Next + Protocol, and if there's a transport layer header --> SRC port + and DST port. It won't have access to the User ID (only Hosts + have access to User ID information.) Unlike some Bump-in-the- + stack implementations, security gateways may be able to look up + the Source Address in the DNS to provide a System Name, e.g., in + situations involving use of dynamically assigned IP addresses in + conjunction with dynamically updated DNS entries. It also won't + have access to the transport layer information if there is an ESP + header, or if it's not the first fragment of a fragmented + message. It is assumed that the available selector information + is sufficient to figure out the relevant Security Policy entry + and Security Association(s). + + o AH-tunnel --> (IP2-AH-IP1-Transport-Data) + - IPv4 -- works + - IPv6 -- works + o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer) + - IPv4 -- works + - IPv6 -- works + + ********************************************************************** + +B.3 Path MTU Discovery + + As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for + Path MTU Discovery. + + The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2) + is: + + ==== = security association (AH or ESP, transport or tunnel) + + + +Kent & Atkinson Standards Track [Page 52] + +RFC 2401 Security Architecture for IP November 1998 + + + ---- = connectivity (or if so labelled, administrative boundary) + .... = ICMP message (hereafter referred to as ICMP PMTU) for + + IPv4: + - Type = 3 (Destination Unreachable) + - Code = 4 (Fragmentation needed and DF set) + - Next-Hop MTU in the low-order 16 bits of the second + word of the ICMP header (labelled unused in RFC 792), + with high-order 16 bits set to zero + + IPv6 (RFC 1885): + - Type = 2 (Packet Too Big) + - Code = 0 (Fragmentation needed and DF set) + - Next-Hop MTU in the 32 bit MTU field of the ICMP6 + + Hx = host x + Rx = router x + SGx = security gateway x + X* = X supports IPsec + +B.3.1 Identifying the Originating Host(s) + +The amount of information returned with the ICMP message is limited +and this affects what selectors are available to identify security +associations, originating hosts, etc. for use in further propagating +the PMTU information. + +In brief... An ICMP message must contain the following information +from the "offending" packet: + - IPv4 (RFC 792) -- IP header plus a minimum of 64 bits + +Accordingly, in the IPv4 context, an ICMP PMTU may identify only the +first (outermost) security association. This is because the ICMP +PMTU may contain only 64 bits of the "offending" packet beyond the IP +header, which would capture only the first SPI from AH or ESP. In +the IPv6 context, an ICMP PMTU will probably provide all the SPIs and +the selectors in the IP header, but maybe not the SRC/DST ports (in +the transport header) or the encapsulated (TCP, UDP, etc.) protocol. +Moreover, if ESP is used, the transport ports and protocol selectors +may be encrypted. + +Looking at the diagram below of a security gateway tunnel (as +mentioned elsewhere, security gateways do not use transport mode)... + + + + + + + + +Kent & Atkinson Standards Track [Page 53] + +RFC 2401 Security Architecture for IP November 1998 + + + H1 =================== H3 + \ | | / + H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5 + / ^ | \ + H2 |........| H4 + + Suppose that the security policy for SG1 is to use a single SA to SG2 + for all the traffic between hosts H0, H1, and H2 and hosts H3, H4, + and H5. And suppose H0 sends a data packet to H5 which causes R1 to + send an ICMP PMTU message to SG1. If the PMTU message has only the + SPI, SG1 will be able to look up the SA and find the list of possible + hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out + that H0 sent the traffic that triggered the ICMP PMTU message. + + original after IPsec ICMP + packet processing packet + -------- ----------- ------ + IP-3 header (S = R1, D = SG1) + ICMP header (includes PMTU) + IP-2 header IP-2 header (S = SG1, D = SG2) + ESP header minimum of 64 bits of ESP hdr (*) + IP-1 header IP-1 header + TCP header TCP header + TCP data TCP data + ESP trailer + + (*) The 64 bits will include enough of the ESP (or AH) header to + include the SPI. + - ESP -- SPI (32 bits), Seq number (32 bits) + - AH -- Next header (8 bits), Payload Len (8 bits), + Reserved (16 bits), SPI (32 bits) + + This limitation on the amount of information returned with an ICMP + message creates a problem in identifying the originating hosts for + the packet (so as to know where to further propagate the ICMP PMTU + information). If the ICMP message contains only 64 bits of the IPsec + header (minimum for IPv4), then the IPsec selectors (e.g., Source and + Destination addresses, Next Protocol, Source and Destination ports, + etc.) will have been lost. But the ICMP error message will still + provide SG1 with the SPI, the PMTU information and the source and + destination gateways for the relevant security association. + + The destination security gateway and SPI uniquely define a security + association which in turn defines a set of possible originating + hosts. At this point, SG1 could: + + + + + + +Kent & Atkinson Standards Track [Page 54] + +RFC 2401 Security Architecture for IP November 1998 + + + a. send the PMTU information to all the possible originating hosts. + This would not work well if the host list is a wild card or if + many/most of the hosts weren't sending to SG1; but it might work + if the SPI/destination/etc mapped to just one or a small number of + hosts. + b. store the PMTU with the SPI/etc and wait until the next packet(s) + arrive from the originating host(s) for the relevant security + association. If it/they are bigger than the PMTU, drop the + packet(s), and compose ICMP PMTU message(s) with the new packet(s) + and the updated PMTU, and send the originating host(s) the ICMP + message(s) about the problem. This involves a delay in notifying + the originating host(s), but avoids the problems of (a). + + Since only the latter approach is feasible in all instances, a + security gateway MUST provide such support, as an option. However, + if the ICMP message contains more information from the original + packet, then there may be enough information to immediately determine + to which host to propagate the ICMP/PMTU message and to provide that + system with the 5 fields (source address, destination address, source + port, destination port, and transport protocol) needed to determine + where to store/update the PMTU. Under such circumstances, a security + gateway MUST generate an ICMP PMTU message immediately upon receipt + of an ICMP PMTU from further down the path. NOTE: The Next Protocol + field may not be contained in the ICMP message and the use of ESP + encryption may hide the selector fields that have been encrypted. + +B.3.2 Calculation of PMTU + + The calculation of PMTU from an ICMP PMTU has to take into account + the addition of any IPsec header by H1 -- AH and/or ESP transport, or + ESP or AH tunnel. Within a single host, multiple applications may + share an SPI and nesting of security associations may occur. (See + Section 4.5 Basic Combinations of Security Associations for + description of the combinations that MUST be supported). The diagram + below illustrates an example of security associations between a pair + of hosts (as viewed from the perspective of one of the hosts.) (ESPx + or AHx = transport mode) + + Socket 1 -------------------------| + | + Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet + + In order to figure out the PMTU for each socket that maps to SPI-B, + it will be necessary to have backpointers from SPI-B to each of the 2 + paths that lead to it -- Socket 1 and Socket 2/SPI-A. + + + + + + +Kent & Atkinson Standards Track [Page 55] + +RFC 2401 Security Architecture for IP November 1998 + + +B.3.3 Granularity of Maintaining PMTU Data + + In hosts, the granularity with which PMTU ICMP processing can be done + differs depending on the implementation situation. Looking at a + host, there are three situations that are of interest with respect to + PMTU issues: + + a. Integration of IPsec into the native IP implementation + b. Bump-in-the-stack implementations, where IPsec is implemented + "underneath" an existing implementation of a TCP/IP protocol + stack, between the native IP and the local network drivers + c. No IPsec implementation -- This case is included because it is + relevant in cases where a security gateway is sending PMTU + information back to a host. + + Only in case (a) can the PMTU data be maintained at the same + granularity as communication associations. In the other cases, the + IP layer will maintain PMTU data at the granularity of Source and + Destination IP addresses (and optionally TOS/Class), as described in + RFC 1191. This is an important difference, because more than one + communication association may map to the same source and destination + IP addresses, and each communication association may have a different + amount of IPsec header overhead (e.g., due to use of different + transforms or different algorithms). The examples below illustrate + this. + + In cases (a) and (b)... Suppose you have the following situation. + H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds + the PMTU of the network hop between them. + + ================================== + | | + H1* --- R1 ----- R2 ---- R3 ---- H2* + ^ | + |.......| + + If R1 is configured to not fragment subscriber traffic, then R1 sends + an ICMP PMTU message with the appropriate PMTU to H1. H1's + processing would vary with the nature of the implementation. In case + (a) (native IP), the security services are bound to sockets or the + equivalent. Here the IP/IPsec implementation in H1 can store/update + the PMTU for the associated socket. In case (b), the IP layer in H1 + can store/update the PMTU but only at the granularity of Source and + Destination addresses and possibly TOS/Class, as noted above. So the + result may be sub-optimal, since the PMTU for a given + SRC/DST/TOS/Class will be the subtraction of the largest amount of + IPsec header used for any communication association between a given + source and destination. + + + +Kent & Atkinson Standards Track [Page 56] + +RFC 2401 Security Architecture for IP November 1998 + + + In case (c), there has to be a security gateway to have any IPsec + processing. So suppose you have the following situation. H1 is + sending to H2 and the packet to be sent from SG1 to R exceeds the + PMTU of the network hop between them. + + ================ + | | + H1 ---- SG1* --- R --- SG2* ---- H2 + ^ | + |.......| + + As described above for case (b), the IP layer in H1 can store/update + the PMTU but only at the granularity of Source and Destination + addresses, and possibly TOS/Class. So the result may be sub-optimal, + since the PMTU for a given SRC/DST/TOS/Class will be the subtraction + of the largest amount of IPsec header used for any communication + association between a given source and destination. + +B.3.4 Per Socket Maintenance of PMTU Data + + Implementation of the calculation of PMTU (Section B.3.2) and support + for PMTUs at the granularity of individual "communication + associations" (Section B.3.3) is a local matter. However, a socket- + based implementation of IPsec in a host SHOULD maintain the + information on a per socket basis. Bump in the stack systems MUST + pass an ICMP PMTU to the host IP implementation, after adjusting it + for any IPsec header overhead added by these systems. The + determination of the overhead SHOULD be determined by analysis of the + SPI and any other selector information present in a returned ICMP + PMTU message. + +B.3.5 Delivery of PMTU Data to the Transport Layer + + The host mechanism for getting the updated PMTU to the transport + layer is unchanged, as specified in RFC 1191 (Path MTU Discovery). + +B.3.6 Aging of PMTU Data + + This topic is covered in Section 6.1.2.4. + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 57] + +RFC 2401 Security Architecture for IP November 1998 + + +Appendix C -- Sequence Space Window Code Example + + This appendix contains a routine that implements a bitmask check for + a 32 packet window. It was provided by James Hughes + (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com) + and is intended as an implementation example. Note that this code + both checks for a replay and updates the window. Thus the algorithm, + as shown, should only be called AFTER the packet has been + authenticated. Implementers might wish to consider splitting the + code to do the check for replays before computing the ICV. If the + packet is not a replay, the code would then compute the ICV, (discard + any bad packets), and if the packet is OK, update the window. + +#include <stdio.h> +#include <stdlib.h> +typedef unsigned long u_long; + +enum { + ReplayWindowSize = 32 +}; + +u_long bitmap = 0; /* session state - must be 32 bits */ +u_long lastSeq = 0; /* session state */ + +/* Returns 0 if packet disallowed, 1 if packet permitted */ +int ChkReplayWindow(u_long seq); + +int ChkReplayWindow(u_long seq) { + u_long diff; + + if (seq == 0) return 0; /* first == 0 or wrapped */ + if (seq > lastSeq) { /* new larger sequence number */ + diff = seq - lastSeq; + if (diff < ReplayWindowSize) { /* In window */ + bitmap <<= diff; + bitmap |= 1; /* set bit for this packet */ + } else bitmap = 1; /* This packet has a "way larger" */ + lastSeq = seq; + return 1; /* larger is good */ + } + diff = lastSeq - seq; + if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */ + if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */ + bitmap |= ((u_long)1 << diff); /* mark as seen */ + return 1; /* out of order but good */ +} + +char string_buffer[512]; + + + +Kent & Atkinson Standards Track [Page 58] + +RFC 2401 Security Architecture for IP November 1998 + + +#define STRING_BUFFER_SIZE sizeof(string_buffer) + +int main() { + int result; + u_long last, current, bits; + + printf("Input initial state (bits in hex, last msgnum):\n"); + if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0); + sscanf(string_buffer, "%lx %lu", &bits, &last); + if (last != 0) + bits |= 1; + bitmap = bits; + lastSeq = last; + printf("bits:%08lx last:%lu\n", bitmap, lastSeq); + printf("Input value to test (current):\n"); + + while (1) { + if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break; + sscanf(string_buffer, "%lu", ¤t); + result = ChkReplayWindow(current); + printf("%-3s", result ? "OK" : "BAD"); + printf(" bits:%08lx last:%lu\n", bitmap, lastSeq); + } + return 0; +} + + + + + + + + + + + + + + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 59] + +RFC 2401 Security Architecture for IP November 1998 + + +Appendix D -- Categorization of ICMP messages + +The tables below characterize ICMP messages as being either host +generated, router generated, both, unassigned/unknown. The first set +are IPv4. The second set are IPv6. + + IPv4 + +Type Name/Codes Reference +======================================================================== +HOST GENERATED: + 3 Destination Unreachable + 2 Protocol Unreachable [RFC792] + 3 Port Unreachable [RFC792] + 8 Source Host Isolated [RFC792] + 14 Host Precedence Violation [RFC1812] + 10 Router Selection [RFC1256] + + + + +Type Name/Codes Reference +======================================================================== +ROUTER GENERATED: + 3 Destination Unreachable + 0 Net Unreachable [RFC792] + 4 Fragmentation Needed, Don't Fragment was Set [RFC792] + 5 Source Route Failed [RFC792] + 6 Destination Network Unknown [RFC792] + 7 Destination Host Unknown [RFC792] + 9 Comm. w/Dest. Net. is Administratively Prohibited [RFC792] + 11 Destination Network Unreachable for Type of Service[RFC792] + 5 Redirect + 0 Redirect Datagram for the Network (or subnet) [RFC792] + 2 Redirect Datagram for the Type of Service & Network[RFC792] + 9 Router Advertisement [RFC1256] + 18 Address Mask Reply [RFC950] + + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 60] + +RFC 2401 Security Architecture for IP November 1998 + + + IPv4 +Type Name/Codes Reference +======================================================================== +BOTH ROUTER AND HOST GENERATED: + 0 Echo Reply [RFC792] + 3 Destination Unreachable + 1 Host Unreachable [RFC792] + 10 Comm. w/Dest. Host is Administratively Prohibited [RFC792] + 12 Destination Host Unreachable for Type of Service [RFC792] + 13 Communication Administratively Prohibited [RFC1812] + 15 Precedence cutoff in effect [RFC1812] + 4 Source Quench [RFC792] + 5 Redirect + 1 Redirect Datagram for the Host [RFC792] + 3 Redirect Datagram for the Type of Service and Host [RFC792] + 6 Alternate Host Address [JBP] + 8 Echo [RFC792] + 11 Time Exceeded [RFC792] + 12 Parameter Problem [RFC792,RFC1108] + 13 Timestamp [RFC792] + 14 Timestamp Reply [RFC792] + 15 Information Request [RFC792] + 16 Information Reply [RFC792] + 17 Address Mask Request [RFC950] + 30 Traceroute [RFC1393] + 31 Datagram Conversion Error [RFC1475] + 32 Mobile Host Redirect [Johnson] + 39 SKIP [Markson] + 40 Photuris [Simpson] + + +Type Name/Codes Reference +======================================================================== +UNASSIGNED TYPE OR UNKNOWN GENERATOR: + 1 Unassigned [JBP] + 2 Unassigned [JBP] + 7 Unassigned [JBP] + 19 Reserved (for Security) [Solo] + 20-29 Reserved (for Robustness Experiment) [ZSu] + 33 IPv6 Where-Are-You [Simpson] + 34 IPv6 I-Am-Here [Simpson] + 35 Mobile Registration Request [Simpson] + 36 Mobile Registration Reply [Simpson] + 37 Domain Name Request [Simpson] + 38 Domain Name Reply [Simpson] + 41-255 Reserved [JBP] + + + + + +Kent & Atkinson Standards Track [Page 61] + +RFC 2401 Security Architecture for IP November 1998 + + + IPv6 + +Type Name/Codes Reference +======================================================================== +HOST GENERATED: + 1 Destination Unreachable [RFC 1885] + 4 Port Unreachable + +Type Name/Codes Reference +======================================================================== +ROUTER GENERATED: + 1 Destination Unreachable [RFC1885] + 0 No Route to Destination + 1 Comm. w/Destination is Administratively Prohibited + 2 Not a Neighbor + 3 Address Unreachable + 2 Packet Too Big [RFC1885] + 0 + 3 Time Exceeded [RFC1885] + 0 Hop Limit Exceeded in Transit + 1 Fragment reassembly time exceeded + + +Type Name/Codes Reference +======================================================================== +BOTH ROUTER AND HOST GENERATED: + 4 Parameter Problem [RFC1885] + 0 Erroneous Header Field Encountered + 1 Unrecognized Next Header Type Encountered + 2 Unrecognized IPv6 Option Encountered + + + + + + + + + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 62] + +RFC 2401 Security Architecture for IP November 1998 + + +References + + [BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: + Mathematical Foundations and Model", Technical Report M74- + 244, The MITRE Corporation, Bedford, MA, May 1973. + + [Bra97] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Level", BCP 14, RFC 2119, March 1997. + + [DoD85] US National Computer Security Center, "Department of + Defense Trusted Computer System Evaluation Criteria", DoD + 5200.28-STD, US Department of Defense, Ft. Meade, MD., + December 1985. + + [DoD87] US National Computer Security Center, "Trusted Network + Interpretation of the Trusted Computer System Evaluation + Criteria", NCSC-TG-005, Version 1, US Department of + Defense, Ft. Meade, MD., 31 July 1987. + + [HA94] Haller, N., and R. Atkinson, "On Internet Authentication", + RFC 1704, October 1994. + + [HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [HM97] Harney, H., and C. Muckenhirn, "Group Key Management + Protocol (GKMP) Architecture", RFC 2094, July 1997. + + [ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC + DIS 11577, International Standards Organisation, Geneva, + Switzerland, 29 November 1992. + + [IB93] John Ioannidis and Matt Blaze, "Architecture and + Implementation of Network-layer Security Under Unix", + Proceedings of USENIX Security Symposium, Santa Clara, CA, + October 1993. + + [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network- + Layer Security for IP", presentation at the Spring 1993 + IETF Meeting, Columbus, Ohio + + [KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC + 2402, November 1998. + + [KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + + + + +Kent & Atkinson Standards Track [Page 63] + +RFC 2401 Security Architecture for IP November 1998 + + + [Ken91] Kent, S., "US DoD Security Options for the Internet + Protocol", RFC 1108, November 1991. + + [MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, + "Internet Security Association and Key Management Protocol + (ISAKMP)", RFC 2408, November 1998. + + [Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC + 2412, November 1998. + + [Pip98] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John + Wiley & Sons, New York, NY, 1994. + + [SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, + Document SDN.301, Revision 1.5, 15 May 1989, published in + NIST Publication NIST-IR-90-4250, February 1990. + + [SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP + Payload Compression Protocol (IPComp)", RFC 2393, August + 1998. + + [TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security + Document Roadmap", RFC 2411, November 1998. + + [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High- + level Networks", ACM Computing Surveys, Vol. 15, No. 2, + June 1983. + +Disclaimer + + The views and specification expressed in this document are those of + the authors and are not necessarily those of their employers. The + authors and their employers specifically disclaim responsibility for + any problems arising from correct or incorrect implementation or use + of this design. + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 64] + +RFC 2401 Security Architecture for IP November 1998 + + +Author Information + + Stephen Kent + BBN Corporation + 70 Fawcett Street + Cambridge, MA 02140 + USA + + Phone: +1 (617) 873-3988 + EMail: kent@bbn.com + + + Randall Atkinson + @Home Network + 425 Broadway + Redwood City, CA 94063 + USA + + Phone: +1 (415) 569-5000 + EMail: rja@corp.home.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 65] + +RFC 2401 Security Architecture for IP November 1998 + + +Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + +Kent & Atkinson Standards Track [Page 66] + |