2.2.3.5 Notify Payload (Payload Type 0x0B) Packet
The notify payload is similar to the IKEv1 notification payload, as specified in [RFC2408] section 3.14. However, the field that is referred to as spiSize in IKEv1 is referred to as Flags in the Authenticated Internet Protocol; also, the SPI field is absent. The receiver MUST interpret the spiSize field as a Flags field if the exchange type for the message is an Authenticated Internet Protocol private exchange type, as specified in section 2.2.1.
The following diagram shows the Notify payload 0x0B packet structure.
|
|
|
|
|
|
|
|
|
|
1 |
|
|
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
|
|
3 |
|
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Domain_of_Interpretation |
|||||||||||||||||||||||||||||||
Protocol-ID |
Flags |
Notify_Message_Type |
|||||||||||||||||||||||||||||
Notification_Data (variable) |
|||||||||||||||||||||||||||||||
... |
Domain_of_Interpretation (4 bytes): This field, which specifies the domain of interpretation (DOI), MUST be set to 1 (IPSEC_DOI) as specified in [RFC2408] section A.2.
Protocol-ID (1 byte): This field indicates the exchange type to which this notification applies. It MUST be one of the following values.
Flags (1 byte): This flag indicates a reliable notify message, which MUST be acknowledged by the peer. If this flag is not set, the recipient MUST NOT acknowledge the notify message. See section 3.1.5.1 for additional information. The following table shows the only allowed Flags field.
-
Value
Meaning
0x01
RELIABLE_NOTIFY_FLAG
Reliable notification
-
All other flags MUST be set to zero by the sender and MUST be ignored by the recipient.
Notify_Message_Type (2 bytes): The Notify_Message_Type identifies the type of notification that is sent with this message. The notify message types are from the private range, as specified in [RFC2408] section 3.14.1.
-
Value
Meaning
0x9C45
EXCHANGE_INFO
This notify message type is used by the negotiation discovery IKE protocol extension, as specified in [MS-IKEE] section 3.7.
0x9C54
NOTIFY_STATUS
This notify message type is used to request the peer to delete its state for the corresponding security association (SA), as specified in [MS-IKEE] section 3.8.
0x9C55
NOTIFY_DOS_COOKIE
This notify message type is used by the responder under the denial of service protection mode, as specified in [MS-IKEE] section 3.9.
0x9C56
NOTIFY_ACK
This notify message type is used to acknowledge a reliable notify message.
0x9C57
NOTIFY_QM_SYNCHRONIZE
This notify message type is used to signal the end of the quick mode phase.
0x9C58
NOTIFY_ACQUIRE
This notify message type is used to instruct the peer to negotiate a new main mode security association (MM SA).
Notification_Data (variable): The contents of this field depend on the Notify_Message_Type field. The following list describes the field contents for various notify message types:
NOTIFY_QM_SYNCHRONIZE (0 bytes): No notification data.
NOTIFY_STATUS (4 bytes): An error code that indicates the type of failure that is triggering the SA deletion notification. The values that are transmitted as error codes are implementation-specific.<9>
NOTIFY_ACK (4 bytes): The sequence number of the Crypto payload that carried the Notify payload that is being acknowledged.
NOTIFY_ACQUIRE: (See section 2.2.3.6)
A Notify payload of type NOTIFY_ACQUIRE MUST be followed by two phase-2 Identification payloads, as specified in [RFC2407] section 4.6.2. Each of these phase-2 Identification payloads MUST have the Generic payload header and MUST follow and be adjacent to the Notify payload. The first Identification payload MUST be the initiator Identification payload. The second payload MUST be the peer Identification payload. If any of these conditions is not met, the responder MUST silently discard the packet.
NOTIFY_DOS_COOKIE (8 bytes): The responder cookie value.
When the NOTIFY_DOS_COOKIE notify message type is used, it MUST be the only payload in the message, and it MUST NOT be within a Crypto payload.
EXCHANGE_INFO (4 bytes): Flags. The following table describes the flag values.
Value
Meaning
0x00000001
IKE_EXCHANGE_INFO_ND_BOUNDARY
This flag is used by the negotiation discovery IKE protocol extension, as specified in [MS-IKEE] section 2.2.6.
0x00000002
IKE_EXCHANGE_INFO_GUARANTEE_ENCRYPTION
This flag is used by the negotiation discovery IKE protocol extension, as specified in [MS-IKEE] section 2.2.6.
-
These flags can be set independently. All other flags MUST be set to zero by the sender and MUST be ignored by the recipient.