Subject: Re: IKEv2 cookie question

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 3 Apr 2003 18:13:56 -0500 (EST)

Uri is correct. (good catch!)

The reason for having both N(COOKIE_REQUIRED) and N(COOKIE)
is that IKEv2 has high numbers for type codes for notifies
for "just information" vs low numbers for type codes of
notifies for "errors". Since Alice also sends a COOKIE
in the next message, then that would argue for making
the cookie notification payload a "just information" type.
But since Bob is explaining why he's refusing the connection
attempt, it would argue for being an error type when Bob sends it.

So the spec does it by having two payloads...one an error (COOKIE_REQUIRED),
and the other (COOKIE) passing the cookie.

Certainly there are lots of perfectly reasonable ways of
doing this (for instance, just removing the N(COOKIE_REQUIRED)
and not having it look like an "error", or having two type
codes for COOKIE, depending on which direction the COOKIE is
travelling). Nothing really wrong with how Charlie chose to
do it, other than as Uri points out, the spec is inconsistent.

So probably the easiest change is to add a low-number notification
type for COOKIE_REQUIRED, e.g.,

        COOKIE_REQUIRED                       12

            IKE_SA_INIT rejected because no cookie was included.

>>Is there any way to fix the spec to clear up this ambiguity?
err...yeah...I believe it's not too late at this point. Thanks, again.

Radia

	From: Uri Meth <[email-masked]>

	In the MSEC group, there has been a proposal to potentially add cookies
	to the GSAKMP protocol.  Since IKE had already dealt with this issue I
	looked into how you did cookies.  I am very intrigued by your use of
	cookies, but in reading through the IKEv2 spec I have some questions.
	Either I do not understand your syntax, something is missing, or there
	is some mis-information.  Please help me clarify what is happening.
	
	In Section 2.6 - Cookies , you give the disection for you message 
structure 
	using cookies:
	
	       Initiator                          Responder
	       -----------                        -----------
	       HDR(A,0), SAi1, KEi, Ni   -->
	
	                                 <-- HDR(A,0), N(COOKIE_REQUIRED),
	                                                   N(COOKIE)
	
	       HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->

	From this message I interpret that the reponder sends the initiator a
	message with two (2) notification payloads, cookie_required and cookie.
	The initiator then rebuilds the initial message with the cookie received
	from the responder in the notification cookie payload.
	
	However, in Section 3.10.1 - Notify Message Types, you only have a value
	for COOKIE and not for COOKIE_REQUIRED.  
	
	All this leads me to believe that what you really meant to say is that
	the responder sends a message with one (1) notification payload
	containing the Cookie value.  The initiator takes this cookie value from
	the notification payload and sends it back to the responder in the
	rebuilt initial message.
	
	So which definition is correct?  Is there any way to fix the spec to
	clear up this ambiguity?  Thanx
	
	UM
	-- 
	Uri Meth                            (410) 872 - 1515 x233 (voice)
	SPARTA, Inc.                        (410) 872 - 8079      (fax)
	7075 Samuel Morse Drive             [email-masked]
	Columbia, MD 21046

---

From: Uri Meth <[email-masked]>
Date: Fri, 4 Apr 2003 12:23:06 -0500

Based on the addition of the COOKIE_REUQIRED type, and there being 2
notification payloads in the responder message, I still would like to
make sure I understand one last point - the contents of
N(COOKIE_REQUIRED) (the notification payload of type COOKIE_REQUIRED).

The Notification_Data field of this payload, will be empty as there is
nothing more to pass except to let the initiator know that a cookie is
required.  The real information that will be necessary to extract from
the message is the computed valued which is contained in the
Notification_Data field of the N(COOKIE) payload.

Is all this correct? Thanx

UM