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

[Martin Willi]

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