Hi, Thank you all for the comments. I believe there is a misunderstanding of the resource issue we are facing, so please find below a more detailed description.
The resource in question is neither related to the CPU nor the memory, nor the bandwidth as comments seem to suggest but instead related to the number of table entries that perform the IPsec processing that varies between 720 to 4000 depending on the hardware chip. When gateways rekey at the same time, ephemeral SAs are created in the table entry and are filling the entries of the table which means, if we consider the worst case scenario, only half of the table entries can be used. In our cases, using the 4000 entry table, leaving 400 unused entries is not sufficient to prevent legitimate SA from being created and so the hardware is not used at its full capacity. We are proposing a determinist mechanism to address this issue. The general idea is that peers agree that one of the peers will handle the rekey to renew the SA when that SA expires during a given time slot. To take Tero's numbers the rekey time slot could be (0.85 ± 0.05) leaving the future responder the time to realize the commitment has not been respected and take over the rekey. The mechanism is not expected to interfere with any other reasons that would lead to a rekey. The mechanism currently does not provide the SA life time as we thought the mechanism would be mostly useful between gateway that are known to have the same configuration. We are fine extending the mechanism and including the SA life time if we can agree that this does not generate any security / privacy consideration. Randomizing the SA lifetime is a probabilistic approach we - and our customers - do not want to rely on even if the probability of collision decreases with the SA lifetime. Similarly considering different SA lifetime on every device would require some changes in the way the gateways are provisioned our customers would like to avoid. Yours, Daniel On Wed, Nov 24, 2021 at 10:55 AM Valery Smyslov <smyslov.i...@gmail.com> wrote: > 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 > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
