NAME

  SG_R_A_RFC2408_3_6_1_P1_NP_0 -  [Responder Test]Transform Payload format check

TARGET

  SGW

SYNOPSIS

  SG_R_A_RFC2408_3_6_1_P1_NP_0.seq [-tooloption ...] -pkt SG_R_A_RFC2408_3_6_1_P1_NP_0.def -tooloption : v6eval tool option

  See also ike_common.def and ike_ipsec.def and ike_addr.def and ike_pkt_ph1_recv.def and ike_pkt_ph2_recv.def

INITIALIZATION

TEST PROCEDURE

  This test check is following.


                       AGGRESSIVE EXCHANGE


 #   Initiator(TN)         Direction      Responder(NUT)
(1)  HDR; SA, KE, Ni, IDii ========>


(2)                        <========       HDR; SA, KE, Nr, IDir, HASH_R
                        Judgement (Check *1)


   1. Send the first message from TN
      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).
      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. Additionally, the initiator 
      transmits identification information.


   2. Receive the second message from NUT
      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.Additionally, the responder 
      transmits identification information and the results of the agreed
      upon authentication function(hash function).

JUDGEMENT

        The first message must be accepted. 
        And the second message's Transform Payload Format must be base 
        on description of RFC(see above Verification Points).

TERMINATION

  Clean up SAD and SPD

REFERENCE

  RFC2407
  4.4.2.1 KEY_IKE


   The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
   key exchange (IKE) as defined in the [IKE] document.  All
   implementations within the IPSEC DOI MUST support KEY_IKE.



 
  RFC2408


  2.5.2 RESERVED Fields


   The existence of RESERVED fields within ISAKMP payloads are used
   strictly to preserve byte alignment.  All RESERVED fields in the
   ISAKMP protocol MUST be set to zero (0) when a packet is issued.  The
   receiver SHOULD check the RESERVED fields for a zero (0) value and
   discard the packet if other values are found.


  (omit)


  3.6 Transform Payload


  (omit)


                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! Next Payload  !   RESERVED    !         Payload Length        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Transform #  !  Transform-Id !           RESERVED2           !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     ~                        SA Attributes                          ~
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 
  (omit)


    o  Next Payload (1 octet) - Identifier for the payload type of the
       next payload in the message.  This field MUST only contain the
       value "3" or "0".  If there are additional Transform payloads in
       the proposal, then this field will be 3.  If the current
       Transform payload is the last within the proposal, then this
       field will be 0.


    o  RESERVED (1 octet) - Unused, set to 0.


    o  Payload Length (2 octets) - Length in octets of the current
       payload, including the generic payload header, Transform values,
       and all SA Attributes.


    o  Transform # (1 octet) - Identifies the Transform number for the
       current payload.  If there is more than one transform proposed
       for a specific protocol within the Proposal payload, then each
       Transform payload has a unique Transform number.  A description
       of the use of this field is found in section 4.2.


    o  Transform-Id (1 octet) - Specifies the Transform identifier for
       the protocol within the current proposal.  These transforms are
       defined by the DOI and are dependent on the protocol being
       negotiated.


    o  RESERVED2 (2 octets) - Unused, set to 0.


    o  SA Attributes (variable length) - This field contains the
       security association attributes as defined for the transform
       given in the Transform-Id field.  The SA Attributes SHOULD be
       represented using the Data Attributes format described in section
       3.3.  If the SA Attributes are not aligned on 4-byte boundaries,
       then subsequent payloads will not be aligned and any padding will
       be added at the end of the message to make the message 4-octet
       aligned.


  (omit)


  5.3 Generic Payload Header Processing


   When creating any of the ISAKMP Payloads described in sections 3.4
   through 3.15 a Generic Payload Header is placed at the beginning of
   these payloads.  When creating the Generic Payload Header, the
   transmitting entity (initiator or responder) MUST do the following:


   1.  Place the value of the Next Payload in the Next Payload field.
       These values are described in section 3.1.


   2.  Place the value zero (0) in the RESERVED field.


   3.  Place the length (in octets) of the payload in the Payload Length
       field.


   4.  Construct the payloads as defined in the remainder of this
       section.


  (omit)


5.6 Transform Payload Processing


   When creating a Transform Payload, the transmitting entity (initiator
   or responder) MUST do the following:


   1.  Determine the Transform # for this transform.


   2.  Determine the number of transforms to be offered for this
       proposal.  Transforms are described in sections 3.6.


   3.  Construct a Transform payload.


  (omit)

SEE ALSO

  perldoc V6evalTool

  IKE.html IKE Test Common Utility