[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEv2 cookie question



On 4/4/03 7:04 PM, "Radia Perlman - Boston Center for Networking"
<Radia.Perlman@sun.com> wrote:

I would like the N(COOKIE_REQUIRED) to contain the "requested cookie".
Notify messages without expectations embedded in it, makes me want to send
the N(WHO_CARES) message. :-)

Any clarification of the draft is important and will facilitate
interoperability and adoption. Of course, endless revisions has its own
issues. I strongly suggest that everyone take a good read of the latest
draft, and present as many points (including any ambiguities) that may cause
interop issues.

Scott

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