Hi Harold, I failed to understand one thing. The situation you are trying to avoid in most cases happens if peers are configured with equal SA lifetime. Why you don't just configure your gateways with different lifetimes? It seems to me that in scenarios you describe you have a total control over gateways?
> > 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. In our tests we emulated ~3000 SAs between two hosts with lifetime ~300 secs. With SA lifetimes randomization collisions were very rare (don't remember exact data, I believe few percent of total rekeys). > > 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> I can't buy the last argument. Rekey consumes two ~100 bytes messages and little CPU cycles (unless you do PFS). If you can handle 5G traffic, then couple of hundreds extra bytes happened in approximately 1% of all rekeys (which in turn are very small fraction of data traffic) cannot saturate 5G network, IMHO. > 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. Exactly. For this reason I don't think the proposed solution is workable. > 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. It's not enough. There are many cases when rekey is caused not because of time expiration, but due to other reasons. For example, peer may count number of bytes sent and rekey after some amount is reached (when it is critical to limit the number of bytes processed with the same key). Or the number of messages sent (when you want to limit the number of times a key was used for crypto operations). Or just because peer receives too many packets with invalid ICV and decides that he/she is under attack trying to break the current key. I only mentioned those reasons that we implemented... So, there are a lot of reasons for rekey. I think that the ability for any peer to rekey at any time it thinks it is needed is a fundamental property of IKEv2 and I think we should not break it. Regards, Valery. > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
