Re: issues with IKE that need resolution

Shawn_Mamros@BayNetworks.COM (Shawn Mamros) Thu, 17 September 1998 15:02 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA01154 for ipsec-outgoing; Thu, 17 Sep 1998 11:02:40 -0400 (EDT)
Message-Id: <3.0.32.19980916145815.00a09680@bl-mail1.corpeast.baynetworks.com>
X-Sender: smamros@bl-mail1.corpeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 16 Sep 1998 14:58:16 -0400
To: Daniel Harkins <dharkins@cisco.com>
From: Shawn_Mamros@BayNetworks.COM
Subject: Re: issues with IKE that need resolution
Cc: ipsec@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

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

So that final Quick Mode message would presumably include the "CONNECTED"
Notify payload, right?  Would there also be a Hash payload to authenticate
it?  If so, what goes in that hash?  If people are already implementing
this, it'd be nice to know how it's done...

Also, is the initiator required to send the commit bit in the third Quick
Mode message if it requires the fourth "CONNECTED" message, or does the
responder always need to keep an eye out for it earlier on in the exchange
(perhaps even as early as Phase 1?)?

-Shawn Mamros
E-mail to: smamros@BayNetworks.com