summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2401.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2401.txt')
-rw-r--r--doc/rfc/rfc2401.txt3699
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", &current);
+ 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]
+