When querying SAs the keys will end up in this buffer (the allocated
messages that are returned are already wiped). The kernel also returns
XFRM_MSG_NEWSA as response to XFRM_MSG_ALLOCSPI but we can't distinguish
this here as we only see the response.
References #2388.
When requiring unique flags for CHILD_SAs, allow the configuration to
request different marks for each direction by using the %unique-dir keyword.
This is useful when different marks are desired for each direction but the
number of peers is not predefined.
An example use case is when implementing a site-to-site route-based VPN
without VTI devices.
A use of 0.0.0.0/0 - 0.0.0.0/0 traffic selectors with identical in/out marks
results in outbound traffic being wrongfully matched against the 'fwd'
policy - for which the underlay 'template' does not match - and dropped.
Using different marks for each direction avoids this issue as the 'fwd' policy
uses the 'in' mark will not match outbound traffic.
Closesstrongswan/strongswan#78.
Initiation might later fail, of course, but we don't really
require an IP address when installing, that is, unless the remote
traffic selector is dynamic. As that would result in installing a
0.0.0.0/0 remote TS which is not ideal when a single IP is expected as
remote.
This fixes CHILD_SA rekeying with TKM and changes how we switch to the
outbound IPsec SA with Netlink/XFRM (using SPIs on the outbound policy
instead of installing the outbound SA delayed).
For charon-tkm it changes when esa_select() and esa_reset() are called,
now with the outbound policy and the inbound SA, respectively, instead
of the outbound SA in both cases.
Also fixed is a potential traffic loss when a rekey collision is lost.
After a rekeying the outbound SA and policy is deleted immediately, however,
the inbound SA is not removed until a few seconds later, so delayed packets
can still be processed.
This adds a flag to get_esa_id() that specifies the location of the
given SPI.
This splits the SA installation also on the initiator, so we can avoid
installing the outbound SA if we lost a rekey collision, which might
have caused traffic loss depending on the timing of the DELETEs that are
sent in both directions.
Specifying an integer instead of YES in evaltest.dat causes the number to get
compared against the actual number of lines matching the pattern.
This may be used to count matching packets or log lines.
This tries to avoid packet loss during rekeying by delaying the usage of
the new outbound IKE_SA until the old one is deleted.
Note that esa_select() is a no-op in the current TKM implementation. And
the implementation also doesn't benefit from the delayed deletion of the
inbound SA as it calls esa_reset() when the outbound SA is deleted.