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

[Christophe Gouault]

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 
not updated.
   For example, if the responder (our side) later tries to initiate a 
negotiation,
   the acquire message is dropped,because the trap CHILD_SA that was 
supposed
   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?

Best Regards,
Christophe