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.
RFC 5996 compatible implementations MAY send an INFORMATIONAL message
with an AUTHENTICATION_FAILED if the initiator failed to authenticate us.
Handle such a message like a DELETE for an IKE_SA.
According to RFC 5996, we MAY send an INFORMATIONAL message having an
AUTHENTICATION_FAILED. We don't do any retransmits, though, but just close
the IKE_SA after one message has been sent, avoiding the danger that an
unauthenticated IKE_SA stays alive.
While this was problematic in earlier releases, it seems that it works just
fine the way we handle compression now. So there is no need to disable it over
NATed connections or when using forceencaps.
Passing back the buffer address we memwipe() is not ideal, as it could, in
theory, change the behavior of the compiler and not-optimize memwipe(). But
as checking a larger stack is very difficult for different architectures
and compilers, we do it nonetheless for now.
Beside some OS X love, this merge introduces virtual IP and route installation
support on the pfkey/pfroute kernel interfaces.
Each virtual IP gets installed on a dedicated TUN device. As Linux-like source
routes are not supported, routes for the negotiated traffic selectors get
installed using the TUN device.
To prevent IKE packets from using those routes, special exclude routes get
installed to the IKE gateway. This works for most road-warrior deployments, but
certainly does not for some more exotic configurations, such as those using
virtual-IP-to-host. Mobility is not yet supported, either.
If routes installed along with policies covering the peer address affect local
IKE/ESP packets, they won't get routed correctly. To work around this issue,
the kernel interface can install "exclude" routes for the IKE peer. Not all
networking backends require this workaround, hence we export a flag for it
if it is required.
As forwarding policies are not available on all systems (OS X), using the
forward policy to attach the route is a bad pick. Using input policies allows
OS X to install routes.
It seems that the order of binding sockets of different address families to the
same dynamic port must be v6-before-v4 on Linux, but v4-before-v6 on OS X.
The compiler spits no warning, but the wrong symbol is used when calling
semaphore_create() from strongSwan. Override the name with a #define to force
the use of our semaphore_create().
Introduce a simple IKEv1/IKEv2 command line client, charon-cmd. It does
not need any configuration files at all, but takes a few command line arguments
to establish connections as a road warrior.
Replaces the use of deprecated glibc malloc hooks by overloading malloc calls
and find the originals using dlsym(RTLD_NEXT).
On OS X, we now support the use of leak detective by changing the default
malloc zone functions, backtraces get resolved using atos.
It seems that the performance bottleneck now is stack unwinding. Unfortunately
a new libunwind based backtrace() is not much faster than the libc variant; we
keep that option nonetheless for platforms without backtrace().
malloc hooks have become deprecated, and their use has always been problematic,
especially in multi-threaded applications. Replace the functionality by
overriding all malloc functions and query the system allocator functions
using dlsym() with RTLD_NEXT.
Adds support for --enable/disable-silent-rules when building with Automake
1.11 or 1.12. make V=0 or V=1 can be used to build with a different verbosity
than ./configured.
Martin Willi