[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues with IKE that need resolution
>On Wed, 16 Sep 1998 14:58:16 EDT you wrote
>> > 3. Clarification of use of the commit bit in IKE. This will constrain
>> > the freeform (and confusing) verbage in the base ISAKMP document.
>> > For IKE the commit bit only makes sense in Quick Mode. Most people
>> > I spoke to said that they return a "INVALID_FLAGS" notify message
>> > if the peer tries to set it in any other mode. They also only use it
>> > to extend Quick Mode by a single message-- from the responder back
>> > to the initiator. This was its intended use anyway. Also, most
>> > people send this message as a final Quick Mode exchange message
>> > and not an Informational. The only person I spoke to who did
>> > otherwise said Quick Mode made more sense and was going to change.
At 08:30 PM 9/16/98 -0700, Daniel Harkins wrote:
> What do other people think? I imagine either party could set it and it
>could be set in any message.
I think the approach Dan suggests will provide a more extensible protocol.
Based on the definition of the commit bit, I also assumed it could be set
by either party in any message.
Finally, Section 2 of the IKE ID talks about using IKE in client mode. I
ASSUME the commit bit could be set by either IKE entity to hold off use of
the SA until IKE transfers the SA information to its client.
Tom Markham
References: