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