The current "inbound" flag is used for two purposes: To define the actual
direction of the SA, but also to determine the operation used for SA
installation. If an SPI has been allocated, an update operation is required
instead of an add.
While the inbound flag normally defines the kind of operation required, this
is not necessarily true in all cases. On the HA passive node, we install inbound
SAs without prior SPI allocation.
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.
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.
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
Load complete kernel_netlink plugin instead. Registering the TKM
specific plugins first still ensures that the correct ipsec plugin
is used.
Lazy initialize the RNG_WEAK plugin to avoid the unsatisfiable
soft dependency on startup.
A child SA is being rekeyed if the esa information passed to the add_sa
function contains nonces. If it also contains a valid Diffie-Hellman
context id PFS is used.
The fact that the encr_r encryption key is passed to add_sa in the
inbound case can be used to determine if we are initiator or not by
inspecting the is_encr_r flag of the esa information struct.
Add additional fields to the esa_info_t struct so the necessary data can
be passed from the keymat to the kernel ipsec interface, where ESA
creation and key generation using the TKM takes place.
The information is used during the inbound add_sa call to create an ESP
SA. This makes the hack of storing the local SPI in a kernel interface
variable between subsequent add_sa calls unnecessary.
An SAD entry is added after successfull creation of a TKM ESA context
in the add_sa() function. The corresponding entry is removed in
del_sa() using the SAD, src, dst, spi and protocol parameters.
ESP SAs are created when adding CHILD SAs via the kernel ipsec
interface.
The encr_i key is used to transfer the context id of the parent IKE SA
from the keymat to the TKM kernel ipsec interface.
The existing kernel netlink ipsec interface is currently used as proxy
to perform the actual work. It will be gradually removed as the TKM
implements the needed features.
Andreas Steffen