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

[Christophe Gouault]

Hi Martin,

I hopefully have understood what you describe should be the desirable 
behavior (but which is not the current behavior of charon).

According to my experiments, the current behavior is:

- the initiator always uses the reqid of the trap CHILD_SA that 
triggered the negotiation, even if the remote responder narrowed the 
selectors. Consequently, the narrowed security policies spawned from the 
original CHILD_SA trap use the same reqid as the original policy, which 
is not desirable.
- the responder always uses a new reqid, regardless if a trap CHILD_SAs 
exists. Consequently, if the remote responder narrowed the selectors, 
the spawned narrowed policies will have a new reqid (which is 
desirable). However, if the responder did not narrow the selectors, then 
the reqid of the initial policy will be changed and become different 
from the trap CHILD_SA; the trap CHILD_SA can then nomore be used.


Could you please confirm if my understanding of the desirable behavior 
is correct. For both the initiator and the responder:

- if the selectors of a CHILD_SA match the trap CHILD_SA's, then the 
same reqid should be used for the negotiated CHILD_SA and no new policy 
needs to be added into the kernel.
- if the selectors of a CHILD_SA were narrowed in regard to the trap 
CHILD_SA, then a new reqid should be assigned to the CHILD_SA and new 
narrowed policies need to be added into the kernel with this reqid.

Best Regards,
Christophe

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