rfc1827.txt

RFC 的详细文档！


RFC 1827             Encapsulating Security Payload          August 1995


3.1 Fields of the Encapsulating Security Payload

   The SPI is a 32-bit pseudo-random value identifying the security
   association for this datagram.  If no security association has been
   established, the value of the SPI field shall be 0x00000000.   An SPI
   is similar to the SAID used in other security protocols.  The name
   has been changed because the semantics used here are not exactly the
   same as those used in other security protocols.

   The set of SPI values in the range 0x00000001 though 0x000000FF are
   reserved to the Internet Assigned Numbers Authority (IANA) for future
   use.  A reserved SPI value will not normally be assigned by IANA
   unless the use of that particular assigned SPI value is openly
   specified in an RFC.

   The SPI is the only mandatory transform-independent field.
   Particular transforms may have other fields unique to the transform.
   Transforms are not specified in this document.

3.2 Security Labeling with ESP

   The encrypted IP datagram need not and does not normally contain any
   explicit Security Label because the SPI indicates the sensitivity
   level.  This is an improvement over the current practices with IPv4
   where an explicit Sensitivity Label is normally used with
   Compartmented Mode Workstations and other systems requiring Security
   Labels [Ken91] [DIA].  In some situations, users MAY choose to carry
   explicit labels (for example, IPSO labels as defined by RFC-1108
   might be used with IPv4) in addition to using the implicit labels
   provided by ESP.  Explicit label options could be defined for use
   with IPv6 (e.g., using the IPv6 End-to-End Options Header or the IPv6
   Hop-by-Hop Options Header).  Implementations MAY support explicit
   labels in addition to implicit labels, but implementations are not
   required to support explicit labels.  Implementations of ESP in
   systems claiming to provide multi-level security MUST support
   implicit labels.

4. ENCAPSULATING SECURITY PROTOCOL PROCESSING

   This section describes the steps taken when ESP is in use between two
   communicating parties.  Multicast is different from unicast only in
   the area of key management (See the definition of the SPI, above, for
   more detail on this).  There are two modes of use for ESP.  The first
   mode, which is called "Tunnel-mode", encapsulates an entire IP
   datagram inside ESP.  The second mode, which is called "Transport-
   Mode", encapsulates a transport-layer (e.g., UDP, TCP) frame inside
   ESP.  The term "Transport-mode" must not be misconstrued as
   restricting its use to TCP and UDP. For example, an ICMP message MAY



Atkinson                    Standards Track                     [Page 5]

RFC 1827             Encapsulating Security Payload          August 1995


   be sent either using the "Transport-mode" or the "Tunnel-mode"
   depending upon circumstance.  ESP processing occurs prior to IP
   fragmentation on output and after IP reassembly on input.  This
   section describes protocol processing for each of these two modes.

4.1 ESP in Tunnel-mode

   In Tunnel-mode ESP, the ESP header follows all of the end-to-end
   headers (e.g., Authentication Header, if present in cleartext) and
   immediately precedes an tunnelled IP datagram.

   The sender takes the original IP datagram, encapsulates it into the
   ESP, uses at least the sending userid and Destination Address as data
   to locate the correct Security Association, and then applies the
   appropriate encryption transform.  If host-oriented keying is in use,
   then all sending userids on a given system will have the same
   Security Association for a given Destination Address.  If no key has
   been established, then the key management mechanism is used to
   establish an encryption key for this communications session prior to
   the use of ESP.  The (now encrypted) ESP is then encapsulated in a
   cleartext IP datagram as the last payload.  If strict red/black
   separation is being enforced, then the addressing and other
   information in the cleartext IP headers and optional payloads MAY be
   different from the values contained in the (now encrypted and
   encapsulated) original datagram.

   The receiver strips off the cleartext IP header and cleartext
   optional IP payloads (if any) and discards them.  It then uses the
   combination of Destination Address and SPI value to locate the
   correct session key to use for this packet.  It then decrypts the ESP
   using the session key that was just located for this packet.

   If no valid Security Association exists for this session (for
   example, the receiver has no key), the receiver MUST discard the
   encrypted ESP and the failure MUST be recorded in the system log or
   audit log.  This system log or audit log entry SHOULD include the SPI
   value, date/time, cleartext Sending Address, cleartext Destination
   Address, and the cleartext Flow ID.  The log entry MAY also include
   other identifying data.  The receiver might not wish to react by
   immediately informing the sender of this failure because of the
   strong potential for easy-to-exploit denial of service attacks.

   If decryption succeeds, the original IP datagram is then removed from
   the (now decrypted) ESP.  This original IP datagram is then processed
   as per the normal IP protocol specification.  In the case of system
   claiming to provide multilevel security (for example, a B1 or
   Compartmented Mode Workstation) additional appropriate mandatory
   access controls MUST be applied based on the security level of the



Atkinson                    Standards Track                     [Page 6]

RFC 1827             Encapsulating Security Payload          August 1995


   receiving process and the security level associated with this
   Security Association.  If those mandatory access controls fail, then
   the packet SHOULD be discarded and the failure SHOULD be logged using
   implementation-specific procedures.

4.2 ESP in Transport-mode

   In Transport-mode ESP, the ESP header follows the end-to-end headers
   (e.g., Authentication Header) and immediately precedes a transport-
   layer (e.g., UDP, TCP, ICMP) header.

   The sender takes the original transport-layer (e.g., UDP, TCP, ICMP)
   frame, encapsulates it into the ESP, uses at least the sending userid
   and Destination Address to locate the appropriate Security
   Association, and then applies the appropriate encryption transform.
   If host-oriented keying is in use, then all sending userids on a
   given system will have the same Security Association for a given
   Destination Address. If no key has been established, then the key
   management mechanism is used to establish a encryption key for this
   communications session prior to the encryption.  The (now encrypted)
   ESP is then encapsulated as the last payload of a cleartext IP
   datagram.

   The receiver processes the cleartext IP header and cleartext optional
   IP headers (if any) and temporarily stores pertinent information
   (e.g., source and destination addresses, Flow ID, Routing Header).
   It then decrypts the ESP using the session key that has been
   established for this traffic, using the combination of the
   destination address and the packet's Security Association Identifier
   (SPI) to locate the correct key.

   If no key exists for this session or the attempt to decrypt fails,
   the encrypted ESP MUST be discarded and the failure MUST be recorded
   in the system log or audit log.  If such a failure occurs, the
   recorded log data SHOULD include the SPI value, date/time received,
   clear-text Sending Address, clear-text Destination Address, and the
   Flow ID.  The log data MAY also include other information about the
   failed packet.  If decryption does not work properly for some reason,
   then the resulting data will not be parsable by the implementation's
   protocol engine.  Hence, failed decryption is generally detectable.

   If decryption succeeds, the original transport-layer (e.g., UDP, TCP,
   ICMP) frame is removed from the (now decrypted) ESP.  The information
   from the cleartext IP header and the now decrypted transport-layer
   header is jointly used to determine which application the data should
   be sent to.  The data is then sent along to the appropriate
   application as normally per IP protocol specification.  In the case
   of a system claiming to provide multilevel security (for example, a



Atkinson                    Standards Track                     [Page 7]

RFC 1827             Encapsulating Security Payload          August 1995


   B1 or Compartmented Mode Workstation), additional Mandatory Access
   Controls MUST be applied based on the security level of the receiving
   process and the security level of the received packet's Security
   Association.

4.3. Authentication

   Some transforms provide authentication as well as confidentiality and
   integrity.  When such a transform is not used, then the
   Authentication Header might be used in conjunction with the
   Encapsulating Security Payload.  There are two different approaches
   to using the Authentication Header with ESP, depending on which data
   is to be authenticated.  The location of the Authentication Header
   makes it clear which set of data is being authenticated.

   In the first usage, the entire received datagram is authenticated,
   including both the encrypted and unencrypted portions, while only the
   data sent after the ESP Header is confidential.  In this usage, the
   sender first applies ESP to the data being protected.  Then the other
   plaintext IP headers are prepended to the ESP header and its now
   encrypted data. Finally, the IP Authentication Header is calculated
   over the resulting datagram according to the normal method.  Upon
   receipt, the receiver first verifies the authenticity of the entire
   datagram using the normal IP Authentication Header process.  Then if
   authentication succeeds, decryption using the normal IP ESP process
   occurs.  If decryption is successful, then the resulting data is
   passed up to the upper layer.

   If the authentication process were to be applied only to the data
   protected by Tunnel-mode ESP, then the IP Authentication Header would
   be placed normally within that protected datagram.  However, if one
   were using Transport-mode ESP, then the IP Authentication Header
   would be placed before the ESP header and would be calculated across
   the entire IP datagram.

   If the Authentication Header is encapsulated within a Tunnel-mode ESP
   header, and both headers have specific security classification levels
   associated with them, and the two security classification levels are
   not identical, then an error has occurred.  That error SHOULD be
   recorded in the system log or audit log using the procedures
   described previously.  It is not necessarily an error for an
   Authentication Header located outside of the ESP header to have a
   different security classification level than the ESP header's
   classification level.  This might be valid because the cleartext IP
   headers might have a different classification level after the data
   has been encrypted using ESP.





Atkinson                    Standards Track                     [Page 8]

RFC 1827             Encapsulating Security Payload          August 1995