Project

General

Profile

Actions

Bug #9983

closed

Reauth vs Rekey UI and behavior for swanctl

Added by Jim Pingle almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
Start date:
12/18/2019
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.5.0
Affected Architecture:
All

Description

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)
On Upgrade:
  • 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.

Actions #1

Updated by Jim Pingle almost 5 years ago

  • Description updated (diff)
Actions #2

Updated by Jim Pingle almost 5 years ago

Looks like using lifetime=>reauth_time is best, due to POLA and maintaining consistent behavior. Users can always choose to switch to rekey (or do both) for IKEv2 after upgrade if they prefer.

Actions #3

Updated by Jim Pingle almost 5 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #4

Updated by Jim Pingle almost 5 years ago

  • Status changed from Feedback to Resolved

Seems to be working as intended for now. Can revisit if anything new comes up.

Actions

Also available in: Atom PDF