Due to an unprotected incrementation, two load-tester initiators occasionally
use the same SPI under high load, and hence generate 2 IPsec SAs with the same
identifier. The responder IPsec stack will refuse to configure the second SA.
Use an atomic incrementation to avoid this race condition.
Signed-off-by: Christophe Gouault <[email protected]>
Due to an unprotected incrementation, two load-tester initiators occasionally
use the same identifier under high load. The responder typically drops one of
the connections.
Use an atomic incrementation to avoid this race condition.
Signed-off-by: Christophe Gouault <[email protected]>
Replace the allowany semantic by a more powerful subnet and IP range matching.
Multiple addresses, DNS names, subnets and ranges can be specified in a comma
separated list. Initiators ignore the ranges/subnets, responders match
configurations against all addresses, ranges and subnets.
INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.
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.
For consistency, the local/remote parameters have been replaced by the
initiator/responder options. As initiator, the initiator option can
be overriden by an addrs section taking key/value pairs with address
pools to use on a specific interface.
Christophe Gouault