Hi Martin, On 05/27/2013 09:24 AM, Martin Willi wrote: > Hi Christophe, > >> - if the selectors of a CHILD_SA match the trap CHILD_SA's, then the >> same reqid should be used for the negotiated CHILD_SA and no new policy >> needs to be added into the kernel. > This is true. charon currently does this as initiator only where the SA > is triggered by a trap, but not as responder. > >> - if the selectors of a CHILD_SA were narrowed in regard to the trap >> CHILD_SA, then a new reqid should be assigned to the CHILD_SA and new >> narrowed policies need to be added into the kernel with this reqid. > I'm not sure if this is the ideal solution and what the side effects > are. Probably the packets triggering the acquire won't get processed by > the new policy and are lost, which is bad. Yes they will, from now on they will match the new policy, which has the same reqid as the negotiated SA. > I'm not sure if that would > even work when using the same reqid with narrowed selectors, though. > Something that we would have to test in detail. This is how it works today (charon spawns a new narrowed policy with the same reqid as initiator or with a new reqid as responder). The traffic that triggered the negotiation properly matches the new SP and SA.
The main potential problems I see are future acquire messages that could be triggered by the new SP : they do not match the trap CHILD_SA reqid, so won't be processed. I agree this would need detailed tests. > > The narrowing use case is more hypothetical, and can be avoided by > adjusting the configuration. So I don't think it is that important. agreed :) Thank you for your replies and comments. Best regards, Christophe > Regards > Martin > _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
