[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                                                    K. Seo
draft-ietf-ipsec-rfc2401bis-02.txt                      BBN Technologies
Obsoletes: RFC 2401                                           April 2004
Expires October 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/1id-abstracts.html

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

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



















Kent & Seo                                                      [Page 1]


Internet Draft        Security Architecture for IP            April 2004


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.................................................9
        3.3 Where IPsec May Be Implemented.................................10
    4. Security Associations...............................................11
        4.1 Definition and Scope...........................................11
        4.2 Security Association Functionality.............................15
        4.3 Combining Security Associations................................16
        4.4 Major IPsec Databases..........................................16
           4.4.1 The Security Policy Database (SPD)........................19
              4.4.1.1 Selectors............................................24
              4.4.1.2 Structure of an SPD entry............................27
           4.4.2 Security Association Database (SAD).......................29
        4.5 SA and Key Management..........................................35
           4.5.1 Manual Techniques.........................................35
           4.5.2 Automated SA and Key Management...........................36
           4.5.3 Locating a Security Gateway...............................37
        4.6 Security Associations and Multicast............................38
    5. IP Traffic Processing...............................................38
        5.1 Outbound IP Traffic Processing (protected-to-unprotected)......39
           5.1.1 Handling an Outbound Packet That Must Be Discarded........41
           5.1.2 Header Construction for Tunnel Mode.......................42
              5.1.2.1 IPv4 -- Header Construction for Tunnel Mode..........43
              5.1.2.2 IPv6 -- Header Construction for Tunnel Mode..........45
        5.2 Processing Inbound IP Traffic (unprotected-to-protected).......45
    6. ICMP Processing ....................................................49
    7. Handling Fragments (on the protected side of the IPsec boundary)....49
    8. Auditing............................................................51
    9. Conformance Requirements............................................52
    10. Security Considerations............................................52
    11. Differences from RFC 2401..........................................52
    Acknowledgements.......................................................57
    Appendix A -- Glossary.................................................58
    Appendix B -- Decorrelation............................................61
    Appendix C -- Categorization of ICMP messages [May be deleted].........64
    Appendix D -- ASN.1 for an SPD entry...................................67
    Appendix E -- Fragment Handling Rationale..............................72
    References.............................................................73
    Author Information.....................................................74


Kent & Seo                                                      [Page 2]


Internet Draft        Security Architecture for IP            April 2004


    Notices................................................................77

















































Kent & Seo                                                      [Page 3]


Internet Draft        Security Architecture for IP            April 2004


1. Introduction

1.1 Summary of Contents of Document

    This document specifies the base architecture for IPsec compliant
    systems.  It describes how to provide a set of security services for
    traffic at the IP layer, in both the IPv4 and IPv6 environments.
    This document describes the requirements for systems that implement
    IPsec, the fundamental elements of such systems, and how the elements
    fit together and fit 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 the IPsec architecture. Other documents
    address additional architectural details in specialized environments,
    e.g., use of IPsec in NAT environments and more comprehensive support
    for IP multicast.  The 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 automated (The Internet Key
            Exchange (IKE))
         d. Cryptographic algorithms for authentication and encryption

    This document is not a 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 used throughout this and all
    related IPsec standards.  All other capitalizations of IPsec (e.g.,
    IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of
    the sequence of letters "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 is primarily individuals who
    implement this IP security technology or who architect systems that
    will use this technology.  Technically adept users of this technology
    (end users or system administrators) also are part of the target


Kent & Seo                                                      [Page 4]


Internet Draft        Security Architecture for IP            April 2004


    audience.  A glossary is provided in Appendix A to help fill in gaps
    in background/vocabulary.  This document assumes that the reader is
    familiar with the Internet Protocol (IP), related networking
    technology, and general information system 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. security protocols -- RFCs describing the Authentication Header
            (AH) [Ken04b] and Encapsulating Security Payload (ESP) [Ken04a]
            protocols.
         b. cryptographic algorithms for integrity and encryption -- one RFC
            that defines the mandatory, default algorithms for use with AH
            and ESP [Eas03], a similar RFC that defines the mandatory
            algorithms for use with IKEv2 [Sch03] plus a separate RFC for
            each cryptographic algorithm.
         c. automatic key management -- RFCs on "The Internet Key Exchange
            (IKEv2) Protocol" [Kau03] and "Cryptographic Algorithms for use
            in the Internet Key Exchange Version 2" [Sch03]


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, detection and rejection of
    replays (a form of partial sequence integrity), confidentiality (via
    encryption), and limited traffic flow confidentiality.  These
    services are provided at the IP layer, offering protection for all
    protocols that may be carried over IP in a standard fashion
    (including IP itself).

    IPsec includes a specification for minimal firewall functionality,
    since that is an essential aspect of access control at the IP layer.
    Implementations are free to provide more sophisticated firewall
    mechanisms, and to implement the IPsec-mandated functionality using
    those more sophisticated mechanisms. (Note that interoperability may
    suffer if additional firewall constraints on traffic flows are
    imposed by an IPsec implementation but cannot be negotiated based on
    the traffic selector features defined in this document and negotiated
    via IKEv2.) The IPsec firewall function makes use of the


Kent & Seo                                                      [Page 5]


Internet Draft        Security Architecture for IP            April 2004


    cryptographically-enforced authentication and integrity provided for
    all IPsec traffic to offer better access control than could be
    obtained through use of a firewall (one not privy to IPsec internal
    parameters) plus separate cryptographic protection.

    Most of the security services are provided through 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 a context, and the ways in which they are
    employed, will be determined by the users/administrators in that
    context. It is the goal of the IPsec architecture to ensure that
    compliant implementations include the services and management
    interfaces needed to meet the security requirements of a broad user
    population.

    When IPsec is correctly implemented and deployed, it ought not
    adversely affect users, hosts, and other Internet components that do
    not employ IPsec for traffic protection.  IPsec security protocols
    (AH & ESP, and to a lesser extent, IKE) are designed to be
    cryptographic algorithm-independent.  This modularity permits
    selection of different sets of cryptographic algorithms as
    appropriate, without affecting the other parts of the implementation.
    For example, different user communities may select different sets of
    cryptographic algorithms (creating cryptographically-enforced
    cliques) if required.

    A set of default cryptographic algorithms for use with AH and ESP is
    specified [Eas03] to facilitate interoperability in the global
    Internet.  The use of these cryptographic 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 cryptographic
    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


Kent & Seo                                                      [Page 6]


Internet Draft        Security Architecture for IP            April 2004


    IPsec implementation executes.  For example, defects in OS security,
    poor quality of random number sources, sloppy system management
    protocols and practices, etc. can all degrade the security provided
    by IPsec.  As above, none of these environmental attributes are
    within the scope of this or other IPsec standards.

3. System Overview

    This section provides a high level description of how IPsec works,
    the components of the system, and how they fit together to provide
    the security services noted above.  The goal of this description is
    to enable the reader to "picture" the overall process/system, see how
    it fits into the IP environment, and to provide context for later
    sections of this document, which describe each of the components in
    more detail.

    An IPsec implementation operates in a host, as a security gateway, or
    as an independent device, affording protection to IP traffic. (A
    security gateway is an intermediate system implementing IPsec, e.g.,
    a firewall or router that has been IPsec-enabled.) More detail on
    these classes of implementations is provided later, in Section 3.3.
    The protection offered by IPsec 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 next
    layer header information (Selectors, Section 4.4.1.1) matched against
    entries in the database (SPD).  Each packet is either PROTECTed using
    IPsec security services, DISCARDed, or allowed to BYPASS IPsec
    protection, based on the applicable SPD policies identified by the
    Selectors.


3.1 What IPsec Does

    IPsec creates a boundary between unprotected and protected
    interfaces, for a host or a network (see Figure 1 below). Traffic
    traversing the boundary is subject to the access controls specified
    by the user or administrator responsible for the IPsec configuration.
    These controls indicate whether packets cross the boundary unimpeded,
    are afforded security services via AH or ESP, or are discarded. IPsec
    security services are offered at the IP layer through selection of
    appropriate security protocols, cryptographic algorithms, and
    cryptographic keys.  IPsec can be used to protect one or more "paths"
    (a) between a pair of hosts, (b) between a pair of security gateways,
    or (c) between a security gateway and a host. A compliant host
    implementation MUST support (a) and (c) and a compliant security
    gateway must support all three of these forms of connectivity, since


Kent & Seo                                                      [Page 7]


Internet Draft        Security Architecture for IP            April 2004


    under certain circumstances a security gateway acts as a host.

                         Unprotected
                          ^       ^
                          |       |
            +-------------|-------|-------+
            | +-------+   |       |       |
            | |Discard|<--|       V       |
            | +-------+   |B  +--------+  |
          ................|y..| AH/ESP |..... IPsec Boundary
            |   +---+     |p  +--------+  |
            |   |IKE|<----|a      ^       |
            |   +---+     |s      |       |
            | +-------+   |s      |       |
            | |Discard|<--|       |       |
            | +-------+   |       |       |
            +-------------|-------|-------+
                          |       |
                          V       V
                          Protected

             Figure 1.  Top Level IPsec Processing Model


    In this diagram, "unprotected" refers to an interface that might also
    be described as "black" or "ciphertext." Here, "protected" refers to
    an interface that might also be described as "red" or "plaintext."
    The protected interface noted above may be internal, e.g., in a host
    implementation of IPsec, the protected interface may link to a socket
    layer interface presented by the OS. In this document, the term
    "inbound" refers to traffic entering an IPsec implementation via the
    unprotected interface. The term "outbound" refers to traffic entering
    the implementation via the protected interface, or emitted by the
    implementation on the protected side of the boundary and directed
    toward the unprotected interface.  An IPsec implementation may
    support more than one interface on either or both sides of the
    boundary.

    Note the facilities for discarding traffic on either side of the
    IPsec boundary, the BYPASS facility that allows traffic to transit
    the boundary without cryptographic protection, and the reference to
    IKE as a protected-side key and security management function.

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



Kent & Seo                                                      [Page 8]


Internet Draft        Security Architecture for IP            April 2004


3.2 How IPsec Works

    IPsec uses two protocols to provide traffic security services --
    Authentication Header (AH) and Encapsulating Security Payload (ESP).
    Both protocols are described in detail in their respective RFCs
    [Ken04b, Ken04a]. IPsec implementations MUST support ESP and MAY
    support AH. (Support for AH has been downgraded to MAY because
    experience has shown that there are very few contexts in which ESP
    cannot provide the requisite security services. Note that ESP can be
    used to provide only integrity, without confidentiality, making it
    comparable to AH in most contexts.)

     o The IP Authentication Header (AH) [Ken04b] offers integrity and
       data origin authentication, with optional (at the discretion of
       the receiver) anti-replay features.

     o The Encapsulating Security Payload (ESP) protocol [Ken04a] offers
       the same set of services, and also offers confidentially. Use of
       ESP in a confidentiality-only mode is discouraged. When ESP is
       used with confidentiality enabled, there are provisions for
       limited traffic flow confidentiality, i.e., provisions for
       concealing packet length, and to facilitate efficient generation
       and discard of dummy packets. This capability is likely to be
       effective primarily in VPN and overlay network contexts.

     o Both AH and ESP offer access control, enforced through the
       distribution of cryptographic keys and the management of traffic
       flows as dictated by the Security Policy Database (SPD, Section
       4.4.1).

    These protocols may be applied individually or in combination with
    each other to provide security services in IPv4 and IPv6. However,
    most security requirements can be met through the use of ESP by
    itself.  Each protocol supports two modes of use: transport mode and
    tunnel mode.  In transport mode, AH and ESP provide protection
    primarily for next layer protocols; in tunnel mode, AH and ESP are
    applied to tunneled IP packets.  The differences between the two
    modes are discussed in Section 4.1.

    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, through the SPD management paradigm,
    incorporates facilities for specifying:

     o which security protocols (AH, ESP) to employ, their mode


Kent & Seo                                                      [Page 9]


Internet Draft        Security Architecture for IP            April 2004


       (transport or tunnel), security service options, what
       cryptographic algorithms to use, and in what combinations to use
       the specified protocols and services,
     o the granularity at which protection should be applied.

    Because most of the security services provided by IPsec require the
    use of cryptographic keys, IPsec relies on a separate set of
    mechanisms for putting these keys in place. This document requires
    support for both manual and automated distribution of keys.  It
    specifies a specific public-key based approach (IKEv2 [KAU04]) for
    automated key management, but other automated key distribution
    techniques MAY be used.

    Note: This document mandates support for several features for which
    support is available in IKEv2 but not in IKEv1, e.g., negotiation of
    an SA representing ranges of local and remote ports or negotiation of
    multiple SAs with the same selectors. Therefore this document assumes
    use of IKEv2 or a key and security association management system with
    comparable features.

3.3 Where IPsec Can Be Implemented

    There are many ways in which IPsec may be implemented in a host, or
    in conjunction with a router or firewall to create a security
    gateway, or as an independent security device.

    a. IPsec may be integrated into the native IP stack.  This requires
       access to the IP source code and is applicable to both hosts and
       security gateways, although native host implementations benefit
       the most from this strategy, as explained later (Section 4.4.1,
       paragraph 6; Section 4.4.1.1, last paragraph).

    b. In a "bump-in-the-stack" (BITS) implementation, 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 a dedicated, inline security protocol processor is a
       common design feature of 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.  Usually the
       BITW device is itself 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


Kent & Seo                                                     [Page 10]


Internet Draft        Security Architecture for IP            April 2004


       gateway.

    This document often talks in terms of host or security gateway use of
    IPsec, without regard to whether the implementation is native, BITS
    or BITW. When the distinctions among these implementation options are
    significant, the document makes reference to specific implementation
    approaches.

4. Security Associations

    This section defines Security Association management requirements for
    all IPv6 implementations and for those IPv4 implementations that
    implement AH, ESP, or both AH and ESP.  The concept of a "Security
    Association" (SA) is fundamental to IPsec.  Both AH and ESP make use
    of SAs and a major function of IKE is the establishment and
    maintenance of Security Associations.  All implementations of AH or
    ESP MUST support the concept of a Security Association as described
    below.  The remainder of this section describes various aspects of
    Security Association management, defining required characteristics
    for SA policy management and SA management techniques.

4.1 Definition and Scope

    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 are applied to a traffic stream,
    then two SAs must be created and coordinated to effect protection
    through iterated application of the security protocols.  To secure
    typical, bi-directional communication between two IPsec-enabled
    systems, a pair of Security Associations (one in each direction) are
    required. IKE explicitly creates SA pairs in recognition of this
    common usage requirement.

    For an SA used to carry unicast (or anycast) traffic, the SPI
    (Security Parameters Index - see Appendix A and AH [Ken04b] and ESP
    [Ken04a] specifications) by itself suffices to specify an SA.
    However, as a local matter, an implementation may choose to use the
    SPI in conjunction with the IPsec protocol type (AH or ESP) for SA
    identification. If an IPsec implementation supports multicast, then
    it MUST support  multicast SAs using the algorithm below for mapping
    inbound IPsec datagrams to SAs. Implementations that support only
    unicast traffic need not implement this demultiplexing algorithm.

    In many secure multicast architectures, e.g., [RFC3740], a central
    Group Controller/Key Server unilaterally assigns the group security
    association's SPI.  This SPI assignment is not negotiated or
    coordinated with the key management (e.g., IKE) subsystems that
    reside in the individual end systems that comprise the group.


Kent & Seo                                                     [Page 11]


Internet Draft        Security Architecture for IP            April 2004


    Consequently, it is possible that a group security association and a
    unicast security association can simultaneously use the same SPI. A
    multicast-capable IPsec implementation MUST correctly de-multiplex
    inbound traffic even in the context of SPI collisions.

    Each entry in the Security Association Database (SAD) [Section 4.4.2]
    must indicate whether the SA lookup makes use of the destination, or
    destination and source, IP addresses, in addition to the SPI. For
    multicast SAs, the protocol field is not employed for SA lookups. For
    each inbound, IPsec-protected packet, an implementation must conduct
    its search of the SAD such that it finds the entry that matches the
    "longest" SA identifier. In this context, if two or more SAD entries
    match based on the SPI value, then the entry that also matches based
    on destination, or destination and source, address comparison (as
    indicated in the SAD entry) is the "longest" match. This implies a
    logical ordering of the SAD search as follows:


       1. Search the SAD for a match on {SPI, destination address, source
          address}. If a SAD entry matches then process the inbound ESP
          packet with that matching SAD entry. Otherwise, proceed to step
          2.

       2. Search the SAD for a match on {SPI, destination address}. If the
          SAD entry matches then process the inbound ESP packet with that
          matching SAD entry. Otherwise, proceed to step 3.

       3. Search the SAD for a match on only {SPI} if the receiver has
          chosen to maintain a single SPI space for AH and ESP, and on
          {SPI, protocol} otherwise. If an SAD entry matches then process
          the inbound ESP packet with that matching SAD entry. Otherwise,
          discard the packet and log an auditable event.


    In practice, an implementation MAY choose any method to accelerate
    this search, although its externally visible behavior MUST be
    functionally equivalent to having searched the SAD in the above
    order. For example, a software-based implementation could index into
    a hash table by the SPI. The SAD entries in each hash table bucket's
    linked list are kept sorted to have those SAD entries with the
    longest SA identifiers first in that linked list. Those SAD entries
    having the shortest SA identifiers are sorted so that they are the
    last entries in the linked list. A hardware-based implementation may
    be able to effect the longest match search intrinsically, using
    commonly available TCAM features.

    The indication of whether source and destination address matching is
    required to map inbound IPsec traffic to SAs MUST be set either as a


Kent & Seo                                                     [Page 12]


Internet Draft        Security Architecture for IP            April 2004


    side effect of manual SA configuration or via negotiation using an SA
    management protocol, e.g., IKE or GDOI [RFC3547]. Typically, Source-
    Specific Multicast (SSM) [HC03] groups use a 3-tuple SA identifier
    composed of an SPI, a destination multicast address, and source
    address. An Any-Source Multicast group SA requires only an SPI and a
    destination multicast address as an identifier.

    If different classes of traffic (distinguished by DSCP bits
    [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver
    is employing the optional anti-replay feature available in both AH
    and ESP, this could result in inappropriate discarding of lower
    priority packets due to the windowing mechanism used by this feature.
    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 by IKE. The receiver MUST process the packets
    from the different SAs without prejudice.

    DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and ECN [RaFlBL01]
    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 "classifier".

    As noted above, two types of SAs are defined: transport mode and
    tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose
    to require that both SAs in a pair be of the same mode, transport or
    tunnel.

    A transport mode SA is a security association typically employed
    between a pair of hosts to provide end-to-end security services. When
    security is desired between two intermediate systems along a path
    (vs. end-to-end use of IPsec), transport mode MAY be used between
    security gateways or between a security gateway and a host.  In the
    latter case, transport mode may be used to support in-IP tunneling
    (e.g., IP-in-IP [Per96] or GRE tunneling [FaLiHaMeTr00]) over
    transport mode SAs. To further clarify, the use of transport mode by
    an intermediate system (e.g., a security gateway) is permitted only
    when applied to packets whose source address (for outbound packets)
    or destination address (for inbound packets) is an address belonging
    to the intermediate system itself. The access control functions that
    are an important part of IPsec are significantly limited in this
    context, as they cannot be applied to the end-to-end headers of the
    packets that traverse a transport mode SA used in this fashion. Thus
    this way of using transport mode should be evaluated carefully before


Kent & Seo                                                     [Page 13]


Internet Draft        Security Architecture for IP            April 2004


    being employed in a specific context.

    In IPv4, a transport mode security protocol header appears
    immediately after the IP header and any options, and before any next
    layer protocols (e.g., TCP or UDP).  In IPv6, the security protocol
    header appears after the base IP header and selected extension
    headers, but may appear before or after destination options; it MUST
    appear before next layer protocols (e.g., TCP, UDP, SCTP).  In the
    case of ESP, a transport mode SA provides security services only for
    these next 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 preceding it,
    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 [Ken04b].

    A tunnel mode SA is essentially an SA applied to an IP tunnel, with
    the access controls applied to the headers of the traffic inside the
    tunnel.  Two hosts MAY establish a tunnel mode SA between themselves.
    Aside from the two exceptions below, 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.  The two
    exceptions are as follows.

     o 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.  In this case, the SA terminates at a host
       (management) function within a security gateway and thus merits
       different treatment.

     o As noted above, security gateways MAY support a transport mode SA
       to provide security for IP traffic between two systems along a
       path, e.g., between a host and a security gateway or between two
       security gateways.

    Several concerns motivate the use of tunnel mode for an SA involving
    a security gateway. For example, if there are multiple paths (e.g.,
    via different security gateways) to the same destination behind
    multiple security gateways, it is important that an IPsec packet be
    sent to the security gateway with which the SA was negotiated.
    Similarly, a packet that might be fragmented en-route must have all
    the fragments delivered to the same IPsec instance for reassembly
    prior to cryptographic processing. Also, when a fragment is processed
    by IPsec and transmitted, then fragmented en-route, it is critical
    that there be inner and outer headers to retain the fragmentation
    state data for the pre- and post-IPsec packet formats. Hence there


Kent & Seo                                                     [Page 14]


Internet Draft        Security Architecture for IP            April 2004


    are several reasons for employing tunnel mode when either end of an
    SA is a security gateway.

    Note: AH and ESP cannot be applied using transport mode to IPv4
    packets that are fragments. Only tunnel mode can be employed in such
    cases. For IPv6, it would be feasible to carry a plaintext fragment
    on a transport mode SA; however, for simplicity, this restriction
    also applies to IPv6 packets.  See Section 7 for more details on
    handling plaintext fragments on the protected side of the IPsec
    barrier.

    For a tunnel mode SA, there is an "outer" IP header that specifies
    the IPsec processing source and destination, plus an "inner" IP
    header that specifies the (apparently) ultimate source and
    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 next 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 implementation of IPsec MUST support both transport and
       tunnel mode. This is true for native, BITS, and BITW
       implementations for hosts.

    b) A security gateway MUST support tunnel mode and 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 security between two
       intermediate systems along a path.

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, both AH and ESP offer integrity and authentication
    services, but the coverage differs for each protocol and differs for
    transport vs. tunnel mode. 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 mutable (non-
    predictable) parts of the IP or extension headers. However, the same
    security may be achieved in some contexts by applying ESP to a tunnel
    carrying a packet.



Kent & Seo                                                     [Page 15]


Internet Draft        Security Architecture for IP            April 2004


    The granularity of access control provided is determined by the
    choice of the selectors that define each security association.
    Moreover, the authentication means employed by IPsec peers, e.g.,
    during creation of an IKE (vs. child) SA also effects the granularity
    of the access control afforded.

    If confidentiality 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 that are carrying traffic from
    many subscribers.

    NOTE: A compliant implementation MUST NOT allow instantiation of an
    ESP SA that employs both NULL encryption and no integrity algorithm.
    An attempt to negotiate such an SA is an auditable event by both
    initiator and responder. The audit log entry for this event SHOULD
    include the current date/time, local IKE IP address, and remote IKE
    IP address.  The initiator SHOULD record the relevant SPD entry.


4.3 Combining Security Associations

    This document does not require support for nested security
    associations or for what RFC 2401 called "SA bundles." These features
    still can be effected by appropriate configuration of both the SPD
    and the local forwarding functions (for inbound and outbound
    traffic), but this capability is outside of the IPsec module and thus
    the scope of this specification. As a result, management of
    nested/bundled SAs is potentially more complex and less assured than
    under the model implied by RFC 2401. An implementation that provides
    support for nested SAs SHOULD provide a management interface that
    enables a user or administrator to express the nesting requirement,
    and then create the appropriate SPD entries and forwarding table
    entries to effect the requisite processing.


4.4 Major IPsec Databases

    Many of the details associated with processing IP traffic in an IPsec
    implementation are largely a local matter, not subject to


Kent & Seo                                                     [Page 16]


Internet Draft        Security Architecture for IP            April 2004


    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 IPsec functionality, in support of these
    interoperability and functionality goals.  The model described below
    is nominal; implementations need not match details of this model as
    presented, but the external behavior of implementations MUST
    correspond to the externally observable characteristics of this model
    in order to be deemed compliant.

    There are three nominal databases in this model: the Security Policy
    Database (SPD), the Security Association Database (SAD), and the Peer
    Authorization Database (PAD).  The first specifies the policies that
    determine the disposition of all IP traffic inbound or outbound from
    a host or security gateway (Section 4.4.1).  The second database
    contains parameters that are associated with each established (keyed)
    security association (Section 4.4.2).

    Peer Authorization Database (PAD)

       The third database, the Peer Authorization Database (PAD) provides
       a link between an SA management protocol like IKE and the SPD. The
       PAD indicates the range of identities that an IPv4 or IPv6 peer is
       authorized to represent when (child) SAs are negotiated with the
       peer. The identities may be a list of IPv4 or IPv6 address ranges
       or symbolic names.  The IP version of the identities does not have
       to be the same as that of the IP version of the peer representing
       them. The fundamental requirement associated with the PAD is that
       the traffic selectors passed by the SA management protocol for
       comparison against the SPD MUST be verified as authorized relative
       to the authenticated peer of the SA management protocol. (See also
       Section 4.5.3, which levies requirements on the PAD in support of
       locating security gateways.)

       The PAD also specifies how to authenticate each peer, e.g., via
       shared secret or use of a certificate. If a shared secret is used,
       the secret is stored here. If a certificate is used, the trust
       anchor for the certificate is part of the PAD.  Because the PAD
       might be incorporated into the SA management protocol
       implementation, it is not discussed extensively in this document.

    Multiple Separate IPsec Contexts

       If an IPsec implementation acts as a security gateway for multiple
       subscribers, it MAY implement multiple separate IPsec contexts.
       Each context MAY have and use completely independent identities,
       policies, key management SAs, and/or IPsec SAs.  This is for the


Kent & Seo                                                     [Page 17]


Internet Draft        Security Architecture for IP            April 2004


       most part a local implementation matter. However, a means for
       associating inbound (SA) 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 signaling messages, with the result
       that IPsec SAs are created with a binding to a particular context.
       For example, a security gateway that provides VPN service to
       multiple customers will be able to associate each customer~Os
       traffic with the correct VPN.

    Forwarding vs Security Decisions

       The IPsec model described here embodies a clear separation between
       forwarding (routing) and security decisions, to accommodate a wide
       range of contexts where IPsec may be employed. Forwarding may be
       trivial, in the case where there are only two interfaces, or it
       may be complex, e.g., if there are multiple protected or
       unprotected interfaces or if the context in which IPsec is
       implemented employs a sophisticated forwarding function. IPsec
       assumes only that outbound and inbound traffic that has passed
       through IPsec processing is forwarded in a fashion consistent with
       the context in which IPsec is implemented. Support for nested SAs
       is optional; if required, it requires coordination between
       forwarding tables and SPD entries to cause a packet to traverse
       the IPsec boundary more than once.

    Local" vs "Remote"

       In this document, with respect to IP addresses and ports, the
       terms "Local" and "Remote" are used for policy rules.  "Local"
       refers to the entity being protected by an IPsec implementation,
       i.e., the "source" address/port of outbound packets or the
       "destination" address/port of inbound packets. "Remote" refers to
       a peer entity or peer entities.  The terms "source" and
       "destination" are used for packet header fields.

    "Non-initial" vs "Initial" Fragments

       Throughout this document, the phrase "non-initial" fragments is
       used to mean fragments that do not contain all of the selector
       values that may be needed for access control (e.g., they might not
       contain Next Layer Protocol, source and destination ports, ICMP
       message type/code, Mobility Header type). And the phrase "initial"
       fragment is used to mean a fragment that contains all the selector
       values needed for access control. However, it should be noted that
       for IPv6, which fragment contains the Next Layer Protocol and
       ports (or ICMP message type/code or Mobility Header type) will
       depend on the kind and number of extension headers present.  The


Kent & Seo                                                     [Page 18]


Internet Draft        Security Architecture for IP            April 2004


       "initial" fragment might not be the first fragment.



4.4.1 The Security Policy Database (SPD)

    A security association is a management construct used to enforce
    security policy for traffic crossing the IPsec boundary. 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 specifies minimum management functionality that must be
    provided, to allow a user or system administrator to control whether
    and how IPsec is applied to traffic transmitted or received by a host
    or transiting a security gateway.  The SPD, or relevant caches, must
    be consulted during the processing of ALL traffic (inbound and
    outbound), including traffic not protected by IPsec, that traverses
    the IPsec boundary.  This includes IPsec management traffic such as
    IKE.  An IPsec implementation MUST have at least one SPD, and it MAY
    support multiple SPDs, if appropriate for the context in which the
    IPsec implementation operates. There is no requirement to maintain
    SPDs on a per interface basis, as was specified in RFC 2401. However,
    if an implementation supports multiple SPDs, then it MUST include an
    explicit SPD selection function, that is invoked to select the
    appropriate SPD for outbound traffic processing. The inputs to this
    function are the outbound packet and any local metadata (e.g., the
    interface via which the packet arrived) required to effect the SPD
    selection function. The output of the function is an SPD ID.

    The SPD is an ordered database, consistent with the use of ACLs or
    packet filters in firewalls, routers, etc. The ordering requirement
    arises because entries often will overlap due to the presence of
    (non-trivial) ranges as values for selectors.  Thus a user or
    administrator MUST be able to order the entries to express a desired
    access control policy. There is no way to impose a general, canonical
    order on SPD entries, because of the allowed use of wildcards for
    selector values and because the different types of selectors are not
    hierarchically related.

    Processing Choices --> DISCARD, BYPASS, PROTECT

       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 PROTECT using IPsec.  The


Kent & Seo                                                     [Page 19]


Internet Draft        Security Architecture for IP            April 2004


       first choice refers to traffic that is not allowed to traverse the
       IPsec boundary (in the specified direction).  The second choice
       refers to traffic that is allowed to cross the IPsec boundary
       without IPsec protection.  The third choice refers to traffic that
       is afforded IPsec protection, and for such traffic the SPD must
       specify the security protocols to be employed, their mode,
       security service options, and the cryptographic algorithms to be
       used.

    SPD-S, SPD-I, SPD-O

       An SPD is logically divided into three pieces. The SPD-S (secure
       traffic) contains entries for all traffic subject to IPsec
       protection. SPD-O (outbound) contains entries for all outbound
       traffic that is to be bypassed or discarded. SPD-I (inbound) is
       applied to inbound traffic that will be bypassed or discarded. All
       three of these can be decorrelated (with the exception noted above
       for native host implementations) to facilitate caching.  If an
       IPsec implementation supports only one SPD, then the SPD consists
       of all three parts. If multiple SPDs are supported, some of them
       may be partial, e.g., some SPDs might contain only SPD-I entries,
       to control inbound bypassed traffic on a per-interface basis.  The
       split allows SPD-I to be consulted without having to consult SPD-
       S, for such traffic. Since the SPD-I is just a part of the SPD,
       the same rule applies here, i.e., if a packet that is looked up in
       the SPD-I cannot be matched to an entry there, then the packet
       MUST be discarded.  Note that for outbound traffic, if a match is
       not found in SPD-S, then SPD-O must be checked to see if the
       traffic should be bypassed. Similarly, if SPD-O is checked first
       and no match is found, then SPD-S must be checked.

    SPD entries

       Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
       PROTECT. The entry is keyed by a list of one or more selectors.
       The SPD contains an ordered list of these entries. The required
       selector types are defined in Section 4.4.1.1. These selectors are
       used to define the granularity of the SAs that are created in
       response to an outbound packet or in response to a proposal from a
       peer. The detailed structure of an SPD entry is described in
       Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
       matches anything that is otherwise unmatched, and discards it.

       The SPD MUST permit a user or administrator to specify policy
       entries as follows:

     - SPD-I: For inbound traffic that is to be bypassed or discarded,
       the entry consists of the values of the selectors that apply to


Kent & Seo                                                     [Page 20]


Internet Draft        Security Architecture for IP            April 2004


       the traffic to be bypassed or discarded.

     - SPD-O: For outbound traffic that is to be bypassed or discarded,
       the entry consists of the values of the selectors that apply to
       the traffic to be bypassed or discarded.

     - SPD-S: For traffic that is to be protected using IPsec, the entry
       consists of the values of the selectors that apply to the traffic
       to be protected via AH or ESP, controls on how to create SAs based
       on these selectors, and the parameters needed to effect this
       protection (e.g., algorithms, modes, etc.). Note that an SPD-S
       entry also contains information such as "populate from packet"
       (PFP) flag (see paragraphs below on "How To Derive the Values for
       an SAD entry") and bits indicating whether the SA lookup makes use
       of the local and remote IP addresses in addition to the SPI (see
       AH [Ken04b] or ESP [Ken04a] specifications).

    Representing directionality in an SPD entry

       For traffic protected by IPsec, the Local and Remote address and
       ports in an SPD entry are swapped to represent directionality,
       consistent with IKE conventions. In general, the protocols that
       IPsec deals with have the property of requiring symmetric SAs with
       flipped Local/Remote IP addresses. However, for ICMP, there is
       often no such bi-directional authorization requirement.
       Nonetheless, for the sake of uniformity and simplicity, SPD
       entries for ICMP are specified in the same way as for other
       protocols. Note also that for ICMP, Mobility Header, and non-
       initial fragments, there are no port fields in these packets. ICMP
       has message type and code and Mobility Header has mobility header
       type. Thus SPD entries have provisions for expressing access
       controls appropriate for these protocols, in lieu of the normal
       port field controls. For bypassed or discarded traffic, separate
       inbound and outbound entries are supported, e.g., to permit
       unidirectional flows if required.

    OPAQUE and ANY

       For each selector in an SPD entry, in addition to the literal
       values that define a match, there are two special values: ANY and
       OPAQUE. ANY is a wildcard that matches any value in the
       corresponding field of the packet, or that matches packets where
       that field is not present or is obscured. OPAQUE indicates that
       the corresponding selector field is not available for examination
       because it may not be present in a fragment or does not exist for
       the given Next Layer Protocol. ANY includes OPAQUE.

    How To Derive the Values for an SAD entry


Kent & Seo                                                     [Page 21]


Internet Draft        Security Architecture for IP            April 2004


       For each selector in an SPD entry, the entry specifies how to
       derive the corresponding values for a new Security Association
       Database (SAD, see Section 4.4.2) entry from those in the SPD and
       the packet. The goal is to allow an SAD entry and an SPD cache
       entry to be created based on specific selector values from the
       packet, or from the matching SPD entry. If IPsec processing is
       specified for an entry, a "populate from packet" (PFP) flag may be
       asserted for one or more of the selectors in the SPD entry (Local
       IP address, Remote IP address, Next Layer Protocol, and depending
       on Next Layer Protocol -- Local port, ICMP type/code or Mobility
       Header type; Remote port).  If asserted for a given selector, the
       flag indicates that the SA to be created should take its value for
       that selector from the value in the packet.  Otherwise, the SA
       should take its value(s) for that selector from the value(s) in
       the SPD entry.  Note: In the non-PFP case, the selector values
       negotiated by the SA management protocol (e.g., IKEv2) may be a
       subset of those in the SPD entry, depending on the SPD policy of
       the peer.  Also, whether a single flag is used for, e.g., source
       port, ICMP type/code, and MH type, or a separate flag is used for
       each, is a local matter.

       The following example illustrates the use of the PFP flag in the
       context of a security gateway or a BITS/BITW implementation.
       Consider an SPD entry where the allowed value for Remote address
       is a range of IPv4 addresses: 192.168.2.1 to 192.168.2.10. Suppose
       an outbound packet arrives with a destination address of
       192.168.2.3, and there is no extant SA to carry this packet. The
       value used for the SA created to transmit this packet could be
       either of the two values shown below, depending on what the SPD
       entry for this selector says is the source of the selector value:

                PFP flag value  example of new
                for the Remote   SAD dest. address
                addr. selector  selector value
                --------------- ------------
                a. PFP TRUE     192.168.2.3 (one host)
                b. PFP FALSE    192.168.2.1 to 192.168.2.10 (range of hosts)

       Note that if the SPD entry above had a value of ANY for the Remote
       address, then the SAD selector value would have to be ANY for case
       (b), but would still be as illustrated for case (a).  Thus the PFP
       flag can be used to prohibit sharing of an SA, even among packets
       that match the same SPD entry.

    Management Interface

       For every IPsec implementation, there MUST be a management
       interface that allows a user or system administrator to manage the


Kent & Seo                                                     [Page 22]


Internet Draft        Security Architecture for IP            April 2004


       SPD. The interface must allow the user (or administrator) to
       specify the security processing to be applied to every packet that
       traverses the IPsec boundary. (In a native host IPsec
       implementation making use of a socket interface, the SPD may not
       need to be consulted on a per packet basis, as noted above.)  The
       management interface for the SPD MUST allow creation of entries
       consistent with the selectors defined in Section 4.4.1.1, and MUST
       support (total) ordering of these entries, as seen via this
       interface. The SPD entries' selectors are analogous to the ACL or
       packet filters commonly found in a stateless firewall or packet
       filtering router and which are currently managed this way.

       In host systems, applications MAY be allowed to create SPD
       entries.  (The means of signaling 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. The
       form of the management interface is not specified by this document
       and may differ for hosts vs. security gateways, and within hosts
       the interface may differ for socket-based vs. BITS
       implementations.  However, this document does specify a standard
       set of SPD elements that all IPsec implementations MUST support.

    Decorrelation

       The processing model described in this document assumes the
       ability to decorrelate overlapping SPD entries to permit caching,
       which enables more efficient processing of outbound traffic in
       security gateways and BITS/BITW implementations. (Native host
       implementations have an implicit form of caching available, due to
       the use of, for example, socket interfaces for applications, and
       thus there is no requirement to be able to decorrelate SPD entries
       in these implementations.)

       Note: Decorrelation is a means of improving performance and
       simplifying the processing description; it is not a requirement
       for a compliant implementation. In this section, unless otherwise
       noted, the use of "SPD" refers to the body of policy information
       in both ordered or decorrelated (unordered) state.

       Appendix B provides an algorithm that can be used to decorrelate
       SPD entries, but any algorithm that produces equivalent output may
       be used. Note that when an SPD entry is decorrelated all the
       resulting entries MUST be linked together, so that all members of
       the group derived from an individual, SPD entry (prior to
       decorrelation) can all be placed into caches and into the SAD at
       the same time.  For example, suppose one starts with an entry A
       (from an ordered SPD) that when decorrelated, yields entries A1,


Kent & Seo                                                     [Page 23]


Internet Draft        Security Architecture for IP            April 2004


       A2 and A3.  When a packet comes along that matches, say A2, and
       triggers the creation of an SA, the SA management protocol, e.g.,
       IKEv2, negotiates A.  And all 3 decorrelated entries, A1, A2, and
       A3 are placed in the appropriate SPD-S cache and linked to the SA.
       The intent is that use of a decorrelated SPD ought not create more
       SAs than would have resulted from use of a not-decorrelated SPD.
       Note also that if a decorrelated SPD is employed, the original
       entry from the (correlated) SPD should be retained and passed to
       the SA management protocol, e.g., IKE. Passing the correlated SPD
       entry to the SA management protocol keeps the use of a
       decorrelated SPD a local matter, not visible to peers. When acting
       as a responder, the peer uses a correlated SPD entry for matching,
       and for issuing a "narrowed" response.  Then the decorrelated
       entries are used to populate the SPD-S cache.


    Handling Changes to the SPD while the System is Running

       If a change is made to the SPD while the system is running, a
       check SHOULD be made of the affect of this change on extant SAs.
       This document does not impose a requirement to do this, but an
       implementation MAY choose to check the impact of an SPD change on
       extant SAs and to provide a user/administrator with a mechanism
       for configuring what actions to take, e.g., delete an affected SA,
       allow an affected SA to continue unchanged, etc.

4.4.1.1  Selectors

    An SA 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 Layer Protocol
    and related fields, e.g., ports), 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 by all IPsec implementations to
    facilitate control of SA granularity. Note that both Local and Remote
    addresses should either be IPv4 or IPv6, but not a mix of address
    types. Also, note that the Local/Remote port selectors (and ICMP
    message type and code, and Mobility Header type) may be labeled as
    OPAQUE to accommodate situations where these fields are inaccessible
    due to packet fragmentation.

       - Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges
         of IP addresses (unicast, anycast, broadcast (IPv4 only), or


Kent & Seo                                                     [Page 24]


Internet Draft        Security Architecture for IP            April 2004


         multicast group). This structure allows expression of a single
         IP address (via a trivial range), or a list of addresses (each a
         trivial ranges), or a range of addresses (low and high values,
         inclusive), as well as the most generic form of a list of
         ranges.  Address ranges are used to support more than one
         destination system sharing the same SA, e.g., behind a security
         gateway.

       - Local IP Address(es) (IPv4 or IPv6): this is a list of ranges of
         IP addresses (unicast, anycast, broadcast (IPv4 only), or
         multicast group). This structure allows expression of a single
         IP address (via a trivial range), or a list of addresses (each a
         trivial ranges), or a range of addresses (low and high values,
         inclusive), as well as the most generic form of a list of
         ranges.  Address ranges are used to support more than one source
         system sharing the same SA, e.g., behind a security gateway.
         Local refers to the address(es) being protected by this
         implementation (or policy entry).

       - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
         IPv6 "Next Header" fields.  This is an individual protocol
         number, or ANY. The Next Layer Protocol is whatever comes after
         any IP extension headers that are present. To simplify locating
         the Next Layer Protocol, there SHOULD be a mechanism for
         configuring which IP extension headers to skip.  The default
         configuration for which protocols to skip SHOULD include the
         following protocols: 0 (Hop-by-hop options), 43 (Routing
         Header), 44 (Fragmentation Header), and 60 (Destination
         Options).  Note: The default list does NOT include 51 (AH), or
         50 (ESP).  From a selector lookup point of view, IPsec treats AH
         and ESP as Next Layer Protocols.

         Several additional selectors depend on the Next Layer Protocol
         value:

      * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, SCTP,
        these selectors is a list of ranges of values.  Note that the
        Local and Remote ports may not be available in the case of
        receipt of a fragmented packet, thus a value of OPAQUE also MUST
        be supported.  Note: In a non-initial fragment, port values will
        not be available. If a port selector specifies a value other than
        ANY or OPAQUE, it cannot match packets that are non-initial
        fragments.  If the SA requires a port value other than ANY or
        OPAQUE, an arriving fragment without ports MUST be discarded.

      * If the Next Layer Protocol is a Mobility Header, then there is a
        selector for IPv6 Mobility Header Message Type (MH type) [Mobip].
        This is an 8-bit value that identifies a particular mobility


Kent & Seo                                                     [Page 25]


Internet Draft        Security Architecture for IP            April 2004


        message.  Note that the MH type may not be available in the case
        of receipt of a fragmented packet, thus a value of OPAQUE MUST be
        supported.

      * If the Next Layer Protocol value is ICMP then there is a 16-bit
        selector for the ICMP message type and code. The message type is
        a single 8-bit value, which defines the type of an ICMP message,
        or ANY. The ICMP code is a single 8-bit value that defines a
        specific subtype for an ICMP message. The message type is placed
        in the most significant 8 bits of the 16-bit selector and the
        code is placed in the least significant 8 bits. This 16-bit
        selector can contain a single type and a range of codes, a single
        type and ANY code, ANY type and ANY code. Given a policy entry
        with a range of Types (T-start to T-end) and a range of Codes (C-
        start to C-end), and an ICMP packet with Type t and Code c, an
        implementation MUST test for a match using

         (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end

         Note that the ICMP message type and code may not be available in
         the case of receipt of a fragmented packet, thus a value of
         OPAQUE MUST be supported.

       - Name: A name may be used as a symbolic identifier for an IPsec
         Local or Remote address. Named SPD entries are used in two ways:

            1. A named SPD entry is used by a responder (not an initiator) in
               support of access control when an IP address would not be
               appropriate for the Remote IP address selector, e.g., for "road
               warriors."  The name used to match this field is communicated
               during the IKE negotiation in the ID payload. In this context,
               the initiator's Source IP address (inner IP header in tunnel
               mode) is bound to the Remote IP address in the SAD entry created
               by the IKE negotiation. This address overrides the Remote IP
               address value in the SPD, when the SPD entry is selected in this
               fashion.  All IPsec implementations MUST support this use of
               names.

            2. A named SPD entry may be used by an initiator to identify a user
               for whom an IPsec SA will be created (or for whom traffic may be
               bypassed). Support for this use is optional for multi-user,
               native host implementations and not applicable to other
               implementations. Note that this name is used only locally; it is
               not communicated by the key management protocol.

         An SPD entry can contain both a name (or a list of names) and
         also values for the Local or Remote IP address. If a name is
         used in the IKE exchange, that name is matched against the SPD,


Kent & Seo                                                     [Page 26]


Internet Draft        Security Architecture for IP            April 2004


         rather than matching the corresponding address in the SPD, and
         the IP address in the corresponding SAD entry is derived from
         that of the named entity (Use initiator's source address as the
         "Remote" address for case 1, and use the user's source address
         as the "Local" address for case 2).

         The identifiers employed in named SPD entries are one of the
         following four types:

                 a. a fully qualified user name string (email), e.g.,
                    mozart@foo.example.com
                    (this corresponds to ID_RFC822_ADDR in IKEv2)

                 b. a fully qualified DNS name, e.g.,
                    foo.example.com
                    (this corresponds to ID_FQDN in IKEv2)

                 c. X.500 distinguished name, e.g.,
                    C = US, SP = MA,
                    O = BBN Technologies, CN = Stephen T. Kent
                    (this corresponds to ID_DER_ASN1_DN in IKEv2, after
                    decoding)

                 d. a byte string
                    (this corresponds to Key_ID in IKEv2)


    The IPsec implementation context determines how selectors are used.
    For example, a native host implementation typically makes use of a
    socket interface.  When a new connection is established the SPD can
    be consulted and an SA bound to the socket.  Thus traffic sent via
    that socket need not result in additional lookups to the SPD (SPD-O
    and SPD-S) cache.  In contrast, a BITS, BITW, or security gateway
    implementation needs to look at each packet and perform an SPD-O/SPD-
    S cache lookup based on the selectors.


4.4.1.2  Structure of an SPD entry

    This section contains a prose description of an SPD entry. Also, an
    ASN.1 definition of an SPD entry is provided in Appendix D.

    This text describes the SPD in a fashion that maps directly into IKE
    payloads. One should not create SPD entries that cannot be mapped
    into something that IKE can negotiate. The management GUI can offer
    the user other forms of data entry and display, e.g., the option of
    using address prefixes as well as ranges, and symbolic names for
    protocols, ports, etc. (Do not confuse the use of symbolic names in a


Kent & Seo                                                     [Page 27]


Internet Draft        Security Architecture for IP            April 2004


    management interface with the SPD selector "Name".)  If the reserved,
    symbolic selector value OPAQUE or ANY is employed for a given
    selector type, only it may appear in the list for that selector, and
    it must appear only once in the list for that selector.  Note that
    ANY and OPAQUE are local syntax conventions -D IKEv2 negotiates these
    values via ranges. Also, Remote/Local only applies to ports, not to
    ICMP message type/code or Mobility Header type.

           ANY:     start = 0        end = <max>
           OPAQUE:  start = <max>    end = 0

    An SPD is an ordered list of entries each of which contains the
    following fields.
            o Name -- a list of IDs.  This selector is optional.

            o PFP flags -- one per traffic selector. A given flag, e.g.,
              for Next Layer Protocol, applies to the relevant selector
              across all "selector sets" (see below) contained in an SPD
              entry.  When creating an SA, each flag specifies for the
              corresponding traffic selector whether to instantiate the
              selector from the corresponding field in the packet that
              triggered the creation of the SA or from the value(s) in the
              corresponding SPD entry (see Section 4.4.1, "How To Derive
              the Values for an SAD entry"). Whether a single flag is used
              for, e.g., source port, ICMP type/code, and MH type, or a
              separate flag is used for each, is a local matter.
                 - Local Address
                 - Remote Address
                 - Next Layer Protocol
                 - Local Port, or ICMP message type/code or Mobility
                   Header type (depending on the next layer protocol)
                 - Remote Port, or ICMP message type/code or Mobility
                   Header type (depending on the next layer protocol)

            o One to N selector sets that correspond to the "condition"
              for applying a particular IPsec action. Each selector set
              contains:
                 - Local Address
                 - Remote Address
                 - Next Layer Protocol
                 - Local Port, or ICMP message type/code or Mobility
                   Header type (depending on the next layer protocol)
                 - Remote Port, or ICMP message type/code or Mobility
                   Header type (depending on the next layer protocol)

            o processing info -- which action is required -- PROTECT,
              BYPASS, or DISCARD. There is just one action that goes with
              all the selector sets, not a separate action for each set.


Kent & Seo                                                     [Page 28]


Internet Draft        Security Architecture for IP            April 2004


              If the required processing is PROTECT, the entry contains
              the following information.

                 - IPsec mode -- tunnel or transport
                 - extended sequence number -- Is this SA using extended
                   sequence numbers?
                 - stateful fragment checking -- Is this SA using stateful
                   fragment checking (see Section 7 for more details)
                 - IPsec protocol(s) -- AH, ESP
                 - algorithms -- which ones to use for AH, which ones to
                   use for ESP, ordered by decreasing priority

4.4.2 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,
    each SAD entry is pointed to by entries in the SPD-S part of the SPD
    cache. For inbound processing, for unicast SAs, the SPI is used
    either alone to look up an SA, or the SPI may be used in conjunction
    with the IPsec protocol type.  If an IPsec implementation supports
    multicast, the SPI plus destination address, or SPI plus destination
    and source addresses are used to look up the SA. (See Section 4.1.)
    The following parameters are associated with each entry in the SAD.
    They should all be present except where otherwise noted, e.g., AH
    Authentication algorithm. This description does not purport to be a
    MIB, only a specification of the minimal data items required to
    support an SA in an IPsec implementation.

    For each of the selectors defined in Section 4.4.1.1, the entry for
    an inbound SA in the SAD MUST contain the value or values negotiated
    at the time the SA was created. For a receiver, these values are used
    to check that the header fields of an inbound packet match the
    selector values negotiated for the SA. For the receiver, this is part
    of verifying that a packet arriving on an SA is consistent with the
    policy for the SA. (See Section 6 for rules for ICMP messages.)
    These fields can have the form of specific values, ranges, ANY, or
    OPAQUE, as described in section 4.4.1.1, "Selectors."

    The following data items MUST be in the SAD:

     o Security Parameter Index (SPI): a 32-bit value selected by the
       receiving end of an SA to uniquely identify the SA. In an SAD
       entry for an outbound SA, the SPI is used to construct the
       packet's AH or ESP header. In an SAD entry for an inbound SA, the
       SPI is used to map traffic to the appropriate SA (see text on
       unicast/multicast in Section 4.1).



Kent & Seo                                                     [Page 29]


Internet Draft        Security Architecture for IP            April 2004


     o Sequence Number Counter: a 64-bit used to generate the Sequence
       Number field in AH or ESP headers. 64-bit sequence numbers are the
       default, but 32-bit sequence numbers are also supported if
       negotiated.

     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, or whether
       rollover is permitted. The audit log entry for this event SHOULD
       include the SPI value, current date/time, Local Address, Remote
       Address, and the selectors from the relevant SAD entry.

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

       NOTE: If anti-replay has been disabled by the receiver for an SA,
       e.g., in the case of a manually keyed SA, then the Anti-Replay
       Window is ignored for the SA in question. 64-bit sequence numbers
       are the default, but this counter size accommodates 32-bit
       sequence numbers.

     o AH Authentication algorithm, key, etc. This is required only if AH
       is supported.

     o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode
       algorithm is used, these fields will not be applicable.


     o ESP integrity algorithm, keys, etc. If the integrity service is
       not selected, these fields will not be applicable. If a combined
       mode algorithm is used, these fields will not be applicable.


     o ESP combined mode algorithms, key(s), etc. This data is used when
       a combined mode (encryption and integrity) algorithm is used with
       ESP. If a combined mode algorithm is not used, these fields are
       not applicable.

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


Kent & Seo                                                     [Page 30]


Internet Draft        Security Architecture for IP            April 2004


       exchange for the SA.  Both initiator and responder are responsible
       for constraining the SA lifetime in this fashion.  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 cryptographic 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 MUST 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 that
          warns the implementation to initiate action such as setting up
          a replacement SA; and a hard lifetime when the current SA ends
          and is destroyed.

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

     o IPsec protocol mode: tunnel or transport.  Indicates which mode of
       AH or ESP is applied to traffic on this SA.

     o Stateful fragment checking flag. Indicates whether or not stateful
       fragment checking applies to this SA.

     o Path MTU: any observed path MTU and aging variables.

     o Tunnel header IP source and destination address - both addresses
       must be either IPv4 or IPv6 addresses. The version implies the
       type of IP header to be used.  Only used when the IPsec protocol
       mode is tunnel.

    For each selector, the following tables show the relationship between
    the value in the SPD, the PFP flag, the value in the triggering
    packet and the resulting value in the SAD.  Note that the
    administrative interface for IPsec can use various syntactic options
    to make it easier for the administrator to enter rules. For example,
    although a list of ranges is what IKEv2 sends, it might be clearer
    and less error prone for the user to enter a single IP address or IP
    address prefix.






Kent & Seo                                                     [Page 31]


Internet Draft        Security Architecture for IP            April 2004


                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
       loc addr  list of ranges    0  IP addr "S"  list of ranges
                     or ANY                            or ANY
                 list of ranges    1  IP addr "S"  "S"
                     or ANY

       rem addr  list of ranges    0  IP addr "D"  list of ranges
                     or ANY                            or ANY
                 list of ranges    1  IP addr "D"  "D"
                     or ANY

       protocol  list of prot's*   0  prot. "P"    list of prot's*
                     or ANY**                          or ANY
                 list of prot's*   1  prot. "P"    "P"
                     or ANY**
                 OPAQUE            0  not avail.  "undefined"
                 OPAQUE            1  not avail.  ***






























Kent & Seo                                                     [Page 32]


Internet Draft        Security Architecture for IP            April 2004


    If the protocol is one that has two ports then there will be
    selectors for both Local and Remote ports.

                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
       loc port  list of ranges    0  src port "s" list of ranges
                     or ANY                            or ANY
                 list of ranges    0  no src port  discard packet
                     or ANY
                 OPAQUE            0  not avail.   OPAQUE
                 OPAQUE            1  not avail.   ***
                 list of ranges    1  src port "s" "s"
                     or ANY
                 list of ranges    1  no src port  discard packet
                     or ANY

       rem port  list of ranges    0  dst port "d" list of ranges
                     or ANY                            or ANY
                 list of ranges    0  no dst port  discard packet
                     or ANY
                 OPAQUE            0  not avail.   OPAQUE
                 OPAQUE            1  not avail.   ***
                 list of ranges    1  dst port "d" "d"
                     or ANY
                 list of ranges    1  no dst port  discard packet
                     or ANY

    If the protocol is mobility header then there will be a selector for
    mh type.

                                      Value in
                                      Triggering   Resulting SAD
       Selector  SPD Entry        PFP Packet       Entry
       --------  ---------------- --- ------------ --------------
       mh type   list of ranges    0  mh type "T"  list of ranges
                     or ANY                            or ANY
                 list of ranges    0  no mh type   discard packet
                     or ANY
                 OPAQUE            0  not avail.   OPAQUE
                 OPAQUE            1  not avail.   ***
                 list of ranges    1  mh type "T"  "T"
                     or ANY
                 list of ranges    1  no mh type   discard packet
                     or ANY




Kent & Seo                                                     [Page 33]


Internet Draft        Security Architecture for IP            April 2004


    If the protocol is ICMP, then there will be a 16-bit selector for
    ICMP type and ICMP code.  Note that the type and code are bound to
    each other, i.e., the codes apply to the particular type. This 16-bit
    selector can contain a single type and a range of codes, a single
    type and ANY code, ANY type and ANY code.

                                       Value in
                                       Triggering   Resulting SAD
       Selector   SPD Entry        PFP Packet       Entry
       ---------  ---------------- --- ------------ --------------
       ICMP type  a single type     0  type "t"     list of ranges
                     or ANY                            or ANY
                  a single type     0  no type      discard packet
                     or ANY
                  OPAQUE            0  not avail.   OPAQUE
                  OPAQUE            1  not avail.   ***
                  a single type     1  type "t"     "t"
                     or ANY
                  a single type     1  no type      discard packet
                     or ANY

       ICMP code  list of ranges    0  type "c"     list of ranges
                     or ANY                            or ANY
                  list of ranges    0  no code      discard packet
                     or ANY
                  OPAQUE            0  not avail.   OPAQUE
                  OPAQUE            1  not avail.   ***
                  list of ranges    1  type "c"     "c"
                     or ANY
                  list of ranges    1  no code      discard packet
                     or ANY



















Kent & Seo                                                     [Page 34]


Internet Draft        Security Architecture for IP            April 2004


    If the name selector is used...

                                       Value in
                                       Triggering   Resulting SAD
       Selector   SPD Entry        PFP Packet       Entry
       ---------  ---------------- --- ------------ --------------
       name       list of system-  N/A  packet from   N/A
                     dependent            user or
                     user or sys.         system
                     names

          * "List of protocols" is the information, not the way
            that the SPD or SAD or IKv2 have to represent this
            information.
         ** 0 (zero) is used by IKE to indicate ANY for
            protocol.
        *** Use of PFP=1 with an OPAQUE value is an error and
            SHOULD be prohibited by an IPsec implementation.

4.5 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 service available for AH and ESP requires automated SA
    management.  Moreover, the granularity of key distribution employed
    with IPsec determines the granularity of authentication provided. In
    general, data origin authentication in AH and ESP is limited by the
    extent to which secrets used with the integrity 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.5.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


Kent & Seo                                                     [Page 35]


Internet Draft        Security Architecture for IP            April 2004


    domain, this might 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.5.2 Automated SA and Key Management

    Widespread deployment and use of IPsec requires an Internet-standard,
    scalable, automated, SA management protocol. Such support is required
    to facilitate use of the anti-replay features of AH and ESP, and to
    accommodate on-demand creation of SAs, e.g., for user- and session-
    oriented keying.  (Note that the notion of "rekeying" an SA actually
    implies creation of a new SA with a new SPI, a process that generally
    implies use of an automated SA/key management protocol.)

    The default automated key management protocol selected for use with
    IPsec is IKEv2 [Kau04].  Other automated SA management protocols MAY
    be employed.

    When an automated SA/key management protocol is employed, the output
    from this protocol is used to generate multiple keys for a single SA.
    This also occurs because distinct keys are used for each of the two
    SAs created by IKE. If both integrity and confidentiality are
    employed, then a minimum of four keys are required.  Additionally,
    some cryptographic algorithms may require multiple keys, e.g., 3DES.

    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 keys
    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 keys MUST be taken from the first (left-most, high-
    order) bits and the integrity keys MUST be taken from the remaining
    bits.  The number of bits for each key is defined in the relevant
    cryptographic algorithm specification RFC. In the case of multiple
    encryption keys or multiple integrity keys, the specification for the
    cryptographic algorithm must specify the order in which they are to
    be selected from a single string of bits provided to the


Kent & Seo                                                     [Page 36]


Internet Draft        Security Architecture for IP            April 2004


    cryptographic algorithm.


4.5.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, but the Peer Authorization Database
    described in Section 4.4 is the most likely candidate.

    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 his home organization's
    firewall (SG2). This situation raises several issues:

    1. How does H1 know/learn about the existence of the security gateway
       SG2?

    2. How does it authenticate SG2, and once it has authenticated SG2,
       how does it confirm that SG2 has been authorized to represent H2?

    3. How does SG2 authenticate H1 and verify that H1 is authorized to
       contact H2?

    4. How does H1 know/learn about any additional gateways that 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 one or more security gateways for ranges of
    destination addresses that require its use.  This includes the
    ability to configure information for locating and authenticating one
    or more security gateways and verifying the authorization of these
    gateways to represent the destination host. (The authorization
    function is implied in the PAD.) This document does not address the
    issue of how to automate the discovery/verification of security
    gateways.  The IP Security Policy (IPSP) Working Group is a possible
    future source of guidance. One of its goals is to produce an Internet
    Draft on a "Security Gateway Discovery, Policy Exchange and
    Negotiation Protocol".






Kent & Seo                                                     [Page 37]


Internet Draft        Security Architecture for IP            April 2004


4.6 Security Associations and Multicast

    The receiver-orientation of the Security Association implies that, in
    the case of unicast traffic, the destination system will 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 associated with a single SA.
    So some system or person will need to coordinate among all multicast
    groups to select an SPI or SPIs on behalf of each multicast group and
    then communicate the group's IPsec information to all of the
    legitimate members of that multicast group via mechanisms not defined
    here.

    Multiple senders to a multicast group SHOULD use a single Security
    Association (and hence Security Parameter Index) for all traffic to
    that group when a symmetric key encryption or integrity 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 approaches are
    deferred to the IETF's Multicast Security Working Group.


5. IP Traffic Processing

    As mentioned in Section 4.4.1 "The Security Policy Database (SPD)",
    the SPD (or associated caches) must be consulted during the
    processing of all traffic that crosses the IPsec protection boundary,
    including IPsec management traffic. If no policy is found in the SPD
    that matches a packet (for either inbound or outbound traffic), the
    packet MUST be discarded. To simplify processing, and to allow for
    very fast SA lookups (for SG/BITS/BITW), this document introduces the
    notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
    and a cache for inbound, non-IPsec-protected traffic (SPD-I).  There
    is nominally one cache per SPD. Since SPD entries may overlap, one
    cannot safely cache these entries in general. Simple caching might
    result in a match against a cache entry whereas an ordered search of
    the SPD would have resulted in a match against a different entry.
    But, if the SPD entries are first decorrelated, then the resulting
    entries can safely be cached, and each cached entry will map to
    exactly one SA, or indicate that matching traffic should be bypassed
    or discarded, appropriately. (Note: The original SPD entry might
    result in multiple SAs, e.g., because of PFP.) Unless otherwise
    noted, all references below to the "SPD" or "SPD cache" or "cache"


Kent & Seo                                                     [Page 38]


Internet Draft        Security Architecture for IP            April 2004


    are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
    containing entries from the decorrelated SPD.

    Note: 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.  This provides an implicit caching mechanism and the
    portions of the preceding discussion that address caching can be
    ignored in such implementations.

    Note: It is assumed that one starts with a correlated SPD because
    that is how users and administrators are accustomed to managing these
    sorts of access control lists or firewall filter rules. Then the
    decorrelation algorithm is applied, to build a list of cache-able SPD
    entries. The decorrelation is invisible at the management interface.

    For inbound IPsec traffic, the SAD entry selected by the SPI serves
    as the cache for the selectors to be matched against arriving IPsec
    packets, after AH or ESP processing has been performed.


5.1 Outbound IP Traffic Processing (protected-to-unprotected)

    First consider the path for traffic entering the implementation via a
    protected interface and exiting via an unprotected interface.

                           Unprotected Interface
                                    ^
                                    |
             (nested SAs)      +----------+
            ...................|Forwarding|<-----+
            :                  +----------+      |
            :                        ^           |
            :                        | BYPASS    |
            V                     +-----+     +--------+
        +-------+    +-------+    | SPD |     |PROTECT |
        | SPD-I |    |DISCARD|<---|Cache|---->|(AH/ESP)|
        +-------+    +-------+    +-----+     +--------+
            :                        ^
            :                        |
            :                 +-------------+
            :................>|SPD Selection|
                              +-------------+
                                     ^
                                     |
                             Protected Interface




Kent & Seo                                                     [Page 39]


Internet Draft        Security Architecture for IP            April 2004


            Figure 2.  Processing Model for Outbound Traffic


    IPsec MUST perform the following steps when processing outbound
    packets:

    1. When a packet arrives from the subscriber (protected) interface,
       invoke the SPD selection function to obtain the SPD-ID needed to
       choose the appropriate SPD. (If the implementation uses only one
       SPD, this step is a no-op.)

    2. Match the packet headers against the cache for the SPD specified
       by the SPD-ID from step 1. Note that this cache contains entries
       from SPD-O and SPD-S.

    3a. If there is a match, then process the packet as specified by the
       matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
       or ESP. If IPsec processing is applied, there is a link from the
       SPD cache entry to the relevant SAD entry (specifying the mode,
       cryptographic algorithms, keys, SPI, etc.).  IPsec processing is
       as previously defined, for tunnel or transport modes and for AH or
       ESP, as specified in their respective RFCs [Ken04b and Ken04a].

    3b. If no match is found in the cache, search the SPD (SPD-S and SPD-
       O parts) specified by SPD-ID. If the SPD entry calls for BYPASS or
       DISCARD, create new outbound SPD cache entries and if BYPASS,
       create new inbound SPD cache entries. If the SPD entry calls for
       PROTECT, i.e., creation of an SA, the key management mechanism
       (e.g., IKEv2) is invoked to create the SA. If SA creation
       succeeds, a new outbound (SPD-S) cache entry is created, along
       with outbound and inbound SAD entries, otherwise the packet is
       discarded. (A packet that triggers an SPD lookup MAY be discarded
       by the implementation, or it may be processed against the newly
       created cache entry, if one is created.)  Since SAs are created in
       pairs, an SAD entry for the corresponding inbound SA also is
       created, and it contains the selector values derived from the SPD
       entry (and packet, if any PFP flags were "true") used to create
       the inbound SA, for use in checking inbound traffic delivered via
       the SA.

    4. The packet is passed to the outbound forwarding function
       (operating outside of the IPsec implementation), to select the
       interface to which the packet will be directed. This function may
       cause the packet to be passed back across the IPsec boundary, for
       additional IPsec processing, e.g., in support of nested SAs. If
       so, there MUST be an entry in SPD-I database that permits inbound
       bypassing of the packet.



Kent & Seo                                                     [Page 40]


Internet Draft        Security Architecture for IP            April 2004


    NOTE: With the exception of IPv4 and IPv6 transport mode, an SG,
    BITS, or BITW implementation MAY fragment packets before applying
    IPsec.  The device SHOULD have a configuration setting to disable
    this.  The resulting fragments are evaluated against the SPD in the
    normal manner.  Thus, fragments not containing port numbers (or ICMP
    message type and code, or Mobility Header type) will only match rules
    having port (or ICMP message type and code, or MH type) selectors of
    OPAQUE or ANY. (See section 7 for more details.)

5.1.1  Handling an Outbound Packet That Must Be Discarded

    If an IPsec system receives an outbound packet which it finds it must
    discard, it SHOULD be capable of generating and sending an ICMP
    message to indicate to the sender of the outbound packet that the
    packet was discarded.  The type and code of the ICMP message will
    depend on the reason for discarding the packet, as specified below.
    The reason SHOULD be recorded in the audit log. The audit log entry
    for this event SHOULD include the reason, current date/time, and the
    selector values from the packet.

     a. The selectors of the packet matched an SPD entry requiring the
        packet to be discarded.

            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.

            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)


Kent & Seo                                                     [Page 41]


Internet Draft        Security Architecture for IP            April 2004


            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 ICMP messages under these circumstances, and if this
    facility is selected, to rate limit the transmission of such ICMP
    responses.


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, with
    regard to outbound traffic processing.  This includes how to
    construct the encapsulating (outer) IP header, how to process fields
    in the inner IP header, and what other actions should be taken for
    outbound, tunnel mode traffic.  The general processing described here
    is modeled after RFC 2003, "IP Encapsulation with IP" [Per96]:

     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 as noted below for TTL
       (or Hop Limit) and the DS/ECN Fields.  The inner IP header
       otherwise 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.

    Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
    2003) in several ways:


     o IPsec offers certain controls to a security administrator to
       manage covert channels (which would not normally be a concern for
       tunneling) and to ensure that the receiver examines the right


Kent & Seo                                                     [Page 42]


Internet Draft        Security Architecture for IP            April 2004


       portions of the received packet re: application of access
       controls. An IPsec implementation MAY be configurable with regard
       to how it processes the DS field for tunnel mode for transmitted
       packets. For outbound traffic, one configuration setting for DSCP
       will operate as described in the following sections on IPv4 and
       IPv6 header processing for IPsec tunnels. Another will allow the
       DS field to be mapped to a fixed value, which MAY be configured on
       a per SA basis. (The value might really be fixed for all traffic
       outbound from a device, but per SA granularity allows that as
       well.) This configuration option allows a local administrator to
       decide whether the covert channel provided by copying these bits
       outweighs the benefits of copying.

     o IPsec describes how to handle ECN or DS.

     o IPsec allows the IP version of the encapsulating header to be
       different from that of the inner header.

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


5.1.2.1 IPv4 -- Header Construction for Tunnel Mode

                             <-- How Outer Hdr Relates to Inner Hdr -->
                             Outer Hdr at                 Inner Hdr at
        IPv4                 Encapsulator                 Decapsulator
          Header fields:     --------------------         ------------
            version          4 (1)                        no change
            header length    constructed                  no change
            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
            fragment offset  constructed                  no change
            TTL              constructed (2)              decrement (2)
            protocol         AH, ESP                      no change
            checksum         constructed                  constructed (2)(6)
            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.



Kent & Seo                                                     [Page 43]


Internet Draft        Security Architecture for IP            April 2004


              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 IPv4 checksum changes
                 when the TTL changes.)

                 Note: Decrementing the TTL value is a normal part of
                 forwarding a packet.  Thus, a packet originating from
                 the same node as the encapsulator does not have its TTL
                 decremented, since the sending node is originating the
                 packet rather than forwarding it.

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

                 Note: For multicast traffic, the destination address, or
                 source and destination addresses, may be required for
                 demuxing. In that case, it is important to ensure
                 consistency over the lifetime of the SA by ensuring that
                 the source address that appears in the encapsulating
                 tunnel header is the same as the one that was negotiated
                 during the SA establishment process. There is an
                 exception to this general rule, i.e., a mobile IPsec
                 implementation will update its source address as it
                 moves.

              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.  (The IPv4 checksum changes when the ECN
                 changes.)

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



Kent & Seo                                                     [Page 44]


Internet Draft        Security Architecture for IP            April 2004


5.1.2.2 IPv6 -- Header Construction for Tunnel Mode

    See previous section 5.1.2.1 for notes 1-6 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 (5)    no change
         ECN Field        copied from inner hdr        constructed (6)
         flow label       copied or configured         no change
         payload length   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 (7)             no change

              7. IPsec does not copy the extension headers from the inner
                 packet into the outer header, nor does IPsec construct
                 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 (unprotected-to-protected)

    Inbound processing is somewhat different from outbound processing,
    because of the use of SPIs to map IPsec protected traffic to SAs. The
    inbound SPD cache (SPD-I) is applied only to bypassed or discarded
    traffic. If an arriving packet appears to be an IPsec fragment from
    an unprotected interface, reassembly is performed prior to the IPsec
    processing.  The intent for any SPD cache is that a packet that fails
    to match any entry is then referred to the corresponding SPD. Every
    SPD SHOULD have a nominal, final entry that catches anything that is
    otherwise unmatched, and discards it. This ensures that non-IPsec
    protected traffic that arrives and does not match any SPD-I entry
    will be discarded.










Kent & Seo                                                     [Page 45]


Internet Draft        Security Architecture for IP            April 2004



                       Unprotected Interface
                                 |
                                 V
                              +-----+   IPsec protected
          ------------------->|Demux|-------------------+
          |                   +-----+                   |
          |                      |                      |
          |            Not IPsec |                      |
          |                      |                      |
          |                      V                      |
          |     +-------+    +-------+   +------+       |
          |     |DISCARD|<---| SPD-I |-->| ICMP |       |
          |     +-------+    +-------+   +------+       |
          |                   |                         V
       +-----+                |                    +--------+
   ....|SPD-O|................|....................|PROTECT |...IPsec
       +-----+                |                    |(AH/ESP)| Boundary
          ^                   |                    +--------+
          |                   |       +---+             |
          |            BYPASS |   +-->|IKE|             |
          |                   |   |   +---+             |
          |                   V   |                     V
          |               +----------+             +---------+
          |--------<------|Forwarding|<------------|SAD Check|
                          +----------+             +---------+
                                |
                                V
                        Protected Interface

             Figure 3.  Inbound Traffic Processing Model



    Prior to performing AH or ESP processing, any IP fragments that
    arrive via the unprotected interface are reassembled (by IP).  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 a next layer protocol in the IPv6
    context).

    IPsec MUST perform the following steps:

    1. When a packet arrives, it may be tagged with the ID of the
       interface (physical or virtual) via which it arrived, if necessary
       to support multiple SPDs with different SPD-I entries. (The
       interface ID is mapped to a corresponding SPD-ID.)



Kent & Seo                                                     [Page 46]


Internet Draft        Security Architecture for IP            April 2004


    2. The packet is examined and demuxed into one of three categories:
        - If the packet appears to be IPsec protected and it is addressed
          to this device, an attempt is made to map it to an active SA
          via the SAD.
        - Traffic not addressed to this device, or addressed to this
          device and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD
          lookup. (IKE traffic MUST have an explicit BYPASS entry in the
          SPD.) If multiple SPDs are employed, the tag assigned to the
          packet in step 1 is used to select the appropriate SPD-I (and
          cache) to search.
        - ICMP traffic directed to this device is directed to
          "unprotected" ICMP processing (see Section 6).

    3a. If the packet is addressed to the IPsec device and AH or ESP is
       specified as the protocol, the packet is looked up in the SAD
       identified by the SPD-ID from step 1. For unicast traffic, use
       only the SPI (or SPI plus protocol). For multicast traffic, use
       the SPI plus the destination and/or source addresses, as specified
       in the SAD. If there is no match, discard the traffic.  This is an
       auditable event. The audit log entry for this event SHOULD include
       the current date/time, SPI, source and destination of the packet,
       IPsec protocol, and any other selector values of the packet that
       are available.  If the packet is found in the SAD, process it
       accordingly (see step 4).

    3b. If the packet is not addressed to the device or is addressed to
       this device and is not AH, ESP, or ICMP, look up the packet header
       in the (appropriate) SPD-I cache. If there is a match and the
       packet is to be discarded or bypassed, do so. If there is no cache
       match, look up the packet in the corresponding SPD-I and create a
       cache entry as appropriate. (No SAs are created in response to
       receipt of a packet that requires IPsec protection; only BYPASS or
       DISCARD entries can be created this way.) If there is no match,
       discard the traffic. This is an auditable event. The audit log
       entry for this event SHOULD include the current date/time, SPI if
       available, IPsec protocol if available, source and destination of
       the packet, and any other selector values of the packet that are
       available.

    3c. Unprotected ICMP processing is assumed to take place on the
       unprotected side of the IPsec boundary. Unprotected ICMP messages
       are examined and local policy is applied to determine whether to
       accept or reject these messages and, if accepted, what action to
       take as a result. For example, if an ICMP unreachable message is
       received, the implementation must decide whether to act on it,
       reject it, or act on it with constraints. [See Section 6.]

    4. Apply AH or ESP processing as specified, using the SAD entry


Kent & Seo                                                     [Page 47]


Internet Draft        Security Architecture for IP            April 2004


       selected in step 3a above.  Then match the packet against the
       inbound selectors identified by the SAD entry to verify that the
       received packet is appropriate for the SA via which it was
       received.

       If an IPsec system receives an inbound packet on an SA and the
       packet's header fields are not consistent with the selectors for
       the SA, it MUST discard the packet. This is an auditable event.
       The audit log entry for this event SHOULD include the current
       date/time, SPI, IPsec protocol(s), source and destination of the
       packet, and any other selector values of the packet that are
       available, and the selector values from the relevant SAD entry.
       The system SHOULD also be capable of generating and sending an IKE
       notification to the sender (IPsec peer), indicating that the
       received packet was discarded because of failure to pass selector
       checks.

               IKEv2 NOTIFY MESSAGES - ERROR TYPES        Value
               -----------------------------------        -----
               INVALID_SELECTORS                          iana-tbd

               This error indication MAY be sent in an IKE INFORMATIONAL
               exchange when a node receives an ESP or AH packet whose
               selectors do not match those of the SA on which it was
               delivered (and which caused the packet to be discarded).
               The Notification Data contains the start of the offending
               packet (as in ICMP messages) and the SPI field of the
               notification is set to match the SPI of the IPsec SA.

    To minimize the impact of a DoS attack or a mis-configured peer, the
    IPsec system SHOULD include a management control to allow an
    administrator to configure the IPsec implementation to send or not
    send this IKE notification, and if this facility is selected, to rate
    limit the transmission of such notifications.

    After traffic is bypassed or processed through IPsec, it is handed to
    the inbound forwarding function for disposition. This function may
    cause the packet to be sent (outbound) across the IPsec boundary for
    additional inbound IPsec processing, e.g., in support of nested SAs.
    If so, then as with ALL outbound traffic that is to be bypassed, the
    packet MUST be matched against an SPD-O entry. Ultimately, the packet
    should be forwarded to the destination host or process for
    disposition.







Kent & Seo                                                     [Page 48]


Internet Draft        Security Architecture for IP            April 2004


6. ICMP Processing

    [This section will be filled in when IPsec issue # 91 is resolved.]



7. Handling Fragments (on the protected side of the IPsec boundary)


    Earlier sections of this document describe mechanisms for (a)
    fragmenting an outbound packet after IPsec processing has been
    applied and reassembling it at the receiver before IPsec processing
    and (b) handling inbound fragments received from the unprotected side
    of the IPsec boundary.  This section describes how an implementation
    should handle the processing of outbound plaintext fragments on the
    protected side of the IPsec boundary. (See Appendix E for discussion
    of Fragment Handling Rationale.) In particular, it addresses:

            o mapping an outbound non-initial fragment to the right SA
              (or finding the right SPD entry)
            o verifying that a received non-initial fragment is
              authorized for the SA via which it was received
            o mapping outbound and inbound non-initial fragments to the
              right SPD-O/SPD-I entry or the relevant cache entry, for
              BYPASS/DISCARD traffic

    Note: In Section 4.1, transport mode SAs have been defined to not
    carry fragments (IPv4 or IPv6).  Note also that in Section 4.4.1, two
    special values, ANY and OPAQUE, were defined for selectors and that
    ANY includes OPAQUE.

    Note: The term "non-initial fragment" is used here to indicate a
    fragment that does not contain all the selector values that may be
    needed for access control.  As observed in Section 4.4.1, depending
    on the Next Layer Protocol, in addition to Ports, the ICMP message
    type/code or Mobility Header type could be missing from non-initial
    fragments.  Also, for IPv6, even an initial fragment might NOT
    contain the Next Layer Protocol or Ports (or ICMP message type/code,
    or Mobility Header type) depending on the kind and number of
    extension headers present.  If a non-initial fragment contains the
    Port (or ICMP type and code or Mobility header type) but not the Next
    Layer Protocol, then unless there is an SPD entry for the relevant
    Local/Remote addresses with ANY for Next Layer Protocol and Port (or
    ICMP type and code or Mobility header type), the fragment would not
    contain all the selector information needed for access control.

    To address the above requirements, three approaches have been
    defined:


Kent & Seo                                                     [Page 49]


Internet Draft        Security Architecture for IP            April 2004


    1. All implementations MUST support tunnel mode SAs that are
    configured to pass traffic without regard to port field (or ICMP
    type/code or Mobility Header type) values. If the SA will carry
    traffic for specified protocols, the selector set for the SA MUST
    specify the port fields (or ICMP type/code or Mobility Header type)
    as ANY. An SA defined in this fashion will carry all traffic
    including initial and non-initial fragments for the indicated
    Local/Remote addresses and specified Next Layer protocol(s). If the
    SA will carry traffic without regard to a specific protocol value
    (i.e., ANY is specified as the (Next Layer) protocol selector value),
    then the port field values are undefined and MUST be set to ANY as
    well. (As noted in 4.4.1, ANY includes OPAQUE as well as all specific
    values.)

    2. All implementations MAY/SHOULD support tunnel mode SAs that will
    carry only non-initial fragments, separate from non-fragmented
    packets and initial fragments. The OPAQUE value will be used to
    specify port (or ICMP type/code or Mobility Header type) field
    selectors for an SA to carry such fragments. Receivers MUST perform a
    minimum offset check on IPv4 (non-initial) fragments to protect
    against overlapping fragment attacks when SAs of this type are
    employed. Because such checks cannot be performed on IPv6 non-initial
    fragments, users and administrators are advised that carriage of such
    fragments may be dangerous, and implementers may choose to NOT
    support such SAs for IPv6 traffic. Also, because an SA of this sort
    will carry ALL non-initial fragments that match a specified
    Local/Remote address pair and protocol value, users and
    administrators are advised to protect such traffic using ESP (with
    integrity) and the "strongest" integrity and encryption algorithms
    available at both peers.  (Determination of the "strongest"
    algorithms requires imposing an ordering of the available algorithms,
    a local determination at the discretion of the initiator of the SA.)

    Specific port (or ICMP type/code or Mobility header type) selector
    values will be used to define SAs to carry initial fragments and non-
    fragmented packets. This approach can be used if a user or
    administrator wants to create one or more tunnel mode SAs between the
    same Local/Remote addresses that discriminate based on port (or ICMP
    type/code or Mobility header type) fields.  These SAs MUST have non-
    trivial protocol selector values, otherwise approach #1 above MUST be
    used.

    Note: In general, for approach 2, one needs only a single SA between
    two implementations to carry all non-initial fragments.  However, if
    one chooses to have multiple SAs between the two implementations for
    QoS differentiation, then one might also want multiple SAs to carry
    fragments-without-ports, one for each supported QoS class.  Since
    support for QoS via distinct SAs is a local matter, not mandated by


Kent & Seo                                                     [Page 50]


Internet Draft        Security Architecture for IP            April 2004


    2401bis, the choice to have multiple SAs to carry non-initial
    fragments should also be local.

    3. An implementation MAY/SHOULD support some form of stateful
    fragment checking for a tunnel mode SA with non-trivial port (or ICMP
    type/code or MH type) field values (not ANY or OPAQUE).
    Implementations that will transmit non-initial fragments on a tunnel
    mode SA that makes use of non-trivial port (or ICMP type/code or MH
    type) selectors MUST notify a peer via the IKE NOTIFY payload:

            IKEv2 NOTIFY MESSAGES - ERROR TYPES        Value
            -----------------------------------        -----
            NON FIRST FRAGMENTS ALSO                   iana-tbd


    The peer MUST reject this proposal if it will not accept non-initial
    fragments in this context. If an implementation does not successfully
    negotiate transmission of non-initial fragments for such an SA, it
    MUST NOT send such fragments over the SA.  This standard does not
    specify how peers will deal with such fragments, e.g., via reassembly
    or other means, at either sender or receiver. However, a receiver
    MUST discard non-initial fragments that arrive on an SA with non-
    trivial port (or ICMP type/code or MH type) selector values unless
    this feature has been negotiated.  Also, the receiver MUST discard
    non-initial fragments that do not comply with the security policy
    applied to the overall packet.  Discarding such packets is an
    auditable event. Note that in network configurations where fragments
    of a packet might be sent or received via different security gateways
    or BITW implementations, stateful strategies for tracking fragments
    may fail. Also note that stateful fragment checking may create DoS
    opportunities that may be exploitable by hosts on a protected network
    behind a security gateway.

    An implementation MAY/SHOULD choose to support stateful fragment
    checking for BYPASS/DISCARD traffic for a tunnel mode SA with non-
    trivial port field values (not ANY or OPAQUE) (Approach 3 above).  An
    implementation also MUST permit a user or administrator to accept or
    reject BYPASS/DISCARD traffic using the SPD conventions described in
    approaches 1 and 2 above.



8. 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 this document and
    for each of these events a minimum set of information that SHOULD be


Kent & Seo                                                     [Page 51]


Internet Draft        Security Architecture for IP            April 2004


    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.


9. Conformance Requirements

    All IPv4 systems that claim to implement IPsec MUST comply with all
    requirements of this document.  All IPv6 systems that claim to
    implement IPsec MUST comply with all requirements of this document.


10. Security Considerations

    The focus of this document is security; hence security considerations
    permeate this specification.


11. Differences from RFC 2401

    [This section will be further updated when things have settled down.
    Issue numbers, status, rejected items, and "proposed changes", etc.
    will be removed in final version. Only the text describing the
    differences from 2401 will remain.]

    This architecture document differs substantially from RFC 2401 in
    detail and in organization, but the fundamental notions are
    unchanged.

    o [Issues 40,44,45]
            - 40 [closed] "Interface SPD selector vs. per-interface SPD"
            - 44 [pending] "Proposed change: forwarding table lookup to
              select virtual interface ID"
            - 45 [pending] "Proposed change: use of cache with
              decorrelated SPD"

    The processing model has been revised to address new IPsec scenarios,
    improve performance and simplify implementation.  This includes a
    separation between forwarding (routing) and SPD selection, several SPD
    changes, and the addition of an outbound SPD cache and an inbound SPD
    cache for bypassed or discarded traffic.

    o [Issue #46] [closed] "Proposed change: no need for iterated
    processing" -- There is no longer a requirement to support nested SAs


Kent & Seo                                                     [Page 52]


Internet Draft        Security Architecture for IP            April 2004


    or "SA bundles."  Instead this functionality can be achieved through
    SPD and forwarding table configuration.

    o [Issue #47] [closed] "Proposed change: all selectors can be a list
    of ranges, per IKEv2 spec"

    SPD entries were redefined to provide more flexibility. Each SPD
    entry now consists of a set of selectors, where each selector set
    contains one protocol and a "list of ranges" can now be specified for
    the Local IP address, Remote IP address, Local Port, Remote Port, and
    ICMP message type and code. An individual value for a selector is
    represented via a trivial range and ANY is represented via a range
    than spans all values for the selector. An ASN.1 description is
    included in Appendix D.

    o [Issue #48] [closed] "Proposed change: add ToS traffic selector
    option" -- TOS (IPv4) and Traffic Class (IPv6) have been replaced by
    DSCP and ECN.

    o [Issues #49 and #88]
            - 49 [closed] "Proposed change: red-side fragmentation option"
            - 88 [accepted] "Lift the prohibition on red-side
              fragmentation by SG, BITS, BITW"
    For tunnel mode SAs, an SG, BITS, or BITW implementation is now
    allowed to fragment packets before applying IPsec.  This applies only
    to IPv4.  For IPv6 packets, only the originator is allowed to
    fragment it.

    o [Issue #50 and #87]
            - 50 [closed] "Proposed change: tunnel vs. transport mode"
            - 87 [closed] "Permit Security Gateways to use transport mode
              when they are the endpoints of the communication"
    When security is desired between two intermediate systems along a
    path or between an intermediate system and an end system, transport
    mode may now be used between security gateways and between a security
    gateway and a host.

    o [Issue #57] [closed] "ECN support"

    The tunnel section has been updated to explain how to handle DSCP and
    ECN bits.

    o [Issue #67] [closed] "IPsec management traffic"

    2401bis clarifies that for all traffic that crosses the IPsec
    boundary, including IPsec management traffic, the SPD or associated
    caches must be consulted.



Kent & Seo                                                     [Page 53]


Internet Draft        Security Architecture for IP            April 2004


    o [Issue #68] [closed] "VPNs with overlapping IP address ranges"

    2401bis now defines how to handle the situation of a security gateway
    with multiple subscribers requiring separate IPsec contexts.

    o [Issue #69] [closed] "Multiple protocols per SPD entry" -- Covered
    by resolution of Issue #47

    o [Issue #70] [closed] "Add diffserv (IPv4) and class (IPv6) as
    selectors -- Covered by Issues #48 and #57

    o [Issue #71] [closed] "Add definition of reserved SPIs"

    A definition of reserved SPIs has been added.

    o [Issue #72] [closed] "Explain why ALL IP packets must be checked"

    Text has been added explaining why ALL IP packets must be checked --
    IPsec includes minimal firewall functionality to support access
    control at the IP layer.

    o [Issue #73] [closed] "IP Option & Ext Hdr handling in Tunnel Mode"

    The tunnel section has been updated to clarify how to handle the IP
    options field and IPv6 extension headers when constructing the outer
    header.

    o [Issue #74] [closed] "Inbound SA lookup -- multicast & unicast"

    SA mapping for inbound traffic has been updated to be consistent with
    the changes made in AH and ESP for support of unicast, anycast, and
    multicast SAs.

    o [Issue #75] [closed] "TOS (now ECN) copying in tunnel mode"

    Guidance has been added re: how to handle the covert channel created
    in tunnel mode by copying the DSCP value to outer header.

    o [Issue #76] [accepted] "More explanation re: ESPv3 TFC padding &
    dummy packets"

    Modified ESP -- added more explanation re: ESPv3 TFC padding. IKEv2
    to be modified to support negotiation of use of TFC padding.

    o [Issue #77] [closed] "Should AH be mandatory?"

    Support for AH in both IPv4 and IPv6 is now a MAY.



Kent & Seo                                                     [Page 54]


Internet Draft        Security Architecture for IP            April 2004


    o [Issue #78] [closed] "PMTU issues" -- Ongoing discussion: PMTU
    discovery (Ravi Kumar (9/30/03), Michael Richardson (11/14/03 and
    11/17/03) Will be updated based on conclusion of discussion on ICMP
    handling.

    o [Issue #79] [closed] "Detection of dead peers and dead SAs -- No
    change required; IKEv2 handles dead peer/SA detection

    o [Issue #80] [closed] "Security gateway discovery" -- The IPSP
    working group was supposed to produce an ID on "SG discovery, Policy
    Exchange and Negotiation Protocol" in June 2003, but has not yet
    posted this draft.

    Added text saying "The IP Security Policy (IPSP) Working Group is a
    possible future source of guidance. One of their goals is to produce
    a Internet Draft on a "Security Gateway Discovery, Policy Exchange
    and Negotiation Protocol."

    o [Issue #81] [closed] "Handling outbound red fragments (e.g., on
    separate SA)" The Issues Tracking Database lists this as Closed
    (rejected). The working group rejected creation of a separate SA for
    fragments. Based on a subsequent discussion on the mailing list,
    2401bis was amended with 3 approaches.

    Three approaches have been added for handling plaintext fragments on
    the protected side of the IPsec boundary. An appendix has been added
    documenting the rationale behind them.

    o [Issue #82] [closed] "Creation of SAs"

    Current 2401bis draft has revised text re: how to derive selector
    values for SAs (from the SPD entry or from the packet, etc.). A new
    table describing the relationship between selector values in an SPD
    entry, the PFP flag, and resulting selector values in the
    corresponding SAD entry. Also, an appendix on decorrelation has been
    added.

    o [Issue #83] [rejected] "DROP'd inbound packet -- missing required
    IPsec protection"

    o [Issue #84] [closed] "DROP'd outbound packet"

    If an IPsec system receives an outbound packet which it finds it must
    discard, it SHOULD be capable of generating and sending an ICMP
    message to indicate to the sender of the outbound packet that the
    packet was discarded.

    o [Issue #85] [closed] "DROP'd inbound packet -- does not match SA"


Kent & Seo                                                     [Page 55]


Internet Draft        Security Architecture for IP            April 2004


    If an IPsec system receives an inbound packet on an SA and the
    packet's header fields are not consistent with the selectors for the
    SA, it SHOULD be able to send an IKE notification to the sender of
    the packet.

    o [Issue #86] [closed] "Add IPv6 mobility header message type as
    selector"

    IPv6 mobility header has been added as a possible Next Layer
    Protocol. IPv6 mobility header message type has been added as a
    selector.

    o [Issue #87] [closed] "Permit Security Gateways to use transport
    mode when they are the endpoints of the communication" -- See Issue
    50.

    o [Issue #88] [accepted] "Lift the prohibition on red-side
    fragmentation by SG, BITS, BITW" -- See Issue 49.

    o [Issue #89] [closed] " Remove the selector "name"" -- Rejected.
    See issue 93.

    o [Issue #90] [closed] "Remove the selector "data sensitivity level"
    -- The selector "data sensitivity level" has been removed to simplify
    things.

    o [Issue #91] [pending] "Handling ICMP error messages" -- Ongoing
    discussion

    o [Issue #93] [pending] "Clarification re: the selector "name""

    The text for the selector name has been updated and clarified.

    o [ na ] "Next Layer Protocol" has been further explained and a
    default list of protocols to skip when looking for the Next Layer
    Protocol has been added.

    o [ na ] The text has been amended to say that 2401bis assumes use of
    IKEv2 or an SA management protocol with comparable features.

    o [ na ] Text has been added clarifying the algorithm for mapping
    inbound IPsec datagrams to SAs in the presence of multicast SAs

    o [ na ] Text and an ASN.1 description have been added to clarify the
    structure of an SPD entry and its alignment with what can be
    negotiated in IKE.




Kent & Seo                                                     [Page 56]


Internet Draft        Security Architecture for IP            April 2004


Acknowledgements

    The authors 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.
    Also a contributor who wishes to remain nameless, deserves special
    thanks for providing extensive help in the editing of this
    specification.  The authors also would like to thank the members of
    the IPsec and MSEC working groups who have contributed to the
    development of this protocol specification.








































Kent & Seo                                                     [Page 57]


Internet Draft        Security Architecture for IP            April 2004


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., [Shi00, 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 & Seo                                                     [Page 58]


Internet Draft        Security Architecture for IP            April 2004


    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.

    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.

    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.

    Protected vs Unprotected
       "Protected" refers to the systems or interfaces that are inside
       the IPsec protection boundary and "unprotected" refers to the
       systems or interfaces that are outside the IPsec protection
       boundary. IPsec provides a boundary through which traffic passes.
       There is an asymmetry to this barrier, which is reflected in the
       processing model. Outbound data, if not discarded or bypassed, is
       protected via the application of AH or ESP and the addition of the
       corresponding headers.  Inbound data, if not discarded or
       bypassed, is processed via the removal of AH or ESP headers. In
       this document, inbound traffic enters an IPsec implementation from
       the "unprotected" interface.  Outbound traffic enters the
       implementation via the "protected" interface, or is internally
       generated by the implementation on the "protected" side of the
       boundary and directed toward the "unprotected" interface. An IPsec
       implementation may support more than one interface on either or
       both sides of the boundary.  The protected interface may be
       internal, e.g., in a host implementation of IPsec.  The protected
       interface may link to a socket layer interface presented by the


Kent & Seo                                                     [Page 59]


Internet Draft        Security Architecture for IP            April 2004


       OS.

    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.  State data
       associated with an SA is represented in the Security Association
       Database (SAD).

    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
       termed unprotected (they are generally at least less protected
       than those "behind" the SG), while the networks and hosts on the
       internal side are viewed as protected.  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 directly or via another security gateway).

    SPI
       Acronym for "Security Parameters Index" (SPI). The SPI is an
       arbitrary 32-bit value that is used by a receiver to identify the
       SA to which an incoming packet should be bound. 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.  Additional IP
       address information is used to identify multicast SAs. 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]




Kent & Seo                                                     [Page 60]


Internet Draft        Security Architecture for IP            April 2004


Appendix B - Decorrelation

    This section is based on work done for caching of policies in the IP
    Security Policy Working Group by Luis Sanchez, Matt Condell, and John
    Zao.

    Two SPD entries are correlated if there is a non-null intersection
    between the values of corresponding selectors in each entry.  Caching
    correlated SPD entries can lead to incorrect policy enforcement.  A
    solution to this problem, that still allows for caching, is to remove
    the ambiguities by decorrelating the entries.  That is, the SPD
    entries must be rewritten so that for every pair of entries there
    exists a selector for which there is a null intersection between the
    values in both of the entries. Once the entries are decorrelated,
    there is no longer any ordering requirement on them, since only one
    entry will match any lookup.  The next section describes
    decorrelation in more detail and presents an algorithm that may be
    used to implement decorrelation.

    B.1 Decorrelation Algorithm

    The basic decorrelation algorithm takes each entry in a correlated
    SPD and divides it up into a set of entries using a tree structure.
    The resulting entries that are decorrelated with the decorrelated set
    of entries are then added to that decorrelated set.

    The basic algorithm does not guarantee an optimal set of decorrelated
    entries.  That is, the entries may be broken up into smaller sets
    than is necessary, though they will still provide all the necessary
    policy information.  Some extensions to the basic algorithm are
    described later to improve this and improve the performance of the
    algorithm.

            C  A set of ordered, correlated entries (a correlated SPD)
            Ci The ith entry in C.
            U  The set of decorrelated entries being built from C
            Ui The ith entry in U.
            Sik The kth selection for policy Ci
            Ai The action for policy Ci

    A policy (SPD entry) P may be expressed as a sequence of selector
    values and an action (BYPASS, DISCARD, or PROTECT):

            Ci = Si1 x Si2 x ... x Sik -> Ai

    1) Put C1 in set U as U1

    For each policy Cj (j > 1) in C


Kent & Seo                                                     [Page 61]


Internet Draft        Security Architecture for IP            April 2004



    2) If Cj is decorrelated with every entry in U, then add it to U.

    3) If Cj is correlated with one or more entries in U, create a tree
    rooted at the policy Cj that partitions Cj into a set of decorrelated
    entries.  The algorithm starts with a root node where no selectors
    have yet been chosen.

      A) Choose a selector in Cj, Sjn, that has not yet been chosen when
         traversing the tree from the root to this node.  If there are no
         selectors not yet used, continue to the next unfinished branch
         until all branches have been completed.  When the tree is
         completed, go to step D.

         T is the set of entries in U that are correlated with the entry
         at this node.

         The entry at this node is the entry formed by the selector
         values of each of the branches between the root and this node.
         Any selector values that are not yet represented by branches
         assume the corresponding selector value in Cj, since the values
         in Cj represent the maximum value for each selector.

      B) Add a branch to the tree for each value of the selector Sjn that
         appears in any of the entries in T.  (If the value is a superset
         of the value of Sjn in Cj, then use the value in Cj, since that
         value represents the universal set.)  Also add a branch for the
         complement of the union of all the values of the selector Sjn
         in T.  When taking the complement, remember that the universal
         set is the value of Sjn in Cj.  A branch need not be created
         for the null set.

      C) Repeat A and B until the tree is completed.

      D) The entry to each leaf now represents an entry that is a subset
         of Cj.  The entries at the leaves completely partition Cj in
         such a way that each entry is either completely overridden by
         an entry in U, or is decorrelated with the entries in U.

         Add all the decorrelated entries at the leaves of the tree to U.

    4) Get next Cj and go to 2.

    5) When all entries in C have been processed, then U will contain an
    decorrelated version of C.

    There are several optimizations that can be made to this algorithm.
    A few of them are presented here.


Kent & Seo                                                     [Page 62]


Internet Draft        Security Architecture for IP            April 2004


    It is possible to optimize, or at least improve, the amount of
    branching that occurs by carefully choosing the order of the
    selectors used for the next branch.  For example, if a selector Sjn
    can be chosen so that all the values for that selector in T are equal
    to or a superset of the value of Sjn in Cj, then only a single branch
    needs to be created (since the complement will be null).

    Branches of the tree do not have to proceed with the entire
    decorrelation algorithm.  For example, if a node represents an entry
    that is decorrelated with all the entries in U, then there is no
    reason to continue decorrelating that branch.  Also, if a branch is
    completely overridden by an entry in U, then there is no reason to
    continue decorrelating the branch.

    An additional optimization is to check to see if a branch is
    overridden by one of the CORRELATED entries in set C that has already
    been decorrelated.  That is, if the branch is part of decorrelating
    Cj, then check to see if it was overridden by an entry Cm, m < j.
    This is a valid check, since all the entries Cm are already expressed
    in U.

    Along with checking if an entry is already decorrelated in step 2,
    check if Cj is overridden by any entry in U. If it is, skip it since
    it is not relevant.  An entry x is overridden by another entry y if
    every selector in x is equal to or a subset of the corresponding
    selector in entry y.
























Kent & Seo                                                     [Page 63]

Internet Draft        Security Architecture for IP            April 2004


Appendix C -- Categorization of ICMP messages [May be deleted]

    The tables below characterize ICMP messages as being either host
    generated, router generated, both, unassigned/unknown.  The first set
    of messages are for IPv4.  The second set of messages are for 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 & Seo                                                     [Page 64]

Internet Draft        Security Architecture for IP            April 2004


                                     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 & Seo                                                     [Page 65]

Internet Draft        Security Architecture for IP            April 2004


                                     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 & Seo                                                     [Page 66]


Internet Draft        Security Architecture for IP            April 2004


Appendix D -- ASN.1 for an SPD entry (work in progress)


    This appendix uses ASN.1 syntax to describe the information that is
    contained in an SPD.  Since it describes encodings that are to be
    used with the key management protocol, e.g., IKEv2, using ASN.1
    constraints, it will not compile as shown due to "duplicate" tags.

    -- An SPD is a list of policies in decreasing order of preference
    SPD ::= SEQUENCE OF SPDEntry

    -- An entry describes either traffic to be afforded IPsec protection
    -- or traffic that is to be bypassed or discarded
    SPDEntry ::= CHOICE {
        iPsecEntry       IPsecEntry,              -- PROTECT traffic
        bypassOrDiscard  BypassOrDiscardEntry }   -- DISCARD/BYPASS
                                                  -- traffic

    -- A "selector set"
    IPsecEntry ::= SEQUENCE {               -- Each entry consist of:

        name        SEQUENCE {
            passed      SET OF Names,       -- Matched to IKE ID
            local       SET OF Names },     -- Used internally

        -- Populate from packet flags
        pFPs        BIT STRING { -- applies to ALL of the correspond-
                        pfpLocalAddr  (0),  -- ing traffic selectors;
                        pfpRemoteAddr (1),  -- one does not want to
                        pfpProtocol   (2),  -- allow some SelectorSet
                        pfpLocalNext  (3),  -- items to use one value
                        pfpRemoteNext (4)}, -- and some to use another

        -- Policy "condition"
        condition   SET OF SelectorList,

        -- Policy "action"
        processing  SEQUENCE {
            mode        BOOLEAN,    -- TRUE: transport, FALSE: tunnel
            extSeqNum   BOOLEAN,    -- TRUE: 64 bit, FALSE: 32 bit
            fragCheck   BOOLEAN,    -- TRUE: stateful fragment checking,
                                    -- FALSE: no stateful fragment
                                    --        checking

    [need to add fields/etc. for the following
            SEQ counter overflow
            SA lifetime
            manual SPI


Kent & Seo                                                     [Page 67]


Internet Draft        Security Architecture for IP            April 2004


            DS
            ECN
            DF
            Flow Label]

                        CHOICE {
                aH          IntegrityAlgs,
                eSP         SEQUENCE {
                                IntegrityAlgs,
                                ConfidentialityAlgs } } } }

    Names ::= CHOICE {                      -- IKEv2 IDs:
                    DistinguishedName,      -- ID_DER_ASN1_DN
                    FQDN,                   -- ID_FQDN
                    RFC822Name } OPTIONAL,  -- ID_RFC822_ADDR

    BypassOrDiscardEntry ::= SEQUENCE {
        action      BOOLEAN,        -- TRUE: BYPASS, FALSE: DISCARD
        outbound    SET OF SelectorList OPTIONAL,   -- one or both may
        inbound     SET OF SelectorList OPTIONAL }  -- be present

    -- A "selector set"
    SelectorList ::= SEQUENCE {
        localAddr   AddrList,
        remoteAddr  AddrList,

        protocol    CHOICE {
            -- Representation for ANY protocol
            anyProt     SEQUENCE {
                            INTEGER (0),    -- ANY protocol
                            SEQUENCE {      -- with either
                                ANY,        -- ANY next layer selector
                                ANY },      -- ANY next layer selector

            -- Protocols that have no next layer items
            noNext      SEQUENCE {
                            INTEGER (2..254),
                            SEQUENCE {      -- if protocol has no next
                                OPAQUE,
                                OPAQUE } },

            --  Fragments that have no next layer information
            frag        SEQUENCE {
                            INTEGER (44),   -- Fragment identifier
                            SEQUENCE {
                                OPAQUE,
                                OPAQUE } },



Kent & Seo                                                     [Page 68]


Internet Draft        Security Architecture for IP            April 2004


            -- Protocols that have one next layer item
            oneNext     SEQUENCE {
                            INTEGER (1..254),   -- ICMP, MH, ICMPv6
                            SEQUENCE {          -- ICMP Type*256+Code
                type            NextChoice,     -- MH   Type*256
                                OPAQUE } },

            -- Protocols that have two next layer items
            twoNext     SEQUENCE {
                            INTEGER (2..254),   -- Protocol
                            SEQUENCE {
                local           NextChoice,     -- Local and
                remote          NextChoice }}}  -- Remote ports
            }

    NextChoice ::= CHOICE {
        aNY         ANY,
        oPAQUE      OPAQUE,
        range       Next }

    -- Representation of ANY in next layer field
    ANY ::= SEQUENCE {
        start       INTEGER (0),
        end         INTEGER (65535) }

    -- Representation of OPAQUE in next layer field
    OPAQUE ::= SEQUENCE {
        start       INTEGER (65535),
        end         INTEGER (0) }

    -- Range for a next layer field
    Next ::= SEQUENCE {
        start       INTEGER (0..65535),
        end         INTEGER (0..65535) }

    -- List of IP addresses
    AddrList ::= SEQUENCE {
                    IPv4List OPTIONAL,
                    IPv6List OPTIONAL }











Kent & Seo                                                     [Page 69]


Internet Draft        Security Architecture for IP            April 2004


    -- IPv4 address representations
    IPv4List ::= CHOICE {
        anyIPv4     SEQUENCE {
                        OCTET STRING ('00000000'H) (SIZE (4)),
                        OCTET STRING ('FFFFFFFF'H) (SIZE (4)) },
        ipv4List    SET OF CHOICE {
            ipv4Addr    OCTET STRING (SIZE (4)),
            ipv4Range   SEQUENCE {    -- close, but not quite right ...
                ipv4Start   OCTET STRING ('00000001'H..'FFFFFFFE'H)
                                         (SIZE (4)),
                ipv4End     OCTET STRING ('00000001'H..'FFFFFFFE'H)
                                         (SIZE (4)) } } }

    -- IPv6 address representations
    IPv6List ::= CHOICE {
        anyIPv6     SEQUENCE {
                        OCTET STRING
                              ('00000000000000000000000000000000'H)
                              (SIZE (16)),
                        OCTET STRING
                              ('FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF'H)
                              (SIZE (16)) },
        ipv6List    SET OF CHOICE {
            ipv6Addr    OCTET STRING (SIZE (16)),
            ipv6Range   SEQUENCE {    -- close, but not quite right ...
                ipv6Start   OCTET STRING
                                  ('00000000000000000000000000000001'H
                                 ..'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE'H)
                                  (SIZE (16)),
                ipv6End     OCTET STRING
                                  ('00000000000000000000000000000001'H
                                 ..'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE'H)
                                  (SIZE (16))
                } } }

    -- Integrity Algorithms, ordered by decreasing preference
    IntegrityAlgs ::= SEQUENCE OF IntegAlg

    -- Confidentiality Algorithms, ordered by decreasing preference
    ConfidentialityAlgs ::= SEQUENCE OF ConfAlg










Kent & Seo                                                     [Page 70]


Internet Draft        Security Architecture for IP            April 2004


    -- Integrity Algorithms
    IntegAlg ::= SEQUENCE {
        algorithm   ENUMERATED {
                        NONE (0),
                        AUTH_HMAC_MD5_96 (1),
                        AUTH_HMAC_SHA1_96 (2),
                        AUTH_DES_MAC (3),
                        AUTH_KPDK_MD5(4),
                        AUTH_AES_XCBC_96 (5),
                        TBD (6..65535) },
        parameters  ANY DEFINED BY algorithm OPTIONAL }

    -- Confidentiality Algorithms
    ConfAlg ::= SEQUENCE {
        algorithm   ENUMERATED {
                        ENCR_DES_IV64 (1),
                        ENCR_DES (2),
                        ENCR_3DES (3),
                        ENCR_RC5 (4),
                        ENCR_IDEA (5),
                        ENCR_CAST (6),
                        ENCR_BLOWFISH (7),
                        ENCR_3IDEA (8),
                        ENCR_DES_IV32 (9),
                        ENCR_RC4 (10),
                        ENCR_NULL (11),
                        ENCR_AES_CBC (12),
                        ENCR_AES_CTR (13),
                        TBD (14..65535) },
        parameters  ANY DEFINED BY algorithm OPTIONAL }




















Kent & Seo                                                     [Page 71]


Internet Draft        Security Architecture for IP            April 2004


Appendix E -- Fragment Handling Rationale

    [Will be added in next draft -- based on write up Steve distributed
    on the list plus subsequent discussion.]














































Kent & Seo                                                     [Page 72]


Internet Draft        Security Architecture for IP            April 2004


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.

    [Eas03]   Eastlake, D., "Cryptographic Algorithm Implementation
              Requirements For ESP And AH", draft-ietf-ipsec-esp-ah-
              algorithms-00.txt, December 2003.

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

    [Kau03]   Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol",
              draft-ietf- ipsec-ikev2-11.txt, October 2003

    [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

    [Sch03]   Schiller, J., "Cryptographic Algorithms for use in the
              Internet Key Exchange Version 2", draft-ietf-ipsec-
              ikev2-algorithms-04.txt, September 2003


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


Kent & Seo                                                     [Page 73]


Internet Draft        Security Architecture for IP            April 2004


              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.

    [FaLiHaMeTr00]Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina,
              P., "Generic Routing Encapsulation (GRE), RFC 2784, March
              2000.

    [Gro02]   Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.

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

    [ISO]     ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
              DIS 11577, International Standards Organisation, Geneva,
              Switzerland, 29 November 1992.

    [IB93]    Ioannidis, J. and Blaze, M., "Architecture and
              Implementation of Network-layer Security Under Unix",
              Proceedings of USENIX Security Symposium, Santa Clara, CA,
              October 1993.

    [IBK93]   Ioannidis, J., Blaze, M., and Karn, P., "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.

    [NiBlBaBL98]Nichols, K., Blake, S., Baker, F., Black, D., "Definition
              of the Differentiated Services Field (DS Field) in the IPv4
              and IPv6 Headers", RFC2474, December 1998.

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

    [Per96]   Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.



Kent & Seo                                                     [Page 74]


Internet Draft        Security Architecture for IP            April 2004


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

    [RaFlBL01]Ramakrishnan, K., Floyd, S., Black, D., "The Addition of
              Explicit Congestion Notification (ECN) to IP", RFC 3168,
              September 2001.

    [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group
              Domain of Interpretation", RFC 3547, July 2003.

    [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security
              Architecture", RFC 3740, March 2004.

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

    [Shi00]   Shirey, R., "Internet Security Glossary", RFC 2828, May
              2000.
    [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.

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



Author Information

    Stephen Kent
    BBN Technologies
    10 Moulton Street
    Cambridge, MA  02138
    USA

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








Kent & Seo                                                     [Page 75]


Internet Draft        Security Architecture for IP            April 2004


    Karen Seo
    BBN Technologies
    10 Moulton Street
    Cambridge, MA  02138
    USA

    Phone: +1 (617) 873-3152
    EMail: kseo@bbn.com










































Kent & Seo                                                     [Page 76]


Internet Draft        Security Architecture for IP            April 2004



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 (2004).  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.

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

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


Kent & Seo                                                     [Page 77]


Internet Draft        Security Architecture for IP            April 2004


    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires October 2004















































Kent & Seo                                                     [Page 78]


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