While it has some tests that we don't directly cover with the new unit tests,
most of them require special infrastructure and therefore have not been used
for a long time.
This test asserts that the handling of XFRM expire messages from the
kernel are handled correctly by the xfrm-proxy and the Esa Event Service
(EES) in charon-tkm.
Store the remote instead of the local SPI in the SAD when adding a new
entry in the kernel plugin's add_sa() function.
Since only one ESA context must be destroyed for an inbound/outbound
CHILD SA pair, it does not matter which SPI is used to retrieve it in
the del_sa function.
With these changes, charon dynamically allocates reqids for CHILD_SAs. This
allows the reuse of reqids for identical policies, and basically allows multiple
CHILD_SAs with the same selectors. As reqids do not uniquely define a CHILD_SA,
a new unique identifier for CHILD_SAs is introduced, and the kernel backends
use a proto/dst/SPI tuple to identify CHILD_SAs.
charon-tkm is not yet updated and expires are actually broken with this merge.
As some significant refactorings are required, this is fixed using a separate
merge.
References #422, #431, #463.
Update the call to hydra->kernel_interface->expire to make
ees_callback.c compile again. The required destination host argument is
set to NULL for now.
To quickly check out IKE_SAs and find associated CHILD_SAs, the
child_sa_manager stores relations between CHILD_SAs and IKE_SAs. It provides
CHILD_SA specific IKE_SA checkout functions wrapping the ike_sa_manager.
As we now use the same reqid for multiple CHILD_SAs with the same selectors,
having marks based on the reqid makes not that much sense anymore. Instead we
use unique marks that use a custom identifier. This identifier is reused during
rekeying, keeping the marks constant for any rule relying on it (for example
installed by updown).
This also simplifies handling of reqid allocation, as we do not have to query
the marks that is not yet assigned for an unknown reqid.
To reassign reqids where appropriate, we explicitly allocate or confirm them
centrally on the kernel-interface.
Currently the state is stored in the kernel-interface wrapper for all
backends, but we may add appropriate methods to each backend to implement
a custom reqid allocation logic, if required.
The kernel backend uses an inbound parameter these days, where it makes
no sense to pass the update flag. The kernel backend decides itself how
it handles SA installation based on the inbound flag.
While we can handle the first selector only in BEET mode in kernel-netlink,
passing the full list gives the backend more flexibility how to handle this
information.
The reqid is not strictly required, as we set the reqid with the update
call when installing the negotiated SA.
If we don't need a reqid at this stage, we can later allocate the reqid in
the kernel backend once the SA parameters have been fully negotaited. This
allows us to assign the same reqid for the same selectors to avoid conflicts
on backends this is necessary.
Martin Willi