rfc2406.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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.





Kent & Atkinson             Standards Track                    [Page 12]

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.

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



Kent & Atkinson             Standards Track                    [Page 13]

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.




Kent & Atkinson             Standards Track                    [Page 14]

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
   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



Kent & Atkinson             Standards Track                    [Page 15]

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.





Kent & Atkinson             Standards Track                    [Page 16]

RFC 2406           IP Encapsulating Security Payload       November 1998


   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.