rfc2401.txt

中、英文RFC文档大全打包下载完全版 .

        SAs.
                o User ID
                    - native host implementations
                    - BITW and BITS implementations acting as HOSTS
                      with only one user
                    - security gateway implementations for INBOUND
                      processing.
                o System names -- all implementations]

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

      - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or
        the IPv6 "Next Header" fields.  This may be an individual
        protocol number.  These packet fields may not contain the
        Transport Protocol due to the presence of IP extension headers,
        e.g., a Routing Header, AH, ESP, Fragmentation Header,
        Destination Options, Hop-by-hop options, etc.  Note that the
        Transport Protocol may not be available in the case of receipt
        of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
        be supported.
        [REQUIRED for all implementations]

        NOTE: To locate the transport protocol, a system has to chain
        through the packet headers checking the "Protocol" or "Next
        Header" field until it encounters either one it recognizes as a
        transport protocol, or until it reaches one that isn't on its
        list of extension headers, or until it encounters an ESP header
        that renders the transport protocol opaque.

      - Source and Destination (e.g., TCP/UDP) Ports: These may be
        individual UDP or TCP port values or a wildcard port.  (The use
        of the Next Protocol field and the Source and/or Destination
        Port fields (in conjunction with the Source and/or Destination
        Address fields), as an SA selector is sometimes referred to as
        "session-oriented keying.").  Note that the source and
        destination ports may not be available in the case of receipt of
        a packet with an ESP header, thus a value of "OPAQUE" SHOULD be
        supported.

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





Kent & Atkinson             Standards Track                    [Page 19]

RFC 2401              Security Architecture for IP         November 1998


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

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

   The IPsec implementation context determines how selectors are used.
   For example, a host implementation integrated into the stack may make
   use of a socket interface.  When a new connection is established the
   SPD can be consulted and an SA (or SA bundle) bound to the socket.
   Thus traffic sent via that socket need not result in additional
   lookups to the SPD/SAD.  In contrast, a BITS, BITW, or security
   gateway implementation needs to look at each packet and perform an
   SPD/SAD lookup based on the selectors. The allowable values for the
   selector fields differ between the traffic flow, the security
   association, and the security policy.

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

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

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

   NOTE: In principle, one could have selectors and/or selector values
   in the SPD which cannot be negotiated for an SA or SA bundle.
   Examples might include selector values used to select traffic for



Kent & Atkinson             Standards Track                    [Page 20]

RFC 2401              Security Architecture for IP         November 1998


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

4.4.3 Security Association Database (SAD)

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

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

         o Outer Header's Destination IP address: the IPv4 or IPv6
           Destination address.
           [REQUIRED for all implementations]
         o IPsec Protocol: AH or ESP, used as an index for SA lookup
           in this database.  Specifies the IPsec protocol to be
           applied to the traffic on this SA.
           [REQUIRED for all implementations]
         o SPI: the 32-bit value used to distinguish among different
           SAs terminating at the same destination and using the same
           IPsec protocol.
           [REQUIRED for all implementations]

   For each of the selectors defined in Section 4.4.2, the SA entry in
   the SAD MUST contain the value or values which were negotiated at the
   time the SA was created.  For the sender, these values are used to
   decide whether a given SA is appropriate for use with an outbound
   packet.  This is part of checking to see if there is an existing SA



Kent & Atkinson             Standards Track                    [Page 21]

RFC 2401              Security Architecture for IP         November 1998


   that can be used.  For the receiver, these values are used to check
   that the selector values in an inbound packet match those for the SA
   (and thus indirectly those for the matching policy).  For the
   receiver, this is part of verifying that the SA was appropriate for
   this packet.  (See Section 6 for rules for ICMP messages.)  These
   fields can have the form of specific values, ranges, wildcards, or
   "OPAQUE" as described in section 4.4.2, "Selectors".  Note that for
   an ESP SA, the encryption algorithm or the authentication algorithm
   could be "NULL".  However they MUST not both be "NULL".

   The following SAD fields are used in doing IPsec processing:

         o Sequence Number Counter: a 32-bit value used to generate the
           Sequence Number field in AH or ESP headers.
           [REQUIRED for all implementations, but used only for outbound
           traffic.]
         o Sequence Counter Overflow: a flag indicating whether overflow
           of the Sequence Number Counter should generate an auditable
           event and prevent transmission of additional packets on the
           SA.
           [REQUIRED for all implementations, but used only for outbound
           traffic.]
         o Anti-Replay Window: a 32-bit counter and a bit-map (or
           equivalent) used to determine whether an inbound AH or ESP
           packet is a replay.
           [REQUIRED for all implementations but used only for inbound
           traffic. NOTE: If anti-replay has been disabled by the
           receiver, e.g., in the case of a manually keyed SA, then the
           Anti-Replay Window is not used.]
         o AH Authentication algorithm, keys, etc.
           [REQUIRED for AH implementations]
         o ESP Encryption algorithm, keys, IV mode, IV, etc.
           [REQUIRED for ESP implementations]
         o ESP authentication algorithm, keys, etc. If the
           authentication service is not selected, this field will be
           null.
           [REQUIRED for ESP implementations]
         o Lifetime of this Security Association: a time interval after
           which an SA must be replaced with a new SA (and new SPI) or
           terminated, plus an indication of which of these actions
           should occur.  This may be expressed as a time or byte count,
           or a simultaneous use of both, the first lifetime to expire
           taking precedence. A compliant implementation MUST support
           both types of lifetimes, and must support a simultaneous use
           of both.  If time is employed, and if IKE employs X.509
           certificates for SA establishment, the SA lifetime must be
           constrained by the validity intervals of the certificates,
           and the NextIssueDate of the CRLs used in the IKE exchange



Kent & Atkinson             Standards Track                    [Page 22]

RFC 2401              Security Architecture for IP         November 1998


           for the SA.  Both initiator and responder are responsible for
           constraining SA lifetime in this fashion.
           [REQUIRED for all implementations]

           NOTE: The details of how to handle the refreshing of keys
           when SAs expire is a local matter.  However, one reasonable
           approach is:
             (a) If byte count is used, then the implementation
                 SHOULD count the number of bytes to which the IPsec
                 algorithm is applied.  For ESP, this is the encryption
                 algorithm (including Null encryption) and for AH,
                 this is the authentication algorithm.  This includes
                 pad bytes, etc.  Note that implementations SHOULD be
                 able to handle having the counters at the ends of an
                 SA get out of synch, e.g., because of packet loss or
                 because the implementations at each end of the SA
                 aren't doing things the same way.
             (b) There SHOULD be two kinds of lifetime -- a soft
                 lifetime which warns the implementation to initiate
                 action such as setting up a replacement SA and a
                 hard lifetime when the current SA ends.
             (c) If the entire packet does not get delivered during
                 the SAs lifetime, the packet SHOULD be discarded.

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