1. INTRODUCTION

   ESP is a mechanism for providing integrity and confidentiality to IP
   datagrams.  It may also provide authentication, depending on which
   algorithm and algorithm mode are used.  Non-repudiation and
   protection from traffic analysis are not provided by ESP.  The IP
   Authentication Header (AH) might provide non-repudiation if used with
   certain authentication algorithms [Atk95b].  The IP Authentication
   Header may be used in conjunction with ESP to provide authentication.
   Users desiring integrity and authentication without confidentiality
   should use the IP Authentication Header (AH) instead of ESP.  This
   document assumes that the reader is familiar with the related
   document "IP Security Architecture", which defines the overall
   Internet-layer security architecture for IPv4 and IPv6 and provides
   important background for this specification [Atk95a].

1.1. Overview

   The IP Encapsulating Security Payload (ESP) seeks to provide
   confidentiality and integrity by encrypting data to be protected and
   placing the encrypted data in the data portion of the IP
   Encapsulating Security Payload.  Depending on the user's security
   requirements, this mechanism may be used to encrypt either a
   transport-layer segment (e.g., TCP, UDP, ICMP, IGMP) or an entire IP
   datagram.  Encapsulating the protected data is necessary to provide
   confidentiality for the entire original datagram.

   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.

1.2. Requirements Terminology

   In this document, the words that are used to define the significance
   of each particular requirement are usually capitalised.  These words
   are:

   - MUST

      This word or the adjective "REQUIRED" means that the item is an
      absolute requirement of the specification.

   - SHOULD

      This word or the adjective "RECOMMENDED" means that there might
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and the case
      carefully weighed before taking a different course.

   - MAY

      This word or the adjective "OPTIONAL" means that this item is
      truly optional.  One vendor might choose to include the item
      because a particular marketplace requires it or because it
      enhances the product, for example; another vendor may omit the
      same item.