Project

General

Profile

Issue #2510

margintime not used when rekey=no

Added by Emeric Poupon about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Category:
starter
Affected version:
5.6.1
Resolution:
Won't fix

Description

Hello,

Here is the situation:
  • initiator is using reauth=no, margintime=5m
  • responder is using reauth=yes, margintime=5m, lifetime=30m

The initiator actually gets the AUTH_LIFETIME notify back from the responder, but it does not apply the margintime.

Therefore, both initiator and responder hosts may reauth the IKE SA at the same time (at 55m), leading to an extra IKE SA negotiated.

Two questions:
- is that valid that the responder tries to reauthenticate the IKE SA? In the wiki it seems to be valid: If the responder can not initiate the reauthentication itself (e.g. due to asymmetric authentication like EAP) it will close the IKE_SA if the client fails to reauthenticate the SA in time.
- is it valid that the margintime is not applied on the initiator?

Regards

History

#1 Updated by Tobias Brunner about 3 years ago

Here is the situation:
  • initiator is using reauth=no, margintime=5m
  • responder is using reauth=yes, margintime=5m, lifetime=30m

The initiator actually gets the AUTH_LIFETIME notify back from the responder, but it does not apply the margintime.

It actually does (documented here: ExpiryRekey), without randomization, though (see source:src/libcharon/sa/ike_sa.c#L2399).

Therefore, both initiator and responder hosts may reauth the IKE SA at the same time (at 55m), leading to an extra IKE SA negotiated.

Since the responder does not send back its configured lifetime, but the calculated (randomized) reauth time, the client should always start earlier than the responder with the above config (check the log and status output to see when reauths are scheduled).

Two questions:
- is that valid that the responder tries to reauthenticate the IKE SA? In the wiki it seems to be valid: If the responder can not initiate the reauthentication itself (e.g. due to asymmetric authentication like EAP) it will close the IKE_SA if the client fails to reauthenticate the SA in time.

If it is possible, i.e. not prevented by an asymmetric config, it's definitely valid for the responder to initiate the reauthentication (e.g. for site-to-site connections). It is currently not possible to disable reauthentication but still request the clients to reauth (but in scenarios where that might be relevant, e.g. for mobile clients, the config is usually asymmetric).

- is it valid that the margintime is not applied on the initiator?

As far as I can tell it is. Please provide more information that show that it isn't.

#2 Updated by Tobias Brunner about 3 years ago

  • Status changed from New to Feedback

#3 Updated by Emeric Poupon about 3 years ago

Tobias Brunner wrote:

Here is the situation:
  • initiator is using reauth=no, margintime=5m
  • responder is using reauth=yes, margintime=5m, lifetime=30m

The initiator actually gets the AUTH_LIFETIME notify back from the responder, but it does not apply the margintime.

It actually does (documented here: ExpiryRekey), without randomization, though (see source:src/libcharon/sa/ike_sa.c#L2399).

Thanks for your support!

Actually the initial bug report is incomplete.
Using rekey=yes make the margintime to be applied, but switching both reauth and rekey options to "no" makes the problem appear.

Here is the initiator config :

conn "TUNN" 
        lifetime = 30m
        ikelifetime = 60m
        margintime = 5m
        rekeyfuzz = 100%
        reauth=no
        rekey=no

Here is the responder config :

conn "TUNN" 
        lifetime = 30m
        ikelifetime = 30m
        margintime = 0m
        rekeyfuzz = 100%

With that configuration, initiator and responder try to reauthenticate at the same time.
The actual problem is: "margintime not used when reauth=no and rekey=no"
Since there are situations where the initiator may reauth even if reauth is set to no, I think margintime should be used.

#4 Updated by Tobias Brunner about 3 years ago

Using rekey=yes make the margintime to be applied, but switching both reauth and rekey options to "no" makes the problem appear.

I see. Yes, that's because if you set rekey=no starter won't send any of the rekeying settings to the daemon: source:src/starter/starterstroke.c#L192. What's the reason you disabled rekeying?

With swanctl.conf you have more control over this (the setting is called over_time there), it defaults to 0 if rekeying and reauthentication are both disable, so you'd have to explicitly set it if you don't want to have rekeying enabled.

#5 Updated by Emeric Poupon about 3 years ago

Tobias Brunner wrote:

Using rekey=yes make the margintime to be applied, but switching both reauth and rekey options to "no" makes the problem appear.

I see. Yes, that's because if you set rekey=no starter won't send any of the rekeying settings to the daemon: source:src/starter/starterstroke.c#L192. What's the reason you disabled rekeying?

With swanctl.conf you have more control over this (the setting is called over_time there), it defaults to 0 if rekeying and reauthentication are both disable, so you'd have to explicitly set it if you don't want to have rekeying enabled.

No particular reason, it is just a bug we spotted during testing sessions.

We planned to move to swanctl.conf, but it requires quite a significant amount of work for us (for example we have patches in starter to close connections that are no longer in the configuration file)

#6 Updated by Tobias Brunner about 3 years ago

  • Subject changed from margintime not used when reauth=no to margintime not used when rekey=no
  • Category set to starter
  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Won't fix

OK, I'll close this issue as it only affects the deprecated starter/stroke backend.

Also available in: Atom PDF