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

[Christophe Gouault]

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 10.0.0.0/16, and traffic to 10.0.1.1 triggers
> an SA. The responder, however, narrows the traffic selector to
> 10.0.1.0/24. Now you have traffic to 10.0.2.1, which triggers another
> CHILD_SA, which might get narrowed by the responder to 10.0.2.0/24.
If the responder narrows the traffic selector, then should it not spawn 
a new security policy in the kernel, with the narrowed selector 
10.0.1.0/24 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 
10.0.0.0/16) accordingly, so the SA may be used for any traffic in the 
10.0.0.0/16 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
>