tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4301


Security Architecture for the Internet Protocol

Part 4 of 4, p. 76 to 101
Prev RFC Part


prevText      Top      Up      ToC       Page 76 
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.

      See "Integrity" below.

      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.

      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.

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

      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.

      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      Up      ToC       Page 78 
      internal, e.g., in a host implementation of IPsec.  The protected
      interface may link to a socket layer interface presented by the

   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

Top      Up      ToC       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

   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

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


    {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
     ipsec (8) asn1-modules (3) spd-module (1) }



           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      Up      ToC       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      Up      ToC       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 }


       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      Up      ToC       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      Up      ToC       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      Up      ToC       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)) }


Top      Up      ToC       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      Up      ToC       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

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

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

   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

   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

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


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

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

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

         +---+     +---+  +---+
         | 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      Up      ToC       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      Up      ToC       Page 98 

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

   [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      Up      ToC       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

Top      Up      ToC       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

   Phone: +1 (617) 873-3988

   Karen Seo
   BBN Technologies
   10 Moulton Street
   Cambridge, MA  02138

   Phone: +1 (617) 873-3152

Top      Up      ToC       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

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

   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-


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