[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues raised at VPN interoperability workshop
Regarding the Commit Bit in Quick Mode:
See my comments below.
On Wed, Jan 19, 2000 at 09:00:33AM -0500, Tim Jenkins wrote:
>
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> > Sent: January 18, 2000 5:38 PM
> > To: ipsec@lists.tislabs.com
> > Subject: issues raised at VPN interoperability workshop
> >
> ...
>
> >
> > Commit Bit
> >
> > * Can you clear the commit bit during phase 2?
> >
> > Yes.
> >
>
> What does this mean?
>
> Is this asking "Can the commit bit be set to 0 in quick mode?"
> (This is normal operation, so I doubt this was the question.)
> Is this asking "Can the commit bit be set to 0 in the third quick mode
> message by the initiator if set in the second by the responder?"
> (Probably not supposed to be. One vendor interpreted this as rejection of
> the bit, another ignored it. Maybe this should be clarified as well.)
I implemented Commit Bit (CB) in Quick Mode (QM) with the following logic.
Regardless of whether the AIX IKE daemon is initiator or responder, the
administrator can configure it such that the IKE daemon turns CB on in QM
only. If the CB is reflected (i.e. turned on) back by the other side then
the IKE daemon will assume that the other side will honor the CB and
process the QM according to draft-ieft-ipsec-ike-01.txt. If the CB is not
reflected back (set to 0) then the IKE daemon will assume that the other
side is not processing the CB and will proceed as though the CB was not set
(The AIX initiator will not wait for the connect-notify before passing the
P2 SA to IPSec. The AIX responder will send a connect-notify just in case
but I assume this should not cause a problem if the initiator is not
expecting a connect-notify).
This logic obviously depends upon the other implementations reflecting (or
not) the CB in a consistent manner. I spoke with several developers at the
San Diego Bakeoff who felt that this is a reasonable approach allowing
implementors to either support or not support the CB without impacting
interoperability. If everyone agrees that this is a "good thing" then I
think the wording in the draft-ieft-ipsec-ike-02.txt should state the
reflecting behavior as a MUST.
> Additionally, there was talk about allowing the initiator of a quick mode
> exchange to set the commit bit. I'd like to propose that this be explicitly
> disallowed, and that it explicitly stated that only the responder of a quick
> mode exchange may set the commit bit.
>
> Reasons:
> 1) The benefit is minimal, if any.
> 2) It increases complexity.
>
> Does anyone do this? Does anyone support this case as responder?
As I stated above, my implementation can turn on the CB as initiator. I am
assuming that if the admin decided they wanted the connect notify sent as
additional P2 SA use synchronization they should be able to request that of
the responder regardless of whether the responder has CB turned on in their
security policy. Again, if the responder chooses not to honor the CB from
the initiator the responder can just perform the QM as though the CB was
not set (and not reflect the CB).
--
Will Fiveash
IBM AIX System Development Internet: will@austin.ibm.com
11400 Burnet Road, Bld.905/9551 Notes: will@austin.ibm.com
Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904
References: