Since active task's destruction might result in adopting tasks from a
rekeyed ike sa it seems better to first destroy the active task list and
then destroy all queued tasks. This way adoption is possible at all,
while otherwise the queued task list would be empty.
Certificates which are set on hold in a CRL might be removed from any
subsequent CRL. Hence you cannot conclude that a certificate is revoked
for good in this case, you would try to retrieve an update CRL to see if
the certificate on hold is still on it or not.
Keying material is derived in two separate steps for local and remote
endpoint. This allows us to securely wipe local/remote secrets
separately, too -- a precondition to wipe quick mode keys from memory in
a secure fashion.
Given the original intent of entry->host, the check for DoS attacks, it
can happen that this value remains NULL when an entry is created. This
is particularly awkward if put_connected_peers is called to check if a
connection to a given peer already exists, since it takes the address
family into consideration (git commit b74219d0) which is gleaned from
entry->host.
This patch guarantees that entry->other is a clone of host before
put_connected_peers is called.
In some cases (especially if a child is half-open) the colliding
rekey-job might not have created the ike_init member. If so, the
nonce check fails with SIGSEGV.
This output helps tracing checkout and checkin of IKE_SAs when there is
more than one IKE_SAs with the same name. I also added the type of
in-air-exchange to the debug output issued by the task_manager in case
a task initiation is delayed, came in handy for me.
Thomas Egerer