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
