This might not be the case if e.g. an address appeared but the old one
is still available but not actually usable. Without this the MOBIKE
task would eventually time out even though we might be able to switch
to a working address.
Because we only queue one MOBIKE task at a time, but destroy superfluous
ones only after we already increased the counter for pending MOBIKE updates,
we have to reduce the counter when such tasks are destroyed. Otherwise, the
queued task would assume another task is queued when it is running and
ignore any successful response.
Due to how reauthentication works for IKEv1 we could get a second
IKE_SA, which might cause problems, when connectivity problems arise
when the connection is initially established.
Fixes#670.
The adopt_children_job_create() function is not available when IKEv1 support
is disabled. Fixes uncommon builds using --enable-ha --disable-ikev1.
Fixes#690.
When having the unity plugin enabled and both peers send the Unity Vendor ID,
we proposed 0.0.0.0/0 as traffic selector, even if no Split-Include has been
received on the SA. This can break compatibility with some responders, as
they don't narrow the TS themselves, but expect the configured TS.
When an initiator starts reauthentication on a connection that uses push
mode to assign a virtual IP, we can't execute the Mode Config before releasing
the virtual IP. Otherwise we would request a new and different lease, which
the client probably can't handle. Defer Mode Config execution, so the same IP
gets first released then reassigned during reauthentication.
If a peer immediately sends DELETE messages when completing Quick Mode rekeying,
the third Quick Mode message and the DELETE are sent simultaneously. This
implies that DELETE messages may arrive before the completing third Quick Mode
message.
Handle this case by ignoring the DELETE INFORMATIONAL in Quick Mode and let
the delete task handle it.
To check if a received IKE_SA_INIT request is a new request or a
retransmit, charon maintains hashes of the pending IKE_SA_INIT
exchanges.
However, the hash calculation is not reentrant because a single hasher
is used for the whole IKE SA manager. It leads to bogus calculations
under high load and hence dropped messages on responder
(IkeInInvalidSpi incremented).
Don't share a single hasher in the IKE SA manager, create a transient
one whenever a message must be hashed.
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
We sent both a notify using IKEv1 and IKEv2. This is a little more aggressive
than required, RFC 5996 says we "SHOULD send an unauthenticated Notify
message of type INVALID_MAJOR_VERSION containing the highest (closest) version
number it supports".
Fixes#657.
As we later potentially use args again, we can't consume it with printf
functions without copying it first. Clone list before passing it to any
consuming function.
Fixes#621.
While the outbound SA actually does not need a replay window, the kernel rejects
zero replay windows on SAs using ESN. The ESN flag is required to use the full
sequence number in ICV calculation, hence we set the replay window.
This restores the behavior we had before 30c009c2.
The use of overlapped I/O was incorrect, as we passed stack based buffers, but
did not cancel/wait for pending completion on all sockets. Our receive-from-all
socket interface is actually tricky to implement using overlapped I/O. Switch
to WSAEventSelect() event management, which can be canceled properly while
working in a select()-like way.
Similar to assign_vips() used by a peer assigning virtual IPs to the other peer,
the handle_vips() hook gets invoked on a peers after receiving attributes. On
release of the same attributes the hook gets invoked again.
This is useful to inspect handled attributes, as the ike_updown() hook is
invoked after authentication, when attributes have not been handled yet.
Tobias Brunner