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

[Christophe Gouault]

Hi Martin,

Thank you for working on this problem.

I had internally just added a patch to reuse the reqid of an installed 
trap having the same config, but your series of patches is safer to 
avoid using duplicate reqids.

Best Regards
Christophe.

On 06/06/2013 03:00 PM, 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.
> I've pushed a few changes to [1] that should fix this issue. Whenever a
> CHILD_SA gets established, we check if we have a trap for that config.
> If yes, we reuse the reqid of that config.
>
>>> - 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.
> While this would be preferable, it is a little more difficult to
> implement. I think this issue is very hypothetical, hence I won't fix it
> for now. The narrowed policy uses the same reqid, which works fine for
> the traffic we have included in the tunnel.
>
> For the traffic outside the tunnel, no additional acquire gets
> triggered. But I think it is not that important, as it is unlikely (or
> at least can be avoided) that the responder has a config for that
> traffic, but did not include it in the narrowing.
>
> Regards
> Martin
>
> [1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/consistent-reqid
>