IKE and IPsec SA Renewal

The keys negotiated for IKE SAs and IPsec SAs should only be used for a limited amount of time. Additionally IPsec SA keys should only encrypt a limited amount of data. This means that each SA should expire after a specific lifetime or after a specific data or packet volume. To avoid interruptions, a replacement SA needs to be negotiated before that happens. This is called rekeying.

Interoperability

There may be interoperability issues related to rekeying and reauthentication. Please refer to Windows and macOS/iOS.

IKE SAs

Depending on the IKE version there are up to three ways to replace an IKE SA before it expires.

Rekeying

In comparison to IKEv1 which only supports reauthentication (see below), IKEv2 provides proper inline rekeying of IKE SAs by use of CREATE_CHILD_SA exchanges. This means that new keys may be established without any interruption of the existing IKE and IPsec SAs.

This is the default for IKEv2 configurations based on swanctl.conf using the vici management interface.

Reauthentication

This method to renew the IKE keys involves creating a complete IKE SA from scratch, which includes complete IKE_SA_INIT and IKE_AUTH exchanges and the recreation of all associated IPsec SAs.

The point of a reauthentication, as the term implies, is to redo the authentication and to verify that the peers still have access to valid credentials. Without reauthentication it is currently possible to keep a connection alive even after a peer’s certificate has expired. Revocation of certificates by means of CRLs or OCSP is also only checked during authentication. Reauthentication also could make sense in cases where smart cards are used for client authentication, as it ensures that the user still has the smart card inserted and unlocked with the PIN.

Reauthenticating an IKE SA may be done in two ways:

Make-before-break: This is the default behavior since version 6.0.0 when reauthenticating an IKEv2 SA. This method first creates duplicates of the IKE SAs and all CHILD SAs overlapping with the existing ones and then deletes the old ones. This avoids interruptions (not completely, as rekeying does, because the responder will usually use the new CHILD SAs before the initiator can install them), but requires that both peers can handle overlapping SAs (e.g. in regards to virtual IPs, duplicate policies or updown scripts). It is supported for IKEv2 since version 5.3.0.
Break-before-make: With this method, all IKE_SAs and CHILD SAs are torn down before recreating them. This will cause some interruptions during which no IPsec SAs are installed. If trap policies are used, it could also trigger unnecessary acquires during the downtime that possibly result in duplicate IPsec SAs. To prevent plaintext traffic from leaving the host, appropriate firewall rules or drop policies may be used.

The make_before_break option was introduced in strongswan.conf with strongSwan version 5.3.0. It is is enabled by default since version 6.0.0.

Setting Default Description

Setting	Default	Description
make_before_break	`yes`	Initiate IKEv2 reauthentication with a make-before-break instead of a break-before-make scheme. Make-before-break uses overlapping `IKE` and `CHILD SA` during reauthentication by first recreating all new SAs before deleting the old ones. This behavior can be beneficial to avoid connectivity gaps during reauthentication, but requires support for overlapping SAs by the peer. strongSwan can handle such overlapping SAs since version 5.3.0

make_before_break

yes

Initiate IKEv2 reauthentication with a make-before-break instead of a break-before-make scheme. Make-before-break uses overlapping IKE and CHILD SA during reauthentication by first recreating all new SAs before deleting the old ones. This behavior can be beneficial to avoid connectivity gaps during reauthentication, but requires support for overlapping SAs by the peer. strongSwan can handle such overlapping SAs since version 5.3.0

IKEv1 SAs are also rekeyed/reauthenticated using a make-before-break scheme. However only the IKE SA is affected. IPsec SAs are adopted by the new IKE SA and not recreated.

IKEv2 Responder Behavior

Responders that have reauthentication configured will use the AUTH_LIFETIME notify defined by RFC 4478 to demand that clients reauthenticate before a certain time. 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. The responder sends the calculated and randomized reauthentication time to the client (not the hard lifetime of the SA).

Starting with version 5.9.4, the criteria for sending an AUTH_LIFETIME notification by the IKE responder have changed: When IKE reauthentication is enabled (reauth_time > 0), AUTH_LIFETIME notifies are now only sent by a responder if it can’t reauthenticate the IKE_SA itself due to asymmetric authentication (i.e. EAP) or the assignment of virtual IP addresses.

Note that strongSwan as a client will adhere to AUTH_LIFETIME notifies even if reauthentication is disabled in the config (or configured differently). It subtracts the locally configured over_time or margintime from the received lifetime and schedules a reauthentication.

Settings

The following settings control when IKE SAs expire and how and when they are replaced. Note that both configuration backends support randomization of rekeying times to avoid collisions.

The following parameters are used in the connections section of swanctl.conf:

Key Default Description [default]

Key	Default	Description [default]
<conn>.reauth_time	`0s`	Time to schedule IKE reauthentication. IKE reauthentication recreates the IKE/ISAKMP SA from scratch and re-evaluates the credentials. In asymmetric configurations (with EAP or configuration payloads) it might not be possible to actively reauthenticate as responder. The IKEv2 reauthentication lifetime negotiation can instruct the client to perform reauthentication. Reauthentication is disabled by default. Enabling it can usually result in short connection interruptions, even when using make-before-break reauthentication, which is now the default. However, they are significantly shorter than when using the legacy break-before-make approach, which could still be used for compatibility reasons by disabling `charon.make_before_break` in `strongswan.conf`
<conn>.rekey_time	`4h`	IKE rekeying refreshes key material using a Diffie-Hellman key exchange, but does not re-check associated credentials. It is supported with IKEv2 only. IKEv1 performs a reauthentication procedure instead. With the default value, IKE rekeying is scheduled every `4` hours minus the configured `rand_time`. If a `reauth_time` is configured, `rekey_time` defaults to zero, disabling rekeying. In that case set `rekey_time` explicitly to both enforce rekeying and reauthentication
<conn>.over_time	[→]	Hard IKE_SA lifetime if rekey/reauth does not complete, as time. To avoid having an IKE or ISAKMP connection kept alive if IKE reauthentication or rekeying fails perpetually, a maximum hard lifetime may be specified. If the IKE_SA fails to rekey or reauthenticate within the specified time, the IKE_SA gets closed. In contrast to CHILD_SA rekeying, `over_time` is relative in time to the `rekey_time` and `reauth_time` values, as it applies to both. The default is 10% of either `rekey_time` or `reauth_time`, whichever value is larger. [`0.1 * max(rekey_time, reauth_time)`]
<conn>.rand_time	[→]	Time range from which to choose a random value to subtract from rekey/reauth times. To avoid having both peers initiating the rekey/reauth procedure simultaneously, a random time gets subtracted from the rekey/reauth times. The default is equal to the configured `over_time`. [`over_time`]

<conn>.reauth_time

0s

Time to schedule IKE reauthentication. IKE reauthentication recreates the IKE/ISAKMP SA from scratch and re-evaluates the credentials. In asymmetric configurations (with EAP or configuration payloads) it might not be possible to actively reauthenticate as responder. The IKEv2 reauthentication lifetime negotiation can instruct the client to perform reauthentication. Reauthentication is disabled by default. Enabling it can usually result in short connection interruptions, even when using make-before-break reauthentication, which is now the default. However, they are significantly shorter than when using the legacy break-before-make approach, which could still be used for compatibility reasons by disabling charon.make_before_break in strongswan.conf

<conn>.rekey_time

4h

IKE rekeying refreshes key material using a Diffie-Hellman key exchange, but does not re-check associated credentials. It is supported with IKEv2 only. IKEv1 performs a reauthentication procedure instead. With the default value, IKE rekeying is scheduled every 4 hours minus the configured rand_time. If a reauth_time is configured, rekey_time defaults to zero, disabling rekeying. In that case set rekey_time explicitly to both enforce rekeying and reauthentication

<conn>.over_time

[→]

Hard IKE_SA lifetime if rekey/reauth does not complete, as time. To avoid having an IKE or ISAKMP connection kept alive if IKE reauthentication or rekeying fails perpetually, a maximum hard lifetime may be specified. If the IKE_SA fails to rekey or reauthenticate within the specified time, the IKE_SA gets closed. In contrast to CHILD_SA rekeying, over_time is relative in time to the rekey_time and reauth_time values, as it applies to both. The default is 10% of either rekey_time or reauth_time, whichever value is larger. [0.1 * max(rekey_time, reauth_time)]

<conn>.rand_time

[→]

Time range from which to choose a random value to subtract from rekey/reauth times. To avoid having both peers initiating the rekey/reauth procedure simultaneously, a random time gets subtracted from the rekey/reauth times. The default is equal to the configured over_time. [over_time]

IPsec SAs

IPsec SAs or CHILD_SAs are always rekeyed by creating new SAs and then deleting the old ones. The cryptographic keys may either be derived from the IKE key material or with a separate Diffie-Hellman (DH) exchange. The latter is also known as Perfect Forward Secrecy (PFS). To use PFS, DH groups may be added to the proposals for the IPsec SAs e.g.

esp_proposals = aes128-sha256-modp3072

in swanctl.conf. To make PFS optional (i.e. let the peer choose whether PFS is used or not) add proposals with and without DH groups e.g.

esp_proposals = aes128-sha256-modp3072,aes128-sha256

IKEv2

There is one important aspect that affects IKEv2. The keys for the CHILD_SA that is implicitly created with the IKE_AUTH exchange will always be derived from the IKE key exchange even if PFS is configured. So if the peers disagree on whether to use PFS or not (or on the DH groups) it will not be known until the CHILD_SA is first rekeyed with a CREATE_CHILD_SA exchange (and fails). This is also the reason why you won’t see a DH group in the status output of the daemon until the SA is first rekeyed.

It’s possible to force a CHILD_SA rekeying via the swanctl command and the vici interface. This could be used to test if there is a PFS configuration mismatch.

Also, since version 5.8.0 strongSwan supports the initiation of childless IKE_SAs. If enabled, no CHILD_SA is created during IKE_AUTH. The first CHILD_SA will be created with a separate CREATE_CHILD_SA exchange. Thus the configuration issue as described above will be apparent right from the start, without having to trigger a rekeying or wait for one.

CHILD_SA Rekeying Behavior since Version 5.5.3

With version 5.5.3 the behavior during IKEv2 CHILD_SA rekeyings has changed to avoid traffic loss. When responding to a CREATE_CHILD_SA request to rekey a CHILD_SA the responder already has everything available to install and use the new CHILD_SA. However, immediately doing so (as strongSwan did before 5.5.3) could lead to lost traffic as the initiator won’t be able to process inbound packets until it receives the CREATE_CHILD_SA response and updates the inbound SA. To avoid this the responder only installs the new inbound SA and delays installing the outbound SA until it receives the DELETE notify for the replaced CHILD_SA.

The messages transporting these DELETE notifications could reach the peer before packets sent with the deleted outbound SAs reach it. To reduce the chance of traffic loss due to this the inbound SA of the replaced CHILD_SA is not removed for a configurable amount of seconds as defined by the

charon.delete_rekeyed_delay

parameter after the DELETE notify has been processed.

IKEv1

With IKEv1 each Quick Mode exchange uses the complete proposals, so already the first IPsec SA will use PFS according to the configuration.

Settings

The following settings control when IPsec SAs expire and when they are replaced. Note that both configuration backends support randomization of rekeying margins to avoid collisions.

The following parameters are used in the connections.<conn>.children section of swanctl.conf

Key Default Description [default]

Key	Default	Description [default]
<child>.rekey_time	[→]	Time to schedule CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of `rand_time` gets subtracted to form the effective soft lifetime. If `life_time` is explicitly configured, it defaults to 10% less than that, otherwise CHILD_SA rekeying is scheduled every hour, minus `rand_time`. [`1h` or `life_time / 1.1`]
<child>.life_time	[→]	Maximum lifetime before CHILD_SA gets closed. Usually this hard lifetime is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than the `rekey_time`. [`1.1 * rekey_time`]
<child>.rand_time	[→]	Time range from which to choose a random value to subtract from `rekey_time`. The default is the difference between `life_time` and `rekey_time`. [`life_time - rekey_time`]
<child>.rekey_bytes	[→]	Number of bytes processed before initiating CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of `rand_bytes` gets subtracted to form the effective soft volume limit. Volume based CHILD_SA rekeying is disabled by default. If `life_bytes` is explicitly configured, it defaults to 10% less than that. [`0` or `life_bytes / 1.1`]
<child>.life_bytes		Maximum bytes processed before CHILD_SA gets closed. Usually this hard volume limit is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than `rekey_bytes`. [`1.1 * rekey_bytes`]
<child>.rand_bytes	[→]	Byte range from which to choose a random value to subtract from `rekey_bytes`. The default is the difference between `life_bytes` and `rekey_bytes`. [`life_bytes - rekey_bytes`]
<child>.rekey_packets	[→]	Number of packets processed before initiating CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of `rand_packets` gets subtracted to form the effective soft packet count limit. Packet count based CHILD_SA rekeying is disabled by default. If `life_packets` is explicitly configured, it defaults to 10% less than that. [`0` or `life_packets / 1.1`]
<child>.life_packets	[→]	Maximum number of packets processed before CHILD_SA gets closed. Usually this hard packets limit is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than `rekey_packets`. [`1.1 * rekey_packets`]
<child>.rand_packets	[→]	Packet range from which to choose a random value to subtract from `rekey_packets`. The default is the difference between `life_packets` and `rekey_packets`. [`life_packets - rekey_packets`]

<child>.rekey_time

[→]

Time to schedule CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of rand_time gets subtracted to form the effective soft lifetime. If life_time is explicitly configured, it defaults to 10% less than that, otherwise CHILD_SA rekeying is scheduled every hour, minus rand_time. [1h or life_time / 1.1]

<child>.life_time

[→]

Maximum lifetime before CHILD_SA gets closed. Usually this hard lifetime is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than the rekey_time. [1.1 * rekey_time]

<child>.rand_time

[→]

Time range from which to choose a random value to subtract from rekey_time. The default is the difference between life_time and rekey_time. [life_time - rekey_time]

<child>.rekey_bytes

[→]

Number of bytes processed before initiating CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of rand_bytes gets subtracted to form the effective soft volume limit. Volume based CHILD_SA rekeying is disabled by default. If life_bytes is explicitly configured, it defaults to 10% less than that. [0 or life_bytes / 1.1]

<child>.life_bytes

Maximum bytes processed before CHILD_SA gets closed. Usually this hard volume limit is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than rekey_bytes. [1.1 * rekey_bytes]

<child>.rand_bytes

[→]

Byte range from which to choose a random value to subtract from rekey_bytes. The default is the difference between life_bytes and rekey_bytes. [life_bytes - rekey_bytes]

<child>.rekey_packets

[→]

Number of packets processed before initiating CHILD_SA rekeying. CHILD_SA rekeying refreshes key material, optionally using a Diffie-Hellman exchange if a group is specified in the proposal. To avoid rekey collisions initiated by both ends simultaneously, a value in the range of rand_packets gets subtracted to form the effective soft packet count limit. Packet count based CHILD_SA rekeying is disabled by default. If life_packets is explicitly configured, it defaults to 10% less than that. [0 or life_packets / 1.1]

<child>.life_packets

[→]

Maximum number of packets processed before CHILD_SA gets closed. Usually this hard packets limit is never reached, because the CHILD_SA gets rekeyed before. If that fails for whatever reason, this limit closes the CHILD_SA. The default is 10% more than rekey_packets. [1.1 * rekey_packets]

<child>.rand_packets

[→]

Packet range from which to choose a random value to subtract from rekey_packets. The default is the difference between life_packets and rekey_packets. [life_packets - rekey_packets]

Example

With the default settings in swanctl.conf the following times are used:

IKE SA default:
```
rekey_time = 4h = 240m
over_time = 0.1 * rekey_time = 24m
rand_time = over_time = 24m

expiry = rekey_time + over_time = 264m
rekey = rekey_time - random(0, rand_time) = [216, 240]m
```
Thus the daemon will attempt to rekey the IKE SA at a random time between 216 and 240 minutes after establishing the SA. Or in other words, between 24 and 48 minutes before the SA expires.
IPsec SA default:
```
rekey_time = 1h = 60m
life_time = 1.1 * rekey_time = 66m
rand_time = life_time - rekey_time = 6m

expiry = life_time = 66m
rekey = rekey_time - random(0, rand_time) = [54, 60]m
```
Thus the daemon will attempt to rekey the IPsec SA at a random time between 54 and 60 minutes after establishing the SA. Or in other words, between 6 and 12 minutes before the SA expires.

Since the rekeying of an SA needs some time, the margin values must not be set too low.