Reauth vs Rekey UI and behavior for swanctl
The IPsec P1 GUI has one "lifetime" box and separate checkboxes to disable reauth and rekey, though as far as I can see rekey for IKE is never configured so that box didn't have any effect.
After #9603, the backend code assumes "lifetime" means rekey for IKEv2 and reauth for IKEv1, which may not always be what the user expects. For example, on 2.4.4 (and before #9603), lifetime was used for the reauth timer alone, even though it wasn't the best choice.
In strongSwan with ipsec.conf, reauth was the default for IKEv1 and IKEv2, and now on swanctl.conf IKEv2 defaults to rekey (IKEv1 does not support rekey), and while reauth works for IKEv2 it can be problematic in that it's potentially disruptive.To make things more clear, we need to change the UI to something more intuitive that reflects what is possible now. In the UI, use three separate fields:
- Rekey Time -- For IKEv2 and Auto, set to 0 to disable rekey
- Reauth Time -- For IKEv1 and Auto, set to 0 to disable reauth
- Over Time -- Available for both, set to 0 to default (which automatically uses 10% of whichever is higher, rekey or reauth)
- lifetime changes to Reauth Time for IKEv1 and auto
- If "Disable Reauth" is set, then set the Reauth time to 0 and set Over Time to lifetime
- lifetime changes to Rekey Time for IKEv2 and auto
- If "Disable Rekey" is set, then set Rekey time to 0 and set Over Time to lifetime
- margintime changes to Over Time, which has a similar effect but can be used with either reauth or rekey, and should be set to 10% of the reauth or rekey value on upgrade
With these changes, the user will have an optimal set of values after upgrade, but can change the values to suit their preferences.
The main question is whether to keep IKEv2 on reauth after upgrade or not. Some might consider it a POLA violation to change, but since the behavior is better overall, it may be worth changing.