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




 
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




 
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