By aborting the active task we don't have to wait for potential
retransmits if the other peer does not respond to the current task.
Since IKEv1 has no sequential message IDs and INFORMATIONALs are no real
exchanges this should not be a problem.
Fixes#1537
References #429, #1410Closesstrongswan/strongswan#48
This change allows selectively modifying the default plugin list by setting
the `load` setting of individual plugins (e.g. to disable them or to change
their priority) without enabling charon.load_modular and having to configure
a section and a load statement for every plugin.
If a function we whitelist allocates memory while leak detective is enabled
but only frees it after LD has already been disabled, free() will get called
with invalid pointers (not pointing to the actually allocated memory by LD),
which will cause checks in the C library to fail and the program to crash.
This tries to detect such cases and calling free with the correct pointer.
Lots of static data is allocated in this function, which isn't freed until
the library is unloaded (we can't call OPENSSL_cleanup() as initialization
would fail when calling it again later). When enabling the leak
detective the test runner eventually crashes as all the data allocated during
initialization has an invalid size when freed after leak detective has been
unloaded.
There is currently no way to compare the outer and inner algorithms
encoded in a parsed CRL. X509_CRL_verify() does not seem to check that
either, though (unlike X509_verify()).
We can't call OPENSSL_cleanup() as that would prevent us from
re-initializing the library again (which we use in the Android app, that
loads/unloads plugins).
Depending on the lifetimes a CHILD_SA we rekeyed as responder might
expire shortly afterwards. We don't want to rekey it again.
When retrying due to an INVALID_KE_PAYLOAD notify the expected state
is CHILD_REKEYING if it is anything else (e.g. due to a collision) we
ignore it.
We also abort the exchange properly if we don't find the CHILD_SA, no
need for an empty INFORMATIONAL exchange anymore.
If a passive rekeying fails due to an INVALID_KE_PAYLOAD we don't want
to consider this task later when resolving collisions. This previously
might have caused the wrong SA to get deleted/installed based on the nonces
in the unsuccessful exchange.
Such a task is not initiated unless a certain time has passed. This
allows delaying certain tasks but avoids problems if we'd do this
via a scheduled job (e.g. if the IKE_SA is rekeyed in the meantime).
If the IKE_SA is rekeyed the delay of such tasks is reset when the
tasks are adopted i.e. they get executed immediately on the new IKE_SA.
This hasn't been implemented for IKEv1 yet.
If the peer does not detect the rekey collision and deletes the old
IKE_SA and then receives the colliding rekey request it will respond with
TEMPORARY_FAILURE. That notify may arrive before the DELETE does, in
which case we may just conclude the rekeying initiated by the peer.
Also, since the IKE_SA is destroyed in any case when we receive a delete
there is no point in storing the delete task in collide() as process_i()
in the ike-rekey task will never be called.
We conclude the rekeying before deleting the IKE_SA. Waiting for the
potential TEMPORARY_FAILURE notify is no good because if that response
does not reach us the peer will not retransmit it upon our retransmits
of the rekey request if it already deleted the IKE_SA after receiving
our response to the delete.
This makes handling such IKE_SAs more specifically compared to keeping them
in state IKE_CONNECTING or IKE_ESTABLISHED (which we did when we lost a
collision - even triggering the ike_updown event), or using IKE_REKEYING for
them, which would also be ambiguous.
For instance, we can now reject anything but DELETES for such SAs.
As the static plugin that creates and destroys the default sender was
not initialized because of the missing socket the daemon won't destroy
our sender. Test cases will eventually have to flush the IKE_SA manager to
satisfy the leak detective. However, in case of a test failure and if there
are IKE_SAs in the manager the daemon will flush the SAs when deinitializing,
which will cause deletes to get sent. This crashes if the sender is already
destroyed.
In case listeners on the stack are triggered while cleaning up after a
test failed (e.g. via ike_sa_manager_t::flush) remaining listeners defined on
the stack would cause a segmentation fault.
Moving to the new SA only after receiving the DELETE for the old SA was
not ideal as it rendered the new SA unusable (because it simply didn't
exist in the manager) if the DELETE was delayed/got dropped.
Andreas Steffen