Hi Tero, >> 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.
While there might be configurations that prevent this extension from working at all (but I think e.g. with IPComp sending the CPI with the regular IPCOMP_SUPPORTED notify in the optimized rekeying exchange should be fine), I think, with regards to key exchanges, a regular rekeying is really only necessary the first time the initial Child SA is rekeyed. For all other Child SAs it's perfectly fine to use optimized rekeyings because their proposals were negotiated with a regular CREATE_CHILD_SA exchange. >> 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. That's exactly what I'm proposing. Make it *mandatory* that the first rekeying of the Child SA that's created with IKE_AUTH is a regular one. Because if that's not the case, it might be impossible for a responder to deduce what the initiator's proposal is. All further rekeyings of that Child SA can be optimized afterwards. Regards, Tobias _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
