issue 32 -- Omitting COOKIE2 from non-RR messages

Tero wrote:

>> 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.
>  
>
I think I agree...

>> 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.
>  
>
Ok.

--Jari