mode (transport or tunnel) and are described in the Security
   Architecture document.

   If authentication is selected, encryption is performed first, before
   the authentication, and the encryption does not encompass the
   Authentication Data field.  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.  It also allows for the
   possibility of parallel processing of packets at the receiver, i.e.,
   decryption can take place in parallel with authentication.  Note that
   since the Authentication Data is not protected by encryption, a keyed
   authentication algorithm must be employed to compute the ICV.





 
RFC 2406           IP Encapsulating Security Payload       November 1998


3.3.3  Sequence Number Generation

   The sender's counter is initialized to 0 when an SA is established.
   The sender increments the Sequence Number for this SA and inserts the
   new value into the Sequence Number field.  Thus the first packet sent
   using a given SA will have a Sequence Number of 1.

   If anti-replay is enabled (the default), the sender checks to ensure
   that the counter has not cycled before inserting the new value in the
   Sequence Number field.  In other words, the sender MUST NOT send a
   packet on an SA if doing so would cause the Sequence Number to cycle.
   An attempt to transmit a packet that would result in Sequence Number
   overflow is an auditable event. (Note that this approach to Sequence
   Number management does not require use of modular arithmetic.)

   The sender assumes anti-replay is enabled as a default, unless
   otherwise notified by the receiver (see 3.4.3).  Thus, if the counter
   has cycled, the sender will set up a new SA and key (unless the SA
   was configured with manual key management).

   If anti-replay is disabled, the sender does not need to monitor or
   reset the counter, e.g., in the case of manual key management (see
   Section 5).  However, the sender still increments the counter and
   when it reaches the maximum value, the counter rolls over back to
   zero.

3.3.4  Integrity Check Value Calculation

   If authentication is selected for the SA, the sender computes the ICV
   over the ESP packet minus the Authentication Data.  Thus the SPI,
   Sequence Number, Payload Data, Padding (if present), Pad Length, and
   Next Header are all encompassed by the ICV computation.  Note that
   the last 4 fields will be in ciphertext form, since encryption is
   performed prior to authentication.

   For some authentication algorithms, the byte string over which the
   ICV computation is performed must be a multiple of a blocksize
   specified by the algorithm.  If the length of this byte string does
   not match the blocksize requirements for the algorithm, implicit
   padding MUST be appended to the end of the ESP packet, (after the
   Next Header field) prior to ICV computation.  The padding octets MUST
   have a value of zero.  The blocksize (and hence the length of the
   padding) is specified by the algorithm specification.  This padding
   is not transmitted with the packet.  Note that MD5 and SHA-1 are
   viewed as having a 1-byte blocksize because of their internal padding
   conventions.






 
RFC 2406           IP Encapsulating Security Payload       November 1998


3.3.5  Fragmentation

   If necessary, fragmentation is performed after ESP processing within
   an IPsec implementation.  Thus, transport mode ESP is applied only to
   whole IP datagrams (not to IP fragments).  An IP packet to which ESP
   has been applied may itself be fragmented by routers en route, and
   such fragments must be reassembled prior to ESP processing at a
   receiver.  In tunnel mode, ESP is applied to an IP packet, the
   payload of which may be a fragmented IP packet.  For example, a
   security gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
   implementation (as defined in the Security Architecture document) may
   apply tunnel mode ESP to such fragments.

   NOTE: For transport mode -- As mentioned at the beginning of Section
   3.1, bump-in-the-stack and bump-in-the-wire implementations may have
   to first reassemble a packet fragmented by the local IP layer, then
   apply IPsec, and then fragment the resulting packet.

   NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire
   implementations, it will be necessary to walk through all the
   extension headers to determine if there is a fragmentation header and
   hence that the packet needs reassembling prior to IPsec processing.