Re: [IPsec] FW: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt
Paul Wouters writes: > 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. I think the normal way to do that is to make it so that the original initiator stays initiator. This is usually smart thing anyway as it keeps statistics etc more stable, and in case there is asymmetricy between the nodes, it keeps the asymmetry same. Easiest way to do that is to use shorter lifetime for the initiator, i.e., if your configured lifetime is 3600 seconds, on original initiator you use n * (0.85 ± 0.05), and on the original responder you use n * (1.00 ± 0.05), i.e., your original initiator will start rekey between 2880 and 3240 seconds, and the original responder is only trying rekey after 3420-3780 seconds, so original initiator should be able to finish rekey before original responder even starts thinking about it. Btw, I think 300 seconds is way too short rekey interval and would considere anything less than 10 minutes, or half an hour as an DoS attack against the gateway. Doing Diffie-Hellman that often is consuming lots of resources, and I have no idea what your trust model is to require that frequent rekeying, but similar method should work there too, but at some point you will need to add some fixed modifiers too. I think the implementation I am familiar with did substract fixed 30 seconds from the initiator value always, just to make sure there was time to finish the rekey before other started it. And I think there was lower limit of rekey interval of two minutes or so, and that was mostly because QA wanted to have short rekeying interval for testing (so tests do not run too long), not for real operational use... I.e., the rekeying interval on the original initiator was set to n * (0.85 ± 0.05) - 30 seconds, and on the responder it was set to n * (1.00 ± 0.05). On the responder you would not normally need randomization but I think it was there just in case we talked to some other implementation than our own and having it there might help then. Also it does not really matter if this happens every now and then, i.e., once per 100 rekeys or something like that, it usually is only issue when it happens almost every time. If you follow the rules in RFC you should recover from the duplicate SAs on the next rekey. On the other hand if you are doing Diffie-Hellmans that often you clearly are not concerned about resource use :-) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] FW: New Version Notification for draft-liu-ipsecme-ikev2-rekey-redundant-sas-00.txt
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. > > > > > > 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. > > 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 :) > > > > > 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. > > > > 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
