[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: issues raised at VPN interoperability workshop



Hi, Will.

> > 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.)
> 
> If your implementation receives a spurious connect-notify 
> will it affect
> (i.e. delete) the previously negotiated P2 SA?  I hope it won't.

No. I think we just send Payload Malformed (and only if you send it after we
have stopped waiting for retransmits).


> If we can all agree that an implementation MUST reflect the CB if they
> intend to honor it otherwise they should not reflect the CB 
> then I would
> not send the C-N as a responder if the initiator did not reflect it.

Since my box is only ever a commit bit responder, I don't really care
whether an implementation is allowed to turn the commit bit off, SO LONG AS
IT IS STANDARDIZED. I thought Dan's explanation at the town hall meeting was
that clearing the commit bit in QM3 did not abdicate the responder from
sending the C-N.

>From Dan's Town Hall Summary:

>   * Can you clear the commit bit during phase 2?
> 
> Yes.
> 
>   * Is the commit bit even mandatory? If it's not and you 
> don't support it
>     what do you do if it's set in an offer? Refuse it?
> 
> It's mandatory.

In other words, you can clear the commit bit, but you can't refuse the
offer.


> > 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.
> 
> I'm not sure this is true.  Let's say Host A initiates the 1st QM
> negotiation for a IPSec tunnel between Host A and Host B then Host B
> initiates the next QM negotiation that will refresh the P2 SA 
> for the IPSec
> tunnel between them because Host B's P2 SA lifetime was 
> shorter than Host
> A's.  Which host will be the first to use the new P2 SA? 

My quote above was actually an attempt to explain why it is not necessary
for the initiator to send a C-N. You have already agreed with me on this
subject.

But since you brought up rekeying, "draft-jenkins-ipsec-rekeying" explains
quite explicitly how you can avoid the lost packets problem by continuing to
use the old SA for a brief period before switching to the new one.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.



Follow-Ups: