If authentication has been selected, verification and decryption MAY
   be performed serially or in parallel.  If performed serially, then
   ICV verification SHOULD be performed first.  If performed in
   parallel, verification MUST be completed before the decrypted packet
   is passed on for further processing.  This order of processing
   facilitates rapid detection and rejection of replayed or bogus
   packets by the receiver, prior to decrypting the packet, hence
   potentially reducing the impact of denial of service attacks.  Note:

   If the receiver performs decryption in parallel with authentication,
   care must be taken to avoid possible race conditions with regard to
   packet access and reconstruction of the decrypted packet.

   Note that there are several ways in which the decryption can "fail":

        a. The selected SA may not be correct -- The SA may be
           mis-selected due to tampering with the SPI, destination
           address, or IPsec protocol type fields. Such errors, if they
           map the packet to another extant SA, will be
           indistinguishable from a corrupted packet, (case c).
           Tampering with the SPI can be detected by use of
           authentication.  However, an SA mismatch might still occur
           due to tampering with the IP Destination Address or the IPsec
           protocol type field.

        b. The pad length or pad values could be erroneous -- Bad pad
           lengths or pad values can be detected irrespective of the use
           of authentication.

        c. The encrypted ESP packet could be corrupted -- This can be
           detected if authentication is selected for the SA.,

   In case (a) or (c), the erroneous result of the decryption operation
   (an invalid IP datagram or transport-layer frame) will not
   necessarily be detected by IPsec, and is the responsibility of later
   protocol processing.

4.  Auditing

   Not all systems that implement ESP will implement auditing.  However,
   if ESP is incorporated into a system that supports auditing, then the
   ESP implementation MUST also support auditing and MUST allow a system
   administrator to enable or disable auditing for ESP.  For the most
   part, the granularity of auditing is a local matter.  However,
   several auditable events are identified in this specification and for
   each of these events a minimum set of information that SHOULD be
   included in an audit log is defined.  Additional information also MAY
   be included in the audit log for each of these events, and additional




 
RFC 2406           IP Encapsulating Security Payload       November 1998


   events, not explicitly called out in this specification, also MAY
   result in audit log entries.  There is no requirement for the
   receiver to transmit any message to the purported sender in response
   to the detection of an auditable event, because of the potential to
   induce denial of service via such action.

5.  Conformance Requirements

   Implementations that claim conformance or compliance with this
   specification MUST implement the ESP syntax and processing described
   here and MUST comply with all requirements of the Security
   Architecture document.  If the key used to compute an ICV is manually
   distributed, correct provision of the anti-replay service would
   require correct maintenance of the counter state at the sender, until
   the key is replaced, and there likely would be no automated recovery
   provision if counter overflow were imminent.  Thus a compliant
   implementation SHOULD NOT provide this service in conjunction with
   SAs that are manually keyed.  A compliant ESP implementation MUST
   support the following mandatory-to-implement algorithms:

             - DES in CBC mode [MD97]
             - HMAC with MD5 [MG97a]
             - HMAC with SHA-1 [MG97b]
             - NULL Authentication algorithm
             - NULL Encryption algorithm

   Since ESP encryption and authentication are optional, support for the
   2 "NULL" algorithms is required to maintain consistency with the way
   these services are negotiated.  NOTE that while authentication and
   encryption can each be "NULL", they MUST NOT both be "NULL".

6.  Security Considerations

   Security is central to the design of this protocol, and thus security
   considerations permeate the specification.  Additional security-
   relevant aspects of using the IPsec protocol are discussed in the
   Security Architecture document.

7.  Differences from RFC 1827

   This document differs from RFC 1827 [ATK95] in several significant
   ways.  The major difference is that, this document attempts to