strongSwan - Design by Margo Galas <galas (at) solnet (dot) ch>

Main Sponsors



strongSwan 5.9.7 Released

We are happy to announce the release of strongSwan 5.9.7, which delays the IKEv2 key derivation, changes inbound message processing, fixes DHCP request retransmission and comes with several other new features and fixes.

This release includes several changes that were developed for the upcoming IKEv2 extension for multiple key exchanges and the related IKE_INTERMEDIATE exchange over the last four years (see the ikev2-qske-multi-ke branch for those changes). Since it's still unclear when the multi-KE extension will be finalized, and rebasing a branch with so many changes is always a struggle, we decided to merge some of the changes that are not directly related to the actual protocol changes and release them now.

Delaying IKEv2 Key Derivation

The initial IKEv2 key material is based on a Diffie-Hellman exchange for which public keys are exchanged in KE payloads in the first two IKE_SA_INIT messages. So far, strongSwan immediately did the key derivation when it received the peer's KE payload while processing an IKE_SA_INIT message. As responder, this isn't ideal as it's a relatively costly operation (especially for large MODP groups) and IKE_SA_INIT requests could be sent from spoofed IP addresses (until the DoS protection gets activated and COOKIEs are required). With this release the key derivation is delayed until the keys are actually required to process the IKE_AUTH request.

Note that this change has implications for Diffie-Hellman implementations. Please refer to the developer notes in the complete changelog.

Inbound IKEv2 Message Processing

All inbound messages, but in particular requests, are now processed differently. Instead of parsing all messages right away (which might trigger a key derivation or require keys we don't have anymore in the multi-KE use case), we now check a request's message ID and compare its hash to that of the previous request to decide if it's a valid retransmit. For fragmented messages we only keep track of the first fragment so we can send the corresponding response immediately if a retransmit of it is received, instead of waiting for all fragments and reconstructing the complete messages, which we did before.

Fixed DHCP Request Retransmission

The retransmission logic in the dhcp plugin has been fixed. As originally intended, four retransmits are now sent over a total of 15 seconds for each DHCP request. Previously, it could happen that some or all of the five messages were sent at basically the same time, without any delay to wait for a response.

connmark Plugin Considers Masks

The connmark plugin now considers configured masks in installed firewall rules. For instance, with mark_in = mark_out = %unique/0x0000ffff, mark values in the upper two bytes would not get reset by the rules installed by the plugin and could be used for other purposes. However, note that in this example the daemon would have to get restarted after 65'535 CHILD_SAs (at the latest) to reset the global 32-bit counter for unique marks as that's unaware of any masks.

Other Notable Features and Fixes

  • Child config selection has been fixed as responder in cases where multiple children use transport mode traffic selectors.
  • The outbound SA/policy is now also removed after IKEv1 CHILD_SA rekeyings.
  • The openssl plugin supports AES and Camellia in CTR mode.
  • The AES-XCBC/CMAC PRFs are demoted in the default proposal (after HMAC-based PRFs) since they were never widely adopted (RFC 8247 only mentions AES-XCBC and recommends it exclusively for IoT deployments).
  • The kdf plugin is now automatically enabled if any of the aesni, cmac or xcbc plugins are enabled, or if none of the plugins that directly provide HMAC-based KDFs are enabled (botan, openssl or wolfssl).
  • Several issues have been fixed when building strongSwan with GCC 12.

Download Complete Changelog