Using the register_constructor function enables custom keymat_t
implementations per IKE version. If no constructor is registered the
default behavior is preserved.
Since the 3.5 Linux kernel both UDP implementations have a separate static
flag to indicate whether ANY sockets enabled UDP decapsulation.
As we only ever enabled it for one address family (in earlier versions IPv4
only, now for IPv6, if supported, and for IPv4 otherwise) UDP decapsulation
wouldn't work anymore (at least for one address family).
This branch introduces a userland IPsec implementation (libipsec) and an
Android App which targets the VpnService API that is provided by Android 4+.
The implementation is based on the bachelor thesis 'Userland IPsec for
Android 4' by Giuliano Grassi and Ralf Sager.
This branch comes with some preliminary changes for the user-land IPsec
implementation and the Android App.
One important change is that the UDP ports used by the socket-default plugin
were made configurable (either via ./configure or strongswan.conf).
Also, the plugin does randomly allocate a port if it is configured to 0,
which is useful for client implementations. A consequence of these
changes is that the local UDP port used when creating ike_cfg_t objects has
to be fetched from the socket.
This makes EAP-GTC a generic plain password authentication method,
as it is used with XAuth. Instead of verifying credentials with
PAM, any backend can be configured. The default is xauth-pam,
providing the same functionality as EAP-GTC in strongSwan 4.x.
When sender_t is used to send ESP packets this would otherwise cause an extreme
amount of debug messages.
With this change all messages sent via sender_t.send_no_marker() cause no extra
DBG1 log message, but for debugging purposes the socket plugins do log the same
message again with DBG2 for all packets.
This is mainly because the other parts of the existing android plugin
can not be built in the NDK (access to keystore and system properties are
not part of the stable NDK libraries).
If two initiators use the same SPI and also use the same SA proposal the
hash for the initial message would be exactly the same. For IKEv2 and
Aggressive Mode that's not a problem as these messages include random
data (Ni, KEi payloads).
As we only can negotiate a single TS in IKEv1, don't prepend the
triggering packet TS, as we do in IKEv2. Otherwise we don't establish
the TS of the configuration, but only that of the triggering packet.
Fixes#207.
If additional authentication constraints, such as group membership,
is not fulfilled by an XAuth backend, we search for another
peer configuration that fulfills all constraints, including those
from phase1.
Martin Willi