NAME

  SG_R_A_RFC2408_3_5_1_P1_NP_0 -  [Responder Test]Proposal Payload format check

TARGET

  SGW

SYNOPSIS

  SG_R_A_RFC2408_3_5_1_P1_NP_0.seq [-tooloption ...] -pkt SG_R_A_RFC2408_3_5_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 Proposal Payload Format must be base 
        on description of RFC(see above Verification Points).

TERMINATION

  Clean up SAD and SPD

REFERENCE

  RFC2407
  4.4.1.1 PROTO_ISAKMP


   The PROTO_ISAKMP type specifies message protection required during
   Phase I of the ISAKMP protocol.  The specific protection mechanism
   used for the IPSEC DOI is described in [IKE].  All implementations
   within the IPSEC DOI MUST support PROTO_ISAKMP.



  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.5 Proposal 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        !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !  Proposal #   !  Protocol-Id  !    SPI Size   !# of Transforms!
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                        SPI (variable)                         !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  (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 "2" or "0".  If there are additional Proposal payloads in
       the message, then this field will be 2.  If the current Proposal
       payload is the last within the security association 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 entire
       Proposal payload, including generic payload header, the Proposal
       payload, and all Transform payloads associated with this
       proposal.  In the event there are multiple proposals with the
       same proposal number (see section 4.2), the Payload Length field
       only applies to the current Proposal payload and not to all
       Proposal payloads.


    o  Proposal # (1 octet) - Identifies the Proposal number for the
       current payload.  A description of the use of this field is found
       in section 4.2.


    o  Protocol-Id (1 octet) - Specifies the protocol identifier for the
       current negotiation.  Examples might include IPSEC ESP, IPSEC AH,
       OSPF, TLS, etc.


    o  SPI Size (1 octet) - Length in octets of the SPI as defined by
       the Protocol-Id.  In the case of ISAKMP, the Initiator and
       Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
       therefore, the SPI Size is irrelevant and MAY be from zero (0) to
       sixteen (16).  If the SPI Size is non-zero, the content of the
       SPI field MUST be ignored.  If the SPI Size is not a multiple of
       4 octets it will have some impact on the SPI field and the
       alignment of all payloads in the message.  The Domain of
       Interpretation (DOI) will dictate the SPI Size for other
       protocols.


    o  # of Transforms (1 octet) - Specifies the number of transforms
       for the Proposal.  Each of these is contained in a Transform
       payload.


    o  SPI (variable) - The sending entity's SPI. In the event the SPI
       Size is not a multiple of 4 octets, there is no padding applied
       to the payload, however, it can be applied at the end of the
       message.


  (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.5 Proposal Payload Processing


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


   1.  Determine the Protocol for this proposal.


   2.  Determine the number of proposals to be offered for this protocol
       and the number of transforms for each proposal.  Transforms are
       described in section 3.6.


   3.  Generate a unique pseudo-random SPI.


   4.  Construct a Proposal payload.


  (omit)

SEE ALSO

  perldoc V6evalTool

  IKE.html IKE Test Common Utility