A more detailed diagram of the ESP Header follows below.

  +-------------+--------------------+------------+---------------------+
  |             Security Association Identifier (SPI), 32 bits          |
  +=============+====================+============+=====================+
  |             Opaque Transform Data, variable length                  |
  +-------------+--------------------+------------+---------------------+

   Encryption and authentication algorithms, and the precise format of
   the Opaque Transform Data associated with them are known as
   "transforms".  The ESP format is designed to support new transforms
   in the future to support new or additional cryptographic algorithms.
   The transforms are specified by themselves rather than in the main
   body of this specification.  The mandatory transform for use with IP
   is defined in a separate document [KMS95].  Other optional transforms
   exist in other separate specifications and additional transforms
   might be defined in the future.









 
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




 
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