[strongSwan-dev] On reqid, del_policy() and kernel_interface.

[Tobias Brunner]

Hi Dmirty,

> One has to either do some weird stuff to 
> recover the aforementioned parameters (if that is at all possible) or 
> (re)design your SPD/SAD so that it can handle duplicate policies and/or 
> is reliant on the ordering of {add,del}_policy() calls and reqid (which 
> doesn't have a very well defined meaning as far as I can tell).

Because most kernels can't handle duplicate policies our kernel plugins
keep track of the SAs associated with policies (based on reqid and
priority).  This allows make-before-break reauthentication, duplicate
IPsec SAs (e.g. if both peers initiate it concurrently) and it prevents
that a sequence of commands like `ipsec route x; ipsec up x; ipsec
unroute x` removes/uninstalls the active IPsec policies in the kernel
(and in turn ensures the trap policy remains installed in the kernel if
the sequence was `ipsec up x; ipsec route x; ipsec down x` instead).

Priorities in our kernel plugins are based on a base priority and the
size of the traffic selectors.  So more specific policies are always
preferred over less specific ones irrespective of the installation order.

And since 5.3.0 reqids uniquely identify a set of traffic selectors
(with the exception of SAs based on wider trap policies).  Which was not
always the case in earlier versions, where reqids identified CHILD_SAs
(they remained the same during rekeyings but not during
reauthentications on the responder).

> On the other hand all these issues (seem to) go away if del_policy() 
> comes with {spi,src,dst}: we know exactly which policy to delete, we 
> don't have to rely on ordering, we don't have to rely on reqid to search 
> for SA after an SP match has occurred, no need to maintain auxiliary 
> mapping to recover missing data, etc.

The current interface got extended as stuff was needed for our own
plugins.  For del_policy() it worked fine so far and extending it would
only have complicated things on higher layers when preparing data to
make the call completely symmetrical to add_policy().  But I guess it
would even make things in our own plugins a bit safer if we'd remove the
exactly matching policy/SA from the cache and not just the first one
that matches based on the reqid and the priority (which probably works
fine in most cases, though, due to how they are inserted and how the
calls are structured).

I pushed some changes to the policy-del-ext branch.  Let me know if they
work for you.

Regards,
Tobias