TCP/IP Tutorial and Technical Overview - IBM Redbooks

Note: For ISAKMP phase 1 messages, the SPI field within the Proposal
Payload is not used to identify the ISAKMP Security Association. During
phase 1, the ISAKMP SA is identified instead by the pair of values
, both of which must be non-zero
values. Because the Responder Cookie has not yet been generated by
Host-B, the ISAKMP SA is not yet unambiguously identified.
Transform Payload The Transform Payload specifies KEY_OAKLEY. For
the KEY_OAKLEY transform, Host-A must also
specify the relevant attributes: namely, the
authentication method to be used, the pseudo-random
function to be used, and the encryption algorithm to be
used.
Note: Multiple proposals can be included in message 1.
IKE phase 1, message 2
In message 1, Host-A proposed one or more candidate protection suites to be
used to protect the ISAKMP exchanges. Host-B uses message 2 to indicate
which one, if any, it will support. If Host-A proposed just a single option, Host-B
merely needs to acknowledge that the proposal is acceptable.
The source and destination addresses to be placed in the IP header are those of
Host-B (responder) and Host-A (initiator), respectively. The UDP header
identifies that the destination port is 500, which has been assigned for use by the
ISAKMP protocol. The payload of the UDP packet carries the ISAKMP message
itself.
The message contents are as follows:
ISAKMP header The ISAKMP header in message 2 indicates an
exchange type of Main Mode and contains a Message
ID of 0. Host-B sets the Responder Cookie field to a
random value, which we call Cookie-B, and copies into
the Initiator Cookie field the value that was received in
the Cookie-A field of message 1. The value pair
serves as the SPI for the
ISAKMP Security Association.
Security Association The Security Association field identifies the Domain of
Interpretation (DOI). Because the hosts plan to run
IPSec protocols between themselves, the DOI is
simply IP.
834 TCP/IP Tutorial and Technical Overview