[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 cookie question
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
On Thu, Apr 03, 2003 at 06:13:56PM -0500, Radia Perlman - Boston Center for Networking wrote:
> 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 <umeth@columbia.sparta.com>
>
>
> 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 umeth@sparta.com
> Columbia, MD 21046
>
--
Uri Meth (410) 872 - 1515 x233 (voice)
SPARTA, Inc. (410) 872 - 8079 (fax)
7075 Samuel Morse Drive umeth@sparta.com
Columbia, MD 21046