[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 cookie question
Yes, you're right. The N(COOKIE_REQUIRED) would have
no data associated with it, but that would always
be accompanied by N(COOKIE).
Now that you're making me explain it, it sounds sort
of silly, though certainly not "broken". Here are
some alteratives. Anyone care either way, or are we
just making sure the spec is accurate at this point?
a) assign COOKIE a notify type which is informational,
and don't consider it an "error".
b) Put the actual cookie inside the N(COOKIE_REQUIRED)
payload (so Bob wouldn't actually send an N(COOKIE)).
So instead it's really Bob saying, "Send me THIS cookie".
Radia
From: Uri Meth <umeth@columbia.sparta.com>
To: ipsec@lists.tislabs.com
Subject: Re: IKEv2 cookie question
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
USMail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046
Phone: (410) 381-9400 x233
Fax: (410) 381-5559
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