[strongSwan-dev] rationale of reqid update on responder side
martin at strongswan.org
Wed May 22 08:58:18 CEST 2013
> a trap CHILD_SA is created with an initial reqid, and IPsec policies
> are configured in the kernel with this reqid.
Yes. It is important to keep the reqid, so the acquire for a trap policy
can be fulfilled with the newly established SAs.
But this approach has also its problems as well: If a single trap policy
results in multiple different CHILD_SAs (which is possible in IKEv2),
you have two different CHILD_SAs having the same reqid.
> Why does charon behave differently whether it is initiator or responder?
> What is the purpose of changing the CHILD_SA reqid in the responder case?
reqids are actually not "changed", but the new CHILD_SA is established
without any context to the trap policy. There is currently no relation
between these two, hence they use different reqids.
We could add a lookup to find any trap for the same config we establish
a CHILD_SA passively; currently this is not done. I think we should
consider such an extension.
More information about the Dev