NAME

  SG_I_A_RFC2408_3_6_1_P1_NP_3 - [Initiator Test] Transform Payload format check(Multiple Transform Payload)

TARGET

  SGW

SYNOPSIS

  SG_I_A_RFC2408_3_6_1_P1_NP_3.seq [-tooloption ...] -pkt SG_I_A_RFC2408_3_6_1_P1_NP_3.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(NUT)         Direction      Responder(TN)
(1)  HDR; SA, KE, Ni, IDii ========>
                Judgement (Check *1)


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

JUDGEMENT

       The first message's Transform Payload 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)


  4.2 Security Association Establishment


   (omit)


   The Transform payload provides the initiating entity with the
   capability to present to the responding entity multiple mechanisms,
   or transforms, for a given protocol.  The Proposal payload identifies
   a Protocol for which services and mechanisms are being negotiated.
   The Transform payload allows the initiating entity to present several
   possible supported transforms for that proposed protocol.  There may
   be several transforms associated with a specific Proposal payload
   each identified in a separate Transform payload.  The multiple
   transforms MUST be presented with monotonically increasing numbers in
   the initiator's preference order.  The receiving entity MUST select a
   single transform for each protocol in a proposal or reject the entire
   proposal.  The use of the Transform number in multiple Transform
   payloads provides a second level OR operation, i.e.  Transform 1 OR
   Transform 2 OR Transform 3.  Example 1 below shows two possible
   transforms for ESP and a single transform for AH. Example 2 below
   shows one transform for AH AND one transform for ESP OR two
   transforms for ESP alone.  Note that the Next Payload field of the
   Transform payload points to another Transform payload or 0.  The
   Proposal payload delineates the different proposals.


   (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)


  RFC2409


  5. Exchanges


  (omit)


   Main Mode, Aggressive Mode, and Quick Mode do security association
   negotiation. Security Association offers take the form of Transform
   Payload(s) encapsulated in Proposal Payload(s) encapsulated in
   Security Association (SA) payload(s). If multiple offers are being
   made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST
   take the form of multiple Transform Payloads for a single Proposal
   Payload in a single SA payload. To put it another way, for phase 1
   exchanges there MUST NOT be multiple Proposal Payloads for a single
   SA payload and there MUST NOT be multiple SA payloads. This document
   does not proscribe such behavior on offers in phase 2 exchanges.


  (omit)

SEE ALSO

  perldoc V6evalTool
  IKE.html IKE Test Common Utility