[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 2401




Network Working Group                             Stephen Kent, BBN Corp
draft-ietf-ipsec-arch-sec-02.txt         Randall Atkinson, @Home Network
Obsoletes RFC 1825                                         November 1997





            Security Architecture for the Internet Protocol




Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of 6 months.
   Internet Drafts may be updated, replaced, or obsoleted by other
   documents at any time.  It is not appropriate to use Internet Drafts
   as reference material or to cite them other than as "work in
   progress".  Please check the I-D abstract listing contained in each
   Internet Draft directory to learn the current status of this or any
   other Internet Draft.

   This particular Internet Draft is a product of the IETF's IP Security
   (IPsec) working group.  It is intended that a future version of this
   draft be submitted to the IESG for publication as a Draft Standard
   RFC.  Comments about this draft may be sent to the authors or to the
   IPsec WG mailing list <ipsec@tis.com>.  Distribution of this document
   is unlimited.

   Copyright (C) The Internet Society (November 1997).  All Rights
   Reserved.


















Kent, Atkinson                                                  [Page 1]


Internet Draft       Security Architecture for IP          November 1997


Table of Contents

   1. Introduction............................................................4
      1.1 Summary of Contents of Document.....................................4
      1.2 Audience............................................................4
      1.3 Related Documents...................................................5
   2. Design Objectives.......................................................5
      2.1 Goals/Objectives/Requirements/Problem Description...................5
      2.2 Caveats and Assumptions.............................................6
   3. System Overview ........................................................6
      3.1 What IPsec Does.....................................................7
      3.2 How IPsec Works.....................................................7
      3.3 Where IPsec May Be Implemented......................................8
   4. Security Associations...................................................9
      4.1 Definition and Scope................................................9
      4.2 Security Association Functionality.................................11
      4.3 Combining Security Associations....................................12
      4.4 Security Association Databases.....................................13
         4.4.1 The Security Policy Database (SPD)............................13
         4.4.2 Selectors.....................................................16
         4.4.3 Security Association Database (SAD)...........................19
      4.5 Basic Combinations of Security Associations........................21
      4.6 SA and Key Management..............................................23
         4.6.1 Manual Techniques.............................................24
         4.6.2 Automated SA and Key Management...............................24
         4.6.3 Locating a Security Gateway...................................25
      4.7 Security Associations and Multicast................................26
   5. IPsec Traffic Processing...............................................27
      5.1 Outbound IPsec Traffic Processing..................................27
         5.1.1 Selecting and Using an SA or SA Bundle........................27
         5.1.2 Header Construction for Tunnel Mode...........................28
            5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..............29
            5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..............30
      5.2 Processing Inbound IPsec Traffic...................................30
      5.2.1 Selecting and Using an SA or SA Bundle...........................30
      5.2.2 Handling of AH and ESP tunnels...................................31
   6. ICMP Processing (relevant to IPsec)....................................31
      6.1 PMTU/DF Processing.................................................32
         6.1.1 DF Bit........................................................32
         6.1.2 Path MTU Discovery (PMTU).....................................32
            6.1.2.1 Propagation of PMTU......................................33
            6.1.2.2 Calculation of PMTU......................................34
            6.1.2.3 Granularity of PMTU Processing...........................34
            6.1.2.4 PMTU Aging...............................................34
   7. Auditing...............................................................35
   8. Use in Systems Supporting Information Flow Security....................35
      8.1 Relationship Between Security Associations and Data Sensitivity....36
      8.2 Sensitivity Consistency Checking...................................36


Kent, Atkinson                                                  [Page 2]


Internet Draft       Security Architecture for IP          November 1997


      8.3 Additional MLS Attributes for Security Association Databases.......37
      8.4 Additional Inbound Processing Steps for MLS Networking.............37
      8.5 Additional Outbound Processing Steps for MLS Networking............37
      8.6 Additional MLS Processing for Security Gateways....................38
   9. Performance Issues.....................................................38
   10. Conformance Requirements..............................................39
   11. Security Considerations...............................................39
   12. Differences from RFC 1825.............................................39
   Acknowledgements..........................................................39
   Appendix A -- Glossary....................................................40
   Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues.........44
      B.1 DF bit.............................................................44
      B.2 Fragmentation......................................................44
      B.3 Path MTU Discovery.................................................48
         B.3.1 Identifying the Originating Host(s)...........................49
         B.3.2 Calculation of PMTU...........................................51
         B.3.3 Granularity of Maintaining PMTU Data..........................51
         B.3.4 Per Socket Maintenance of PMTU Data...........................53
         B.3.5 Delivery of PMTU Data to the Transport Layer..................53
         B.3.6 Aging of PMTU Data............................................53
   Appendix C -- Sequence Space Window Code Example..........................54
   Appendix D -- Categorization of ICMP messages.............................56
   References................................................................59
   Disclaimer................................................................62
   Author Information........................................................62

























Kent, Atkinson                                                  [Page 3]


Internet Draft       Security Architecture for IP          November 1997


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 (ISAKMP/Oakley)
        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
   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.




Kent, Atkinson                                                  [Page 4]


Internet Draft       Security Architecture for IP          November 1997


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) [KA97a] and Encapsulating Security Payload (ESP)
           [KA97b] protocols.
        c. algorithms for authentication and encryption -- a separate
           RFC for each algorithm.
        d. automatic key management, e.g., an RFC on ISAKMP/Oakley and
           "The Internet IP Security Domain of Interpretation for
           ISAKMP" [Pip97].

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
   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.



Kent, Atkinson                                                  [Page 5]


Internet Draft       Security Architecture for IP          November 1997


   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
   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


Kent, Atkinson                                                  [Page 6]


Internet Draft       Security Architecture for IP          November 1997


   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.

   NOTE: When encryption is employed within IPsec, it prevents effective
   compression by lower protocol layers.  However, IPsec does not
   provide its own compression services.  Such services may be provided
   by existing higher layer protocols, or, in the future, in IP itself.
   The IETF working group, "IP Payload Compression Protocol (ippcp)" has
   the charter to "develop 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 such protocols as IPsec."

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
   [KA97a, KA97b].

        o The IP Authentication Header (AH) [KA97a] provides
          connectionless integrity, data origin authentication, and an
          optional anti-replay service.
        o The Encapsulating Security Payload (ESP) protocol [KA97b]
          provides confidentiality (encryption), and limited traffic
          flow confidentiality.  It also may provide connectionless


Kent, Atkinson                                                  [Page 7]


Internet Draft       Security Architecture for IP          November 1997


          integrity, data origin authentication, and an anti-replay
          service.
        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 (ISAKMP/Oakley --
   [MSST97, Orm97, HC97]) 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                                                  [Page 8]


Internet Draft       Security Architecture for IP          November 1997



        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 ISAKMP/Oakley 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


Kent, Atkinson                                                  [Page 9]


Internet Draft       Security Architecture for IP          November 1997


   mechanisms currently are defined only for unicast SAs.  Hence, in the
   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 (and options).  For more details on the coverage
   afforded by AH, see the AH specification [KA97b].

   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                                                 [Page 10]


Internet Draft       Security Architecture for IP          November 1997


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 always provides confidentiality for traffic.  (However, the
   strength of the confidentiality service will depend, 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) "below" the ESP header is 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.

   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 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).






Kent, Atkinson                                                 [Page 11]


Internet Draft       Security Architecture for IP          November 1997


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
             since the processing is performed at one IPsec instance the
             (ultimate) destination.

           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
             site along the path.

   These two approaches also can be combined, i.e., an SA bundle could
   be constructed from one tunnel mode SA and one or two transport mode
   SAs, applied in sequence.  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.

   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.


Kent, Atkinson                                                 [Page 12]


Internet Draft       Security Architecture for IP          November 1997


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).

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.

   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


Kent, Atkinson                                                 [Page 13]


Internet Draft       Security Architecture for IP          November 1997


   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.  This interface must allow the user (or system administrator) to
   specify the security processing to be applied to each 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 ordering of these entries.

   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
   which of the following values should used in the SA: (a) the value in
   the packet, (b) the value associated with the policy, or (c) a
   wildcard.

   Case (c) permits the sharing of an SA (or SA bundle) by multiple SPD


Kent, Atkinson                                                 [Page 14]


Internet Draft       Security Architecture for IP          November 1997


   entries.  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 and enumerated lists for some
   selectors.)  More detail on matching of packets against SPD entries
   is provided in Section 5.

   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
   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.  To allow minimization of the number
   of SAs, the linkage between the SPD and the SAD (at both the sender
   and the receiver) MUST allow an SA to be used in more than one
   bundle.

   The SPD also will be consulted when any IPsec implementation is the
   target of an SA establishment request from another IPsec


Kent, Atkinson                                                 [Page 15]


Internet Draft       Security Architecture for IP          November 1997


   implementation, e.g., using ISAKMP/Oakley.

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
   implementation, the transport layer protocol, source/destination
   ports, and UserID (if present) may be opaque.

      - Destination IP Address (IPv4 or IPv6): this may be a single IP
        address (unicast, broadcast, or multicast group), an enumerated
        list or range of addresses, or a wildcard (mask) address.  The
        latter two are required 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> used to uniquely identify an SA.  It could
        have the same value.
        [REQUIRED for all implementations]

      - Source IP Address(es) (IPv4 or IPv6): this may be a single IP
        address, an enumerated list or range of addresses, or a wildcard
        (mask) address.  The latter two are required 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]

      - UserID: a user identifier from the operating system.  Note that
        one of the possible values of this selector is "OPAQUE".  (The
        use of a User ID as an SA selector is sometimes referred to as
        "user-oriented keying.")
        [REQUIRED for host implementations, unless the layering of the
        implementation precludes access to this information, e.g., a
        BITS implementation need not support this selector.]

      - Data sensitivity level: (IPSO/CIPSO labels)
        [REQUIRED for all systems providing information flow security as


Kent, Atkinson                                                 [Page 16]


Internet Draft       Security Architecture for IP          November 1997


        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, a list of protocol numbers, or a range of
        protocol numbers.  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 IPv6 implementations, MAY be supported in IPv4
        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.

      - IPsec protocol (AH or ESP or AH/ESP): If present, this is
        obtained from the IPv4 "Protocol" field or the IPv6 "Next
        Header" field.
        [REQUIRED for all implementations]

        NOTE: The "Protocol" or "Next Header" field could contain a
        Transport Protocol, Routing Header, AH, ESP, Fragmentation
        Header, Destination Options, Hop-by-hop options, etc.  Although
        IPv6 recommends a particular order for extension headers, it
        also specifies that the implementation must be prepared to
        accept them in any order.  So to check for the existence of an
        IPsec header, a system has to chain through the packet headers
        checking the Protocol/Next Header field until it has checked all
        that are not opaque.

      - Source and Destination (e.g., TCP/UDP) Ports: These may be
        individual UDP or TCP port values, an enumerated list of ports,
        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.
        [REQUIRED for all implementations]



Kent, Atkinson                                                 [Page 17]


Internet Draft       Security Architecture for IP          November 1997


      - IPv6 Class (from IP header): This may be expressed as a wildcard
        value or a specific IPv6 Class value.
        [REQUIRED for all systems that implement IPv6]

      - IPv6 Flow Label (from IP header): This may be expressed as a
        wildcard value or a specific Flow Label.  The IPv6 spec (RFC
        1883) calls for all datagrams for a given IPv6 Flow Label to
        have the same Source Address, Destination Address, Hop-by-hop
        Options header, and Routing Header.  The Flow Label may be
        assigned on a per socket basis.  It would then be correlated
        with the Source/Destination and could be used to provide finer
        granularity selection of security association(s).
        [REQUIRED for all systems that implement IPv6]

      - IPv4 Type of Service (TOS): Obtained from the IPv4 header.  This
        may be expressed as a wildcard or an explicit value.
        [REQUIRED for all IPv4 systems that implement IPsec]


   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, list, etc.)















Kent, Atkinson                                                 [Page 18]


Internet Draft       Security Architecture for IP          November 1997



     Field         Traffic Value       SAD Entry            SPD Entry
     --------      -------------   ----------------   --------------------
     src addr      single IP addr  single,list,wild   single,list,wildcard
     dst addr      single IP addr  single IP addr     single,list,wildcard
     xpt protocol* xpt protocol    single,list,wild   single,list,wildcard
     src port*     single src port single,list,wild   single,list,wildcard
     dst port*     single dst port single,list,wild   single,list,wildcard
     user id*      single user id  single,list,wild   single,list,wildcard
     IPsec prot    AH,ESP,AH/ESP   single or wild     single or wildcard
     IPv6 class    IPv6 class      single,list,wild   single,list,wildcard
     IPv6 flow     IPv6 flow       single,list,wild   single,list,wildcard
     IPv4 TOS      IPv4 TOS        single,list,wild   single,list,wildcard
     sec. labels   single value    single,list,wild   single,list,wildcard

           * The SAD and SPD entries for these fields could be "OPAQUE"
             because the traffic value is encrypted.

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, before it creates an SA, the implementation should check to
   see if the SAD already has an appropriate SA (created by some other
   SPD entry).  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]


Kent, Atkinson                                                 [Page 19]


Internet Draft       Security Architecture for IP          November 1997



      For each of the selectors defined in Section 4.4.2, the SA entry
      in the SAD MUST contain the value or values which were negotiated
      at the time the SA was created.  For the sender, these values are
      used to decide whether a given SA is appropriate for use with an
      outbound packet.  This is part of checking to see if there is an
      existing SA that can be used.  For the receiver, these values are
      used to check that the selector values in an inbound packet match
      those for the SA (and thus indirectly those for the matching
      policy).  For the receiver, this is part of verifying that the SA
      was appropriate for this packet.  (See Section 6 for rules for
      ICMP messages.)  These fields can have the form of specific
      values, lists, ranges, wildcards, or "OPAQUE" as described in
      section 4.4.2, "Selectors".

      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.]
            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.
              [REQUIRED for all implementations]
            o IPsec protocol mode: tunnel, transport or wildcard.  Indicates
              which mode of AH or ESP is applied to traffic on this SA.
              [REQUIRED for all implementations, unless implicitly defined by
              context]
            o Path MTU: any observed path MTU and aging variables.  See


Kent, Atkinson                                                 [Page 20]


Internet Draft       Security Architecture for IP          November 1997


              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.  Also, in transport mode at the sender, first ESP, then
        AH can be applied to the packet.  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                                                 [Page 21]


Internet Draft       Security Architecture for IP          November 1997


   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 builds on case 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














Kent, Atkinson                                                 [Page 22]


Internet Draft       Security Architecture for IP          November 1997


   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
        details of support for this case, (how H1 locates SG2,
        authenticates it, and verifies its authorization to represent
        H2) are discussed in Section 4.4.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 headers
        in a packet between H1 and SG2 would look like one of the ones
        in case 2.

   The following combinations of AH and ESP MUST be supported in the
   indicated contexts:

           - Cases 1, 3, 4 (between H1 and H2):
                   a. AH in transport mode
                   b. ESP in transport mode
                   b. AH followed by ESP in transport mode
                   d. any one of a, b, or c above AH or ESP in tunnel mode
           - Cases 1, 2, 3, and 4 (all SAs shown):
                   e. AH in tunnel mode
                   f. ESP in tunnel mode

   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,


Kent, Atkinson                                                 [Page 23]


Internet Draft       Security Architecture for IP          November 1997


   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.

   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 ISAKMP/Oakley [MSST97, Orm97, HC97] under the IPsec domain
   of interpretation [Pip97].  Other automated SA management protocols


Kent, Atkinson                                                 [Page 24]


Internet Draft       Security Architecture for IP          November 1997


   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

   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:









Kent, Atkinson                                                 [Page 25]


Internet Draft       Security Architecture for IP          November 1997


        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:

        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 hos.

   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


Kent, Atkinson                                                 [Page 26]


Internet Draft       Security Architecture for IP          November 1997


   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].

5. IPsec Traffic Processing

5.1 Outbound IPsec 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, search the SAD
              for an SA (created by other SPD entries) that matches.  If
              none exist, create an appropriate SA bundle.

           3. Use the SA bundle found/created in (2) to do the required
              IPsec processing, e.g., authenticate and encrypt.



Kent, Atkinson                                                 [Page 27]


Internet Draft       Security Architecture for IP          November 1997


   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.

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, respectively.
         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).


















Kent, Atkinson                                                 [Page 28]


Internet Draft       Security Architecture for IP          November 1997


5.1.2.1 IPv4 -- Header Construction for Tunnel Mode


                        <-- How Outer Hdr  Relates 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
       TTL              constructed (2)              decrement (2)
       protocol         AH, ESP, routing hdr         no change
       checksum         constructed                  no change
       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.
        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.
        4. configuration determines whether to copy from the inner
           header (IPv4 only), clear or set the DF.
        5. If Inner Hdr is IPv4, copy the TOS.  If Inner Hdr is IPv6,
           map the Class to TOS.

















Kent, Atkinson                                                 [Page 29]


Internet Draft       Security Architecture for IP          November 1997


5.1.2.2 IPv6 -- Header Construction for Tunnel Mode

   See previous section 5.1.2 for notes 1-5 indicated by (footnote number).

                        <-- 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 count        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, copy the Class.  If Inner Hdr IPv4,
          map the TOS to Class.

5.2 Processing Inbound IPsec 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.

           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 SHOULD match the SA


Kent, Atkinson                                                 [Page 30]


Internet Draft       Security Architecture for IP          November 1997


              selector value.  (However, an AH or ESP-protected ICMP packet
              from a gateway may legitimately appear in a tunnel mode SA
              with a source IP address other than that bound to the SA, and
              thus such packets should be permitted as exceptions to this
              check.  See Section 6.)  Other packet fields MAY match the SA
              selector values as required by local policy.

              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.

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.

6. ICMP Processing (relevant to IPsec)

   An ICMP message protected by AH or ESP and generated by a router
   SHOULD be processed and forwarded in a tunnel mode SA, and MUST NOT
   be subjected to source address checks.  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


Kent, Atkinson                                                 [Page 31]


Internet Draft       Security Architecture for IP          November 1997


   source IP address selectors bound to the SA in which the message
   arrives.

   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.

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


Kent, Atkinson                                                 [Page 32]


Internet Draft       Security Architecture for IP          November 1997



           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
                     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 PMTU
           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
           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, e.g., the 576
     byte minimum for IPv6, 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).



Kent, Atkinson                                                 [Page 33]


Internet Draft       Security Architecture for IP          November 1997


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.)

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
        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


Kent, Atkinson                                                 [Page 34]


Internet Draft       Security Architecture for IP          November 1997


   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.

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

   A multi-level secure (MLS) network is one where a single network is
   used to communicate data with different sensitivity information
   labels (e.g., Unclassified, Company Proprietary, Secret) [DoD85,
   DoD87].  The IP security 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 [BL73].  This
   section pertains only to the use of these IP security mechanisms in
   MLS environments.  Nothing in this section applies to systems not
   claiming to provide MLS.

   As used in this section, "sensitivity information" might include
   implementation-defined hierarchic levels, categories, and/or
   releasability information.

   The Authentication Header can be used to provide strong assurance for
   both mandatory access control decisions in multi-level networks and


Kent, Atkinson                                                 [Page 35]


Internet Draft       Security Architecture for IP          November 1997


   discretionary access control decisions in all kinds of networks.  If
   explicit IP sensitivity information (e.g., IPSO [Ken91]) is used and
   confidentiality is not considered necessary within the particular
   operational environment, the Authentication Header can be used to
   provide authentication for the entire packet, including cryptographic
   binding of the sensitivity information to the IP header and 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.  The Internet-standard
   encryption algorithm could be used, in conjunction with appropriate
   key management, to provide strong Discretionary Access Controls
   (DAC).  Key management could use sensitivity information to provide
   Mandatory Access Controls (MAC).  Some environments, depending on
   their local policy, might consider the Internet-standard encryption
   algorithm sufficiently strong 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
   could 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
   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


Kent, Atkinson                                                 [Page 36]


Internet Draft       Security Architecture for IP          November 1997


   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.

   Sensitivity information is needed in the model shown in [BL73].

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
   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.



Kent, Atkinson                                                 [Page 37]


Internet Draft       Security Architecture for IP          November 1997


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 for 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,
   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.


Kent, Atkinson                                                 [Page 38]


Internet Draft       Security Architecture for IP          November 1997


   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.

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.



Kent, Atkinson                                                 [Page 39]


Internet Draft       Security Architecture for IP          November 1997


   For over 2 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                                                 [Page 40]


Internet Draft       Security Architecture for IP          November 1997


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                                                 [Page 41]


Internet Draft       Security Architecture for IP          November 1997


   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 a set of internal
      hosts, providing security services for these hosts when they
      communicate with external hosts also employing IPsec (either


Kent, Atkinson                                                 [Page 42]


Internet Draft       Security Architecture for IP          November 1997


      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.
      [Section 8.6">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                                                 [Page 43]


Internet Draft       Security Architecture for IP          November 1997


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

   Fragmentation MUST be done after outbound IPsec processing.
   Reassembly MUST be done before inbound IPsec processing.  The general
   reasoning is shown below (delimited by the ****'s).

   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.




Kent, Atkinson                                                 [Page 44]


Internet Draft       Security Architecture for IP          November 1997


                                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.
                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.)


Kent, Atkinson                                                 [Page 45]


Internet Draft       Security Architecture for IP          November 1997


                                                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 24 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
          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 is to the ultimate
              destination, this is fine.  But in AH or ESP tunnel modes


Kent, Atkinson                                                 [Page 46]


Internet Draft       Security Architecture for IP          November 1997


              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,
       TOS, Next Protocol, and if there's a transport layer header -->
       SRC port and DST port.  One cannot assume IPsec has access to the
       User ID.  It is assumed that the available selector information
       is sufficient to figure out the relevant Security Association(s).

          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


Kent, Atkinson                                                 [Page 47]


Internet Draft       Security Architecture for IP          November 1997


       selectors from the packet -- SRC address, DST address, TOS/Class,
       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.)  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 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)
        ---- = 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




Kent, Atkinson                                                 [Page 48]


Internet Draft       Security Architecture for IP          November 1997


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
        - IPv6 (RFC 1885) -- IP header plus a minimum of 576 bytes

   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)...

        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.











Kent, Atkinson                                                 [Page 49]


Internet Draft       Security Architecture for IP          November 1997


        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:

   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,


Kent, Atkinson                                                 [Page 50]


Internet Draft       Security Architecture for IP          November 1997


   if the ICMP message contains more information from the original
   packet, e.g., the 576 byte minimum for IPv6, 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 576 bytes 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.  The
   diagram below illustrates several possible combinations of security
   associations between a pair of hosts (as viewed from the perspective
   of one of the hosts.)  (ESPt or AHt = tunnel mode; ESPx or AHx =
   transport mode)

   Socket 1 -----------------------------------------------           I
                                                          |           n
   Socket 2 (ESPt/SPI-A) -------------------------------  |           t
                                                        | |           e
   Socket 3 (AHx/SPI-B, ESPt/SPI-C) --- AHx (SPI-D) --- ESPt (SPI-E)--r
                                                        |             n
   Socket 4 (ESPx/SPI-F, ESPt/SPI-G) -- ESPx (SPI-H) ---              e
                                                                      t

   In order to figure out the PMTU for each socket that maps to SPI-E,
   it will be necessary to have backpointers from SPI-E to each of the
   four paths that lead to it -- Socket 1, SPI-A, SPI-D, and SPI-H.

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:








Kent, Atkinson                                                 [Page 51]


Internet Draft       Security Architecture for IP          November 1997


   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.

   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.




Kent, Atkinson                                                 [Page 52]


Internet Draft       Security Architecture for IP          November 1997


                         ================
                         |              |
                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.2.2) and support
   for PMTUs at the granularity of individual "communication
   associations" (Section B.2.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                                                 [Page 53]


Internet Draft       Security Architecture for IP          November 1997


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 & (1 << diff)) return 0; /* this packet already seen */
    bitmap |= (1 << diff);              /* mark as seen */
    return 1;                           /* out of order but good */
}

char string_buffer[512];


Kent, Atkinson                                                 [Page 54]


Internet Draft       Security Architecture for IP          November 1997


#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                                                 [Page 55]

Internet Draft       Security Architecture for IP          November 1997


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.

   [Please let us know if any of these should re-categorized.]



                                   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                                                 [Page 56]

Internet Draft       Security Architecture for IP          November 1997


                                   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                                                 [Page 57]

Internet Draft       Security Architecture for IP          November 1997


                                   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                                                 [Page 58]


Internet Draft       Security Architecture for IP          November 1997


References


   [BCCH94]  R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of
             IAB Workshop on Security in the Internet Architecture",
             RFC-1636, DDN Network Information Center, June 1994.

   [Bel89]   Steven M. Bellovin, "Security Problems in the TCP/IP
             Protocol Suite", ACM Computer Communications Review, Vol.
             19, No. 2, March 1989.

   [Bel95]   Steven M. Bellovin, Presentation at IP Security Working
             Group Meeting, Proceedings of the 32nd Internet Engineering
             Task Force, March 1995, Internet Engineering Task Force,
             Danvers, MA.

   [Bel96]   Steven M. Bellovin, "Problem Areas for the IP Security
             Protocols", Proceedings of the Sixth Usenix Unix Security
             Symposium, July, 1996.

   [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.

   [CB94]    William R. Cheswick & Steven M. Bellovin, Firewalls &
             Internet Security, Addison-Wesley, Reading, MA, 1994.

   [CG96]    Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with
             Replay Prevention", Internet Draft, 1 May 1996.

   [DIA]     US Defense Intelligence Agency, "Compartmented Mode
             Workstation Specification", Technical Report DDS-2600-
             6243-87.

   [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.

   [DH76]    W. Diffie & M. Hellman, "New Directions in Cryptography",
             IEEE Transactions on Information Theory, Vol. IT-22, No. 6,
             November 1976, pp. 644-654.



Kent, Atkinson                                                 [Page 59]


Internet Draft       Security Architecture for IP          November 1997


   [DH95]    Steve Deering & Bob Hinden, Internet Protocol version 6
             (IPv6) Specification, RFC-1883, December 1995.

   [EK96]    D. Eastlake III & C. Kaufman, "Domain Name System Protocol
             Security Extensions", Internet Draft, 30 January 1996.

   [GM93]    J. Galvin & K. McCloghrie, "Security Protocols for version
             2 of the Simple Network Management Protocol (SNMPv2)",
             RFC-1446, DDN Network Information Center, April 1993.

   [HA94]    N. Haller & R. Atkinson, "On Internet Authentication",
             RFC-1704, DDN Network Information Center, October 1994.

   [HC97]    D. Harkins & D. Carrel, "The resolution of ISAKMP with
             Oakley", Internet Draft, February 1997.

   [HM97]    H. Harney, C.  Muckenhirn, "Group Key Management Protocol
             (GKMP) Architecture", RFC 2094, July 1997.

   [Hugh96]  J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay
             Prevention Security Transform", Internet Draft, June 1996.

   [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

   [KA97a]   Steve Kent, Randall Atkinson, "IP Authentication Header",
             Internet Draft, October 1997.

   [KA97b]   Steve Kent, Randall Atkinson, "IP Encapsulating Security
             Payload (ESP)", Internet Draft, October 1997.

   [Ken91]   Steve Kent, "US DoD Security Options for the Internet
             Protocol", RFC-1108, DDN Network Information Center,
             November 1991.

   [Ken93]   Steve Kent, Privacy Enhancement for Internet Electronic
             Mail: Part II: Certificate-Based Key Management, RFC-1422,
             DDN Network Information Center, 10 February 1993.


Kent, Atkinson                                                 [Page 60]


Internet Draft       Security Architecture for IP          November 1997


   [KB93]    J. Kohl & B. Neuman, The Kerberos Network Authentication
             Service (V5), RFC-1510, DDN Network Information Center, 10
             September 1993.

   [MSST97]  D Maughan, M. Schertler, M. Schneider, & J. Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP", Internet Draft, July 26, 1997.

   [NS78]    R.M. Needham & M.D. Schroeder, "Using Encryption for
             Authentication in Large Networks of Computers",
             Communications of the ACM, Vol. 21, No. 12, December 1978,
             pp. 993-999.

   [NS81]    R.M. Needham & M.D. Schroeder, "Authentication Revisited",
             ACM Operating Systems Review, Vol. 21, No. 1., 1981.

   [OG96]    Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with
             Replay Prevention", Internet Draft, 1 May 1996.

   [Orm97]   H. K. Orman, "The OAKLEY Key Determination Protocol",
             Internet Draft, July 25, 1997.

   [OTA94]   US Congress, Office of Technology Assessment, "Information
             Security & Privacy in Network Environments", OTA-TCT-606,
             Government Printing Office, Washington, DC, September 1994.

   [Pip97]   D. Piper, "The Internet IP Security Domain of
             Interpretation for ISAKMP", Internet Draft, October 1997.

   [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.

   [STD-1]   J. Postel, "Internet Official Protocol Standards", STD-1,
             March 1996.

   [TDG97]   R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document
             Roadmap", Internet Draft, July 1997.

   [VK83]    V.L. Voydock & S.T. Kent, "Security Mechanisms in High-
             level Networks", ACM Computing Surveys, Vol. 15, No. 2,
             June 1983.

   [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and
             Zappala, D., "RSVP: A New Resource ReSerVation Protocol",


Kent, Atkinson                                                 [Page 61]


Internet Draft       Security Architecture for IP          November 1997


             IEEE Network magazine, September 1993.


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.



Author Information

   Stephen Kent
   BBN Corporation
   70 Fawcett Street
   Cambridge, MA  02140
   USA
   E-mail: kent@bbn.com
   Telephone: +1 (617) 873-3988

   Randall Atkinson
   @Home Network
   425 Broadway
   Redwood City, CA 94063
   USA
   E-mail: rja@inet.org


   Copyright (C) The Internet Society (November 1997).  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.


Kent, Atkinson                                                 [Page 62]


Internet Draft       Security Architecture for IP          November 1997


   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                                                 [Page 63]


Html markup produced by rfcmarkup 1.114, available from https://tools.ietf.org/tools/rfcmarkup/