RE: Racing QM Initiator's

[Andrew Krywaniuk <[e-mail]>]

As was already discussed, you can't simply abort one of the negotiations.
You may have to negotiate two SAs for the same selectors. However, you do
have the option of fixing the problem when rekeying.

draft-jenkins-ipsec-rekeying-02.txt recommends (sort of) the following:

3.4.4 Re-keying Timing

   To reduce the probability of simultaneous re-keying, each device
   should re-key at a variable time with respect to the SA's expiration
   limit, in case they are the same. These recommendations apply to
   both phase 1 and phase 2 SAs.

   An example of this is that the end with the higher IP address re-
   keys at 95% of the lifetime, while the end with lower IP address re-
   keys at 85% of the lifetime.

   Whatever rule is chosen, it is recommended that the rule be
   deterministic in order to have predictable and consistent behaviour
   between peers. If the rule had used the SPI as the determining
   factor (as an example did in the first version of this document),
   different peers would be doing the re-keying at different times.

   In any case, simultaneous attempts at re-keying should be supported
   in one form or another, since it can never be guaranteed that this
   will not happen under all circumstances.


As you can see, Tim doesn't actually suggest that 85% and 95% be
standardized. That would impinge on implementors' choice of policy.

However, we could recommend that A send a lifetime notify to B, stating the
time at which she intends to REKEY (rather than the actually expiry time). B
parses the lifetime notify and chooses his own set of rekeying constraints
which fall within his policy but do not conflict with A's stated intentions.

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


> -----Original Message-----
> From: Radha Gowda [mailto:[e-mail]]
> Sent: Wednesday, October 13, 1999 5:44 PM
> To: Ben McCann
> Cc: [e-mail]
> Subject: Re: Racing QM Initiator's
> 
> 
> > 3. One SG aborts and becomes responder. How do you know which should
> > abort? The SG with the lowest IP address?
> 
> Ben,  we also experienced the same problem.  Not just in 
> phase2, but in phase1
> 
> as well.   Just to get things going, we decided to let the 
> one with the higher
> 
> IP address be the initiator.
>