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

Versions: (RFC 2401) 00 01 02 03 04 05 06 RFC 4301

Network Working Group                                            S. Kent
Internet Draft                                          BBN Technologies
draft-ietf-ipsec-rfc2401bis-00.txt                          October 2003
Obsoletes: 2401
Expires April 2004







            Security Architecture for the Internet Protocol




Status of this Memo

   This document is an Internet Draft and is subject to all provisions
   of Section 10 of RFC2026. 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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as a "work in progress".

   The list of current Internet Drafts can be accessed at
   http://www.ietf.org/lid-abstracts.html

   The list of Internet Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


















Kent                                                            [Page 1]


Internet Draft        Security Architecture for IP          October 2003


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 .....................................................7
       3.1 What IPsec Does.................................................7
       3.2 How IPsec Works.................................................8
       3.3 Where IPsec May Be Implemented..................................9
   4. Security Associations................................................9
       4.1 Definition and Scope...........................................10
       4.2 Security Association Functionality.............................12
       4.3 Combining Security Associations................................13
       4.4 Security Association Databases.................................15
          4.4.1 The Security Policy Database (SPD)........................16
          4.4.2 Selectors.................................................20
          4.4.3 Security Association Database (SAD).......................25
       4.5 Basic Combinations of Security Associations....................28
       4.6 SA and Key Management..........................................31
          4.6.1 Manual Techniques.........................................31
          4.6.2 Automated SA and Key Management...........................31
          4.6.3 Locating a Security Gateway...............................32
       4.7 Security Associations and Multicast............................33
   5. IP Traffic Processing...............................................34
       5.1 Outbound IP Traffic Processing.................................34
          5.1.1 Selecting and Using an SA or SA Bundle....................34
          5.1.2 Header Construction for Tunnel Mode.......................35
             5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..........36
             5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..........37
       5.2 Processing Inbound IP Traffic..................................38
          5.2.1 Selecting and Using an SA or SA Bundle....................38
          5.2.2 Handling of AH and ESP tunnels............................41
   6. ICMP Processing (relevant to IPsec).................................41
       6.1 PMTU/DF Processing.............................................42
          6.1.1 DF Bit....................................................42
          6.1.2 Path MTU Discovery (PMTU).................................42
             6.1.2.1 Propagation of PMTU..................................42
             6.1.2.2 Calculation of PMTU..................................43
             6.1.2.3 Granularity of PMTU Processing.......................43
             6.1.2.4 PMTU Aging...........................................44
   7. Auditing............................................................45
   8. Use in Systems Supporting Information Flow Security.................45
       8.1 Relationship Between Security Associations and Data Sensitivity.46
       8.2 Sensitivity Consistency Checking...............................47


Kent                                                            [Page 2]


Internet Draft        Security Architecture for IP          October 2003


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

























Kent                                                            [Page 3]


Internet Draft        Security Architecture for IP          October 2003


1. Introduction

1.1 Summary of Contents of Document

   This memo specifies the base architecture for IPsec compliant
   systems.  The goal of the architecture is to provide various security
   services for traffic at the IP layer, in both the IPv4 and IPv6
   environments.  This document describes the goals of such systems,
   their components and how they fit together with each other and into
   the IP environment.  It also describes the security services offered
   by the IPsec protocols, and how these services can be employed in the
   IP environment.  This document does not address all aspects of IPsec
   architecture.  Subsequent documents will address additional
   architectural details of a more advanced nature, e.g., use of IPsec
   in NAT environments and more complete support for IP multicast.  The
   following fundamental components of the IPsec security architecture
   are discussed in terms of their underlying, required functionality.
   Additional RFCs (see Section 1.3 for pointers to other documents)
   define the protocols in (a), (c), and (d).


        a. Security Protocols -- Authentication Header (AH) and Encapsulating
           Security Payload (ESP)
        b. Security Associations -- what they are and how they work, how they
           are managed, associated processing
        c. Key Management -- manual and automatic (The Internet Key Exchange
           (IKE))
        d. Algorithms for authentication and encryption

   This document is not an overall Security Architecture for the
   Internet; it addresses security only at the IP layer, provided
   through the use of a combination of cryptographic and protocol
   security mechanisms.

   The spelling "IPsec" is preferred and standard.  All other
   capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated.
   However, any capitalization of IPsec should be understood to refer to
   the IPsec protocols.

   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


Kent                                                            [Page 4]


Internet Draft        Security Architecture for IP          October 2003


   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.

1.3 Related Documents

   As mentioned above, other documents provide detailed definitions of
   some of the components of IPsec and of their inter-relationship.
   They include RFCs on the following topics:

       a. "IP Security Document Roadmap" [TDG97] -- a document providing
          guidelines for specifications describing encryption and
          authentication algorithms used in this system.

       b. security protocols -- RFCs describing the Authentication Header
          (AH) [KA98a] and Encapsulating Security Payload (ESP) [KA98b]
          protocols.

       c. algorithms for authentication and encryption -- a separate RFC
                                                     for each algorithm.

       d. automatic key management -- RFCs on "The Internet Key Exchange
          (IKE)" [HC98], "Internet Security Association and Key Management
          Protocol (ISAKMP)" [MSST97],"The OAKLEY Key Determination Protocol"
          [Orm97], and "The Internet IP Security Domain of Interpretation
          for ISAKMP" [Pip98].

2. Design Objectives

2.1 Goals/Objectives/Requirements/Problem Description

   IPsec is designed to provide interoperable, high quality,
   cryptographically-based security for IPv4 and IPv6.  The set of
   security services offered includes access control, connectionless
   integrity, data origin authentication, protection against replays (a
   form of partial sequence integrity), confidentiality (encryption),
   and limited traffic flow confidentiality.  These services are
   provided at the IP layer, offering protection for IP and/or next
   layer protocols.

   IPsec provides a range of security services to help secure
   communication for the computers and networks it protects. In addition
   to IP layer confidentiality and integrity, receiver-optional anti-
   replay and data origin authentication (via SA key management), IPsec
   also provides access control for all traffic traversing it.  Thus
   IPsec includes a specification for minimal firewall functionality,


Kent                                                            [Page 5]


Internet Draft        Security Architecture for IP          October 2003


   since that is a necessary part of secure IP. Implementations are free
   to provide more sophisticated firewall mechanisms, and to implement
   the IPsec-mandated functionality using those more sophisticated
   mechanisms.

   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.

   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.


Kent                                                            [Page 6]


Internet Draft        Security Architecture for IP          October 2003


3. System Overview [Will change to reflect decisions re: [40],[44],[45]
processing model; and [46] nesting and bundling of SAs]

   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 actions based on IP and transport layer
   header information (Selectors, Section 4.4.2) matched against entries
   in the database (SPD).  Each packet is either afforded IPsec security
   services, discarded, or allowed to bypass IPsec, based on the
   applicable database policies identified by the Selectors.


3.1 What IPsec Does

   IPsec provides security services at the IP layer by enabling a system
   to select required security protocols, determine the algorithm(s) to
   use for the service(s), and put in place any cryptographic keys
   required to provide the requested services.  IPsec can be used to
   protect one or more "paths" between a pair of hosts, between a pair
   of security gateways, or between a security gateway and a host.  (The
   term "security gateway" is used throughout the IPsec documents to
   refer to an intermediate system that implements IPsec protocols.  For
   example, a router or a firewall implementing IPsec is a security
   gateway.)

   The set of security services that IPsec can provide includes access
   control, connectionless integrity, data origin authentication,
   rejection of replayed packets (a form of partial sequence integrity),
   confidentiality (encryption), and limited traffic flow
   confidentiality.  Because these services are provided at the IP
   layer, they can be used by any higher layer protocol, e.g., TCP, UDP,
   ICMP, BGP, etc.

   The IPsec DOI also supports negotiation of IP compression [SMPT98],
   motivated in part by the observation that when encryption is employed
   within IPsec, it prevents effective compression by lower protocol


Kent                                                            [Page 7]


Internet Draft        Security Architecture for IP          October 2003


   layers.

3.2 How IPsec Works

   IPsec uses two protocols to provide traffic security --
   Authentication Header (AH) and Encapsulating Security Payload (ESP).
   Both protocols are described in more detail in their respective RFCs
   [KA98a, KA98b]. IPsec implementations MUST support ESP and MAY
   support AH.

       o The IP Authentication Header (AH) [KA98a] provides connectionless
         integrity, data origin authentication, and an optional anti-replay
         service.

       o The Encapsulating Security Payload (ESP) protocol [KA98b] may
         provide confidentiality (encryption), and limited traffic flow
         confidentiality. It also may provide connectionless integrity, data
         origin authentication, and an anti-replay service.  (One or the
         other set of these security services must be applied whenever ESP
         is invoked.)

       o Both AH and ESP are vehicles for access control, based on the
         distribution of cryptographic keys and the management of traffic
         flows relative to these security protocols.

   These protocols may be applied alone or in combination with each
   other to provide a desired set of security services in IPv4 and IPv6.
   Each protocol supports two modes of use: transport mode and tunnel
   mode.  In transport mode the protocols provide protection primarily
   for next 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


Kent                                                            [Page 8]


Internet Draft        Security Architecture for IP          October 2003


   for putting these keys in place. (The keys are used for
   authentication/integrity and encryption services.)  This document
   requires support for both manual and automatic distribution of keys.
   It specifies a specific public-key based approach (IKE -- [MSST97,
   Orm97, HC98]) for automatic key management, but other automated key
   distribution techniques MAY be used.  For example, KDC-based systems
   such as Kerberos and other public-key systems such as SKIP could be
   employed.

3.3 Where IPsec May Be Implemented

   There are several ways in which IPsec may be implemented in a host or
   in conjunction with a router or firewall (to create a security
   gateway).  Several common examples are provided below:

        a. Integration of IPsec into the native IP implementation.  This
           requires access to the IP source code and is applicable to both
           hosts and security gateways.

        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 [Will change to reflect decisions re: -
[40,44,45] changes in processing model (caching, etc.); - [46]
nesting/bundling of SAs; - [67] IPsec management traffic; - [82]
clarification re: creation of SAs]

   This section defines Security Association management requirements for
   all IPv6 implementations and for those IPv4 implementations that
   implement AH, ESP, or both.  The concept of a "Security Association"
   (SA) is fundamental to IPsec.  Both AH and ESP make use of SAs and a
   major function of IKE is the establishment and maintenance of
   Security Associations.  All implementations of AH or ESP MUST support


Kent                                                            [Page 9]


Internet Draft        Security Architecture for IP          October 2003


   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 [May change to reflect decisions re: [50]
should transport support by SG be MAY or MUST and [87] follow-on
proposed approach]


   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. The set of SPI values in
   the range 1 through 255 are reserved by the Internet Assigned Numbers
   Authority (IANA) for future use.  A reserved SPI value will not
   normally be assigned by IANA unless the use of the assigned SPI value
   is specified in an RFC. The SPI value of zero (0) is reserved for
   local implementation-specific use and MUST NOT be sent on the wire.
   For example, a key management implementation MAY use the zero SPI
   value to mean "No Security Association Exists" during the period when
   the IPsec implementation has requested that its key management entity
   establish a new SA, but the SA has not yet been established. In
   principle, the Destination Address may be a unicast address, an IP
   broadcast address, or a multicast group address.  However, IPsec SA
   management mechanisms currently are defined only for unicast SAs.
   Hence, in the discussions that follow, SAs will be described
   primarily in the context of point-to-point communication, even though
   the concept is applicable in the point-to-multipoint case as well.

   Note: If different classes of traffic (distinguished by DSCP bits)
   are sent on the same SA, this could result in inappropriate
   discarding of lower priority packets due to the windowing mechanism
   used by receivers to reject replays. Therefore a sender SHOULD put
   traffic of different classes, but with the same selector values, on
   different SAs to appropriately support QoS.  To permit this, the
   IPsec implementation MUST permit establishment and maintenance of
   multiple SAs between a given sender and receiver, with the same
   selectors. Distribution of traffic among these parallel SAs to
   support QoS is locally determined by the sender and is not negotiated


Kent                                                           [Page 10]


Internet Draft        Security Architecture for IP          October 2003


   by IKE. The receiver MUST process the packets from the different SAs
   without prejudice.

   DISCUSSION:  While the DSCP and ECN fields are not "selectors", as
   that term in used in this architecture, the sender will need a
   mechanism to direct packets with a given (set of) DSCP values to the
   appropriate SA.  This mechanism might be termed a "filter".

   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. Also, in the case where link security is desired between
   two intermediate systems along a path, transport mode MAY be used
   between two security gateways.  In the latter case, transport mode
   would be used to support IP-in-IP or GRE tunneling over transport
   mode SAs. Note that the access control functions that are an
   important part of IPsec are significantly constrained in this
   context. So this way of using transport mode should be evaluated
   carefully before being employed.  In IPv4, a transport mode security
   protocol header appears immediately after the IP header and any
   options, and before any higher layer protocols (e.g., TCP or UDP).
   In IPv6, the security protocol header appears after the base IP
   header and extensions, but may appear before or after destination
   options, and before higher layer protocols.  In the case of ESP, a
   transport mode SA provides security services only for these higher
   layer protocols, not for the IP header or any extension headers
   preceding the ESP header.  In the case of AH, the protection is also
   extended to selected portions of the IP header, selected portions of
   extension headers, and selected options (contained in the IPv4
   header, IPv6 Hop- by-Hop extension header, or IPv6 Destination
   extension headers).  For more details on the coverage afforded by AH,
   see the AH specification [KA98a].

   A tunnel mode SA is essentially an SA applied to an IP tunnel.  With
   only a couple of exceptions, 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 typically 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. Also, as noted above,
   security gateways MAY support transport mode to provide link
   security. 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


Kent                                                           [Page 11]


Internet Draft        Security Architecture for IP          October 2003


   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.

   In summary,
           a) A host MUST support both transport and tunnel mode.

           b) A security gateway is required to support only tunnel mode but
              MAY support transport mode.  If it supports transport mode, that
              should be used only when the security gateway is acting as a host,
              e.g., for network management, or to provide link security.

4.2 Security Association Functionality


   The set of security services offered by an SA depends on the security
   protocol selected, the SA mode, the endpoints of the SA, and on the
   election of optional services within the protocol.  For example, AH
   provides data origin authentication and connectionless integrity for
   IP datagrams (hereafter referred to as just "authentication").  The
   "precision" of the authentication service is a function of the
   granularity of the security association with which AH is employed, as
   discussed in Section 4.4.2, "Selectors".

   AH also offers an anti-replay (partial sequence integrity) service at
   the discretion of the receiver, to help counter denial of service
   attacks.  AH is an appropriate protocol to employ when
   confidentiality is not required (or is not permitted, e.g , due to
   government restrictions on use of encryption).  AH also provides
   authentication for selected portions of the IP header, which may be
   necessary in some contexts.  For example, if the integrity of an IPv4
   option or IPv6 extension header must be protected en route between
   sender and receiver, AH can provide this service (except for the non-
   predictable but mutable parts of the IP header.)

   ESP optionally provides confidentiality for traffic.  (The strength
   of the confidentiality service depends in part, on the encryption
   algorithm employed.)  ESP also may optionally provide authentication
   (as defined above).  If authentication is negotiated for an ESP SA,


Kent                                                           [Page 12]


Internet Draft        Security Architecture for IP          October 2003


   the receiver also may elect to enforce an anti-replay service with
   the same features as the AH anti-replay service.  The scope of the
   authentication offered by ESP is narrower than for AH, i.e., the IP
   header(s) "outside" the ESP header is(are) not protected.  If only
   the next layer protocols need to be authenticated, then ESP
   authentication is an appropriate choice and is more space efficient
   than use of AH encapsulating ESP.  Note that although both
   confidentiality and authentication are optional, they cannot both be
   omitted. At least one of them MUST be selected.

   If confidentiality service is selected, then an ESP (tunnel mode) SA
   between two security gateways can offer partial traffic flow
   confidentiality.  The use of tunnel mode allows the inner IP headers
   to be encrypted, concealing the identities of the (ultimate) traffic
   source and destination.  Moreover, ESP payload padding also can be
   invoked to hide the size of the packets, further concealing the
   external characteristics of the traffic. Similar traffic flow
   confidentiality services may be offered when a mobile user is
   assigned a dynamic IP address in a dialup context, and establishes a
   (tunnel mode) ESP SA to a corporate firewall (acting as a security
   gateway).  Note that fine granularity SAs generally are more
   vulnerable to traffic analysis than coarse granularity ones which are
   carrying traffic from many subscribers.

4.3 Combining Security Associations [May change depending on decisions
re: [46] nested SAs and bundles]


   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


Kent                                                           [Page 13]


Internet Draft        Security Architecture for IP          October 2003


   combination; further nesting yields no added benefit (assuming use of
   adequately strong algorithms in each protocol) since the processing
   is performed at one IPsec instance at the (ultimate) destination.

   Host 1 --- Security ---- Internet -- Security --- Host 2
    | |        Gwy 1                      Gwy 2        | |
    | |                                                | |
    | -----Security Association 1 (ESP transport)------- |
    |                                                    |
    -------Security Association 2 (AH transport)----------

   o Iterated tunneling refers to the application of multiple layers of
   security protocols effected through IP tunneling.  This approach
   allows for multiple levels of nesting, since each tunnel can
   originate or terminate at a different IPsec site along the path.  No
   special treatment is expected for ISAKMP traffic at intermediate
   security gateways other than what can be specified through
   appropriate SPD entries (See Case 3 in Section 4.5)

     There are 3 basic cases of iterated tunneling -- support is
   required only for cases 2 and 3.:

     1. both endpoints for the SAs are the same -- The inner and outer
   tunnels could each be either AH or ESP, though it is unlikely that
   Host 1 would specify both to be the same, i.e., AH inside of AH or
   ESP inside of ESP.

        Host 1 --- Security ---- Internet -- Security --- Host 2
         | |        Gwy 1                      Gwy 2        | |
         | |                                                | |
         | -------Security Association 1 (tunnel)---------- | |
         |                                                    |
         ---------Security Association 2 (tunnel)--------------

     2. one endpoint of the SAs is the same -- The inner and outer
   tunnels could each be either AH or ESP.

        Host 1 --- Security ---- Internet -- Security --- Host 2
         | |        Gwy 1                      Gwy 2         |
         | |                                     |           |
         | ----Security Association 1 (tunnel)----           |
         |                                                   |
         ---------Security Association 2 (tunnel)-------------

     3. neither endpoint is the same -- The inner and outer tunnels
   could each be either AH or ESP.




Kent                                                           [Page 14]


Internet Draft        Security Architecture for IP          October 2003


        Host 1 --- Security ---- Internet -- Security --- Host 2
         |          Gwy 1                      Gwy 2         |
         |            |                          |           |
         |            --Security Assoc 1 (tunnel)-           |
         |                                                   |
         -----------Security Association 2 (tunnel)-----------

   These two approaches also can be combined, e.g., an SA bundle could
   be constructed from one tunnel mode SA and one or two transport mode
   SAs, applied in sequence.  (See Section 4.5 "Basic Combinations of
   Security Associations.") Note that nested tunnels can also occur
   where neither the source nor the destination endpoints of any of the
   tunnels are the same.  In that case, there would be no host or
   security gateway with a bundle corresponding to the nested tunnels.

   For transport mode SAs, only one ordering of security protocols seems
   appropriate.  AH is applied to both the next layer protocols and
   (parts of) the IP header.  Thus if AH is used in a transport mode, in
   conjunction with ESP, AH SHOULD appear as the first header after IP,
   prior to the appearance of ESP.  In that context, AH is applied to
   the ciphertext output of ESP.  In contrast, for tunnel mode SAs, one
   can imagine uses for various orderings of AH and ESP.  The required
   set of SA bundle types that MUST be supported by a compliant IPsec
   implementation is described in Section 4.5.

4.4 Security Association Databases [Will change to reflect decisions re:
- [40,44,45] changes in processing model (caching, etc.); - [46]
nesting/bundling of SAs; - [67] IPsec management traffic; - [82]
clarification re: creation of SAs] -

   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


Kent                                                           [Page 15]


Internet Draft        Security Architecture for IP          October 2003


   associated with each (active) security association.  This section
   also defines the concept of a Selector, a set of IP and next layer
   protocol field values that is used by the Security Policy Database to
   map traffic to a policy, i.e., an SA (or SA bundle).

   Each interface for which IPsec is enabled requires nominally separate
   inbound vs.  outbound databases (SAD and SPD), because of the
   directionality of many of the fields that are used as selectors.
   Typically there is just one such interface, for a host or security
   gateway (SG).  Note that an SG would always have at least 2
   interfaces, but the "internal" one to the corporate net, usually
   would not have IPsec enabled and so only one pair of SADs and one
   pair of SPDs would be needed.  On the other hand, if a host had
   multiple interfaces or an SG had multiple external interfaces, it
   might be necessary to have separate SAD and SPD pairs for each
   interface.

   IPsec devices supporting services such as: security gateway for
   multiple subscribers, IPsec-protected tunnel links for overlay
   networks, etc. MAY implement multiple separate IPsec contexts.  These
   contexts MAY have and use completely independent identities,
   policies, key management SAs, and/or IPsec SAs.  This is for the most
   part a local implementation matter.  However, a means for associating
   inbound proposals with local contexts is required.  To this end, if
   supported by the key management protocol in use, context identifiers
   MAY be conveyed from initiator to responder in the signalling
   messages, with the result that IPsec SAs are created with a binding
   to a particular context.


4.4.1 The Security Policy Database (SPD)

   Ultimately, a security association is a management construct used to
   enforce a security policy in the IPsec environment.  Thus an
   essential element of SA processing is an underlying Security Policy
   Database (SPD) that specifies what services are to be offered to IP
   datagrams and in what fashion.  The form of the database and its
   interface are outside the scope of this specification.  However, this
   section does specify certain minimum management functionality that
   must be provided, to allow a user or system administrator to control
   how IPsec is applied to traffic transmitted or received by a host or
   transiting a security gateway.

   The SPD must be consulted during the processing of all traffic
   (INBOUND and OUTBOUND), including non-IPsec traffic.  In order to
   support this, the SPD requires distinct entries for inbound and
   outbound traffic.  One can think of this as separate SPDs (inbound
   vs.  outbound).  In addition, a nominally separate SPD must be


Kent                                                           [Page 16]


Internet Draft        Security Architecture for IP          October 2003


   provided for each IPsec-enabled interface.

   An SPD must discriminate among traffic that is afforded IPsec
   protection and traffic that is allowed to bypass IPsec.  This applies
   to the IPsec protection to be applied by a sender and to the IPsec
   protection that must be present at the receiver.  For any outbound or
   inbound datagram, three processing choices are possible: discard,
   bypass IPsec, or apply IPsec.  The first choice refers to traffic
   that is not allowed to exit the host, traverse the security gateway,
   or be delivered to an application at all.  The second choice refers
   to traffic that is allowed to pass without additional IPsec
   protection.  The third choice refers to traffic that is afforded
   IPsec protection, and for such traffic the SPD must specify the
   security services to be provided, protocols to be employed,
   algorithms to be used, etc.

   For every IPsec implementation, there MUST be an administrative
   interface that allows a user or system administrator to manage the
   SPD.  Specifically, every inbound or outbound packet is subject to
   processing by IPsec and the SPD must specify what action will be
   taken in each case.  Thus the administrative interface must allow the
   user (or system administrator) to specify the security processing to
   be applied to any packet entering or exiting the system, on a packet
   by packet basis.  (In a host IPsec implementation making use of a
   socket interface, the SPD may not need to be consulted on a per
   packet basis, but the effect is still the same.)  The management
   interface for the SPD MUST allow creation of entries consistent with
   the selectors defined in Section 4.4.2, and MUST support (total)
   ordering of these entries.  It is expected that through the use of
   wildcards in various selector fields, and because all packets on a
   single UDP or TCP connection will tend to match a single SPD entry,
   this requirement will not impose an unreasonably detailed level of
   SPD specification.  The selectors are analogous to what are found in
   a stateless firewall or filtering router and which are currently
   manageable this way.

   In host systems, applications MAY be allowed to select what security
   processing is to be applied to the traffic they generate and consume.
   (Means of signalling such requests to the IPsec implementation are
   outside the scope of this standard.)  However, the system
   administrator MUST be able to specify whether or not a user or
   application can override (default) system policies.  Note that
   application specified policies may satisfy system requirements, so
   that the system may not need to do additional IPsec processing beyond
   that needed to meet an application's requirements.  The form of the
   management interface is not specified by this document and may differ
   for hosts vs. security gateways, and within hosts the interface may
   differ for socket-based vs.  BITS implementations.  However, this


Kent                                                           [Page 17]


Internet Draft        Security Architecture for IP          October 2003


   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. The SPD MUST permit a security administrator to
   specify policy entries as follows:

   - each SPD entry is a list of 1 or more selector set pairs - each
   selector set pair consists of one selector set for the SA from the
   initiator to the receiver and one selector set for the SA from the
   receiver to the initiator.  - each selector set consists of the
   following selector types: - source IP address range - destination IP
   address range - protocol(or OPAQUE or ANY) - source port range (or
   OPAQUE or ANY) - destination port range (or OPAQUE or ANY) - IPv6
   mobility header type (MH type) range - ICMP message type range - ICMP
   codes range - name (list) - data sensitivity level (list)

   This will enable policies to be specified that, for example, support
   use of a single SA to carry traffic for multiple protocols. Note that
   this text describes the representation in the SPD that maps into IKE
   payloads. The management GUI can offer the user other forms of data
   entry and display, e.g., the option of using address masks as well as
   ranges not representable by a mask, and symbolic names for protocols,
   ports, etc. (Do not confuse the use of symbolic names in a management
   interface with the reference to symbolic SPD selector types.) If the
   reserved, symbolic selector value OPAQUE is employed for a given
   selector type, only it may appear in the list for that type, and it
   must appear only once in the list for that type.

   Each entry includes an indication of whether traffic matching this
   policy will be bypassed, discarded, or subject to IPsec processing.
   If IPsec processing is to be applied, the entry includes an SA (or SA
   bundle) specification, listing the IPsec protocols, modes, and
   algorithms to be employed, including any nesting requirements.  For
   example, an entry may call for all matching traffic to be protected
   by ESP in transport mode using 3DES-CBC with an explicit IV, nested
   inside of AH in tunnel mode using HMAC/SHA-1.

   For each selector, the policy entry specifies how to derive the
   corresponding values for a new Security Association Database (SAD,
   see Section 4.4.3) entry from those in the SPD and the packet (Note
   that at present, ranges are only supported for IP addresses; but
   wildcarding can be expressed for all selectors):

           a. use the value in the packet itself -- This will limit use of the


Kent                                                           [Page 18]


Internet Draft        Security Architecture for IP          October 2003


              SA to those packets which have this packet's value for the selector
              even if the selector for the policy entry has a range of allowed
              values or a wildcard for this selector.

           b. use the value associated with the policy entry -- If this were to
              be just a single value, then there would be no difference between
              (b) and (a).  However, if the allowed values for the selector are
              a range (for IP addresses) or wildcard, then in the case of a range,
              (b) would enable use of the SA by any packet with a selector value
              within the range not just by packets with the selector value of the
              packet that triggered the creation of the SA.  In the case of a
              wildcard, (b) would allow use of the SA by packets with any value
              for this selector.

   For example, suppose there is an SPD entry where the allowed value
   for source address is any of a range of hosts (192.168.2.1 to
   192.168.2.10).  And suppose that a packet is to be sent that has a
   source address of 192.168.2.3.  The value to be used for the SA could
   be any of the sample values below depending on what the policy entry
   for this selector says is the source of the selector value:

            source for the  example of
            value to be     new SAD
            used in the SA  selector value
            --------------- ------------
            a. packet       192.168.2.3 (one host)
            b. SPD entry    192.168.2.1 to 192.168.2.10 (range of hosts)

   Note that if the SPD entry had an allowed value of wildcard for the
   source address, then the SAD selector value could be wildcard (any
   host).  Case (a) can be used to prohibit sharing, even among packets
   that match the same SPD entry.

   As described below in Section 4.4.3, selectors may include "wildcard"
   entries and hence the selectors for two entries may overlap.  (This
   is analogous to the overlap that arises with ACLs or filter entries
   in routers or packet filtering firewalls.)  Thus, to ensure
   consistent, predictable processing, SPD entries MUST be ordered and
   the SPD MUST always be searched in the same order, so that the first
   matching entry is consistently selected.  (This requirement is
   necessary as the effect of processing traffic against SPD entries
   must be deterministic, but there is no way to canonicalize SPD
   entries given the use of wildcards for some selectors.)  More detail
   on matching of packets against SPD entries is provided in Section 5.

   Note that if ESP is specified, either (but not both) authentication
   or encryption can be omitted.  So it MUST be possible to configure
   the SPD value for the authentication or encryption algorithms to be


Kent                                                           [Page 19]


Internet Draft        Security Architecture for IP          October 2003


   "NULL".  However, at least one of these services MUST be selected,
   i.e., it MUST NOT be possible to configure both of them as "NULL".

   The SPD can be used to map traffic to specific SAs or SA bundles.
   Thus it can function both as the reference database for security
   policy and as the map to existing SAs (or SA bundles).  (To
   accommodate the bypass and discard policies cited above, the SPD also
   MUST provide a means of mapping traffic to these functions, even
   though they are not, per se, IPsec processing.)  The way in which the
   SPD operates is different for inbound vs. outbound traffic and it
   also may differ for host vs.  security gateway, BITS, and BITW
   implementations.  Sections 5.1 and 5.2 describe the use of the SPD
   for outbound and inbound processing, respectively.

   Because a security policy may require that more than one SA be
   applied to a specified set of traffic, in a specific order, the
   policy entry in the SPD must preserve these ordering requirements,
   when present.  Thus, it must be possible for an IPsec implementation
   to determine that an outbound or inbound packet must be processed
   thorough a sequence of SAs.  Conceptually, for outbound processing,
   one might imagine links (to the SAD) from an SPD entry for which
   there are active SAs, and each entry would consist of either a single
   SA or an ordered list of SAs that comprise an SA bundle.  When a
   packet is matched against an SPD entry and there is an existing SA or
   SA bundle that can be used to carry the traffic, the processing of
   the packet is controlled by the SA or SA bundle entry on the list.
   For an inbound IPsec packet for which multiple IPsec SAs are to be
   applied, the lookup based on destination address, IPsec protocol, and
   SPI should identify a single SA.

   The SPD is used to control the flow of ALL traffic through an IPsec
   system, including security and key management traffic (e.g., ISAKMP)
   from/to entities behind a security gateway.  This means that ISAKMP
   traffic must be explicitly accounted for in the SPD, else it will be
   discarded.  Note that a security gateway could prohibit traversal of
   encrypted packets in various ways, e.g., having a DISCARD entry in
   the SPD for ESP packets or providing proxy key exchange.  In the
   latter case, the traffic would be internally routed to the key
   management module in the security gateway.

4.4.2  Selectors

   An SA (or SA bundle) may be fine-grained or coarse-grained, depending
   on the selectors used to define the set of traffic for the SA.  For
   example, all traffic between two hosts may be carried via a single
   SA, and afforded a uniform set of security services.  Alternatively,
   traffic between a pair of hosts might be spread over multiple SAs,
   depending on the applications being used (as defined by the Next


Kent                                                           [Page 20]


Internet Draft        Security Architecture for IP          October 2003


   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 Name (if present) may be "OPAQUE", i.e., inaccessible
   because of encryption or fragmentation.  Note also that both Source
   and Destination addresses should either be IPv4 or IPv6.


      - Destination IP Address (IPv4 or IPv6): this may be a single IP
        address (unicast, anycast, broadcast (IPv4 only), or multicast
        group), a range of addresses (high and low values (inclusive),
        address + mask, or a wildcard address.  The last three are used
        to support more than one destination system sharing the same SA
        (e.g., behind a security gateway). Note that this selector is
        conceptually different from the "Destination IP Address" field
        in the <Destination IP Address, IPsec Protocol, SPI> tuple used
        to uniquely identify an SA.  When a tunneled packet arrives at
        the tunnel endpoint, its SPI/Destination address/Protocol are
        used to look up the SA for this packet in the SAD.  This
        destination address comes from the encapsulating IP header.
        Once the packet has been processed according to the tunnel SA
        and has come out of the tunnel, its selectors are "looked up" in
        the Inbound SPD.  The Inbound SPD has a selector called
        destination address.  This IP destination address is the one in
        the inner (encapsulated) IP header.  In the case of a
        transport'd packet, there will be only one IP header and this
        ambiguity does not exist.
        [REQUIRED for all implementations]


      - Source IP Address(es) (IPv4 or IPv6): this may be a single IP
        address (unicast, anycast, broadcast (IPv4 only), or multicast
        group), range of addresses (high and low values inclusive),
        address + mask, or a wildcard address.  The last three are used
        to support more than one source system sharing the same SA
        (e.g., behind a security gateway or in a multihomed host).
        [REQUIRED for all implementations]


      - Name: There are 2 cases (Note that these name forms are
        supported in the IPsec DOI.)
                 1. User ID
                     a. a fully qualified user name string (DNS), e.g.,


Kent                                                           [Page 21]


Internet Draft        Security Architecture for IP          October 2003


                        mozart@foo.bar.com
                     b. X.500 distinguished name, e.g., C = US, SP = MA, O = GTE
                        Internetworking, CN = Stephen T. Kent.
                 2. System name (host, security gateway, etc.)
                     a. a fully qualified DNS name, e.g., foo.bar.com
                     b. X.500 distinguished name
                     c. X.500 general name

        NOTE: One of the possible values of this selector is "OPAQUE".

        [REQUIRED for the following cases.  Note that support for name
        forms other than addresses is not required for manually keyed
        SAs.
                 o User ID
                     - native host implementations
                     - BITW and BITS implementations acting as HOSTS
        with only one user
                     - security gateway implementations for INBOUND
        processing.
                 o System names -- all implementations]

      - Data sensitivity level: (IPSO/CIPSO labels)
        [REQUIRED for all systems providing information flow security as
        per Section 8, OPTIONAL for all other systems.]

      - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
        IPv6 "Next Header" fields.  This may be an individual protocol
        number.  These packet fields may not contain the Next Layer
        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 Next Layer
        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..br [REQUIRED for all implementations]

        NOTE: To locate the Next Layer 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
        Next Layer 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 Next Layer Protocol opaque. Note: The IPv6
        mobility header is a possible next layer protocol.


      - Source and Destination (e.g., TCP/UDP) Ports: These may be
        individual UDP or TCP port values or a wildcard port.  (The use
        of the Next Protocol field and the Source and/or Destination
        Port fields (in conjunction with the Source and/or Destination


Kent                                                           [Page 22]


Internet Draft        Security Architecture for IP          October 2003


        Address fields), as an SA selector is sometimes referred to as
        "session-oriented keying.").  Note that the source and
        destination ports may not be available in the case of receipt of
        a packet with an ESP header, thus a value of "OPAQUE" SHOULD be
        supported.

        The following table summarizes the relationship between the
        "Next Header" value in the packet and SPD and the derived Port
        Selector value for the SPD and SAD.

               Next Hdr        Transport Layer   Derived Port Selector Field
               in Packet       Protocol in SPD   Value in SPD and SAD
               --------        ---------------   ---------------------------
               ESP             ESP or ANY        ANY (i.e., don't look at it)
               -don't care-    ANY               ANY (i.e., don't look at it)
               specific value  specific value    NOT ANY (i.e., drop packet)
                  fragment
               specific value  specific value    actual port selector field
                  not fragment

        If the packet has been fragmented, then the port information may
        not be available in the current fragment.  If so, discard the
        fragment.  An ICMP PMTU should be sent for the first fragment,
        which will have the port information.
        [MAY be supported]

      - IPv6 Mobility Header Message Type (MH type) [Mobip]:  This is an
        8-bit selector that identifies the particular mobility message
        in question.  This MUST be used only if the Next Layer Protocol
        is defined to be an IPv6 Mobility Header. Note that the MH type
        may not be available in the case of receipt of a packet with an
        ESP header, thus a value of "OPAQUE" SHOULD be supported.

      - ICMP message type: This defines the type of ICMP message.  This
        selector can be a list. Note that the ICMP message type may not
        be available in the case of receipt of a packet with an ESP
        header, thus a value of "OPAQUE" SHOULD be supported.

      - ICMP code: This defines a specific cause for the ICMP message.
        This selector can be a list. Note that the ICMP code may not be
        available in the case of receipt of a packet with an ESP header,
        thus a value of "OPAQUE" SHOULD be supported.



   The 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


Kent                                                           [Page 23]


Internet Draft        Security Architecture for IP          October 2003


   SPD can be consulted and an SA (or SA bundle) bound to the socket.
   Thus traffic sent via that socket need not result in additional
   lookups to the SPD/SAD.  In contrast, a BITS, BITW, or security
   gateway implementation needs to look at each packet and perform an
   SPD/SAD lookup based on the selectors. The allowable values for the
   selector fields differ between the traffic flow, the security
   association, and the security policy.

   The following table summarizes the kinds of entries that one needs to
   be able to express in the SPD and SAD.  It shows how they relate to
   the fields in data traffic being subjected to IPsec screening.
   (Note: the "wild" or "wildcard" entry for src and dst addresses
   includes a mask, range, etc.)

      Field         Traffic Value       SAD Entry            SPD Entry
      --------      -------------   ----------------   --------------------
      src addr      single IP addr  single,range,wild  single,range,wildcard
      dst addr      single IP addr  single,range,wild  single,range,wildcard
      xpt protocol* xpt protocol    single,wildcard    single,wildcard
      src port*     single src port single,wildcard    single,wildcard
      dst port*     single dst port single,wildcard    single,wildcard
      user id*      single user id  single,wildcard    single,wildcard
      sec. labels   single value    single,wildcard    single,wildcard
      mh type       single value    single,wildcard    single,wildcard
      ICMP type     single value    single,wildcard    single,wildcard
      ICMP code     single value    single,wildcard    single,wildcard


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

   NOTE: In principle, one could have selectors and/or selector values
   in the SPD which cannot be negotiated for an SA or SA bundle.
   Examples might include selector values used to select traffic for
   discarding or enumerated lists which cause a separate SA to be
   created for each item on the list.  For now, this is left for future
   versions of this document and the list of required selectors and
   selector values is the same for the SPD and the SAD.  However, it is
   acceptable to have an administrative interface that supports use of
   selector values which cannot be negotiated provided that it does not
   mislead the user into believing it is creating an SA with these
   selector values.  For example, the interface may allow the user to
   specify an enumerated list of values but would result in the creation
   of a separate policy and SA for each item on the list.  A vendor
   might support such an interface to make it easier for its customers
   to specify clear and concise policy specifications.




Kent                                                           [Page 24]


Internet Draft        Security Architecture for IP          October 2003


4.4.3 Security Association Database (SAD)

   In each IPsec implementation there is a nominal Security Association
   Database, in which each entry defines the parameters associated with
   one SA.  Each SA has an entry in the SAD.  For outbound processing,
   entries are pointed to by entries in the SPD.  Note that if an SPD
   entry does not currently point to an SA that is appropriate for the
   packet, the implementation creates an appropriate SA (or SA Bundle)
   and links the SPD entry to the SAD entry (see Section 5.1.1).  For
   inbound processing, each entry in the SAD is indexed by a destination
   IP address, IPsec protocol type, and SPI.  The following parameters
   are associated with each entry in the SAD.  This description does not
   purport to be a MIB, but only a specification of the minimal data
   items required to support an SA in an IPsec implementation.

   For inbound processing: The following packet fields are used to look
   up the SA in the SAD.

   For a unicast SA, the SPI can be used by itself to specify an SA, or
   it may be used in conjunction with the IPsec protocol type (AH or
   ESP). Since the SPI value is generated by the receiver for a unicast
   SA, whether the value is sufficient to identify an SA by itself, or
   whether it must be used in conjunction with the IPsec protocol value
   is a local matter. This mechanism for mapping inbound traffic to
   unicast SAs MUST be supported by all IPsec implementations.

   If an IPsec implementation supports multicast SAs as well as unicast
   SAs, then it MUST use the following algorithm for mapping all inbound
   IPsec datagrams to SAs.  (Implementations that support only unicast
   traffic need not implement this algorithm.)  Each entry in the
   Security Association Database (SAD) must indicate whether the SA
   lookup makes use of (a) the SPI but neither the source or destination
   address (unicast), (b) the destination IP address plus the SPI, or
   (c) source plus destination IP addresses in addition to the SPI. (For
   multicast SAs, the protocol field is not employed for SA lookups.)
   Nominally, this indication can be represented by two bits, one
   associated with the source IP address and the other for the
   destination IP address. A "1" value for each bit indicates the need
   to match against the corresponding address field as part of the SA
   lookup process.  Thus, for example, unicast SAs would have both bits
   set to zero, since neither the source nor destination IP address is
   required for SA matching.

   For multicast methods that rely only on the destination address to
   specify a multicast group, only the destination bit would be set to
   "1," implying the need to use the destination address plus the SPI to
   determine the appropriate SA. For multicast methods (e.g., SSM
   [HC03]) that also require the source address to identify a multicast


Kent                                                           [Page 25]


Internet Draft        Security Architecture for IP          October 2003


   group, both bits would be set to "1."  (There is no current
   requirement to support multicast SA mapping based on the source
   address but not the destination address, thus one of the possible
   four values is not meaningful.)  The indication as to whether source
   and destination address matching is required to map inbound IPsec
   traffic to SAs MUST be set either as a side effect of manual SA
   configuration or via negotiation using an SA management protocol,
   e.g., IKE.

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

   The following SAD fields are used in doing IPsec processing:

        o Sequence Number Counter: a 32-bit value used to generate the
          Sequence Number field in AH or ESP headers.

          [REQUIRED for all implementations, but used only for outbound traffic.]

        o Sequence Counter Overflow: a flag indicating whether overflow of the
          Sequence Number Counter should generate an auditable event and prevent
          transmission of additional packets on the SA.

          [REQUIRED for all implementations, but used only for outbound traffic.]

        o Anti-Replay Window: a 32-bit counter and a bit-map (or equivalent) used
          to determine whether an inbound AH or ESP packet is a replay.

          [REQUIRED for all implementations but used only for inbound traffic.
          NOTE: If anti-replay has been disabled by the receiver, e.g., in the
          case of a manually keyed SA, then the Anti-Replay Window is not used.]

        o AH Authentication algorithm, keys, etc.

          [REQUIRED for AH implementations]



Kent                                                           [Page 26]


Internet Draft        Security Architecture for IP          October 2003


        o ESP Encryption algorithm, keys, IV mode, IV, etc.

          [REQUIRED for ESP implementations]

        o ESP authentication algorithm, keys, etc. If the authentication service
          is not selected, this field will be null.

          [REQUIRED for ESP implementations]

        o Lifetime of this Security Association: a time interval after which an
          SA must be replaced with a new SA (and new SPI) or terminated, plus an
          indication of which of these actions should occur.  This may be
          expressed as a time or byte count, or a simultaneous use of both, the
          first lifetime to expire taking precedence. A compliant implementation
          MUST support both types of lifetimes, and must support a simultaneous
          use of both.  If time is employed, and if IKE employs X.509
          certificates for SA establishment, the SA lifetime must be constrained
          by the validity intervals of the certificates, and the NextIssueDate
          of the CRLs used in the IKE exchange for the SA.  Both initiator and
          responder are responsible for constraining SA lifetime in this fashion.

          [REQUIRED for all implementations]

          NOTE: The details of how to handle the refreshing of keys when SAs
          expire is a local matter.  However, one reasonable approach is:

          (a) If byte count is used, then the implementation SHOULD count the number
              of bytes to which the IPsec algorithm is applied.  For ESP, this is
              the encryption algorithm (including Null encryption) and for AH, this
              is the authentication algorithm.  This includes pad bytes, etc.  Note
              that implementations SHOULD be able to handle having the counters at
              the ends of an SA get out of synch, e.g., because of packet loss or
              because the implementations at each end of the SA aren't doing things
              the same way.

          (b) There SHOULD be two kinds of lifetime -- a soft lifetime which warns
              the implementation to initiate action such as setting up a replacement
              SA and a hard lifetime when the current SA ends.

          (c) If the entire packet does not get delivered during the SAs lifetime,
              the packet SHOULD be discarded.

        o IPsec protocol mode: tunnel, transport or wildcard.  Indicates which
          mode of AH or ESP is applied to traffic on this SA.  Note that if this
          field is "wildcard" at the sending end of the SA, then the application
          has to specify the mode to the IPsec implementation.  This use of
          wildcard allows the same SA to be used for either tunnel or transport
          mode traffic on a per packet basis, e.g., by different sockets.  The


Kent                                                           [Page 27]


Internet Draft        Security Architecture for IP          October 2003


          receiver does not need to know the mode in order to properly process
          the packet's IPsec headers.

          [REQUIRED as follows, unless implicitly defined by context:
                              - host implementations must support all modes
                        - gateway implementations must support tunnel mode]

          NOTE: The use of wildcard for the protocol mode of an inbound SA may add
          complexity to the situation in the receiver (host only).  Since the
          packets on such an SA could be delivered in either tunnel or transport
          mode, the security of an incoming packet could depend in part on which
          mode had been used to deliver it.  If, as a result, an application cared
          about the SA mode of a given packet, then the application would need a
          mechanism to obtain this mode information.

        o Path MTU: any observed path MTU and aging variables.  See Section
          6.1.2.4

         [REQUIRED for all implementations but used only for outbound traffic]

4.5 Basic Combinations of Security Associations [May change depending on
decisions re: [46] nesting/bundling SAs]

   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.







Kent                                                           [Page 28]


Internet Draft        Security Architecture for IP          October 2003


    Case 1.  The case of providing end-to-end security between 2 hosts across the
Internet (or an Intranet).

                  ====================================
                  |                                  |
                 H1* ------ (Inter/Intranet) ------ H2*

         Note that either transport or tunnel mode can be selected by the hosts.
So the headers in a packet between H1 and H2 could look like any of the following:

                   Transport                  Tunnel
              -----------------          ---------------------
              1. [IP1][AH][next]        4. [IP2][AH][IP1][next]
              2. [IP1][ESP][next]       5. [IP2][ESP][IP1][next]
              3. [IP1][AH][ESP][next]

         Note that there is no requirement to support general nesting, but in
transport mode, both AH and ESP can be applied to the packet.  In this event, the
SA establishment procedure MUST ensure that first ESP, then AH are applied to the
packet.

    Case 2.  This case illustrates simple virtual private networks support.

                           ===========================
                           |                         |
      ---------------------|----                  ---|-----------------------
      |                    |   |                  |  |                      |
      |  H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2  |
      |        Intranet)       |                  |          Intranet)      |
      --------------------------                  ---------------------------
          admin. boundary                               admin. boundary

         Only tunnel mode is required here.  So the headers in a packet between
SG1 and SG2 could look like either of the following:

                         Tunnel
                 ---------------------
                 4. [IP2][AH][IP1][next]
                 5. [IP2][ESP][IP1][next]











Kent                                                           [Page 29]


Internet Draft        Security Architecture for IP          October 2003


    Case 3.  This case combines cases 1 and 2, adding end-to-end security between
the sending and receiving hosts.  It imposes no new requirements on the hosts or
security gateways, other than a requirement for a security gateway to be
configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it.

         ===============================================================
         |                                                             |
         |                 =========================                   |
         |                 |                       |                   |
      ---|-----------------|----                ---|-------------------|---
      |  |                 |   |                |  |                   |  |
      | H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
      |        Intranet)       |                |          Intranet)      |
      --------------------------                ---------------------------
           admin. boundary                            admin. boundary

    Case 4.  This covers the situation where a remote host (H1) uses the Internet
to reach an organization's firewall (SG2) and to then gain access to some server
or other machine (H2).  The remote host could be a mobile host (H1) dialing up to
a local PPP/ARA server (not shown) on the Internet and then crossing the Internet
to the home organization's firewall (SG2), etc.  The details of support for this
case, (how H1 locates SG2, authenticates it, and verifies its authorization to
represent H2) are discussed in Section 4.6.3, "Locating a Security Gateway".

         ======================================================
         |                                                    |
         |==============================                      |
         ||                            |                      |
         ||                         ---|----------------------|---
         ||                         |  |                      |  |
         H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
               ^                    |           Intranet)        |
               |                    ------------------------------
         could be dialup              admin. boundary (optional)
         to PPP/ARA server

         Only tunnel mode is required between H1 and SG2.  So the choices for the
SA between H1 and SG2 would be one of the ones in case 2.  The choices for the SA
between H1 and H2 would be one of the ones in case 1.

         Note that in this case, the sender MUST apply the transport header before
the tunnel header.  Therefore the management interface to the IPsec implementation
MUST support configuration of the SPD and SAD to ensure this ordering of IPsec
header application.

As noted above, support for additional combinations of AH and ESP is
optional.  Use of other, optional combinations may adversely affect
interoperability.


Kent                                                           [Page 30]


Internet Draft        Security Architecture for IP          October 2003


4.6 SA and Key Management

   IPsec mandates support for both manual and automated SA and
   cryptographic key management.  The IPsec protocols, AH and ESP, are
   largely independent of the associated SA management techniques,
   although the techniques involved do affect some of the security
   services offered by the protocols. For example, the optional anti-
   replay services available for AH and ESP require automated SA
   management.  Moreover, the granularity of key distribution employed
   with IPsec determines the granularity of authentication provided.
   (See also a discussion of this issue in Section 4.7.)  In general,
   data origin authentication in AH and ESP is limited by the extent to
   which secrets used with the authentication algorithm (or with a key
   management protocol that creates such secrets) are shared among
   multiple possible sources.

   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


Kent                                                           [Page 31]


Internet Draft        Security Architecture for IP          October 2003


   generally implies use of an automated SA/key management protocol.)

   The default automated key management protocol selected for use with
   IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of
   interpretation [Pip98].  Other automated SA management protocols MAY
   be employed.

   When an automated SA/key management protocol is employed, the output
   from this protocol may be used to generate multiple keys, e.g., for a
   single ESP SA.  This may arise because:

            o the encryption algorithm uses multiple keys (e.g., triple DES)
            o the authentication algorithm uses multiple keys
            o both encryption and authentication algorithms are employed

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


Internet Draft        Security Architecture for IP          October 2003


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

   This document does not address the issue of how to automate the
   discovery/verification of security gateways.  Note: The IP Security
   Policy (IPSP) working group is working on an"SG discovery, Policy
   Exchange and Negotiation Protocol".

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


Kent                                                           [Page 33]


Internet Draft        Security Architecture for IP          October 2003


   Association (and hence Security Parameter Index) for all traffic to
   that group when a symmetric key encryption or authentication
   algorithm is employed. In such circumstances, the receiver knows only
   that the message came from a system possessing the key for that
   multicast group.  In such circumstances, a receiver generally will
   not be able to authenticate which system sent the multicast traffic.
   Specifications for other, more general multicast cases are deferred
   to later IPsec documents.



5. IP Traffic Processing

   As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
   the SPD must be consulted during the processing of all traffic
   (INBOUND and OUTBOUND), including non-IPsec traffic.  If no policy is
   found in the SPD that matches the packet (for either inbound or
   outbound traffic), the packet MUST be discarded.

   NOTE: All of the cryptographic algorithms used in IPsec expect their
   input in canonical network byte order (see Appendix in RFC 791) and
   generate their output in canonical network byte order.  IP packets
   are also transmitted in network byte order.

5.1 Outbound IP Traffic Processing [Will change to reflect decisions re:
[40],[44],[45] new processing model; [46] nested/bundled SAs; and [81]
handling outbound fragments]

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


Kent                                                           [Page 34]


Internet Draft        Security Architecture for IP          October 2003


             were found or none match, create an appropriate SA bundle and link
             the SPD entry to the SAD entry.  If no key management entity is
             found, drop the packet.

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

   In a host IPsec implementation based on sockets, the SPD will be
   consulted whenever a new socket is created, to determine what, if
   any, IPsec processing will be applied to the traffic that will flow
   on that socket.

   NOTE: A compliant implementation MUST not allow instantiation of an
   ESP SA that employs both a NULL encryption and a NULL authentication
   algorithm.  An attempt to negotiate such an SA is an auditable event.

5.1.2 Header Construction for Tunnel Mode

   This section describes the handling of the inner and outer IP
   headers, extension headers, and options for AH and ESP tunnels.  This
   includes how to construct the encapsulating (outer) IP header, how to
   handle fields in the inner IP header, and what other actions should
   be taken.  The general idea is modeled after the one used in RFC
   2003, "IP Encapsulation with IP":

         o The outer IP header Source Address and Destination Address identify
           the "endpoints" of the tunnel (the encapsulator and decapsulator).
           The inner IP header Source Address and Destination Addresses identify
           the original sender and recipient of the datagram, (from the
           perspective of this tunnel), respectively.  (see footnote 3 after
           the table in 5.1.2.1 for more details on the encapsulating source
           IP address.)

         o The inner IP header is not changed except to decrement the TTL as
           noted below, and remains unchanged during its delivery to the tunnel
           exit point.

         o No change to IP options or extension headers in the inner header
           occurs during delivery of the encapsulated datagram through the tunnel.

         o If need be, other protocol headers such as the IP Authentication
           header may be inserted between the outer IP header and the inner IP
           header.

   The tables in the following sub-sections show the handling for the
   different header/option fields (constructed = the value in the outer
   field is constructed independently of the value in the inner).



Kent                                                           [Page 35]


Internet Draft        Security Architecture for IP          October 2003


5.1.2.1 IPv4 -- Header Construction for Tunnel Mode [May be affected by
decisions on [75] "TOS (now DSCP and ECN) copying in tunnel mode"]

                         <-- How Outer Hdr Relates to Inner Hdr -->
                         Outer Hdr at                 Inner Hdr at
    IPv4                 Encapsulator                 Decapsulator
      Header fields:     --------------------         ------------
        version          4 (1)                        no change
        header length    constructed                  no change



        DS Field         copied from inner hdr (5)    no change
        ECN Field        copied from inner hdr        constructed (6)
        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                  constructed (2)
        src address      constructed (3)              no change
        dest address     constructed (3)              no change
    Options            never copied                 no change

         1. The IP version in the encapsulating header can be different from the
value in the inner header.

         2. The TTL in the inner header is decremented by the encapsulator prior
to forwarding and by the decapsulator if it forwards the packet.  (The checksum
changes when the TTL changes.)

            NOTE: The decrementing of the TTL is one of the usual actions that
takes place when forwarding a packet.  Packets originating from the same node as
the encapsulator do not have their TTL's decremented, as the sending node is
originating the packet rather than forwarding it.

         3. src and dest addresses depend on the SA, which is used to determine
the dest address which in turn determines which src address (net interface) is
used to forward the packet.

            NOTE: In principle, the encapsulating IP source address can be any of
the encapsulator's interface addresses or even an address different from any of
the encapsulator's IP addresses, (e.g., if it's acting as a NAT box) so long as
the address is reachable through the encapsulator from the environment into which
the packet is sent.  This does not cause a problem because IPsec does not
currently have any INBOUND processing requirement that involves the Source Address
of the encapsulating IP header.  So while the receiving tunnel endpoint looks at


Kent                                                           [Page 36]


Internet Draft        Security Architecture for IP          October 2003


the Destination Address in the encapsulating IP header, it only looks at the
Source Address in the inner (encapsulated) IP header.

         4. configuration determines whether to copy from the inner header (IPv4
only), clear or set the DF.

         5. If the packet will immediately enter a domain for which the DSCP value
in the outer header is not appropriate, that value MUST be mapped to an
appropriate value for the domain [RFC 2474].  See [RFC 2475 for further
information.

         6. If the ECN field in the inner header is set to ECT(0) or ECT(1) and
the ECN field in the outer header is set to CE, then set the ECN field in the
inner header to CE, otherwise make no change to the ECN field in the inner header.

Note: IPsec does not copy the options from the inner header into the outer header,
and IPsec does not construct the options in the outer header. However, post-IPsec
code MAY insert/construct options for the outer header.

5.1.2.2 IPv6 -- Header Construction for Tunnel Mode [May be affected by decisions
on [75] "TOS (now DSCP and ECN) copying in 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



        DS Field         copied from inner hdr (6)    no change
        ECN Field        copied from inner hdr        constructed (7)
        flow id          copied or configured         no change
        len              constructed                  no change
        next header      AH,ESP,routing hdr           no change
        hop limit        constructed (2)              decrement (2)
        src address      constructed (3)              no change
        dest address     constructed (3)              no change
      Extension headers  never copied                 no change

        6. If the packet will immediately enter a domain for which the DSCP value
in the outer header is not appropriate, that value MUST be mapped to an
appropriate value for the domain [RFC 2474].  See [RFC 2475] for further
information.

        (7) If the ECN field in the inner header is set to ECT(0) or ECT(1) and


Kent                                                           [Page 37]


Internet Draft        Security Architecture for IP          October 2003


the ECN field in the outer header is set to CE, then set the ECN field in the
inner header to CE, otherwise make no change to the ECN field in the inner header.

Note: IPsec does not copy the extension headers from the inner header into the
outer header, and IPsec does not construct the extension headers in the outer
header. However, post-IPsec code MAY insert/construct extension headers for the
outer header.

5.2 Processing Inbound IP Traffic [Will change to reflect [40],[44],[45] new
processing model and [46] SA nesting/bundles.


   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 [May change to reflect
decisions re: [85] DROPØd inbound packet Ï does not match SA]



   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. To look up an SA: For unicast, the SPI may be used alone to select an
   SA, or may be combined with the protocol, at the option of the receiver.  For
   multicast SAs, the SPI is combined with the destination address, and optionally
   the source address, to select an SA. (See Section 4.4.3 for more details.) If the
   SA lookup fails, drop the packet and log/report the error.

            2. Use the SA found in (1) to do the IPsec processing, e.g., authenticate
   and decrypt.  This step includes matching the packet's (Inner Header if tunneled)
   selectors to the selectors in the SA.  Local policy determines the specificity of
   the SA selectors (single value, list, range, wildcard).  In general, a packet's
   source address MUST match the SA selector value.  However, an ICMP packet received
   on a tunnel mode SA may have a source address other than that bound to the SA and
   thus such packets should be permitted as exceptions to this check.  For an ICMP
   packet, the selectors from the enclosed problem packet (the source and destination
   addresses and ports should be swapped) should be checked against the selectors for
   the SA.  Note that some or all of these selectors may be inaccessible because of
   limitations on how many bits of the problem packet the ICMP packet is allowed to


Kent                                                           [Page 38]


Internet Draft        Security Architecture for IP          October 2003


   carry or due to encryption.  See Section 6.

               Do (1) and (2) for every IPsec header until a Transport Protocol
   Header or an IP header that is NOT for this system is encountered.  Keep track of
   what SAs have been used and their order of application.

            3. Find an incoming policy in the SPD that matches the packet.  This
   could be done, for example, by use of backpointers from the SAs to the SPD or by
   matching the packet's selectors (Inner Header if tunneled) against those of the
   policy entries in the SPD.

            4. Check whether the required IPsec processing has been applied, i.e.,
   verify that the SA's found in (1) and (2) match the kind and order of SAs required
   by the policy found in (3).

               NOTE: The correct "matching" policy will not necessarily be the first
   inbound policy found.  If the check in (4) fails, steps (3) and (4) are repeated
   until all policy entries have been checked or until the check succeeds.

   If an IPsec system receives an inbound (unprotected) packet for which the matching
   SPD entry requires IPsec protection, it MUST drop the packet.  It SHOULD also be
   capable of generating and sending an ICMP message to indicate to the sender that
   the receiver dropped the packet.  The reason SHOULD be recorded in the audit log.

   IPv4    Type = 3 (destination unreachable)
           Code = 13 (Communication Administratively Prohibited)

   IPv6    Type = 1 (destination unreachable)
           Code = 1 (Communication with Destination Administratively Prohibited

   Note that an attacker could send packets with a spoofed source address, W.X.Y.Z,
   to an IPsec entity causing it to send ICMP messages to W.X.Y.Z.  This creates an
   opportunity to use an IPsec receiver in a DoS attack. To address this, the
   implementation SHOULD provide management controls to allow an administrator to
   configure an IPsec implementation to silently discard the packet or to respond
   with the above ICMP message, and if this facility is selected, to rate limit the
   transmission of such ICMP responses.  If responding with an ICMP message is
   supported, then rate limiting MUST be supported.


   If an IPsec system receives an outbound packet which it finds it must drop, it
   SHOULD be capable of generating and sending an ICMP message to indicate to the
   sender of the outbound packet that the packet was dropped.  The type and code of
   the ICMP message will depend on the reason for dropping the packet.  The reason
   SHOULD be recorded in the audit log.

   a. the selectors of the packet matched an SPD entry requiring the packet to be
   dropped -->


Kent                                                           [Page 39]


Internet Draft        Security Architecture for IP          October 2003



   IPv4    Type = 3 (destination unreachable)
           Code = 13 (Communication Administratively
                      Prohibited)

   IPv6    Type = 1 (destination unreachable)
           Code = 1 (Communication with destination
                     administratively prohibited

   b1. the IPsec system was unable to set up the SA required by the SPD entry
   matching the packet because the IPsec peer at the other end of the exchange is
   administratively prohibited from communicating with the initiator and rejects the
   negotiation.

   IPv4    Type = 3 (destination unreachable)
           Code = 13 (Communication Administratively
                      Prohibited)

   IPv6    Type = 1 (destination unreachable)
           Code = 1 (Communication with destination
                     administratively prohibited

   b2. the IPsec system was unable to set up the SA required by the SPD entry
   matching the packet because the IPsec peer at the other end of the exchange could
   not be contacted.

   IPv4    Type = 3 (destination unreachable)
           Code = 1 (host unreachable)

   IPv6    Type = 1 (destination unreachable)
           Code = 3 (address unreachable)

   Note that an attacker behind a security gateway could send packets with a spoofed
   source address, W.X.Y.Z, to an IPsec entity causing it to send ICMP messages to
   W.X.Y.Z.  This creates an opportunity for a DoS attack among hosts behind a
   security gateway. To address this, a security gateway SHOULD include a management
   control to allow an administrator to configure an IPsec implementation to send or
   not send the above ICMP message, and if this facility is selected, to rate limit
   the transmission of such ICMP responses.

   At the end of these steps, pass the resulting packet to the Transport
   Layer or forward the packet.  Note that any IPsec headers processed
   in these steps may have been removed, but that this information,
   i.e., what SAs were used and the order of their application, may be
   needed for subsequent IPsec or firewall processing.

   Note that in the case of a security gateway, if forwarding causes a
   packet to exit via an IPsec-enabled interface, then additional IPsec


Kent                                                           [Page 40]


Internet Draft        Security Architecture for IP          October 2003


   processing may be applied.

5.2.2 Handling of AH and ESP tunnels

   The handling of the inner and outer IP headers, extension headers,
   and options for AH and ESP tunnels should be performed as described
   in the tables in Section 5.1.

6. ICMP Processing (relevant to IPsec).fi

   The focus of this section is on the handling of ICMP error messages.
   Other ICMP traffic, e.g., Echo/Reply, should be treated like other
   traffic and can be protected on an end-to-end basis using SAs in the
   usual fashion.

   An ICMP error message protected by AH or ESP and generated by a
   router SHOULD be processed and forwarded in a tunnel mode SA.  Local
   policy determines whether or not it is subjected to source address
   checks by the router at the destination end of the tunnel.  Note that
   if the router at the originating end of the tunnel is forwarding an
   ICMP error message from another router, the source address check
   would fail.  An ICMP message protected by AH or ESP and generated by
   a router MUST NOT be forwarded on a transport mode SA (unless the SA
   has been established to the router acting as a host, e.g., a Telnet
   connection used to manage a router).  An ICMP message generated by a
   host SHOULD be checked against the source IP address selectors bound
   to the SA in which the message arrives.  Note that even if the source
   of an ICMP error message is authenticated, the returned IP header
   could be invalid. Accordingly, the selector values in the IP header
   SHOULD also be checked to be sure that they are consistent with the
   selectors for the SA over which the ICMP message was received.

   The table in Appendix D characterize ICMP messages as being either
   host generated, router generated, both, unknown/unassigned.  ICMP
   messages falling into the last two categories should be handled as
   determined by the receiver's policy.

   An ICMP message not protected by AH or ESP is unauthenticated and its
   processing and/or forwarding may result in denial of service.  This
   suggests that, in general, it would be desirable to ignore such
   messages.  However, it is expected that many routers (vs. security
   gateways) will not implement IPsec for transit traffic and thus
   strict adherence to this rule would cause many ICMP messages to be
   discarded.  The result is that some critical IP functions would be
   lost, e.g., redirection and PMTU processing.  Thus it MUST be
   possible to configure an IPsec implementation to accept or reject
   (router) ICMP traffic as per local security policy.



Kent                                                           [Page 41]


Internet Draft        Security Architecture for IP          October 2003


   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.

   Note: An IPsec system SHOULD provide controls that allow an
   administrator to configure the IPsec system to set a threshold for
   the minimum size to which the PTMU can be set via processing an ICMP
   PMTU from a public Internet source. The default might be that the
   ciphertext size would be 576 bytes (IPv4) or 1280 (IPv6).

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) [May change to reflect decisions re:
[78] PMTU discovery]

   This section discusses IPsec handling for Path MTU Discovery
   messages.  ICMP PMTU is used here to refer to an ICMP message for:

            IPv4 (RFC 792):
                    - Type = 3 (Destination Unreachable)
                    - Code = 4 (Fragmentation needed and DF set)
                    - Next-Hop MTU in the low-order 16 bits of the second word of the
   ICMP header (labelled "unused" in RFC 792), with high-order 16 bits set to zero

            IPv6 (RFC 1885):
                    - Type = 2 (Packet Too Big)
                    - Code = 0 (Fragmentation needed)
                    - Next-Hop MTU in the 32 bit MTU field of the ICMP6 message


6.1.2.1 Propagation of PMTU

   The amount of information returned with the ICMP PMTU message (IPv4
   or IPv6) is limited and this affects what selectors are available for
   use in further propagating the PMTU information.  (See Appendix B for
   more detailed discussion of this topic.)


Kent                                                           [Page 42]


Internet Draft        Security Architecture for IP          October 2003


    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 then there may be enough non-opaque
information to immediately determine to which host to propagate the ICMP/PMTU
message and to provide that system with the 5 fields (source address, destination
address, source port, destination port, transport protocol) needed to determine
where to store/update the PMTU.  Under such circumstances, a security gateway MUST
generate an ICMP PMTU message immediately upon receipt of an ICMP PMTU from
further down the path.

    o Distributing the PMTU to the Transport Layer -- The host mechanism for
getting the updated PMTU to the transport layer is unchanged, as specified in RFC
1191 (Path MTU Discovery).

6.1.2.2 Calculation of PMTU

   The calculation of PMTU from an ICMP PMTU MUST take into account the
   addition of any IPsec header -- AH transport, ESP transport, AH/ESP
   transport, ESP tunnel, AH tunnel.  (See Appendix B for discussion of
   implementation issues.)

   Note: In some situations the addition of IPsec headers could result
   in an effective PMTU (as seen by the host or application) that is
   unacceptably small.  To avoid this problem, the implementation may
   establish a threshold below which it will not report a reduced PMTU.
   In such cases, the implementation would apply IPsec and then fragment
   the resulting packet according to the PMTU.  This would result in a
   more efficient use of the available bandwidth.

6.1.2.3 Granularity of PMTU Processing

   In hosts, the granularity with which ICMP PMTU processing can be done
   differs depending on the implementation situation.  Looking at a


Kent                                                           [Page 43]


Internet Draft        Security Architecture for IP          October 2003


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


Kent                                                           [Page 44]


Internet Draft        Security Architecture for IP          October 2003


   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

   Information of various sensitivity levels may be carried over a
   single network.  Information labels (e.g., Unclassified, Company
   Proprietary, Secret) [DoD85, DoD87] are often employed to distinguish
   such information.  The use of labels facilitates segregation of
   information, in support of information flow security models, e.g.,
   the Bell-LaPadula model [BL73].  Such models, and corresponding
   supporting technology, are designed to prevent the unauthorized flow
   of sensitive information, even in the face of Trojan Horse attacks.
   Conventional, discretionary access control (DAC) mechanisms, e.g.,
   based on access control lists, generally are not sufficient to
   support such policies, and thus facilities such as the SPD do not
   suffice in such environments.

   In the military context, technology that supports such models is
   often referred to as multi-level security (MLS).  Computers and
   networks often are designated "multi-level secure" if they support
   the separation of labelled data in conjunction with information flow
   security policies.  Although such technology is more broadly
   applicable than just military applications, this document uses the
   acronym "MLS" to designate the technology, consistent with much
   extant literature.

   IPsec mechanisms can easily support MLS networking.  MLS networking
   requires the use of strong Mandatory Access Controls (MAC), which
   unprivileged users or unprivileged processes are incapable of
   controlling or violating.  This section pertains only to the use of


Kent                                                           [Page 45]


Internet Draft        Security Architecture for IP          October 2003


   these IP security mechanisms in MLS (information flow security
   policy) 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.

   AH can be used to provide strong authentication in support of
   mandatory access control decisions in MLS environments.  If explicit
   IP sensitivity information (e.g., IPSO [Ken91]) is used and
   confidentiality is not considered necessary within the particular
   operational environment, AH can be used to authenticate the binding
   between sensitivity labels in the IP header and the IP payload
   (including user data).  This is a significant improvement over
   labeled IPv4 networks where the sensitivity information is trusted
   even though there is no authentication or cryptographic binding of
   the information to the IP header and user data.  IPv4 networks might
   or might not use explicit labelling.  IPv6 will normally use implicit
   sensitivity information that is part of the IPsec Security
   Association but not transmitted with each packet instead of using
   explicit sensitivity information.  All explicit IP sensitivity
   information MUST be authenticated using either ESP, AH, or both.

   Encryption is useful and can be desirable even when all of the hosts
   are within a protected environment, for example, behind a firewall or
   disjoint from any external connectivity.  ESP can be used, in
   conjunction with appropriate key management and encryption
   algorithms, in support of both DAC and MAC.  (The choice of
   encryption and authentication algorithms, and the assurance level of
   an IPsec implementation will determine the environments in which an
   implementation may be deemed sufficient to satisfy MLS requirements.)
   Key management can make use of sensitivity information to provide
   MAC.  IPsec implementations on systems claiming to provide MLS SHOULD
   be capable of using IPsec to provide MAC for IP-based communications.

8.1 Relationship Between Security Associations and Data Sensitivity

   Both the Encapsulating Security Payload and the Authentication Header
   can be combined with appropriate Security Association policies to
   provide multi-level secure networking.  In this case each SA (or SA
   bundle) is normally used for only a single instance of sensitivity
   information.  For example, "PROPRIETARY - Internet Engineering" must
   be associated with a different SA (or SA bundle) from "PROPRIETARY -
   Finance".





Kent                                                           [Page 46]


Internet Draft        Security Architecture for IP          October 2003


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
   packet will depart.  This check will either verify that the
   sensitivities match, or that the packet's sensitivity falls within
   the range of the interface or address/prefix.

   The checking SHOULD be done on both inbound and outbound processing.

8.3 Additional MLS Attributes for Security Association Databases

   Section 4.4 discussed two Security Association databases (the
   Security Policy Database (SPD) and the Security Association Database
   (SAD)) and the associated policy selectors and SA attributes.  MLS
   networking introduces an additional selector/attribute:

            - Sensitivity information.

   The Sensitivity information aids in selecting the appropriate
   algorithms and key strength, so that the traffic gets a level of
   protection appropriate to its importance or sensitivity as described
   in section 8.1.  The exact syntax of the sensitivity information is
   implementation defined.

8.4 Additional Inbound Processing Steps for MLS Networking

   After an inbound packet has passed through IPsec processing, an MLS
   implementation SHOULD first check the packet's sensitivity (as
   defined by the SA (or SA bundle) used for the packet) with the
   interface or address/prefix as described in section 8.2 before
   delivering the datagram to an next 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.





Kent                                                           [Page 47]


Internet Draft        Security Architecture for IP          October 2003


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.

8.6 Additional MLS Processing for Security Gateways

   An MLS security gateway MUST follow the previously mentioned inbound
   and outbound processing rules as well as perform some additional
   processing specific to the intermediate protection of packets in an
   MLS environment.

   A security gateway MAY act as an outbound proxy, creating SAs for MLS
   systems that originate packets forwarded by the gateway.  These MLS
   systems may explicitly label the packets to be forwarded, or the
   whole originating network may have sensitivity characteristics
   associated with it.  The security gateway MUST create and use
   appropriate SAs for AH, ESP, or both, to protect such traffic it
   forwards.

   Similarly such a gateway SHOULD accept and process inbound AH and/or
   ESP packets and forward appropriately, using explicit packet
   labeling, or relying on the sensitivity characteristics of the
   destination network.

9. Performance Issues [May change to reflect changes in [40],[44],[45]
processing model and [46] SA nesting/bundles.

   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.



Kent                                                           [Page 48]


Internet Draft        Security Architecture for IP          October 2003


   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.

   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 2401 [Will change]

   This architecture document differs substantially from RFC 2401 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


Kent                                                           [Page 49]


Internet Draft        Security Architecture for IP          October 2003


   requirements for supported combinations of AH and ESP are newly
   added, as are details of PMTU management.

Acknowledgements

   The author would like to acknowledge the contributions of Ran
   Atkinson, who played a critical role in initial IPsec activities, and
   who authored the first series of IPsec standards: RFCs 1825-1827.
   Karen Seo deserves special thanks for providing help in the editing
   of this and the previous version of this specification.  The author
   also would like to thank the members of the IPsec and MSEC working
   groups who have contributed to the development of this protocol
   specification.

   [For implementors using decorrelation, there may be an appendix with
   implementor's notes describing how to avoid creating any unnecessary
   SAs for a set of decorrelated SPD entries created from the same
   original correlated SPD entry when one or more selector values are
   populated from subscriber traffic.]































Kent                                                           [Page 50]


Internet Draft        Security Architecture for IP          October 2003


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


Internet Draft        Security Architecture for IP          October 2003


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


Internet Draft        Security Architecture for IP          October 2003


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


Internet Draft        Security Architecture for IP          October 2003


Appendix B -- Analysis/Discussion of PMTU/DF/Fragmentation Issues [May
be changed depending on decisions re: [78] PMTU handling]

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 [May change depending on decisions re: [78] PMTU
handling and community response to Mark DuffyØs proposed approach to
red-side fragmentation.  This assumes that ssues [49] & [81] red-side
fragmentation and handling outbound fragments] have been rejected by the
list.].fi

   If required, IP fragmentation occurs after IPsec processing within an
   IPsec implementation.  Thus, transport mode AH or ESP is applied only
   to whole IP datagrams (not to IP fragments).  An IP packet to which
   AH or ESP has been applied may itself be fragmented by routers en
   route, and such fragments MUST be reassembled prior to IPsec
   processing at a receiver.  In tunnel mode, AH or ESP is applied to an
   IP packet, the payload of which may be a fragmented IP packet.  For
   example, a security gateway, "bump-in-the-stack" (BITS), or "bump-in-
   the-wire" (BITW) IPsec implementation may apply tunnel mode AH to
   such fragments.  Note that BITS or BITW implementations are examples
   of where a host IPsec implementation might receive fragments to which
   tunnel mode is to be applied.  However, if transport mode is to be
   applied, then these implementations MUST reassemble the fragments
   prior to applying IPsec.


Kent                                                           [Page 54]


Internet Draft        Security Architecture for IP          October 2003


   NOTE: IPsec always has to figure out what the encapsulating IP header
   fields are.  This is independent of where you insert IPsec and is
   intrinsic to the definition of IPsec.  Therefore any IPsec
   implementation that is not integrated into an IP implementation must
   include code to construct the necessary IP headers (e.g., IP2):

         o AH-tunnel --> IP2-AH-IP1-Transport-Data
         o ESP-tunnel -->  IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer

    *********************************************************************

   Overall, the fragmentation/reassembly approach described above works
   for all cases examined.

                                 AH Xport   AH Tunnel  ESP Xport  ESP Tunnel
    Implementation approach      IPv4 IPv6  IPv4 IPv6  IPv4 IPv6  IPv4 IPv6
    -----------------------      ---- ----  ---- ----  ---- ----  ---- ----
    Hosts (integr w/ IP stack)     Y    Y     Y    Y     Y    Y     Y    Y
    Hosts (betw/ IP and drivers)   Y    Y     Y    Y     Y    Y     Y    Y
    S. Gwy (integr w/ IP stack)               Y    Y                Y    Y
    Outboard crypto processor *

         * If the crypto processor system has its own IP address, then it is
covered by the security gateway case.  This box receives the packet from the host
and performs IPsec processing.  It has to be able to handle the same AH, ESP, and
related IPv4/IPv6 tunnel processing that a security gateway would have to handle.
If it doesn't have it's own address, then it is similar to the bump-in-the stack
implementation between IP and the network drivers.

   The following analysis assumes that:

         1. There is only one IPsec module in a given system's stack.  There isn't
an IPsec module A (adding ESP/encryption and thus) hiding the transport protocol,
SRC port, and DEST port from IPsec module B.

         2. There are several places where IPsec could be implemented (as shown in
the table above).

                 a. Hosts with integration of IPsec into the native IP
implementation.  Implementer has access to the source for the stack.

                 b. Hosts with bump-in-the-stack implementations, where IPsec is
implemented between IP and the local network drivers.  Source access for stack is
not available; but there are well-defined interfaces that allows the IPsec code to
be incorporated into the system.

                 c. Security gateways and outboard crypto processors with
integration of IPsec into the stack.


Kent                                                           [Page 55]


Internet Draft        Security Architecture for IP          October 2003



         3. Not all of the above approaches are feasible in all hosts.  But it was
assumed that for each approach, there are some hosts for whom the approach is
feasible.

   For each of the above 3 categories, there are IPv4 and IPv6, AH
   transport and tunnel modes, and ESP transport and tunnel modes -- for
   a total of 24 cases (3 x 2 x 4).

   Some header fields and interface fields are listed here for ease of
   reference -- they're not in the header order, but instead listed to
   allow comparison between the columns.  (* = not covered by AH
   authentication.  ESP authentication doesn't cover any headers that
   precede it.)

                                                 IP/Transport Interface
                 IPv4            IPv6            (RFC 1122 -- Sec 3.4)
                 ----            ----            ----------------------
                 Version = 4     Version = 6
                 Header Len
                 *TOS            Class,Flow Lbl  TOS
                 Packet Len      Payload Len     Len
                 ID                              ID (optional)
                 *Flags                          DF
                 *Offset
                 *TTL            *Hop Limit      TTL
                 Protocol        Next Header
                 *Checksum
                 Src Address     Src Address     Src Address
                 Dst Address     Dst Address     Dst Address
                 Options?        Options?        Opt

                 ? = AH covers Option-Type and Option-Length, but might not cover
Option-Data.

   The results for each of the 20 cases is shown below ("works" = will
   work if system fragments after outbound IPsec processing, reassembles
   before inbound IPsec processing).  Notes indicate implementation
   issues.

     a. Hosts (integrated into IP stack)
           o AH-transport  --> (IP1-AH-Transport-Data)
                     - IPv4 -- works
                     - IPv6 -- works
           o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
                     - IPv4 -- works
                     - IPv6 -- works
           o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)


Kent                                                           [Page 56]


Internet Draft        Security Architecture for IP          October 2003


                     - IPv4 -- works
                     - IPv6 -- works
           o ESP-tunnel -->  (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
                     - IPv4 -- works
                     - IPv6 -- works

     b. Hosts (Bump-in-the-stack) -- put IPsec between IP layer and network
drivers.  In this case, the IPsec module would have to do something like one of
the following for fragmentation and reassembly.

             - do the fragmentation/reassembly work itself and send/receive the
packet directly to/from the network layer.  In AH or ESP transport mode, this is
fine.  In AH or ESP tunnel mode where the tunnel end is at the ultimate
destination, this is fine.  But in AH or ESP tunnel modes where the tunnel end is
different from the ultimate destination and where the source host is multi-homed,
this approach could result in sub-optimal routing because the IPsec module may be
unable to obtain the information needed (LAN interface and next-hop gateway) to
direct the packet to the appropriate network interface.  This is not a problem if
the interface and next-hop gateway are the same for the ultimate destination and
for the tunnel end.  But if they are different, then IPsec would need to know the
LAN interface and the next-hop gateway for the tunnel end.  (Note: The tunnel end
(security gateway) is highly likely to be on the regular path to the ultimate
destination.  But there could also be more than one path to the destination, e.g.,
the host could be at an organization with 2 firewalls.  And the path being used
could involve the less commonly chosen firewall.)  OR

             - pass the IPsec'd packet back to the IP layer where an extra IP
header would end up being pre-pended and the IPsec module would have to check and
let IPsec'd fragments go by.

                                     OR

             - pass the packet contents to the IP layer in a form such that the IP
layer recreates an appropriate IP header At the network layer, the IPsec module
will have access to the following selectors from the packet -- SRC address, DST
address, Next Protocol, and if there's a transport layer header --> SRC port and
DST port.  One cannot assume IPsec has access to the Name.  It is assumed that the
available selector information is sufficient to figure out the relevant Security
Policy entry and Security Association(s).

           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


Kent                                                           [Page 57]


Internet Draft        Security Architecture for IP          October 2003


                     - IPv6 -- works
           o ESP-tunnel -->  (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
                     - IPv4 -- works
                     - IPv6 -- works

     c. Security gateways -- integrate IPsec into the IP stack

        NOTE: The IPsec module will have access to the following selectors from
the packet -- SRC address, DST address, Next Protocol, and if there's a transport
layer header --> SRC port and DST port.  It won't have access to the User ID (only
Hosts have access to User ID information.)  Unlike some Bump-in-the-stack
implementations, security gateways may be able to look up the Source Address in
the DNS to provide a System Name, e.g., in situations involving use of dynamically
assigned IP addresses in conjunction with dynamically updated DNS entries.  It
also won't have access to the transport layer information if there is an ESP
header, or if it's not the first fragment of a fragmented message.  It is assumed
that the available selector information is sufficient to figure out the relevant
Security Policy entry and Security Association(s).

           o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
                     - IPv4 -- works
                     - IPv6 -- works
           o ESP-tunnel -->  (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
                     - IPv4 -- works
                     - IPv6 -- works

    **********************************************************************

B.3 Path MTU Discovery

   As mentioned earlier, "ICMP PMTU" refers to an ICMP message used for
   Path MTU Discovery.

   The legend for the diagrams below in B.3.1 and B.3.3 (but not B.3.2)
   is:















Kent                                                           [Page 58]


Internet Draft        Security Architecture for IP          October 2003


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


B.3.1 Identifying the Originating Host(s)

   The amount of information returned with the ICMP message is limited
   and this affects what selectors are available to identify security
   associations, originating hosts, etc. for use in further propagating
   the PMTU information.

   In brief...  An ICMP message must contain the following information
   from the "offending" packet:
         - IPv4 (RFC 792) --  IP header plus a minimum of 64 bits

   Accordingly, in the IPv4 context, an ICMP PMTU may identify only the
   first (outermost) security association.  This is because the ICMP
   PMTU may contain only 64 bits of the "offending" packet beyond the IP
   header, which would capture only the first SPI from AH or ESP.  In
   the IPv6 context, an ICMP PMTU will probably provide all the SPIs and
   the selectors in the IP header, but maybe not the SRC/DST ports (in
   the transport header) or the encapsulated (TCP, UDP, etc.) protocol.
   Moreover, if ESP is used, the transport ports and protocol selectors
   may be encrypted.

   Looking at the diagram below of a security gateway tunnel (as
   mentioned elsewhere, security gateways do not use transport mode)...






Kent                                                           [Page 59]


Internet Draft        Security Architecture for IP          October 2003


         H1   ===================           H3
           \  |                 |          /
       H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
           /  ^        |                   \
         H2   |........|                    H4


   Suppose that the security policy for SG1 is to use a single SA to SG2
   for all the traffic between hosts H0, H1, and H2 and hosts H3, H4,
   and H5.  And suppose H0 sends a data packet to H5 which causes R1 to
   send an ICMP PMTU message to SG1.  If the PMTU message has only the
   SPI, SG1 will be able to look up the SA and find the list of possible
   hosts (H0, H1, H2, wildcard); but SG1 will have no way to figure out
   that H0 sent the traffic that triggered the ICMP PMTU message.

         original        after IPsec     ICMP
         packet          processing      packet
         --------        -----------     ------
                                         IP-3 header (S = R1, D = SG1)
                                         ICMP header (includes PMTU)
                         IP-2 header     IP-2 header (S = SG1, D = SG2)
                         ESP header      minimum of 64 bits of ESP hdr (*)
         IP-1 header     IP-1 header
         TCP header      TCP header
         TCP data        TCP data
                         ESP trailer

         (*) The 64 bits will include enough of the ESP (or AH) header to include
the SPI.
                 - ESP -- SPI (32 bits), Seq number (32 bits)
                 - AH -- Next header (8 bits), Payload Len (8 bits), Reserved (16
bits), SPI (32 bits)


   This limitation on the amount of information returned with an ICMP
   message creates a problem in identifying the originating hosts for
   the packet (so as to know where to further propagate the ICMP PMTU
   information).  If the ICMP message contains only 64 bits of the IPsec
   header (minimum for IPv4), then the IPsec selectors (e.g., Source and
   Destination addresses, Next Protocol, Source and Destination ports,
   etc.) will have been lost.  But the ICMP error message will still
   provide SG1 with the SPI, the PMTU information and the source and
   destination gateways for the relevant security association.

   The destination security gateway and SPI uniquely define a security
   association which in turn defines a set of possible originating
   hosts.  At this point, SG1 could:



Kent                                                           [Page 60]


Internet Draft        Security Architecture for IP          October 2003


    a. send the PMTU information to all the possible originating hosts.  This
would not work well if the host list is a wild card or if many/most of the hosts
weren't sending to SG1; but it might work if the SPI/destination/etc mapped to
just one or a small number of hosts.

    b. store the PMTU with the SPI/etc and wait until the next packet(s) arrive
from the originating host(s) for the relevant security association.  If it/they
are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s)
with the new packet(s) and the updated PMTU, and send the originating host(s) the
ICMP message(s) about the problem.  This involves a delay in notifying the
originating host(s), but avoids the problems of (a).


   Since only the latter approach is feasible in all instances, a
   security gateway MUST provide such support, as an option.  However,
   if the ICMP message contains more information from the original
   packet, then there may be enough information to immediately determine
   to which host to propagate the ICMP/PMTU message and to provide that
   system with the 5 fields (source address, destination address, source
   port, destination port, and transport protocol) needed to determine
   where to store/update the PMTU.  Under such circumstances, a security
   gateway MUST generate an ICMP PMTU message immediately upon receipt
   of an ICMP PMTU from further down the path.  NOTE: The Next Protocol
   field may not be contained in the ICMP message and the use of ESP
   encryption may hide the selector fields that have been encrypted.

B.3.2 Calculation of PMTU

   The calculation of PMTU from an ICMP PMTU has to take into account
   the addition of any IPsec header by H1 -- AH and/or ESP transport, or
   ESP or AH tunnel.  Within a single host, multiple applications may
   share an SPI and nesting of security associations may occur.  (See
   Section 4.5 Basic Combinations of Security Associations for
   description of the combinations that MUST be supported).  The diagram
   below illustrates an example of security associations between a pair
   of hosts (as viewed from the perspective of one of the hosts.)  (ESPx
   or AHx = transport mode)

            Socket 1 -------------------------|
                                              |
            Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet

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





Kent                                                           [Page 61]


Internet Draft        Security Architecture for IP          October 2003


B.3.3 Granularity of Maintaining PMTU Data

   In hosts, the granularity with which PMTU ICMP processing can be done
   differs depending on the implementation situation.  Looking at a
   host, there are three situations that are of interest with respect to
   PMTU issues:

    a. Integration of IPsec into the native IP implementation

    b. Bump-in-the-stack implementations, where IPsec is implemented "underneath"
an existing implementation of a TCP/IP protocol stack, between the native IP and
the local network drivers

    c. No IPsec implementation -- This case is included because it is relevant in
cases where a security gateway is sending PMTU information back to a host.

   Only in case (a) can the PMTU data be maintained at the same
   granularity as communication associations.  In the other cases, the
   IP layer will maintain PMTU data at the granularity of Source and
   Destination IP addresses (and optionally TOS/Class), as described in
   RFC 1191.  This is an important difference, because more than one
   communication association may map to the same source and destination
   IP addresses, and each communication association may have a different
   amount of IPsec header overhead (e.g., due to use of different
   transforms or different algorithms).  The examples below illustrate
   this.

   In cases (a) and (b)...  Suppose you have the following situation.
   H1 is sending to H2 and the packet to be sent from R1 to R2 exceeds
   the PMTU of the network hop between them.

                  ==================================
                  |                                |
                 H1* --- R1 ----- R2 ---- R3 ---- H2*
                  ^       |
                  |.......|

   If R1 is configured to not fragment subscriber traffic, then R1 sends
   an ICMP PMTU message with the appropriate PMTU to H1.  H1's
   processing would vary with the nature of the implementation.  In case
   (a) (native IP), the security services are bound to sockets or the
   equivalent.  Here the IP/IPsec implementation in H1 can store/update
   the PMTU for the associated socket.  In case (b), the IP layer in H1
   can store/update the PMTU but only at the granularity of Source and
   Destination addresses and possibly TOS/Class, as noted above.  So the
   result may be sub- optimal, since the PMTU for a given
   SRC/DST/TOS/Class will be the subtraction of the largest amount of
   IPsec header used for any communication association between a given


Kent                                                           [Page 62]


Internet Draft        Security Architecture for IP          October 2003


   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.

                          ================
                          |              |
                 H1 ---- SG1* --- R --- SG2* ---- H2
                  ^       |
                  |.......|

   As described above for case (b), the IP layer in H1 can store/update
   the PMTU but only at the granularity of Source and Destination
   addresses, and possibly TOS/Class.  So the result may be sub-optimal,
   since the PMTU for a given SRC/DST/TOS/Class will be the subtraction
   of the largest amount of IPsec header used for any communication
   association between a given source and destination.

B.3.4 Per Socket Maintenance of PMTU Data

   Implementation of the calculation of PMTU (Section B.3.2) and support
   for PMTUs at the granularity of individual "communication
   associations" (Section B.3.3) is a local matter.  However, a socket-
   based implementation of IPsec in a host SHOULD maintain the
   information on a per socket basis.  Bump in the stack systems MUST
   pass an ICMP PMTU to the host IP implementation, after adjusting it
   for any IPsec header overhead added by these systems.  The
   determination of the overhead SHOULD be determined by analysis of the
   SPI and any other selector information present in a returned ICMP
   PMTU message.

B.3.5 Delivery of PMTU Data to the Transport Layer

   The host mechanism for getting the updated PMTU to the transport
   layer is unchanged, as specified in RFC 1191 (Path MTU Discovery).

B.3.6 Aging of PMTU Data

   This topic is covered in Section 6.1.2.4.









Kent                                                           [Page 63]


Internet Draft        Security Architecture for IP          October 2003


Appendix C -- Sequence Space Window Code Example [Will change to reflect
ESN mod to AH and ESP]


   This appendix contains a routine that implements a bitmask check for
   a 32 packet window.  It was provided by James Hughes
   (jim_hughes@stortek.com) and Harry Varnis (hgv@anubis.network.com)
   and is intended as an implementation example.  Note that this code
   both checks for a replay and updates the window.  Thus the algorithm,
   as shown, should only be called AFTER the packet has been
   authenticated.  Implementers might wish to consider splitting the
   code to do the check for replays before computing the ICV.  If the
   packet is not a replay, the code would then compute the ICV, (discard
   any bad packets), and if the packet is OK, update the window.

#include <stdio.h>
#include <stdlib.h>
typedef unsigned long u_long;

enum {
     ReplayWindowSize = 32
};

u_long bitmap = 0;                      /* session state - must be 32 bits */
u_long lastSeq = 0;                     /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
     u_long diff;

     if (seq == 0) return 0;             /* first == 0 or wrapped */
     if (seq > lastSeq) {                /* new larger sequence number */
         diff = seq - lastSeq;
         if (diff < ReplayWindowSize) {  /* In window */
             bitmap <<= diff;
             bitmap |= 1;                /* set bit for this packet */
         } else bitmap = 1;              /* This packet has a "way larger" */
         lastSeq = seq;
         return 1;                       /* larger is good */
     }
     diff = lastSeq - seq;
     if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
     if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
     bitmap |= ((u_long)1 << diff);              /* mark as seen */
     return 1;                           /* out of order but good */
}


Kent                                                           [Page 64]


Internet Draft        Security Architecture for IP          October 2003



char string_buffer[512];
#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                                                           [Page 65]

Internet Draft        Security Architecture for IP          October 2003


Appendix D -- Categorization of ICMP messages

   The tables below characterize ICMP messages as being either host
   generated, router generated, both, unassigned/unknown.  The first set
   are IPv4.  The second set are IPv6.

                                    IPv4

   Type    Name/Codes                                             Reference
   ========================================================================
   HOST GENERATED:
      3     Destination Unreachable
             2  Protocol Unreachable                               [RFC792]
             3  Port Unreachable                                   [RFC792]
             8  Source Host Isolated                               [RFC792]
            14  Host Precedence Violation                         [RFC1812]
     10     Router Selection                                      [RFC1256]

   Type    Name/Codes                                             Reference
   ========================================================================
   ROUTER GENERATED:
      3     Destination Unreachable
             0  Net Unreachable                                    [RFC792]
             4  Fragmentation Needed, Don't Fragment was Set       [RFC792]
             5  Source Route Failed                                [RFC792]
             6  Destination Network Unknown                        [RFC792]
             7  Destination Host Unknown                           [RFC792]
             9  Comm. w/Dest. Net. is Administratively Prohibited  [RFC792]
            11  Destination Network Unreachable for Type of Service[RFC792]
      5     Redirect
             0  Redirect Datagram for the Network (or subnet)      [RFC792]
             2  Redirect Datagram for the Type of Service & Network[RFC792]
      9     Router Advertisement                                  [RFC1256]
     18     Address Mask Reply                                     [RFC950]
















Kent                                                           [Page 66]

Internet Draft        Security Architecture for IP          October 2003


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

Internet Draft        Security Architecture for IP          October 2003


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


Internet Draft        Security Architecture for IP          October 2003


References [Will be updated after the text settles down]

Normative

   [Bra97]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Level", BCP 14, RFC 2119, March 1997.

   [DH98]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

             [HC03]    Holbrook, H., and Cain, B., "Source Specific
             Multicast for IP", Internet Draft, draft-ietf-ssm-
             arch-01.txt, November 3, 2002.

   [Kau04]   Kaufman, C., "The Internet Key Exchange (IKEv2)", RFC ???,
             ??? 2004

   [Ken04a]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
             ???, ???? 2004.

   [Ken04b]  Kent, S., "IP Authentication Header", RFC ???, ??? 2004.

   [Mobip]   Johnson, D., Perkins, C., Arkko, J., "Mobility Support in
             IPv6", Internet Draft, draft-ietf-mobileip-ipv6-24.txt,
             June 2003

   [Pos81]   Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981

Informative

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

   [DoD85]   US National Computer Security Center, "Department of
             Defense Trusted Computer System Evaluation Criteria", DoD
             5200.28-STD, US Department of Defense, Ft. Meade, MD.,
             December 1985.

   [DoD87]   US National Computer Security Center, "Trusted Network
             Interpretation of the Trusted Computer System Evaluation
             Criteria", NCSC-TG-005, Version 1, US Department of
             Defense, Ft. Meade, MD., 31 July 1987.

   [HA94]    Haller, N., and R. Atkinson, "On Internet Authentication",
             RFC 1704, October 1994.



Kent                                                           [Page 69]


Internet Draft        Security Architecture for IP          October 2003



   [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

   [Ken91]   Kent, S., "US DoD Security Options for the Internet
             Protocol", RFC 1108, November 1991.

   [MSST97]  Maughan, D., Schertler, M., Schneider, M., and J. Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP)", RFC 2408, November 1998.

   [Orm97]   Orman, H., "The OAKLEY Key Determination Protocol", RFC
             2412, November 1998.

   [Pip98]   Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMP", RFC 2407, November 1998.

   [Sch94]   Bruce Schneier, Applied Cryptography, Section 8.6, John
             Wiley & Sons, New York, NY, 1994.

   [SDNS]    SDNS Secure Data Network System, Security Protocol 3, SP3,
             Document SDN.301, Revision 1.5, 15 May 1989, published in
             NIST Publication NIST-IR-90-4250, February 1990.

   [SMPT98]  Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
             Payload Compression Protocol (IPComp)", RFC 2393, August
             1998.

   [TDG97]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
             Document Roadmap", RFC 2411, November 1998.

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






Kent                                                           [Page 70]


Internet Draft        Security Architecture for IP          October 2003


Author Information

   Stephen Kent
   BBN Corporation
   70 Fawcett Street
   Cambridge, MA  02140
   USA

   Phone: +1 (617) 873-3988
   EMail: kent@bbn.com


Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards- related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

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


Kent                                                           [Page 71]


Internet Draft        Security Architecture for IP          October 2003


   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires April 2004





































Kent                                                           [Page 72]


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