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

[Dmitry Shubin]

Hi.

I am working on a custom IPSec implementation and have a 
question/proposal about kernel_interface.

I've noticed that there is a certain asymmetry between add_policy() and 
del_policy() methods: del_policy() receives a smaller set of parameters 
than add_policy(), namely there are no spi, src and dst values provided. 
That makes it hard (or, perhaps, harder than necessary) to actually 
delete policies since there is no way to determine which child_sa a 
del_policy() call came from. 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).

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.

I've poked around the code a bit and at a first glance it appears to be 
a viable idea. Actually, I've done some quick-and-dirty experiments and 
it seems to work just fine, at very least regular connections, traps and 
rekeying do work as expected. Am I missing something?