Previously, the client had to propose no wider selectors than the certificate
permits, otherwise the complete CHILD_SA was rejected. However, with IKEv2
we can dynamically narrow the selectors to what the certificate allows. This
makes client and gateway configurations very simple by just proposing 0.0.0.0/0,
narrowed to selectors the client is permitted to route into the network.
This allows a gateway to enforce the addrblock policy on certificates that
actually have the extension only. For (legacy) certificates not having the
extension, traffic selectors are validated/narrowed by other means, most
likely by the configuration.
Usually, %dynamic is used as traffic selector for transport mode SAs,
however, if wildcard traps are used then the remote TS will be a subnet.
With strongSwan at the remote end that usually works fine as the local
%dynamic TS narrows the proposed TS appropriately. But some
implementations reject non-host TS for transport mode SAs.
Another problem could be if several distinct subnets are configured for a
wildcard trap, as we'd then propose unrelated subnets on that transport
mode SA, which might be problematic even for strongSwan (switch to tunnel
mode and duplicate policies).
Closesstrongswan/strongswan#61.
While RFC 3779 says we SHOULD mark it is critical, this has severe side effects
in practice. The addrblock extension is not widely used nor implemented, and
only a few applications can handle this extension. By marking it critical,
none of these applications can make use of such certificates where included
addrblocks do not matter, such as TLS/HTTPS.
If an application wants to make use of addrblocks, that is usually an explicit
decision. Then the very same application obviously can handle addrblocks, and
there is no need for the extension to be critical. In other words, for local
policy checks it is a local matter to handle the extension, hence making it
critical is usually not of much help.
This strangely never caused any noticeable issues, but was the reason for
build failures in certain test cases (mostly BLISS) due to missing plugin
features when built with specific options on Travis (was not reproducible
locally).
Doing this from the main UI thread (which delivers the broadcast) might
cause an ANR if there is a delay (e.g. while acquiring a mutex in the
native parts). There might also have been a race condition during
termination previously because Unregister() was not synchronized so there
might have been dangling events that got delivered while or after the mutex
in the native parts was destroyed.
Some devices always use the oldest IKE_SA to send DPDs and will delete
all IKE_SAs when there is no response. If uniqueness is not enforced
rekeyed IKE_SAs might not get deleted until they expire so we should
respond to DPDs.
References #2090.
When multihomed, a setup might prefer to dynamically stay on the cheapest
available path by using MOBIKE migrations. If the cheapest path goes away and
comes back, we currently stay on the more expensive path to reduce noise and
prevent potential migration issues. This is usually just fine for links not
generating real cost.
If we have more expensive links in the setup, it can be desirable to always
migrate to the cheapest link available. By setting charon.prefer_best_path,
charon tries to migrate to the path using the highest priority link, allowing
an external application to update routes to indirectly control MOBIKE behavior.
This option has no effect if MOBIKE is unavailable.
Disabling MOBIKE and statically configuring a local address should be
enough indication that the user doesn't want to roam to a different
address. There might not be any routes that indicate we can use the
current address but it might still work (e.g. if the address is on an
interface that is not referenced in any routes and the address itself
is neither). This way we avoid switching to another address for routes
that might be available on the system.
We currently don't make much use of COND_STALE anyway when MOBIKE is not
enabled, e.g. to avoid sending DPDs if the connection is seemingly down.
With MOBIKE enabled we don't exactly check that state but we do don't
send DPDs if there is no route/source address available.
This way updates to the mediation config are respected and the order in
which configs are configured/loaded does not matter.
The SQL plugin currently maintains the strong relationship between
mediated and mediation connection (we could theoretically change that to a
string too).
The original name is returned in the new "name" attribute.
This fixes an issue with bindings that map VICI messages to
dictionaries. For instance, in roadwarrior scenarios where every
CHILD_SA has the same name only the information of the last CHILD_SA
would end up in the dictionary for that name.
PINs are stored in a "hidden" credential set, so that its shared
secrets are not exposed via VICI. Since they are not explicitly loaded as
shared secrets via VICI a client might consider them as removed secrets and
remove them.
