IPsec SAs or CHILD_SAs are always rekeyed by creating new SAs and thendeleting the old ones. The cryptographic keys may either be derived from theIKE key material or with a separate Diffie-Hellman (DH) exchange. The latteris also known as Perfect Forward Secrecy (PFS). To use PFS, DH groupsmay 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 PFSis 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_SAthat is implicitly created with the IKE_AUTH exchange will always be derivedfrom the IKE key exchange even if PFS is configured. So if the peers disagreeon whether to use PFS or not (or on the DH groups) it will not be known untilthe 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 ofthe daemon until the SA is first rekeyed.
It’s possible to force a CHILD_SA rekeying via the swanctl command and thevici interface. This could be used to test if thereis a PFS configuration mismatch.
Also, since version 5.8.0 strongSwan supports the initiation of childlessIKE_SAs. If enabled, no CHILD_SA is created during IKE_AUTH. The firstCHILD_SA will be created with a separate CREATE_CHILD_SA exchange. Thus theconfiguration 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 changedto avoid traffic loss. When responding to a CREATE_CHILD_SA request to rekey aCHILD_SA the responder already has everything available to install and use thenew 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 inboundpackets until it receives the CREATE_CHILD_SA response and updates the inboundSA. To avoid this the responder only installs the new inbound SA and delaysinstalling the outbound SA until it receives the DELETE notify for thereplaced CHILD_SA.
The messages transporting these DELETE notifications could reach the peerbefore packets sent with the deleted outbound SAs reach it. To reduce thechance of traffic loss due to this the inbound SA of the replaced CHILD_SAis 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 alreadythe 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 marginsto avoid collisions.
The following parameters are used in theconnections.<conn>.childrensection of swanctl.conf
| 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 |
<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 |
<child>.rand_time | [→] | Time range from which to choose a random value to subtract from |
<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 | |
<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 | |
<child>.rand_bytes | [→] | Byte range from which to choose a random value to subtract from |
<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 | |
<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 |
<child>.rand_packets | [→] | Packet range from which to choose a random value to subtract from |
