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

[Christophe Gouault]

Hi Martin,

Thank you for your answer.

But I'm afraid I still don't fully get the point.

On 05/22/2013 08:58 AM, Martin Willi wrote:
> Hi Christophe,
>> a trap CHILD_SA is created with an initial reqid, and IPsec policies
>> are configured in the kernel with this reqid.
> Yes. It is important to keep the reqid, so the acquire for a trap policy
> can be fulfilled with the newly established SAs.
>
> But this approach has also its problems as well: If a single trap policy
> results in multiple different CHILD_SAs (which is possible in IKEv2),
> you have two different CHILD_SAs having the same reqid.
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).
>> 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?
> reqids are actually not "changed", but the new CHILD_SA is established
> without any context to the trap policy. There is currently no relation
> between these two, hence they use different reqids.
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.
If we try to initiate a new SA from the (formerly) responder side, we 
get the following error:

root:~# ip xfrm state flush
root:~# ping 10.1.1.1
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
16[KNL] creating acquire job for policy 10.1.1.2/32[udp/46055] === 
10.1.1.1/32[udp/1025] with reqid {2}
15[CFG] trap not found, unable to acquire reqid 2
^C
--- 10.1.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms
> We could add a lookup to find any trap for the same config we establish
> a CHILD_SA passively; currently this is not done. I think we should
> consider such an extension.
>
> Regards
> Martin