[strongSwan-dev] rationale of reqid update on responder side
martin at strongswan.org
Mon May 27 09:24:50 CEST 2013
> - 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. 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.
The narrowing use case is more hypothetical, and can be avoided by
adjusting the configuration. So I don't think it is that important.
More information about the Dev