--------------------

Tero Kivinen (2005-07-12):

> 2.6  Return routability check
...
>    To ensure that the peer cannot generate the correct INFORMATIONAL
>    response without seeing the request, a new payload is added to all
>    INFORMATIONAL messages.  The sender of an INFORMATIONAL request MUST
>    include a COOKIE2 notification payload, and the recipient of an
>    INFORMATIONAL request MUST copy the payload as-is to the response.
>    When processing the response, the original sender MUST verify that
>    the value is the same one as sent.  If the values do not match, the
>    IKE_SA MUST be closed.

I donot think we need to moify all INFORMATIONAL exhcnages to include
N(COOKIE2), only those that are used for the return routability
checks. 

<snip>

> 3.5  COOKIE2 notification payload
> 
>    This payload is included in all INFORMATIONAL exchange messages for
>    return routability check purposes (see Section 2.6).  It is also used
>    in PATH_TEST messages to match requests and responses (see
>    Section 2.5).

I would say we define this in more generic way:
----------------------------------------------------------------------
	This payload MAY be included in any IKEv2 exchange. The data
	associated with this notification MUST be between 8 and 64
	octets in length (inclusive), and MUST be chosen in a way that
	is unpredictable to the recipient. The recipient MUST copy
	this notification to his reply packet. The negotation
	initiator MUST then check that the N(COOKIE2) received from
	the other peer matches the one he sent out.

	This message MUST be included in the IKE exchanges used as a
	return routability check.

	The Notify Message Type for this message is TBD-BY-IANA
	(16396..40959). The Protocol ID field is set to zero (0), and
	SPI Size is set to zero.
----------------------------------------------------------------------

--------------------