[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: issues raised at VPN interoperability workshop
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?
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.
Is it correct to assume that generally, the responder of a phase 2 will be
the first to raise it?
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 -->
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?
If the initiator raised CB first and gets HASH(2) more than once, should he
replay both HDR, HASH(3) and CONNECT notify?
Ylian Saint-Hilaire
INTEL - Communication Architecture Labs
> Aside from the fact that the CB doesn't really accomplish much unless the
> peer's implementation queues packets (I suspect that most sgws don't) and
> yours doesn't...
> 1. The initiator has ample opportunity to setup his SA before the
responder
> uses it.
> 2. The initiator was the one who decided to initiate the SA. Therefore,
one
> can conclude that he will also be the first one to use it.
> The commit bit fixes a race condition that only affects the responder. If
> the responder wants to send the connected notify then he should set the
bit
> himself.
Follow-Ups: