in the Security Architecture document.

   If the received packet falls within the window and is new, or if the
   packet is to the right of the window, then the receiver proceeds to
   ICV verification.  If the ICV validation fails, the receiver MUST
   discard the received IP datagram as invalid; this is an auditable
   event.  The audit log entry for this event SHOULD include the SPI
   value, date/time received, Source Address, Destination Address, the
   Sequence Number, and (in IPv6) the Flow ID.  The receive window is
   updated only if the ICV verification succeeds.

   DISCUSSION:

      Note that if the packet is either inside the window and new, or is
      outside the window on the "right" side, the receiver MUST
      authenticate the packet before updating the Sequence Number window
      data.

3.4.4  Integrity Check Value Verification

   If authentication has been selected, the receiver computes the ICV
   over the ESP packet minus the Authentication Data using the specified
   authentication algorithm and verifies that it is the same as the ICV
   included in the Authentication Data field of the packet.  Details of
   the computation are provided below.

   If the computed and received ICV's match, then the datagram is valid,
   and it is accepted.  If the test fails, then the receiver MUST
   discard the received IP datagram as invalid; this is an auditable
   event.  The log data SHOULD include the SPI value, date/time
   received, Source Address, Destination Address, the Sequence Number,
   and (in IPv6) the cleartext Flow ID.

   DISCUSSION:

      Begin by removing and saving the ICV value (Authentication Data
      field).  Next check the overall length of the ESP packet minus the
      Authentication Data.  If implicit padding is required, based on




 
RFC 2406           IP Encapsulating Security Payload       November 1998


      the blocksize of the authentication algorithm, append zero-filled
      bytes to the end of the ESP packet directly after the Next Header
      field.  Perform the ICV computation and compare the result with
      the saved value, using the comparison rules defined by the
      algorithm specification.  (For example, if a digital signature and
      one-way hash are used for the ICV computation, the matching
      process is more complex.)

3.4.5  Packet Decryption

   As in section 3.3.2, "Packet Encryption", we speak here in terms of
   encryption always being applied because of the formatting
   implications.  This is done with the understanding that "no
   confidentiality" is offered by using the NULL encryption algorithm.
   Accordingly, the receiver:

       1. decrypts the ESP Payload Data, Padding, Pad Length, and Next
          Header using the key, encryption algorithm, algorithm mode,
          and cryptographic synchronization data (if any), indicated by
          the SA.
               - If explicit cryptographic synchronization data, e.g.,
                 an IV, is indicated, it is taken from the Payload
                 field and input to the decryption algorithm as per the
                 algorithm specification.
               - If implicit cryptographic synchronization data, e.g.,
                 an IV, is indicated, a local version of the IV is
                 constructed and input to the decryption algorithm as
                 per the algorithm specification.
       2. processes any padding as specified in the encryption
          algorithm specification.  If the default padding scheme (see
          Section 2.4) has been employed, the receiver SHOULD inspect
          the Padding field before removing the padding prior to
          passing the decrypted data to the next layer.
       3. reconstructs the original IP datagram from:
               - for transport mode -- original IP header plus the
                 original upper layer protocol information in the ESP
                 Payload field
               - for tunnel mode -- tunnel IP header + the entire IP
                 datagram in the ESP Payload field.

   The exact steps for reconstructing the original datagram depend on
   the mode (transport or tunnel) and are described in the Security
   Architecture document.  At a minimum, in an IPv6 context, the
   receiver SHOULD ensure that the decrypted data is 8-byte aligned, to
   facilitate processing by the protocol identified in the Next Header
   field.






 
RFC 2406           IP Encapsulating Security Payload       November 1998