NAME

  SG_I_RFC2406_3_4_3 - [Initiator Test] Sequence Number Verification

TARGET

  SGW

SYNOPSIS

  SG_I_RFC2406_3_4_3.seq [-tooloption ...] -pkt SG_I_RFC2406_3_4_3.def -tooloption : v6eval tool option
  See also ike_common.def and ike_ipsec.def and ike_pkt_ph1_recv.def and ike_pkt_ph2_recv.def

INITIALIZATION

  • Configuration

  • Pre-Sequence

    •        In order to start the negotiation of IKE, 
       TN(HOST-1) transmits Echo Request to TN(HOST-2).

    TEST PROCEDURE

      This test check is following.

    
 * PHASE I

    
Either IDENTITY PROTECTION EXCHANGE or AGGRESSIVE EXCHANGE is performed as a pre sequence.


    
           IDENTITY PROTECTION EXCHANGE

    
 #   Initiator(NUT)     Direction      Responder(TN)
(1)  HDR; SA            ========>

    
(2)                     <========       HDR; SA

    
(3)  HDR; KE; NONCE     ========>

    
(4)                     <========     HDR; KE; NONCE

    
(5)  HDR*; IDii; HASH_I ========>

    
(6)                     <========     HDR*; IDir; HASH_R

    
   1. Receive the first message from NUT
      In the first message (1), the initiator generates a proposal it
      considers adequate to protect traffic for the given situation.  The
      Security Association, Proposal, and Transform payloads are included
      in the Security Association payload (for notation purposes).

    
   2. Send the second message from TN
      In the second message (2), the responder indicates the protection
      suite it has accepted with the Security Association, Proposal, and
      Transform payloads. 

    
   3. Receive the third message from NUT
      In the third (3) message, the initiator send keying material 
      used to arrive at a common shared secret and random information 
      which is used to guarantee liveness and protect against replay attacks.

    
   4. Send the fourth message from TN
      In the fourth (4) message, the responder send keying material 
      used to arrive at a common shared secret and random information 
      which is used to guarantee liveness and protect against replay attacks.

    
   5. Receive the fifth message from NUT
      In the fifth (5) message, the initiator send identification 
      information and the results of the agreed upon authentication 
      function(hash function). 

    
   6. Send the sixth message from TN
      In the sixth (6) message, the responder send identification 
      information and the results of the agreed upon authentication 
      function(hash function).


    
                        AGGRESSIVE EXCHANGE

    
 #     Initiator(NUT)   Direction      Responder(TN)      NOTE
(1)  HDR; SA; KE;      =>                        Begin ISAKMP-SA or
                                                 Proxy negotiation
     NONCE; IDii                                 and Key Exchange

    
(2)                    <=     HDR; SA; KE;
                              NONCE; IDir; AUTH
                                                 Initiator Identity
                                                 Verified by Responder
                                                 Key Generated
                                                 Basic SA agreed upon

    
(3)  HDR*; AUTH        =>
                                                 Responder Identity
                                                 Verified by Initiator
                                                 SA established

    
   1. Recieve the first message from NUT
      In the first message (1), the initiator generates a proposal it
      considers adequate to protect traffic for the given situation.  The
      Security Association, Proposal, and Transform payloads are included
      in the Security Association payload (for notation purposes).  There
      can be only one Proposal and one Transform offered (i.e.  no choices)
      in order for the aggressive exchange to work.  Keying material used
      to arrive at a common shared secret and random information which is
      used to guarantee liveness and protect against replay attacks are
      also transmitted.  Random information provided by both parties SHOULD
      be used by the authentication mechanism to provide shared proof of
      participation in the exchange.  Additionally, the initiator transmits
      identification information.

    
   2. Send the second message from TN
      In the second message (2), the responder indicates the protection
      suite it has accepted with the Security Association, Proposal, and
      Transform payloads.  Keying material used to arrive at a common
      shared secret and random information which is used to guarantee
      liveness and protect against replay attacks is also transmitted.
      Random information provided by both parties SHOULD be used by the
      authentication mechanism to provide shared proof of participation in
      the exchange.  Additionally, the responder transmits identification
      information.  All of this information is transmitted under the
      protection of the agreed upon authentication function.  Local
      security policy dictates the action of the responder if no proposed
      protection suite is accepted.  One possible action is the
      transmission of a Notify payload as part of an Informational
      Exchange.

    
   3. Recieve the third message from NUT
      In the third (3) message, the initiator transmits the results of the
      agreed upon authentication function.  This information is transmitted
      under the protection of the common shared secret.  Local security
      policy dictates the action if an error occurs during these messages.
      One possible action is the transmission of a Notify payload as part
      of an Informational Exchange.


    
 * PHASE II

    
                      QUICK MODE

    
 #   Initiator(NUT)     Direction      Responder(TN)
(1)  HDR*, HASH(1), 
     SA, Ni,IDci, IDcr; ========>

    
(2)                     <========     HDR*, HASH(2), SA, Nr, IDci, IDcr;

    
(3)  HDR*, HASH(3)      ========>

    
   1. Receive the first message from NUT
      In the first message (1), the initiator generates a proposal it
      considers adequate to protect traffic for the given situation.  The
      Security Association, Proposal, and Transform payloads are included
      in the Security Association payload (for notation purposes).
      And initiator send HASH(1) and Nonce. HASH(1) is the prf over the 
      message id (M-ID) from the ISAKMP header concatenated with the entire 
      message that follows the hash including all payload headers, 
      but excluding any padding added for encryption. Nonce is random 
      information which is used to guarantee liveness. IDci and IDcr is
      identification information. 

    
   2. Send the second message from TN
      In the second message (2), the responder indicates the protection
      suite it has accepted with the Security Association, Proposal, and
      Transform payloads. And responder send HASH(2) and Nonce.
      HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni,
      minus the payload header-- is added after M-ID but before the
      complete message. Nonce is random 
      information which is used to guarantee liveness. IDci and IDcr is
      identification information. 

    
   3. Receive the third message from NUT
      In the third (3) message, the initiator send HASH(3).
      HASH(3)-- for liveliness-- is the prf over the
      value zero represented as a single octet, followed by a concatenation
      of the message id and the two nonces-- the initiator's followed by
      the responder's-- minus the payload header.


    
  The test sequence is following.

    
 * IPsec transmission

    
 #   Initiator(NUT)     Direction      Responder(TN)
(1)    IP_HDR; ESP*;
     ICMP(Echo request) ========>

    
(2)                                    IP_HDR; ESP*; 
                        <========      ICMP(Echo reply) <------Sequence Number:1

    
(3)    IP_HDR; ESP*;
     ICMP(Echo request) ========>

    
(4)                                    IP_HDR; ESP*; 
                        <========      ICMP(Echo reply) <------Sequence Number:1(invalid)
                                                        <------Must not foward to HOST-1(TN)
                Judgement (Check *1)

    
   1. Receive the first message from NUT.
      At the first message (1), initiator(NUT) forward Echo request 
      from HOST-1(TN) to HOST-2(TN) via responder(TN).

    
   2. Send the 2nd message from TN.
      At the 2nd message (2), responder(NUT) forward Echo reply 
      (Sequence Number:1) from HOST-2(TN) to HOST-1(TN) via initiator(NUT).

    
   3. Receive the third message from NUT.
      In the third message (3), initiator(NUT) forward Echo reply 
      from HOST-1(TN) to HOST-2(TN) via responder(TN).

    
   4. Send the 4th message from TN
      In the third message (4), responder(TN) forward Echo request 
      (Sequence Number:1(invalid)) from HOST-2(TN) to HOST-1(TN) via initiator(NUT).

    JUDGEMENT

            In Phase I , messages must be exchanged correctly.
        In Phase II , the first to the third message must be exchanged correctly,
        In IPsec SA transmission, the 4th message must not be accepted. 
        And must not be fowarded to HOST-1(TN).

    TERMINATION

      Clean up SAD and SPD

    REFERENCE

      RFC2406
  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.

    
   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.

    SEE ALSO

      perldoc V6evalTool

      IKE.html IKE Test Common Utility