On Wed, 24 Nov 2021, Harold Liu wrote:
Is your implementation not using a rekey fuzz of say 1 to 5 % ? In that way,
two endpoints are extremely unlikely to rekey at the exact same time.
<Harold>
1) We do use randomize the SA life time. Thanks for the feedback.
2) Currently the typical lifetime is 300s (shortest).
3) In the case of gateway to gateway, there is no client or server.
4) In gateway to gateway case, randomizing the SA lifetime is not
sufficient as we do not want to rely on a probabilistic model that depends on
the life time of the child SA, but rather ensure we do not run into such
duplications. At the same time, even though initiator and responder both have
randomize lifetime the lifetime is a completely local value (not negotiated),
and even the initiator and responder can use different values. So there's still
a probability of rekey happening at both ends simultaneously.
5) Due to the arrival of 5G the number of radio access increases greatly
meanwhile IKE sessions are established between GATEWAY and GATEWAY based on
cloud-RAN. At the same time, Cloud-ran causes IKE sessions to be concentrated
on the gateway and gateway so as to the scale of Child SAs is huge, usually
more than thousands. So even a few percent of simultaneous rekeying is
unacceptable because it will bring too many redundant packets and occupy
bandwidth.
</Harold>
Okay that is fair. Please add it to the Introduction of the draft somehow :)
<Harold>
We are looking for a deterministic mechanism. We are happy to change the
one we proposed, but we cannot rely on SA random SA lifetime.
</Harold>
So since lifetime is not negotiated, both endpoints have a need to
rekey. Even if they agree via some other mechanism that one end
should initiate the rekey, what should happen when that rekey is
not happening? At some point the endpoint not initiating will have
to tear down or start a rekey anyway.
So why not, instead of a random process, exchange the maximum Child SA
lifetime accepted before rekey? If the numbers are identical, prefer the
current exchange initiator.
That way, it is deterministic and both endpoints inform the other end
when (plus or minus some fuzz) a rekey is required.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
