[strongSwan-dev] SP update during CHILD SA rekeying

[Emeric POUPON]

Hello,

I am using FreeBSD and routed connections, and I noticed that charon keeps updating SPs during the CHILD SA rekey process.

netstat -s -p pfkey | grep update -> increasing during each CHILD SA rekey.

I can see things like this in the logs:

Apr 30 11:02:13 15[CHD] <TUNNEL|5> CHILD_SA TUNNEL{84} state change: CREATED => INSTALLING
Apr 30 11:02:13 15[CHD] <TUNNEL|5> using AES_CBC for encryption
Apr 30 11:02:13 15[CHD] <TUNNEL|5> using HMAC_SHA2_256_128 for integrity
Apr 30 11:02:13 15[CHD] <TUNNEL|5> adding inbound ESP SA
Apr 30 11:02:13 15[CHD] <TUNNEL|5> SPI 0xccc45a9b, src 192.168.56.100 dst 192.168.56.110
Apr 30 11:02:13 15[KNL] <TUNNEL|5> deleting SAD entry with SPI ccc45a9b
Apr 30 11:02:13 15[KNL] <TUNNEL|5> deleted SAD entry with SPI ccc45a9b
Apr 30 11:02:13 15[KNL] <TUNNEL|5> adding SAD entry with SPI ccc45a9b and reqid {4}
Apr 30 11:02:13 15[KNL] <TUNNEL|5> using encryption algorithm AES_CBC with key size 256
Apr 30 11:02:13 15[KNL] <TUNNEL|5> using integrity algorithm HMAC_SHA2_256_128 with key size 256
Apr 30 11:02:13 01[JOB] watched FD 7 ready to read
Apr 30 11:02:13 15[CHD] <TUNNEL|5> registering outbound ESP SA
Apr 30 11:02:13 15[CHD] <TUNNEL|5> SPI 0xcc124fd9, src 192.168.56.110 dst 192.168.56.100
Apr 30 11:02:13 01[JOB] watcher going to poll() 4 fds
Apr 30 11:02:13 15[KNL] <TUNNEL|5> policy 192.168.100.0/24 === 192.168.110.0/24 in already exists, increasing refcount
Apr 30 11:02:13 15[KNL] <TUNNEL|5> updating policy 192.168.100.0/24 === 192.168.110.0/24 in

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

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.

Emeric

[Tobias Brunner]

Hi Emeric,

Post by Emeric POUPON
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.

Post by Emeric POUPON
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

[Emeric POUPON]

Post by Tobias Brunner
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.

Ok, I think I have something that works (see attached patch), but I am not sure of the solution.
Please tell me what you think about it?

Post by Tobias Brunner

Post by Emeric POUPON
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?

You are right, I will try to fix this asap.

Regards,

Emeric