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

[Ruel, Ryan]

In my case I am running with transport mode and using IPsec+GRE... So yes,
the TS's are exactly the same for all of my endpoints.


I think you are correct in that you need identical TS's to get the same
request ID.  I vaguely recall that (without looking at the code).

/Ryan

On 9/15/15, 9:42 AM, "Dmitry Shubin" <shubin at rnd.stcnet.ru> wrote:

>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
>>
>_______________________________________________
>Dev mailing list
>Dev at lists.strongswan.org
>https://lists.strongswan.org/mailman/listinfo/dev