Tobias Brunner writes: > It already states in section 3: "Non-optimized, regular rekey requests > MUST always be accepted." ... > So you're saying some configs, that are valid for regular IKEv2, will > just not work with this extension? And we'll only know once there is
Combining those two, I think this is fine. I.e., this is optimization and it does NOT NEED to optimize every single possible configuration. We can clearly state that if you are using certain configurations you can't use this optimization, and have to fall back to normal rekey. For example we could say that if you are negotiating multiple protocols (AH + ESP or ESP + IPCOMP), or if you are using anything else than one single KE algorithm for create child sa, you need to use regular rekey. > The only way to avoid that would be the extension either making > childless IKE SAs mandatory, or strictly prohibiting inconsistent KE > configs between IKE and Child SAs, taking away quite a bit of > flexibility IKEv2 offers. You do not need to make childless IKE SA mandatory, you simply need to do first rekey after initial sa creation using normal rekey, and if that normal rekey has SA/KE payloads that are acceptable for the optimized rekey in the future, then you can use optimized rekeys in the future. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
