I_RFC2408_3_4_1_P1 - [Initiator Test] Security Association Payload format check
End-Node
I_RFC2408_3_4_1_P1.seq [-tooloption ...] -pkt I_RFC2408_3_4_1_P1.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
HOST-2(TN):responder
|3ffe:501:ffff:101::11
|
Net-y --+--------+------------------------ 3ffe:501:ffff:101::/64
|
|
ROUTER-1(TN)
|3ffe:501:ffff:100::11
|
Net-z --+--------+------------------------ 3ffe:501:ffff:100::/64
|
|3ffe:501:ffff:100:XXXX
NUT:initiator
XXXX: EUI64 address
Verification PointsSA Payload Format
Next Payload field
This field MUST NOT contain the values for the Proposal(2) or
Transform(3) payload.
Place the value of the Next Payload in the Next Payload field.
(In this test, this field is set as 0).
RESERVED Fields
All RESERVED fields in the ISAKMP protocol MUST be set to zero (0).
Place the value zero (0) in the RESERVED field.
Payload Length field
Place the length (in octets) of the payload in the Payload Length
field.
Domain of Interpretation field
This field MUST be present within the Sercurity Association payload.
(In this test, this field is set as 1(IPsec DOI).)
Situation field
This field MUST be present within the Sercurity Association payload.
Implementations MUST support SIT_IDENTITY_ONLY.
(In this test, this field is set as 1(SIT_IDENTITY_ONLY).)
Configuration
Initiator and Responder IKE parameter
At least, following parameter must be included in proposal.
| Machine |
Src |
Dest |
Phase I |
Phase II |
| Ex mode |
Key Value |
Enc Alg |
Hash Alg |
Auth Method |
DH Group |
PH1 Lt |
IDx |
Proto ID |
Trans ID |
Mode |
Auth Alg |
PH2 Lt |
Upper |
| NUT |
NUT addr |
HOST-2 addr |
Main |
IKE-TEST |
3DES |
SHA |
pre-shared key |
2 |
8 Hour |
NUT addr |
PROTO_IPSEC_ESP |
ESP_3DES |
Transport |
HMAC-SHA |
8 Hour |
any |
| HOST-2 |
HOST-2 addr |
NUT addr |
Main |
IKE-TEST |
3DES |
SHA |
pre-shared key |
2 |
8 Hour |
HOST-2 addr |
PROTO_IPSEC_ESP |
ESP_3DES |
Transport |
HMAC-SHA |
8 Hour |
any |
*Ex Mode = Exchange mode
*IDx = identity payload(FQDN or user FQDN can also be chosen as IDx)
*Enc Alg = IKE Encryption Algorithm
*Hash Alg = IKE Authentication Algorithm
*Key Value = pre-shared key value
*PH1 Lt = Phase-1 Lifetime
*PH2 Lt = Phase-2 Lifetime
*Proto ID = Protocol Identifier
*Trans ID = Transform Identifier
*Mode = Encapsulation Mode
*Auth Alg = Authentication Algorithm
*Auth Method = Authentication Method
*DH Group = Diffie-Hellman Group
*Upper = Upper Layer Protocol
*NUT addr = NUT address
*HOST-2 addr = HOST-2 address
Pre-Sequence
In order to start the negotiation of IKE,
NUT transmits Echo Request to TN(HOST-2).
This test check is following.
IDENTITY PROTECTION EXCHANGE
# Initiator(NUT) Direction Responder(TN)
(1) HDR; SA ========>
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).
The first message's Security Association Payload Format must be base
on description of RFC(see above Verification Points).
Clean up SAD and SPD
RFC2407
4.2.1 SIT_IDENTITY_ONLY
The SIT_IDENTITY_ONLY type specifies that the security association
will be identified by source identity information present in an
associated Identification Payload. See Section 4.6.2 for a complete
description of the various Identification types. All IPSEC DOI
implementations MUST support SIT_IDENTITY_ONLY by including an
Identification Payload in at least one of the Phase I Oakley
exchanges ([IKE], Section 5) and MUST abort any association setup
that does not include an Identification Payload.
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.4 Security Association 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Situation ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(omit)
o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last
in the message, then this field will be 0. This field MUST NOT
contain the values for the Proposal or Transform payloads as they
are considered part of the security association negotiation. For
example, this field would contain the value "10" (Nonce payload)
in the first message of a Base Exchange (see Section 4.4) and the
value "0" in the first message of an Identity Protect Exchange
(see Section 4.5).
o RESERVED (1 octet) - Unused, set to 0.
o Payload Length (2 octets) - Length in octets of the entire
Security Association payload, including the SA payload, all
Proposal payloads, and all Transform payloads associated with the
proposed Security Association.
o Domain of Interpretation (4 octets) - Identifies the DOI (as
described in Section 2.1) under which this negotiation is taking
place. The DOI is a 32-bit unsigned integer. A DOI value of 0
during a Phase 1 exchange specifies a Generic ISAKMP SA which can
be used for any protocol during the Phase 2 exchange. The
necessary SA Attributes are defined in A.4. A DOI value of 1 is
assigned to the IPsec DOI [IPDOI]. All other DOI values are
reserved to IANA for future use. IANA will not normally assign a
DOI value without referencing some public specification, such as
an Internet RFC. Other DOI's can be defined using the description
in appendix B. This field MUST be present within the Security
Association payload.
(omit)
o Situation (variable length) - A DOI-specific field that
identifies the situation under which this negotiation is taking
place. The Situation is used to make policy decisions regarding
the security attributes being negotiated. Specifics for the IETF
IP Security DOI Situation are detailed in [IPDOI]. This field
MUST be present within the Security Association payload.
(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.4 Security Association Payload Processing
When creating a Security Association Payload, the transmitting entity
(initiator or responder) MUST do the following:
1. Determine the Domain of Interpretation for which this negotiation
is being performed.
2. Determine the situation within the determined DOI for which this
negotiation is being performed.
3. Determine the proposal(s) and transform(s) within the situation.
These are described, respectively, in sections 3.5 and 3.6.
4. Construct a Security Association payload.
5. Transmit the message to the receiving entity as described in
section 5.1.
(omit)
perldoc V6evalTool
IKE.html IKE Test Common Utility