[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: issues raised at VPN interoperability workshop
> 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).
I don't think this is a fair assumption. If I am not expecting a
NOTIFY_CONNECTED then I will most likely delete my quick mode object soon
after sending QM3. (I will keep it around for a little while in case I need
to retransmit.) This creates a race conditions: If your spurious
NOTIFY_CONNECTED arrives after I have deleted my quick mode object then I
will not know what to do with it. (In fact, I will most likely think that it
is a malformed QM1.)
> 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.
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.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups: