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
