Introduces a new lightweight array collection having minimal memory overhead.
The new class replaces various linked lists that are used during the full
lifetime of an SA, reducing memory requirements by about 5KB or more per tunnel.
Beside that it makes the code actually simpler, it reduces the number of lists
stored by each IKE_SA and each CHILD_SA by 4, which can be up to 1KB per SA.
Currently we use the very versatile linked-list collection to store elements
with variable count. This is fine, but very inefficient: Due to the many
methods in the linked list, on 64-bit platforms an empty list alone is more
than 200 bytes. As we currently have about 50 lists per IKE_SA/CHILD_SA pair,
this takes up to 10KB just for managing the empty lists. This is about the
half of memory used by an IKE_SA/CHILD_SA pair, and obviously way too much.
The new array type is not an object, but a collection of functions on an
abstract type.
The following lists are per IKE_SA and should be considered for a replacement
with more efficient arrays (this uses load-testers on-demand created dynamic
configurations, other scenarios have different lists):
14 -> ike_sa_create() @ src/libcharon/sa/ike_sa.c:2198
10 -> auth_cfg_create() @ src/libstrongswan/credentials/auth_cfg.c:1088
6 -> task_manager_v2_create() @ src/libcharon/sa/ikev2/task_manager_v2.c:1505
6 -> proposal_create() @ src/libcharon/config/proposal.c:592
5 -> peer_cfg_create() @ src/libcharon/config/peer_cfg.c:657
4 -> child_sa_create() @ src/libcharon/sa/child_sa.c:1090
2 -> child_cfg_create() @ src/libcharon/config/child_cfg.c:536
1 -> ike_cfg_create() @ src/libcharon/config/ike_cfg.c:330
1 -> put_connected_peers() @ src/libcharon/sa/ike_sa_manager.c:854
If realloc moves an allocation, the original allocation gets freed. We
therefore must remove the hdr from the list, as it is invalid. We can add it
afterwards once it has been updated, allowing us to unlock the list during
reallocation.
Adds support for testing plugin functionality to test-runner. Introduces some
good/bad tests for ECDSA/RSA which would have caught those RSA/ECDSA signature
vulnerabilities.
Some static allocations in plugins won't get freed, because in the test case
process the plugins are not destroyed. If a plugin would clean up allocations
done while just using the plugin, these show up as leak in the child process,
letting tests fail.
Enable transport mode in NAT situations when using IKEv2. Additionally brings
an extended leftsubnet format, where each subnet can take a separate protocol
and port.
This has the same meaning as omitting left/rightsubnet, i.e. replace it
by the IKE address. Supporting %dynamic allows configurations with multiple
dynamic selectors in a left/rightsubnet, each with potentially different
proto/port selectors.
If a transport/BEET SA has different selectors for different proto/ports,
installing just the proto/port of the first SA would break any additional
selector.
Checks if a trap policy exists when installing a CHILD_SA as responder,
reuse that reqid and keeping the trap untouched. This makes auto=route on
both sides more reliable.
In addition, we no prevent to refcount an existing policy if the reqid differs;
this should not happen anymore. We now can properly reject new CHILD_SAs in
such conflicts, instead of silently breaking an existing policy.
When we have a trap installed, but a CHILD_SA gets established for the same
config from the peer, we should reuse the same reqid. Otherwise we would have
two identical policies using different reqids, what we can't handle in our
kernel backend.
Previously we silently replaced an existing policy with a new one if the
reqid changed for the same selectors. This will break an old policy in the
favour of the new one (for example if two clients behind the same NAT use
transport mode).
With this change any new policy gets rejected if the reqid differs. This will
make sure we break no existing policy. For rekeying and acquires we still can
have overlapping policies (as we use the same reqid), but for unrelated
connections this is not true anymore (it wasn't actually before, we just
silently broke the existing policy).
When a connection has a single pool that queries recursively the DHCP backend,
we shouldn't return any attributes directly from DHCP when queried for that
pool.
If one selector has a wider IP range than the other, but the other has a
wider port/protocol selector than the first one, none is completely contained
in the other. The check for a match using is_contained_in() therefore would
fail. Using get_subset() can handle such cases, fixing configuration selection.
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.
Martin Willi