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?
_______________________________________________
Dev mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/dev
