[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues raised at VPN interoperability workshop
On Thu, Jan 27, 2000 at 04:23:14PM -0800, Saint-Hilaire, Ylian wrote:
>
> I got a bunch of questions about the Commit bit, it seems it does not make
> much sense to have the initiator of phase 1 raise CB. If he does, It is not
> clear what should be done.
>
> ----------
>
> If I am the phase 2 responder, and I see the initiator raising CB on the
> first packet, is it ok for me to voluntarily not echo it back?
Yes.
> As a responder, if I wanted to use CB to get the SA in my driver first... by
> having the initiator raise CB first, I lost my chance to use the CB as
> intended.
No, see below.
> Is it correct to assume that generally, the responder of a phase 2 will be
> the first to raise it?
Not necessarily.
> If the initiator raises CB first, the conversation will look like this:
>
> Initiator Responder
> ----------- -----------
> HDR*, HASH(1), SA, Ni
> [, KE ] [, IDci, IDcr ] -->
> <-- HDR*, HASH(2), SA, Nr
> [, KE ] [, IDci, IDcr ]
> HDR*, HASH(3) -->
> HDR*, HASH, CONNECT -->
Not if you follow draft-ieft-ipsec-ike-01.txt. It states:
The commit bit in the ISAKMP header ([MSST98]) can be used to extend
a Quick Mode by a single message from the Responder to the Initiator
to delay use of the SAs created by the Quick Mode. This message will
It does not say that the Initiator can send a connect-notify to the
responder.
> What do I do if I get the CONNECT notify before HASH(3)? Do ignore it, get
> the Quick mode message than retry again till I get the CONNECT again? or can
> I simply not echo CB and forget about this case?
The responder should not get a connect-notify from the initiator regardless
of who set 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: