Expiry and Replacement of IKE and IPsec SAs (Rekeying, Reauthentication) - Expiry and Replacement of IKE and IPsec SAs (Rekeying, Reauthentication) (2024)

• Table of contents
• Expiry and Replacement of IKE and IPsec SAs
  • Interoperability
  • IKE
    • Rekeying
    • Reauthentication
      • IKEv2 Responder Behavior
    • Settings
  • IPsec
    • IKEv2
      • CHILD_SA Rekeying Behavior Since 5.5.3
    • Settings
  • swanctl.conf Example
  • ipsec.conf Formula
    • Example
    • Notes

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.

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

It's possible to force a CHILD_SA rekeying via swanctl/vici and ipsec stroke, which could be used to test if there is a PFS configuration mismatch.

Also, since 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 already be created with a separate CREATE_CHILD_SA exchange. So configuration issued 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 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.

swanctl.conf Example¶

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

• IKE SA default:

  rekey_time = 4h = 240mover_time = 10% * rekey_time = 24mrand_time = over_time = 24mexpiry = rekey_time + over_time = 264mrekey = rekey_time - random(0, rand_time) = [216, 240]m

• IPsec SA default:

  rekey_time = 1h = 60mlife_time = 110% * rekey_time = 66mrand_time = life_time - rekey_time = 6mexpiry = life_time = 66mrekey = 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 = 1hmargintime = 9mrekeyfuzz = 100%

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

rekeytime_min = 1h - (9m + 9m) = 42mrekeytime_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.