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

[Dmitry Shubin]

Hi, Ryan.

On 09/15/2015 01:17 PM, Ruel, Ryan wrote:
> I also ran into this issue.
>
> In cases where multiple endpoints are residing behind the same NAT, the port numbers are also needed to identify the correct policy for each endpoint.
>
> strongSwan reuses the same reqid for all of the endpoints sitting behind the same NAT IP, and it becomes impossible to associate outbound policies with outbound SA’s using just the reqid.

Interesting. You can't control SPIs allocated by your peers, so that 
rules that out for the purpose of identification. But what about src_ts? 
They must be exactly the same for two given policies for you to run into 
this issue. Is that right?

Also, I wonder what is the strongswan way of thinking about (partially) 
overlapping policies in general? I haven't researched this topic 
thoroughly or done any experiments to be honest, but already noticed 
something peculiar in the kernel plugin code: they store policies in a 
sorted list where the sorting happens according to (among other things) 
traffic selector "size". I'd like to know the reasoning behind that. 
Doesn't that clash with the RFC requirement on storing policies in order 
they were added (modulo priority)?

> You can modify the strongSwan code to pass them in (which is what I did), but you do need to update the plug-in interfaces in a decent number of places.

Glad to hear that worked for you. That is an indirect confirmation of 
the fact that my understanding is at least somewhat correct: all 
{del,add}_policy() calls are "balanced" in a sense that for each 
add_policy() there must be a matching del_policy() call from the same 
child_sa object AND that the child_sa doesn't change its state in 
between the calls (a state that affects the calls to {add,del}_policy(), 
that is). This is what I'm worried about the most, i.e. can we rely on 
{spi,src,dst} being the same at the time of del_policy() as they were at 
the time of add_policy()?

It would be great if everyone saw the utility of this if we could make 
it part of the mainline.

I'd like to hear something from one of the core developers on the 
subject. If such a modification makes sense and they are willing to 
accept patches I'm willing to create and submit one.

>
> /Ryan
>
>
>
> On 9/14/15, 1:26 PM, "Dmitry Shubin" <shubin at rnd.stcnet.ru> wrote:
>
>> 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
>> Dev at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/dev
> _______________________________________________
> Dev mailing list
> Dev at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/dev
>