[strongSwan-dev] SP update during CHILD SA rekeying

[Tobias Brunner]

Hi Emeric,

> Why does charon trigger a SP update in that case? Is there any relevant information to update since the SP are statically routed?

Technically, charon doesn't do an update but installs new policies with
the new IPsec SAs and removes the old ones when the rekeyed SAs are
deleted (with recent versions this is done separately for in- and
outbound SAs and policies).

The kernel-pfkey plugin tracks which policies are used by which SA and
then decides whether the SA with the highest priority (e.g. regular
polices > trap policies > drop policy) changed and triggers an update if
it did (which is the case during a rekeying when the old SA is removed
and the new SA becomes the first one in the list).  The actual data that
might change in the installed policy is not compared, though (i.e. we
don't actually check whether the update changes anything in the kernel
before triggering it, because it's just simpler to implement this way).

Instead we simply update the policy with the information from the SA
object with the highest priority (that includes type, priority,
protocols, IP addresses, reqid and SPIs).  When switching e.g. from a
trap policy to a regular policy most of that information changes.
However, during rekeyings that's usually not the case anymore.  In
particular, reqids should not change with recent releases (even during
reauthentications), the type, priority and protocols should also stay
the same, IP addresses could change, though (e.g. if the rekeying or a
reauthentication was done because MOBIKE is not supported).  And SPIs
are not actually installed via PF_KEY interface (we only do that via
XFRM on Linux and only for the outbound policy).

So I guess some updates could be avoided by adding some additional
checks for changes when adding/removing tracked SAs, but I've currently
no plans to implement that.

> The problem is that there seems to be a race in FreeBSD: the SP is not really updated, it is removed and then a new one is added, and unfortunately this is not atomic.
> Therefore some packets may leave using the default policy.

Hm, the whole point of doing an update instead of manually removing and
adding policies is to avoid that.  So probably should be fixed in the
kernel, right?

Regards,
Tobias