Conflicts:
configure.in
man/ipsec.conf.5.in
src/libcharon/daemon.c
src/libcharon/plugins/eap_ttls/eap_ttls_peer.c
src/libcharon/plugins/eap_radius/eap_radius_accounting.c
src/libcharon/plugins/eap_radius/eap_radius_forward.c
src/libcharon/plugins/farp/farp_listener.c
src/libcharon/sa/ike_sa.c
src/libcharon/sa/keymat.c
src/libcharon/sa/task_manager.c
src/libcharon/sa/trap_manager.c
src/libstrongswan/plugins/x509/x509_cert.c
src/libstrongswan/utils.h
Applied lost changes of moved files keymat.c and task_manager.c.
Updated listener_t.message hook signature in new plugins.
When the kernel reports the deletion of an interface (RTM_DELLINK),
the cached interface attributes, including ifindex, become invalid
and must be forgotten.
Interface link state changes ("up" and "down") show up as RTM_NEWLINK,
so they will not cause a cached entry to be removed or
prevent listening to address change notifications.
Once an interface has been deleted, the kernel ought to stop sending
notifications for it. If the interface gets recreated with the same
name later, the kernel again reports RTM_NEWLINK, which causes a new
cache entry to be created.
There should be no reason to keep a stale cache entry around, as was
claimed in the comment.
During the update of a CHILD_SA (e.g. caused by MOBIKE) the old policy
is first uninstalled and then the new one is installed. In the short
time in between, where no policy is available in the kernel, unencrypted
packets could have been transmitted.
This allows to unroute a connection while the same connection is
currently established. In this case both CHILD_SAs share the same
reqid but the installed policies have different priorities.
This change tries to prevent a race condition where a thread tries to
install the same policy another thread is currently deleting. If the
second thread releases the mutex in del_policy too early the first
thread could assume the policy does not exist (as it is not cached
anymore) but would not be able to actually install it if the second
thread was not yet able to delete it.
This allows to properly delete a policy e.g. if reauth=yes and
auto=route, because reqids are increased during reauthentication.
It also avoids overriding an installed policy with a trap policy.
This fixes several test cases in IKEv2_Self_Test (part of the IPv6 Ready
Logo Program) which is required for USGv6 certification, namely:
- IKEv2.EN.I.1.1.7.1, IKEv2.EN.I.1.1.7.1: Narrowing the range of members
of the set of traffic selectors
- IKEv2.EN.R.1.1.7.3: Narrowing multiple traffic selector
When traffic selectors of a triggered SA are narrowed by the responder, the
installed policy and the broader trap policy share the same reqid. Without
selectors on the IPsec SA packets matching the trap policy, but not the
narrowed policy, would incorrectly be handled by that IPsec SA. Since only
one selector can be specified per IPsec SA, there is currently no solution
for tunnel mode SAs.
The resulting priorities are as follows:
IPv6 IPv4
routed normal routed normal
max 4096(+3) 2048(+3) 4096(+3) 2048(+3)
min 3072 1024 3840 1792
Where min is for a policy between two single hosts and max is
for /0 on both ends (lower priorities are preferred by the kernel).
(+3) applies for cases where no protocol and no ports are defined.
Tobias Brunner