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