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

[Martin Willi]

Hi Christophe,

> 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.

Regards
Martin