This avoids race conditions between calls to cancel() and jobs that like
to be rescheduled. If jobs were able to reschedule themselves it would
theoretically be possible that two worker threads have the same job
assigned (the one currently executing the job and the one executing the
same but rescheduled job if it already is time to execute it), this means
that cancel() could be called twice for that job.
Creating a new job based on the current one and reschedule that is also
OK, but rescheduling itself is more efficient for jobs that need to be
executed often.
This ensures that no threads are active when plugins and the rest of the
daemon are unloaded.
callback_job_t was simplified a lot in the process as its main
functionality is now contained in processor_t. The parent-child
relationships were abandoned as these were only needed to simplify job
cancellation.
Jobs are now destroyed by the processor, but they are allowed to
reschedule themselves. That is, parts of the reschedule functionality
already provided by callback_job_t is moved to the processor. Not yet
fully supported is JOB_REQUEUE_DIRECT and canceling jobs.
Note: job_t.destroy() is now called not only for queued jobs but also
after execution or cancellation of jobs. job_t.status can be used to
decide what to do in said method.
While Aggressive Mode PSK is widely used, it is known to be subject
to dictionary attacks by passive attackers. We don't complain as
initiator to be compatible with existing (insecure) setups, but
require a scary strongswan.conf option if someone wants to use it
as responder.
According to RFC5996, implementations should just ignore the KE payload
if they select a non-PFS proposals. Some implementations don't, but
return MODP_NONE in INVALID_KE_PAYLOAD, hence we accept that, too.
If both peers initiate quick mode rekeying simultaneously, we end up
with duplicate SAs for a configuration. This can't be avoided, nor do
the standards provide an appropriate solution. Instead of closing one
SA immediately, we keep both. But once rekeying triggers, we don't
refresh the SA with the shorter soft lifetime, but delete it.
If the installation failed the state is not CHILD_ROUTED which means the
wrong priority is used to uninstall the policies. This is a problem for
kernel interfaces that keep track of installed policies as now the proper
policy is not found (if the priority is considered).
Martin Willi