[strongSwan-dev] rationale of reqid update on responder side

[Christophe Gouault]

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
>