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

[Martin Willi]

> 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