[strongSwan-dev] rationale of reqid update on responder side
christophe.gouault at 6wind.com
Tue May 21 17:22:27 CEST 2013
Hi strongswan developers,
I am wondering about the way policy reqids are handled by charon.
As far as I understand, for each connection in ipsec.conf, a CHILD_SA is
routed: a trap CHILD_SA
is created with an initial reqid, and IPsec policies are configured in
the kernel with this reqid.
When completing a negotiation as initiator, a CHILD_SA is created with
the reqid unchanged.
When completing a negotiation as responder, a CHILD_SA is created with
an incremented reqid and
the policy is updated accordingly.
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?
Changing the reqid when responder has 2 adverse effects:
- IPsec SAs previously negotiated for this policy can no more be used
(although the remote initiator may still use them)
- the reqid is used to identify various objects, but some of them are
For example, if the responder (our side) later tries to initiate a
the acquire message is dropped,because the trap CHILD_SA that was
to handle it is still configured with the old reqid.
Sorry if this question was already asked, but could someone explain me
the rationale of reqid update on responder side?
More information about the Dev