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.






 
RFC 1827             Encapsulating Security Payload          August 1995


5. CONFORMANCE REQUIREMENTS

   Implementations that claim conformance or compliance with this
   specification MUST fully implement the header described here, MUST
   support manual key distribution with this header, MUST comply with
   all requirements of the "Security Architecture for the Internet
   Protocol" [Atk95a], and MUST support the use of DES CBC as specified
   in the companion document entitled "The ESP DES-CBC Transform"
   [KMS95].  Implementors MAY also implement other ESP transforms.
   Implementers should consult the most recent version of the "IAB
   Official Standards" RFC for further guidance on the status of this
   document.

6. SECURITY CONSIDERATIONS

   This entire document discusses a security mechanism for use with IP.
   This mechanism is not a panacea, but it does provide an important
   component useful in creating a secure internetwork.

   Cryptographic transforms for ESP which use a block-chaining algorithm
   and lack a strong integrity mechanism are vulnerable to a cut-and-
   paste attack described by Bellovin and should not be used unless the
   Authentication Header is always present with packets using that ESP
   transform [Bel95].

   Users need to understand that the quality of the security provided by
   this specification depends completely on the strength of whichever
   encryption algorithm has been implemented, the correctness of that
   algorithm's implementation, upon the security of the key management
   mechanism and its implementation, the strength of the key [CN94]
   [Sch94, p233] and upon the correctness of the ESP and IP
   implementations in all of the participating systems.

   If any of these assumptions do not hold, then little or no real
   security will be provided to the user.  Use of high assurance
   development techniques is recommended for the IP Encapsulating
   Security Payload.

   Users seeking protection from traffic analysis might consider the use
   of appropriate link encryption.  Description and specification of
   link encryption is outside the scope of this note.

   If user-oriented keying is not in use, then the algorithm in use
   should not be an algorithm vulnerable to any kind of Chosen Plaintext
   attack.  Chosen Plaintext attacks on DES are described in [BS93] and
   [Mat94]. Use of user-oriented keying is recommended in order to