RFC 1827 (rfc1827) - Page 2 of 12


IP Encapsulating Security Payload (ESP)



Alternative Format: Original Text Document



RFC 1827             Encapsulating Security Payload          August 1995


   Use of this specification will increase the IP protocol processing
   costs in participating systems and will also increase the
   communications latency.  The increased latency is primarily due to
   the encryption and decryption required for each IP datagram
   containing an Encapsulating Security Payload.

   In Tunnel-mode ESP, the original IP datagram is placed in the
   encrypted portion of the Encapsulating Security Payload and that
   entire ESP frame is placed within a datagram having unencrypted IP
   headers.  The information in the unencrypted IP headers is used to
   route the secure datagram from origin to destination. An unencrypted
   IP Routing Header might be included between the IP Header and the
   Encapsulating Security Payload.

   In Transport-mode ESP, the ESP header is inserted into the IP
   datagram immediately prior to the transport-layer protocol header
   (e.g., TCP, UDP, or ICMP). In this mode bandwidth is conserved
   because there are no encrypted IP headers or IP options.

   In the case of IP, an IP Authentication Header may be present as a
   header of an unencrypted IP packet, as a header after the IP header
   and before the ESP header in a Transport-mode ESP packet, and also as
   a header within the encrypted portion of a Tunnel-mode ESP packet.
   When AH is present both in the cleartext IP header and also inside a
   Tunnel-mode ESP header of a single packet, the unencrypted IPv6
   Authentication Header is primarily used to provide protection for the
   contents of the unencrypted IP headers and the encrypted
   Authentication Header is used to provide authentication only for the
   encrypted IP packet.  This is discussed in more detail later in this
   document.

   The Encapsulating Security Payload is structured a bit differently
   than other IP payloads. The first component of the ESP payload
   consist of the unencrypted field(s) of the payload.  The second
   component consists of encrypted data.  The field(s) of the
   unencrypted ESP header inform the intended receiver how to properly
   decrypt and process the encrypted data.  The encrypted data component
   includes protected fields for the security protocol and also the
   encrypted encapsulated IP datagram.

   The concept of a "Security Association" is fundamental to ESP.  It is
   described in detail in the companion document "Security Architecture
   for the Internet Protocol" which is incorporated here by reference
   [Atk95a].  Implementors should read that document before reading this
   one.






Atkinson                    Standards Track