Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4301

Security Architecture for the Internet Protocol

Pages: 101
Proposed Standard
Errata
Obsoletes:  2401
Updates:  3168
Updated by:  60407619
Part 4 of 4 – Pages 76 to 101
First   Prev   None

Top   ToC   RFC4301 - Page 76   prevText

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], and [HA94]. Included in this glossary are generic security service and security mechanism terms, plus IPsec-specific terms. Access Control 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 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 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 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.)
Top   ToC   RFC4301 - Page 77
   Data Origin Authentication
      A security service that verifies the identity of the claimed
      source of data.  This service is usually bundled with
      connectionless integrity service.

   Encryption
      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".  Often the term "encryption" is used to
      generically refer to both processes.

   Integrity
      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
Top   ToC   RFC4301 - Page 78
      internal, e.g., in a host implementation of IPsec.  The protected
      interface may link to a socket layer interface presented by the
      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 SA Database (SAD).

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

   Security Parameters Index (SPI)
      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, and flow identifiers
      [Sch94].
Top   ToC   RFC4301 - Page 79

Appendix B: Decorrelation

This appendix 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, which 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 into a set of entries using a tree structure. The nodes of the tree are the selectors that may overlap between the policies. At each node, the algorithm creates a branch for each of the values of the selector. It also creates one branch for the complement of the union of all selector values. Policies are then formed by traversing the tree from the root to each leaf. The policies at the leaves are compared to the set of already decorrelated policy rules. Each policy at a leaf is either completely overridden by a policy in the already decorrelated set and is discarded or is decorrelated with all the policies in the decorrelated set and is added to it. 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.
Top   ToC   RFC4301 - Page 80
   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

   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.
Top   ToC   RFC4301 - Page 81
   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.

   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.
Top   ToC   RFC4301 - Page 82

Appendix C: ASN.1 for an SPD Entry

This appendix is included as an additional way to describe SPD entries, as defined in Section 4.4.1. It uses ASN.1 syntax that has been successfully compiled. This syntax is merely illustrative and need not be employed in an implementation to achieve compliance. The SPD description in Section 4.4.1 is normative. SPDModule {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) ipsec (8) asn1-modules (3) spd-module (1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS RDNSequence FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; -- An SPD is a list of policies in decreasing order of preference SPD ::= SEQUENCE OF SPDEntry SPDEntry ::= CHOICE { iPsecEntry IPsecEntry, -- PROTECT traffic bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS IPsecEntry ::= SEQUENCE { -- Each entry consists of name NameSets OPTIONAL, pFPs PacketFlags, -- Populate from packet flags -- Applies to ALL of the corresponding -- traffic selectors in the SelectorLists condition SelectorLists, -- Policy "condition" processing Processing -- Policy "action" } BypassOrDiscardEntry ::= SEQUENCE { bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD condition InOutBound } InOutBound ::= CHOICE { outbound [0] SelectorLists, inbound [1] SelectorLists, bothways [2] BothWays }
Top   ToC   RFC4301 - Page 83
       BothWays ::= SEQUENCE {
           inbound     SelectorLists,
           outbound    SelectorLists }

       NameSets ::= SEQUENCE {
           passed      SET OF Names-R,  -- Matched to IKE ID by
                                        -- responder
           local       SET OF Names-I } -- Used internally by IKE
                                        -- initiator

       Names-R ::= CHOICE {                   -- IKEv2 IDs
           dName       RDNSequence,           -- ID_DER_ASN1_DN
           fqdn        FQDN,                  -- ID_FQDN
           rfc822      [0] RFC822Name,        -- ID_RFC822_ADDR
           keyID       OCTET STRING }         -- KEY_ID

       Names-I ::= OCTET STRING       -- Used internally by IKE
                                      -- initiator

       FQDN ::= IA5String

       RFC822Name ::= IA5String

       PacketFlags ::= BIT STRING {
                   -- if set, take selector value from packet
                   -- establishing SA
                   -- else use value in SPD entry
           localAddr  (0),
           remoteAddr (1),
           protocol   (2),
           localPort  (3),
           remotePort (4)  }

       SelectorLists ::= SET OF SelectorList

       SelectorList ::= SEQUENCE {
           localAddr   AddrList,
           remoteAddr  AddrList,
           protocol    ProtocolChoice }

       Processing ::= SEQUENCE {
           extSeqNum   BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
           seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
           fragCheck   BOOLEAN, -- TRUE stateful fragment checking,
                                -- FALSE no stateful fragment checking
           lifetime    SALifetime,
           spi         ManualSPI,
           algorithms  ProcessingAlgs,
Top   ToC   RFC4301 - Page 84
           tunnel      TunnelOptions OPTIONAL } -- if absent, use
                                                -- transport mode

       SALifetime ::= SEQUENCE {
           seconds   [0] INTEGER OPTIONAL,
           bytes     [1] INTEGER OPTIONAL }

       ManualSPI ::= SEQUENCE {
           spi     INTEGER,
           keys    KeyIDs }

       KeyIDs ::= SEQUENCE OF OCTET STRING

       ProcessingAlgs ::= CHOICE {
           ah          [0] IntegrityAlgs,  -- AH
           esp         [1] ESPAlgs}        -- ESP

       ESPAlgs ::= CHOICE {
           integrity       [0] IntegrityAlgs,       -- integrity only
           confidentiality [1] ConfidentialityAlgs, -- confidentiality
                                                    -- only
           both            [2] IntegrityConfidentialityAlgs,
           combined        [3] CombinedModeAlgs }

       IntegrityConfidentialityAlgs ::= SEQUENCE {
           integrity       IntegrityAlgs,
           confidentiality ConfidentialityAlgs }

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

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

       -- Integrity Algorithms
       IntegrityAlg ::= SEQUENCE {
           algorithm   IntegrityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       IntegrityAlgType ::= INTEGER {
           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)
           }
Top   ToC   RFC4301 - Page 85
       -- Confidentiality Algorithms
       ConfidentialityAlg ::= SEQUENCE {
           algorithm   ConfidentialityAlgType,
           parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }

       ConfidentialityAlgType ::= INTEGER {
           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)
           }

       CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg

       CombinedModeAlg ::= SEQUENCE {
           algorithm   CombinedModeType,
           parameters  ANY -- DEFINED BY algorithm} -- defined outside
                                    -- of this document for AES modes.

       CombinedModeType ::= INTEGER {
           comb-AES-CCM    (1),
           comb-AES-GCM    (2)
       --  tbd (3..65535)
           }

       TunnelOptions ::= SEQUENCE {
           dscp        DSCP,
           ecn         BOOLEAN,    -- TRUE Copy CE to inner header
           df          DF,
           addresses   TunnelAddresses }

       TunnelAddresses ::= CHOICE {
           ipv4        IPv4Pair,
           ipv6        [0] IPv6Pair }

       IPv4Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(4)),
           remote      OCTET STRING (SIZE(4)) }
Top   ToC   RFC4301 - Page 86
       IPv6Pair ::= SEQUENCE {
           local       OCTET STRING (SIZE(16)),
           remote      OCTET STRING (SIZE(16)) }

       DSCP ::= SEQUENCE {
           copy      BOOLEAN, -- TRUE copy from inner header
                              -- FALSE do not copy
           mapping   OCTET STRING OPTIONAL} -- points to table
                                            -- if no copy

       DF ::= INTEGER {
           clear   (0),
           set     (1),
           copy    (2) }

       ProtocolChoice::= CHOICE {
           anyProt  AnyProtocol,              -- for ANY protocol
           noNext   [0] NoNextLayerProtocol,  -- has no next layer
                                              -- items
           oneNext  [1] OneNextLayerProtocol, -- has one next layer
                                              -- item
           twoNext  [2] TwoNextLayerProtocol, -- has two next layer
                                              -- items
           fragment FragmentNoNext }          -- has no next layer
                                              -- info

       AnyProtocol ::= SEQUENCE {
           id          INTEGER (0),    -- ANY protocol
           nextLayer   AnyNextLayers }

       AnyNextLayers ::= SEQUENCE {      -- with either
           first       AnyNextLayer,     -- ANY next layer selector
           second      AnyNextLayer }    -- ANY next layer selector

       NoNextLayerProtocol ::= INTEGER (2..254)

       FragmentNoNext ::= INTEGER (44)   -- Fragment identifier

       OneNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (1..254),   -- ICMP, MH, ICMPv6
           nextLayer   NextLayerChoice }   -- ICMP Type*256+Code
                                           -- MH   Type*256

       TwoNextLayerProtocol ::= SEQUENCE {
           id          INTEGER (2..254),   -- Protocol
           local       NextLayerChoice,    -- Local and
           remote      NextLayerChoice }   -- Remote ports
Top   ToC   RFC4301 - Page 87
       NextLayerChoice ::= CHOICE {
           any         AnyNextLayer,
           opaque      [0] OpaqueNextLayer,
           range       [1] NextLayerRange }

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

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

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

       -- List of IP addresses
       AddrList ::= SEQUENCE {
           v4List      IPv4List OPTIONAL,
           v6List      [0] IPv6List OPTIONAL }

       -- IPv4 address representations
       IPv4List ::= SEQUENCE OF IPv4Range

       IPv4Range ::= SEQUENCE {    -- close, but not quite right ...
           ipv4Start   OCTET STRING (SIZE (4)),
           ipv4End     OCTET STRING (SIZE (4)) }

       -- IPv6 address representations
       IPv6List ::= SEQUENCE OF IPv6Range

       IPv6Range ::= SEQUENCE {    -- close, but not quite right ...
           ipv6Start   OCTET STRING (SIZE (16)),
           ipv6End     OCTET STRING (SIZE (16)) }

       END
Top   ToC   RFC4301 - Page 88

Appendix D: Fragment Handling Rationale

There are three issues that must be resolved regarding processing of (plaintext) fragments in IPsec: - mapping a non-initial, outbound fragment to the right SA (or finding the right SPD entry) - verifying that a received, non-initial fragment is authorized for the SA via which it is received - mapping outbound and inbound non-initial fragments to the right SPD/cache entry, for BYPASS/DISCARD traffic The first and third issues arise because we need a deterministic algorithm for mapping traffic to SAs (and SPD/cache entries). All three issues are important because we want to make sure that non-initial fragments that cross the IPsec boundary do not cause the access control policies in place at the receiver (or transmitter) to be violated.

D.1. Transport Mode and Fragments

First, we note that transport mode SAs have been defined to not carry fragments. This is a carryover from RFC 2401, where transport mode SAs always terminated at endpoints. This is a fundamental requirement because, in the worst case, an IPv4 fragment to which IPsec was applied might then be fragmented (as a ciphertext packet), en route to the destination. IP fragment reassembly procedures at the IPsec receiver would not be able to distinguish between pre-IPsec fragments and fragments created after IPsec processing. For IPv6, only the sender is allowed to fragment a packet. As for IPv4, an IPsec implementation is allowed to fragment tunnel mode packets after IPsec processing, because it is the sender relative to the (outer) tunnel header. However, unlike IPv4, it would be feasible to carry a plaintext fragment on a transport mode SA, because the fragment header in IPv6 would appear after the AH or ESP header, and thus would not cause confusion at the receiver with respect to reassembly. Specifically, the receiver would not attempt reassembly for the fragment until after IPsec processing. To keep things simple, this specification prohibits carriage of fragments on transport mode SAs for IPv6 traffic. When only end systems used transport mode SAs, the prohibition on carriage of fragments was not a problem, since we assumed that the end system could be configured to not offer a fragment to IPsec. For a native host implementation, this seems reasonable, and, as someone already noted, RFC 2401 warned that a BITS implementation might have to reassemble fragments before performing an SA lookup. (It would
Top   ToC   RFC4301 - Page 89
   then apply AH or ESP and could re-fragment the packet after IPsec
   processing.) Because a BITS implementation is assumed to be able to
   have access to all traffic emanating from its host, even if the host
   has multiple interfaces, this was deemed a reasonable mandate.

   In this specification, it is acceptable to use transport mode in
   cases where the IPsec implementation is not the ultimate destination,
   e.g., between two SGs.  In principle, this creates a new opportunity
   for outbound, plaintext fragments to be mapped to a transport mode SA
   for IPsec processing.  However, in these new contexts in which a
   transport mode SA is now approved for use, it seems likely that we
   can continue to prohibit transmission of fragments, as seen by IPsec,
   i.e., packets that have an "outer header" with a non-zero fragment
   offset field.  For example, in an IP overlay network, packets being
   sent over transport mode SAs are IP-in-IP tunneled and thus have the
   necessary inner header to accommodate fragmentation prior to IPsec
   processing.  When carried via a transport mode SA, IPsec would not
   examine the inner IP header for such traffic, and thus would not
   consider the packet to be a fragment.

D.2. Tunnel Mode and Fragments

For tunnel mode SAs, it has always been the case that outbound fragments might arrive for processing at an IPsec implementation. The need to accommodate fragmented outbound packets can pose a problem because a non-initial fragment generally will not contain the port fields associated with a next layer protocol such as TCP, UDP, or SCTP. Thus, depending on the SPD configuration for a given IPsec implementation, plaintext fragments might or might not pose a problem. For example, if the SPD requires that all traffic between two address ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries apply to this address range), then it should be easy to carry non-initial fragments on the SA defined for this address range, since the SPD entry implies an intent to carry ALL traffic between the address ranges. But, if there are multiple SPD entries that could match a fragment, and if these entries reference different subsets of port fields (vs. ANY), then it is not possible to map an outbound non-initial fragment to the right entry, unambiguously. (If we choose to allow carriage of fragments on transport mode SAs for IPv6, the problems arises in that context as well.) This problem largely, though not exclusively, motivated the definition of OPAQUE as a selector value for port fields in RFC 2401. The other motivation for OPAQUE is the observation that port fields might not be accessible due to the prior application of IPsec. For example, if a host applied IPsec to its traffic and that traffic
Top   ToC   RFC4301 - Page 90
   arrived at an SG, these fields would be encrypted.  The algorithm
   specified for locating the "next layer protocol" described in RFC
   2401 also motivated use of OPAQUE to accommodate an encrypted next
   layer protocol field in such circumstances.  Nonetheless, the primary
   use of the OPAQUE value was to match traffic selector fields in
   packets that did not contain port fields (non-initial fragments), or
   packets in which the port fields were already encrypted (as a result
   of nested application of IPsec).  RFC 2401 was ambiguous in
   discussing the use of OPAQUE vs. ANY, suggesting in some places that
   ANY might be an alternative to OPAQUE.

   We gain additional access control capability by defining both ANY and
   OPAQUE values.  OPAQUE can be defined to match only fields that are
   not accessible.  We could define ANY as the complement of OPAQUE,
   i.e., it would match all values but only for accessible port fields.
   We have therefore simplified the procedure employed to locate the
   next layer protocol in this document, so that we treat ESP and AH as
   next layer protocols.  As a result, the notion of an encrypted next
   layer protocol field has vanished, and there is also no need to worry
   about encrypted port fields either.  And accordingly, OPAQUE will be
   applicable only to non-initial fragments.

   Since we have adopted the definitions above for ANY and OPAQUE, we
   need to clarify how these values work when the specified protocol
   does not have port fields, and when ANY is used for the protocol
   selector.  Accordingly, if a specific protocol value is used as a
   selector, and if that protocol has no port fields, then the port
   field selectors are to be ignored and ANY MUST be specified as the
   value for the port fields. (In this context, ICMP TYPE and CODE
   values are lumped together as a single port field (for IKEv2
   negotiation), as is the IPv6 Mobility Header TYPE value.) If the
   protocol selector is ANY, then this should be treated as equivalent
   to specifying a protocol for which no port fields are defined, and
   thus the port selectors should be ignored, and MUST be set to ANY.

D.3. The Problem of Non-Initial Fragments

For an SG implementation, it is obvious that fragments might arrive from end systems behind the SG. A BITW implementation also may encounter fragments from a host or gateway behind it. (As noted earlier, native host implementations and BITS implementations probably can avoid the problems described below.) In the worst case, fragments from a packet might arrive at distinct BITW or SG instantiations and thus preclude reassembly as a solution option. Hence, in RFC 2401 we adopted a general requirement that fragments must be accommodated in tunnel mode for all implementations. However,
Top   ToC   RFC4301 - Page 91
   RFC 2401 did not provide a perfect solution.  The use of OPAQUE as a
   selector value for port fields (a SHOULD in RFC 2401) allowed an SA
   to carry non-initial fragments.

   Using the features defined in RFC 2401, if one defined an SA between
   two IPsec (SG or BITW) implementations using the OPAQUE value for
   both port fields, then all non-initial fragments matching the
   source/destination (S/D) address and protocol values for the SA would
   be mapped to that SA.  Initial fragments would NOT map to this SA, if
   we adopt a strict definition of OPAQUE.  However, RFC 2401 did not
   provide detailed guidance on this and thus it may not have been
   apparent that use of this feature would essentially create a
   "non-initial fragment only" SA.

   In the course of discussing the "fragment-only" SA approach, it was
   noted that some subtle problems, problems not considered in RFC 2401,
   would have to be avoided.  For example, an SA of this sort must be
   configured to offer the "highest quality" security services for any
   traffic between the indicated S/D addresses (for the specified
   protocol).  This is necessary to ensure that any traffic captured by
   the fragment-only SA is not offered degraded security relative to
   what it would have been offered if the packet were not fragmented.  A
   possible problem here is that we may not be able to identify the
   "highest quality" security services defined for use between two IPsec
   implementation, since the choice of security protocols, options, and
   algorithms is a lattice, not a totally ordered set. (We might safely
   say that BYPASS < AH < ESP w/integrity, but it gets complicated if we
   have multiple ESP encryption or integrity algorithm options.) So, one
   has to impose a total ordering on these security parameters to make
   this work, but this can be done locally.

   However, this conservative strategy has a possible performance
   downside.  If most traffic traversing an IPsec implementation for a
   given S/D address pair (and specified protocol) is bypassed, then a
   fragment-only SA for that address pair might cause a dramatic
   increase in the volume of traffic afforded crypto processing.  If the
   crypto implementation cannot support high traffic rates, this could
   cause problems. (An IPsec implementation that is capable of line rate
   or near line rate crypto performance would not be adversely affected
   by this SA configuration approach.  Nonetheless, the performance
   impact is a potential concern, specific to implementation
   capabilities.)

   Another concern is that non-initial fragments sent over a dedicated
   SA might be used to effect overlapping reassembly attacks, when
   combined with an apparently acceptable initial fragment. (This sort
   of attack assumes creation of bogus fragments and is not a side
   effect of normal fragmentation.) This concern is easily addressed in
Top   ToC   RFC4301 - Page 92
   IPv4, by checking the fragment offset value to ensure that no
   non-initial fragments have a small enough offset to overlap port
   fields that should be contained in the initial fragment.  Recall that
   the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60
   bytes, so any ports should be present in the initial fragment.  If we
   require all non-initial fragments to have an offset of, say, 128 or
   greater, just to be on the safe side, this should prevent successful
   attacks of this sort.  If the intent is only to protect against this
   sort of reassembly attack, this check need be implemented only by a
   receiver.

   IPv6 also has a fragment offset, carried in the fragmentation
   extension header.  However, IPv6 extension headers are variable in
   length and there is no analogous max header length value that we can
   use to check non-initial fragments, to reject ones that might be used
   for an attack of the sort noted above.  A receiver would need to
   maintain state analogous to reassembly state, to provide equivalent
   protection.  So, only for IPv4 is it feasible to impose a fragment
   offset check that would reject attacks designed to circumvent port
   field checks by IPsec (or firewalls) when passing non-initial
   fragments.

   Another possible concern is that in some topologies and SPD
   configurations this approach might result in an access control
   surprise.  The notion is that if we create an SA to carry ALL
   (non-initial) fragments, then that SA would carry some traffic that
   might otherwise arrive as plaintext via a separate path, e.g., a path
   monitored by a proxy firewall.  But, this concern arises only if the
   other path allows initial fragments to traverse it without requiring
   reassembly, presumably a bad idea for a proxy firewall.  Nonetheless,
   this does represent a potential problem in some topologies and under
   certain assumptions with respect to SPD and (other) firewall rule
   sets, and administrators need to be warned of this possibility.

   A less serious concern is that non-initial fragments sent over a
   non-initial fragment-only SA might represent a DoS opportunity, in
   that they could be sent when no valid, initial fragment will ever
   arrive.  This might be used to attack hosts behind an SG or BITW
   device.  However, the incremental risk posed by this sort of attack,
   which can be mounted only by hosts behind an SG or BITW device, seems
   small.

   If we interpret the ANY selector value as encompassing OPAQUE, then a
   single SA with ANY values for both port fields would be able to
   accommodate all traffic matching the S/D address and protocol traffic
   selectors, an alternative to using the OPAQUE value.  But, using ANY
Top   ToC   RFC4301 - Page 93
   here precludes multiple, distinct SAs between the same IPsec
   implementations for the same address pairs and protocol.  So, it is
   not an exactly equivalent alternative.

   Fundamentally, fragment handling problems arise only when more than
   one SA is defined with the same S/D address and protocol selector
   values, but with different port field selector values.

D.4. BYPASS/DISCARD Traffic

We also have to address the non-initial fragment processing issue for BYPASS/DISCARD entries, independent of SA processing. This is largely a local matter for two reasons: 1) We have no means for coordinating SPD entries for such traffic between IPsec implementations since IKE is not invoked. 2) Many of these entries refer to traffic that is NOT directed to or received from a location that is using IPsec. So there is no peer IPsec implementation with which to coordinate via any means. However, this document should provide guidance here, consistent with our goal of offering a well-defined, access control function for all traffic, relative to the IPsec boundary. To that end, this document says that implementations MUST support fragment reassembly for BYPASS/DISCARD traffic when port fields are specified. An implementation also MUST permit a user or administrator to accept such traffic or reject such traffic using the SPD conventions described in Section 4.4.1. The concern is that BYPASS of a cleartext, non-initial fragment arriving at an IPsec implementation could undermine the security afforded IPsec-protected traffic directed to the same destination. For example, consider an IPsec implementation configured with an SPD entry that calls for IPsec-protection of traffic between a specific source/destination address pair, and for a specific protocol and destination port, e.g., TCP traffic on port 23 (Telnet). Assume that the implementation also allows BYPASS of traffic from the same source/destination address pair and protocol, but for a different destination port, e.g., port 119 (NNTP). An attacker could send a non-initial fragment (with a forged source address) that, if bypassed, could overlap with IPsec-protected traffic from the same source and thus violate the integrity of the IPsec-protected traffic. Requiring stateful fragment checking for BYPASS entries with non-trivial port ranges prevents attacks of this sort.
Top   ToC   RFC4301 - Page 94

D.5. Just say no to ports?

It has been suggested that we could avoid the problems described above by not allowing port field selectors to be used in tunnel mode. But the discussion above shows this to be an unnecessarily stringent approach, i.e., since no problems arise for the native OS and BITS implementations. Moreover, some WG members have described scenarios where use of tunnel mode SAs with (non-trivial) port field selectors is appropriate. So the challenge is defining a strategy that can deal with this problem in BITW and SG contexts. Also note that BYPASS/DISCARD entries in the SPD that make use of ports pose the same problems, irrespective of tunnel vs. transport mode notions. Some folks have suggested that a firewall behind an SG or BITW should be left to enforce port-level access controls and the effects of fragmentation. However, this seems to be an incongruous suggestion in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned about firewalls that always discard fragments. If many firewalls don't pass fragments in general, why should we expect them to deal with fragments in this case? So, this analysis rejects the suggestion of disallowing use of port field selectors with tunnel mode SAs.

D.6. Other Suggested Solutions

One suggestion is to reassemble fragments at the sending IPsec implementation, and thus avoid the problem entirely. This approach is invisible to a receiver and thus could be adopted as a purely local implementation option. A more sophisticated version of this suggestion calls for establishing and maintaining minimal state from each initial fragment encountered, to allow non-initial fragments to be matched to the right SAs or SPD/cache entries. This implies an extension to the current processing model (and the old one). The IPsec implementation would intercept all fragments; capture Source/Destination IP addresses, protocol, packet ID, and port fields from initial fragments; and then use this data to map non-initial fragments to SAs that require port fields. If this approach is employed, the receiver needs to employ an equivalent scheme, as it too must verify that received fragments are consistent with SA selector values. A non-initial fragment that arrives prior to an initial fragment could be cached or discarded, awaiting arrival of the corresponding initial fragment. A downside of both approaches noted above is that they will not always work. When a BITW device or SG is configured in a topology that might allow some fragments for a packet to be processed at different SGs or BITW devices, then there is no guarantee that all
Top   ToC   RFC4301 - Page 95
   fragments will ever arrive at the same IPsec device.  This approach
   also raises possible processing problems.  If the sender caches
   non-initial fragments until the corresponding initial fragment
   arrives, buffering problems might arise, especially at high speeds.
   If the non-initial fragments are discarded rather than cached, there
   is no guarantee that traffic will ever pass, e.g., retransmission
   will result in different packet IDs that cannot be matched with prior
   transmissions.  In any case, housekeeping procedures will be needed
   to decide when to delete the fragment state data, adding some
   complexity to the system.  Nonetheless, this is a viable solution in
   some topologies, and these are likely to be common topologies.

   The Working Group rejected an earlier version of the convention of
   creating an SA to carry only non-initial fragments, something that
   was supported implicitly under the RFC 2401 model via use of OPAQUE
   port fields, but never clearly articulated in RFC 2401.  The
   (rejected) text called for each non-initial fragment to be treated as
   protocol 44 (the IPv6 fragment header protocol ID) by the sender and
   receiver.  This approach has the potential to make IPv4 and IPv6
   fragment handling more uniform, but it does not fundamentally change
   the problem, nor does it address the issue of fragment handling for
   BYPASS/DISCARD traffic.  Given the fragment overlap attack problem
   that IPv6 poses, it does not seem that it is worth the effort to
   adopt this strategy.

D.7. Consistency

Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform fragmentation prior to IPsec processing. If this fragmentation is performed after SA lookup at the sender, there is no "mapping to the right SA" problem. But, the receiver still needs to be able to verify that the non-initial fragments are consistent with the SA via which they are received. Since the initial fragment might be lost en route, the receiver encounters all of the potential problems noted above. Thus, if we are to be consistent in our decisions, we need to say how a receiver will deal with the non-initial fragments that arrive.

D.8. Conclusions

There is no simple, uniform way to handle fragments in all contexts. Different approaches work better in different contexts. Thus, this document offers 3 choices -- one MUST and two MAYs. At some point in the future, if the community gains experience with the two MAYs, they may become SHOULDs or MUSTs or other approaches may be proposed.
Top   ToC   RFC4301 - Page 96

Appendix E: Example of Supporting Nested SAs via SPD and Forwarding Table Entries

This appendix provides an example of how to configure the SPD and forwarding tables to support a nested pair of SAs, consistent with the new processing model. For simplicity, this example assumes just one SPD-I. The goal in this example is to support a transport mode SA from A to C, carried over a tunnel mode SA from A to B. For example, A might be a laptop connected to the public Internet, B might be a firewall that protects a corporate network, and C might be a server on the corporate network that demands end-to-end authentication of A's traffic. +---+ +---+ +---+ | A |=====| B | | C | | |------------| | | |=====| | | | +---+ +---+ +---+ A's SPD contains entries of the form: Next Layer Rule Local Remote Protocol Action ---- ----- ------ ---------- ----------------------- 1 C A ESP BYPASS 2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf) 3 A C ANY PROTECT(ESP,transport,integr-only) 4 A B ICMP,IKE BYPASS A's unprotected-side forwarding table is set so that outbound packets destined for C are looped back to the protected side. A's protected-side forwarding table is set so that inbound ESP packets are looped back to the unprotected side. A's forwarding tables contain entries of the form: Unprotected-side forwarding table Rule Local Remote Protocol Action ---- ----- ------ -------- --------------------------- 1 A C ANY loop back to protected side 2 A B ANY forward to B
Top   ToC   RFC4301 - Page 97
      Protected-side forwarding table

        Rule Local Remote Protocol Action
        ---- ----- ------ -------- -----------------------------
         1     A     C       ESP   loop back to unprotected side

   An outbound TCP packet from A to C would match SPD rule 3 and have
   transport mode ESP applied to it.  The unprotected-side forwarding
   table would then loop back the packet.  The packet is compared
   against SPD-I (see Figure 2), matches SPD rule 1, and so it is
   BYPASSed.  The packet is treated as an outbound packet and compared
   against the SPD for a third time.  This time it matches SPD rule 2,
   so ESP is applied in tunnel mode.  This time the forwarding table
   doesn't loop back the packet, because the outer destination address
   is B, so the packet goes out onto the wire.

   An inbound TCP packet from C to A is wrapped in two ESP headers; the
   outer header (ESP in tunnel mode) shows B as the source, whereas the
   inner header (ESP transport mode) shows C as the source.  Upon
   arrival at A, the packet would be mapped to an SA based on the SPI,
   have the outer header removed, and be decrypted and
   integrity-checked.  Then it would be matched against the SAD
   selectors for this SA, which would specify C as the source and A as
   the destination, derived from SPD rule 2.  The protected-side
   forwarding function would then send it back to the unprotected side
   based on the addresses and the next layer protocol (ESP), indicative
   of nesting.  It is compared against SPD-O (see Figure 3) and found to
   match SPD rule 1, so it is BYPASSed.  The packet is mapped to an SA
   based on the SPI, integrity-checked, and compared against the SAD
   selectors derived from SPD rule 3.  The forwarding function then
   passes it up to the next layer, because it isn't an ESP packet.
Top   ToC   RFC4301 - Page 98

References

Normative References

[BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [CD98] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [Eas05] 3rd Eastlake, D., "Cryptographic Algorithm Implementation Requirements For Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005. [HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [Ken05b] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, September 1981.
Top   ToC   RFC4301 - Page 99
   [Sch05]        Schiller, J., "Cryptographic Algorithms for use in the
                  Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
                  December 2005.

   [WaKiHo97]     Wahl, M., Kille, S., and T. Howes, "Lightweight
                  Directory Access Protocol (v3): UTF-8 String
                  Representation of Distinguished Names", RFC 2253,
                  December 1997.

Informative References

[CoSa04] Condell, M., and L. Sanchez, "On the Deterministic Enforcement of Un-ordered Security Policies", BBN Technical Memo 1346, March 2004. [FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [Gro02] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [HC03] Holbrook, H. and B. Cain, "Source Specific Multicast for IP", Work in Progress, November 3, 2002. [HA94] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
Top   ToC   RFC4301 - Page 100
   [RFC3740]      Hardjono, T. and B.  Weis, "The Multicast Group
                  Security Architecture", RFC 3740, March 2004.

   [RaCoCaDe04]   Rajahalme, J., Conta, A., Carpenter, B., and S.
                  Deering, "IPv6 Flow Label Specification", RFC 3697,
                  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.

   [SMPT01]       Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
                  "IP Payload Compression Protocol (IPComp)", RFC 3173,
                  September 2001.

   [ToEgWa04]     Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
                  Transport Mode for Dynamic Routing", RFC 3884,
                  September 2004.

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

Authors' Addresses

Stephen Kent BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA Phone: +1 (617) 873-3988 EMail: kent@bbn.com Karen Seo BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA Phone: +1 (617) 873-3152 EMail: kseo@bbn.com
Top   ToC   RFC4301 - Page 101
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.