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

Christophe Gouault christophe.gouault at 6wind.com
Fri May 24 10:14:34 CEST 2013

Hi Martin,

On 05/23/2013 09:46 AM, Martin Willi wrote:
>> Does this mean we decide to give up older SAs as soon as we establish a new
>> CHILD_SA as responder? This may not be what the remote peer wants (otherwise
>> it would have *rekeyed* the SA instead).
> No. It means that two different CHILD_SAs triggered from the same trap
> policy use the same reqid.
> Assuming a trap policy to, and traffic to triggers
> an SA. The responder, however, narrows the traffic selector to
> Now you have traffic to, which triggers another
> CHILD_SA, which might get narrowed by the responder to
If the responder narrows the traffic selector, then should it not spawn 
a new security policy in the kernel, with the narrowed selector and bind the new CHILD_SA to this new SP?
As far as I understand, the current processing creates the CHILD_SA with 
a new reqid, and updates the reqid of the existing policy (to accordingly, so the SA may be used for any traffic in the subnet. And it also invalidates possibly formerly negotiated 
SAs for this policy.

And I also wonder in which condition charon may decide to narrow the 
selector as you describe.
> So you'll have two CHILD_SA with the same reqid (that of the trap
> policy). This is problematic for the kernel, which uses the reqid to map
> policies to SAs.
>> According to what I observed, the trap CHILD_SA is left unchanged, but
>> the policy in the kernel is updated with the new CHILD_SA reqid (I agree
>> that itis necessary if we want the SA to be used).
>> However, the trap CHILD_SA becomes unusable because it mismatches the
>> policy reqid.
> Yes. Because we can't have two identical policies in XFRM, we use
> refcounting to install it only once. This doesn't work for different
> reqids, as only one reqid can be active for these refcounted policies.
> This is why we reuse the reqid of a trap policy when installing an SA
> triggered by it. And this is what we should do when we install an SA as
> responder for which we have a trap installed.
> Regards
> Martin

More information about the Dev mailing list