a3854d83 changed cleanup order. But we should remove CHILD_SAs first, as routes
for CHILD_SAs might get deleted while removing virtual IPs, resulting in
an error when a CHILD_SA tries to uninstall its route.
When a CHILD_SA is closed in IKEv1, if it is not being rekeyed and
closeaction has been set, we can now perform a restart or hold as is
currently done for IKEv2.
This improves the behavior of the kernel-pfroute plugin (and sometimes
the kernel-pfkey plugin) in case of mobility, mostly when used as as
client but also as gateway, if clients are mobile.
It seems we sometimes get the virtual IP as source (with
rightsubnet=0.0.0.0/0) even if the exclude route is already
installed. Might be a timing issue because shortly afterwards the
lookup seems to succeed.
If IPsec SAs are rekeyed due to an address change (e.g. because
update_sa is not supported) the exact same policy with the same reqid
will be installed, but with different addresses. After the rekeying the
old SA and its policies are removed, using the first matching mapping
breaks the mapping between the policies and the new SA (at least on
FreeBSD, the Linux kernel might only use the reqid for this). Using the
oldest matching SA is still an approximation but it solves the above
issue.
This required some refactoring when handling encrypted payloads.
Also changed log messages so that "encrypted payload" is logged instead
of "encryption payload" (even if we internally still call it that) as
that's the name used in RFC 5996.
Its functionality can be replicated by calling insert_before() followed
by remove_at(). Not the other way around, though, because remove_at()
changes the enumerator position.
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
Martin Willi