Re: QoS selectors (was LAST CALL: IKE)

[Tero Kivinen <kivinen@ssh.fi>]

jpickering@creeksidenet.com writes:
> Simul rekey tiebreaking from IKE's protocol perspective, requires that 
> the responder be able to
> determine at this point if the attempt to create this new SA is a rekey 
> or different SA. If there is nothing in
> the traffic spec (eg a uniqueifier) or elsewhere (eg a new notify 
> payload) to differentiate, tiebreaking
> does not work.

I do not think there is need for tiebraking in those cases. If host A
and B are going to have several SAs up anyways, and they both happen
to rekey one pair simultaneously, they create one extra SA pair, which
they can use next time they need SA which is not tied to any TOS (i.e
when they start rekying next SA, they notice that they already have
new unused SA ready, thus use it instead and simply delete the old
one).

I myself do not consider those extra SAs as a problem in general. Just
make sure that they are not all rekeyed next time, so the number of
SAs does not multiply every rekey. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/