Project

General

Profile

Expiry and Replacement of IKE and IPsec SAs

The keys negotiated for IKE and IPsec/CHILD SAs should only be used for a limited amount of time and to protect a limited amount of data. This means that each SA should expire after a specific lifetime. To avoid interruptions a replacement SA may be negotiated before that happens, which is called "rekeying".

Interoperability

There may be interoperability issues related to rekeying and reauthentication, refer to Windows and Mac OS X/iOS.

IKE

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/vici.

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.

This is the default for configurations based on ipsec.conf.

The point of a reauthentiaction, as the term implies, is to re-do 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 (with CRLs or OCSP) is also only checked during (re)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:

  • Break-before-make: This is default behavior of the IKE daemon when reauthenticating an IKEv2 SA. It means that all IKE and IPsec 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 and hence duplicate IPsec SAs during that down time. To prevent plaintext traffic from leaving the host appropriate firewall rules or drop policies may be used.
  • Make-before-break: This method first creates duplicates of the IKE and all IPsec SAs overlapping with the existing ones and then deletes the old ones. This avoids interruptions 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 5.3.0 but is disabled by default and may be enabled with the charon.make_before_break strongswan.conf setting.
    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/randomized reauthentication time to the client (not the hard lifetime of the SA).

Note that strongSwan as 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.

Setting Default Description
swanctl.conf
Compared to ipsec.conf-based configurations it's possible to enable rekeying and reauthentication for the same IKE SA
In connections.<conn> sections
rekey_time 4h Time when rekeying is initiated. If reauth_time is set the default is zero to disable rekeying. Set both to explicitly rekey and reauthenticate an IKE SA. Only supported for IKEv2, IKEv1 will do a reauthentication instead.
reauth_time 0s Time when reauthentication is initiated. May instruct clients to perform reauthentication.
over_time 10% of max(rekey_time, reauth_time) Hard IKE SA lifetime (relative to rekey_time/reauth_time) if rekey/reauth does not complete.
rand_time over_time Time range from which to choose a random value to subtract from rekey/reauth times.
ipsec.conf
The formula used to calculate rekey times for ipsec.conf-based connections is described below
ikelifetime 3h Absolute time after which an IKE SA expires.
reauth yes Whether to use reauthentication instead of inline rekeying for IKEv2. Always enabled for IKEv1 SAs.
The following options also apply to IPsec SAs
margintime 9m Time before SA expiry the rekeying should start.
rekeyfuzz 100% Percentage by which margintime is randomly increased (may exceed 100%). Randomization may be disabled by setting rekeyfuzz=0%.
rekey yes Whether to rekey SAs at all.
Setting Default Description
strongswan.conf
This applies to both configuration backends
charon.make_before_break no Initiate IKEv2 reauthentication with a make-before-break scheme. Make-before-break uses overlapping IKE and CHILD_SA during reauthentication by first recreating all new SAs before deleting the old ones (see above). 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 5.3.0.

IPsec

IPsec SAs (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 DH exchange. The latter is also known as 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's implicitly created with the IKE_AUTH exchange will always be derived from the IKE keys 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 (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. For IKEv1 that's different as each Quick Mode exchange uses the complete proposals, so already the first IPsec SA will use PFS according to the configuration.

CHILD_SA Rekeying Behavior Since 5.5.3

With 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 received the CREATE_CHILD_SA response and updated 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 for the replaced CHILD_SA.

The messages transporting these DELETEs 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 (charon.delete_rekeyed_delay) after the DELETE has been processed.

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.

Setting Default Description
swanctl.conf
In connections.<conn>.children.<child> sections
rekey_time 1h Time when rekeying is initiated. Set to zero to disable.
life_time 110% * rekey_time Maximum lifetime before an IPsec SA gets closed.
rand_time life_time - rekey_time Time range from which to choose a random value to subtract from rekey_time.
rekey_bytes 0 Number of bytes processed before initiating rekeying.
life_bytes 110% * rekey_bytes Maximum number of bytes processed before an IPsec SA gets closed.
rand_bytes life_bytes - rekey_bytes Byte range from which to choose a random value to subtract from rekey_bytes.
rekey_packets 0 Number of packets processed before initiating rekeying.
life_packets 110% * rekey_packets Maximum number of packets processed before an IPsec SA gets closed.
rand_packets life_packets - rekey_packets Packet range from which to choose a random value to subtract from rekey_packets.
ipsec.conf
The formula used to calculate rekey times for ipsec.conf-based connections is described below
lifetime 1h Absolute time after which an IPsec SA expires.
lifebytes Number of bytes transmitted over an IPsec SA before it expires.
marginbytes Number of transmitted bytes before expiry of an IPsec SA the rekeying should start.
lifepackets Number of packets transmitted over an IPsec SA before it expires.
marginpackets Number of transmitted packets before expiry of an IPsec SA the rekeying should start.
The following options also apply to IKE SAs
margintime 9m Time before SA expiry the rekeying should start.
rekeyfuzz 100% Percentage by which any margin is randomly increased (may exceed 100%). Randomization may be disabled by setting rekeyfuzz=0%.
rekey yes Whether to rekey SAs at all.

swanctl.conf Example

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

  • IKE SA default:
    rekey_time = 4h = 240m
    over_time = 10% * rekey_time = 24m
    rand_time = over_time = 24m
    
    expiry = rekey_time + over_time = 264m
    rekey = rekey_time - random(0, rand_time) = [216, 240]m
    
  • IPsec SA default:
    rekey_time = 1h = 60m
    life_time = 110% * rekey_time = 66m
    rand_time = life_time - rekey_time = 6m
    
    expiry = life_time = 66m
    rekey = rekey_time - random(0, rand_time) = [54, 60]m
    

ipsec.conf Formula

The following formula is used to calculate the rekey time of IPsec SAs (applies equally to IKE SAs and byte and packet limits for IPsec SAs) when configured in ipsec.conf:

rekeytime = lifetime - (margintime + random(0, margintime * rekeyfuzz))

Example

Let's consider the default configuration:

lifetime = 1h
margintime = 9m
rekeyfuzz = 100%

From the formula above follows that the rekey time lies between:

rekeytime_min = 1h - (9m + 9m) = 42m
rekeytime_max = 1h - (9m + 0m) = 51m

Thus, the daemon will attempt to rekey the IPsec SA at a random time between 42 and 51 minutes after establishing the SA.
Or, in other words, between 9 and 18 minutes before the SA expires.

Notes

  • Since the rekeying of an SA needs some time, the margin values must not be too low.
  • The value margin... + margin... * rekeyfuzz must not exceed the original limit. For example, specifying margintime = 30m in the default configuration is a bad idea as there is a chance that the rekey time equals zero and, thus, rekeying gets disabled.