Making the variable volatile avoids a "variable ‘failure’ might be
clobbered by ‘longjmp’" warning (or error when compiling with
-Werror) that's triggered via -Wextra.
The 5.4.0 update changed the default bignum implementation to what
could explicitly be enabled via `--enable-sp-math-all`. Since this uses
fixed-sized buffers sufficient for key sizes of SP_INT_BITS, with a default
of 4096, modp6144 and modp8192 didn't work anymore (wc_DhGenerateKeyPair()
returned MP_EXPTMOD_E). So we have to adapt the feature checks for this.
To support the larger DH groups we can either increase the buffer size
via `--with-max-rsa-bits` or add `--enable-heapmath` so buffers get
(re-)allocated as needed. We go with the latter for now.
This collection of Internet standards and drafts hadn't been
updated for a long time and the documents are readily available
on the Internet anyway. The strongSwan documentation page
https://docs.strongswan.org/docs/5.9/features/ietf.html
specifies which standards are currently supported.
This merge includes changes that were created for the upcoming IKEv2
extension for multiple key exchanges over the last four years, but which
are not directly related to the actual protocol changes.
Changes include renaming diffie_hellman_t to the more generic
key_exchange_t (also renamed are some of the interface's methods),
making utility functions that deal with DH groups more generic, and let
tasks handle the first IKE_AUTH message more reliably by not depending
on e.g. specific message IDs.
One significant change is delaying the IKEv2 key derivation until
the keys are actually needed to process or send the next message. So
instead of deriving the keys directly while processing an IKE_SA_INIT
request (which could come from a spoofed address), this is delayed until
the corresponding IKE_AUTH request is received. Implementations of the
key_exchange_t interface are now expected to do the key derivation and
any costly public key validation in get_shared_secret() and not
set_public_key().
Sent IKE_SA_INIT messages are now also not pre-generated anymore to collect
their encoding for the authentication. Instead, a new post_build() hook
allows the ike-auth task to do so after the actual message has been built,
which allows later tasks and plugins (via message() hook) to modify the
message (e.g. add notifies) after the ike-auth task's build() method
already ran.
Also changed is how inbound requests are processed and retransmits are
detected. Instead of parsing all inbound 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 first 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 message, which we did before.
This way we avoid having to pre-generate the message when it could
theoretically still get modified by a task that follows or from a plugin
via message() hook.
In particular as responder, this delays costly cryptographic operations
until the IKE_AUTH request is received, which is preferable to reduce
the impact of DoS attacks.
Another advantage is that the key material is not changed until all tasks
built or processed a message.
This way we avoid parsing messages with unexpected message IDs, which
might not even be possible if we don't have the keys anymore. However,
the next commit should avoid the latter and this way we avoid deriving
keys for retransmits or unexpected messages.
This also changes how retransmits for fragmented messages are triggered.
Previously, we waited for all fragments and reconstructed the message
before retransmitting the response. Now we only track the first
fragment and if we receive a retransmit of it respond immediately
without waiting for other fragments (which are now ignored). This is in
compliance with RFC 7383, section 2.6.1, and can avoid issues if there
are lots of fragments.
This way we can use the IKE_REKEYED state for both redundant and old SAs
to suppress ike_updown().
In the ike-delete task we don't suppress events in state IKE_REKEYING as
that's the case when we delete an SA the peer is currently rekeying with
multiple key exchanges.
This gives us more flexibility with tasks that return NEED_MORE (currently
none of the colliding tasks do, but that will change with multi-KE
rekeyings). The active task has to check itself if the passive task is
done and should be removed from the task manager.
Since f67199378df9 ("ike-rekey: Handle undetected collisions also if
delete is delayed") we only ever track tasks of type TASK_IKE_REKEY, so
there is no need to check the type or use the generic task_t interface.
Also changed some of the comments to clarify collision handling.
If the peer successfully rekeyed the SA it gets marked as IKE_REKEYED
and it remains until the peer deletes it (or a timeout). There is no
point in rekeying such SAs again.
IKE_REKEYING will be relevant if we have multi-KE rekeyings and are
waiting for followup key exchanges for a passive rekeying.
