3.4  Inbound Packet Processing

3.4.1  Reassembly

   If required, reassembly is performed prior to ESP processing.  If a
   packet offered to ESP for processing appears to be an IP fragment,
   i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
   the receiver MUST discard the packet; this is an auditable event. The
   audit log entry for this event SHOULD include the SPI value,
   date/time received, Source Address, Destination Address, Sequence
   Number, and (in IPv6) the Flow ID.

   NOTE: For packet reassembly, the current IPv4 spec does NOT require
   either the zero'ing of the OFFSET field or the clearing of the MORE
   FRAGMENTS flag.  In order for a reassembled packet to be processed by
   IPsec (as opposed to discarded as an apparent fragment), the IP code
   must do these two things after it reassembles a packet.

3.4.2  Security Association Lookup

   Upon receipt of a (reassembled) packet containing an ESP Header, the
   receiver determines the appropriate (unidirectional) SA, based on the
   destination IP address, security protocol (ESP), and the SPI.  (This
   process is described in more detail in the Security Architecture
   document.)  The SA indicates whether the Sequence Number field will




 
RFC 2406           IP Encapsulating Security Payload       November 1998


   be checked, whether the Authentication Data field should be present,
   and it will specify the algorithms and keys to be employed for
   decryption and ICV computations (if applicable).

   If no valid Security Association exists for this session (for
   example, the receiver has no key), the receiver MUST discard the
   packet; this is an auditable event.  The audit log entry for this
   event SHOULD include the SPI value, date/time received, Source
   Address, Destination Address, Sequence Number, and (in IPv6) the
   cleartext Flow ID.

3.4.3  Sequence Number Verification

   All ESP implementations MUST support the anti-replay service, though
   its use may be enabled or disabled by the receiver on a per-SA basis.
   This service MUST NOT be enabled unless the authentication service
   also is enabled for the SA, since otherwise the Sequence Number field
   has not been integrity protected.  (Note that there are no provisions
   for managing transmitted Sequence Number values among multiple
   senders directing traffic to a single SA (irrespective of whether the
   destination address is unicast, broadcast, or multicast).  Thus the
   anti-replay service SHOULD NOT be used in a multi-sender environment
   that employs a single SA.)

   If the receiver does not enable anti-replay for an SA, no inbound
   checks are performed on the Sequence Number.  However, from the
   perspective of the sender, the default is to assume that anti-replay
   is enabled at the receiver.  To avoid having the sender do
   unnecessary sequence number monitoring and SA setup (see section
   3.3.3), if an SA establishment protocol such as IKE is employed, the
   receiver SHOULD notify the sender, during SA establishment, if the
   receiver will not provide anti-replay protection.

   If the receiver has enabled the anti-replay service for this SA, the
   receive packet counter for the SA MUST be initialized to zero when
   the SA is established.  For each received packet, the receiver MUST
   verify that the packet contains a Sequence Number that does not
   duplicate the Sequence Number of any other packets received during
   the life of this SA.  This SHOULD be the first ESP check applied to a
   packet after it has been matched to an SA, to speed rejection of
   duplicate packets.

   Duplicates are rejected through the use of a sliding receive window.
   (How the window is implemented is a local matter, but the following
   text describes the functionality that the implementation must
   exhibit.)  A MINIMUM window size of 32 MUST be supported; but a
   window size of 64 is preferred and SHOULD be employed as the default.





 
RFC 2406           IP Encapsulating Security Payload       November 1998


   Another window size (larger than the MINIMUM) MAY be chosen by the
   receiver.  (The receiver does NOT notify the sender of the window
   size.)

   The "right" edge of the window represents the highest, validated
   Sequence Number value received on this SA.  Packets that contain
   Sequence Numbers lower than the "left" edge of the window are
   rejected.  Packets falling within the window are checked against a
   list of received packets within the window.  An efficient means for
   performing this check, based on the use of a bit mask, is described