rfc2401.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,250 行 · 第 1/5 页

   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.