[strongSwan] question on ikev2 rekey

[Kseniya Blashchuk]

Hello!
Any help would be appreciated on the issue.
Strongswan version 5.3.5.
We have a trouble connected with traffic loss on IKEv2 rekeying, with
multiple nets in leftsubnet and rightsubnet configured.
My investigation of the issue shows that the reason is the following:
1) when CHILD_SA on our side expires, strongswan sends a CREATE_CHILD_SA
request, containing all networks listed in left- and rightsubnet in Traffic
Selector fields of the proposal.
2) Our peer (I am not sure what software or hardware they use) responds
only with the *first* left- and right- network pair as a match. As a
result, when rekeying is needed for subnets different than the first ones
in a set, SAs are not created for them because they are not matched by the
peer.
3) However, when rekeying is done by the peer, they send only those subnets
in traffic selectors, for which CHILD_SAs are expired.

As a result, when our side is initiating rekeying, we are experiencing some
traffic loss for some subnet pairs until these SAs are not rekeyed by the
peer.

So my question is: is it a default behavior for strongswan to list all
subnets in Traffic Selector fields even if their CHILD SAs are not expired
yet? Is it possible to change this behavior to include only those subnets,
which need rekeying, into proposals? Is it an expected behavior for our
peer? What would you suggest?

The configuration of the peer as follows:
conn myconn
        left=our.ip.address
        leftid=our.id
        leftsubnet=our.ip.net.1,our.ip.net.2,our.ip.net.3
        right=their.ip.address
        rightid=their.id
        rightsubnet=their.ip.net.1,their.ip.net.2,their.ip.net.3
        authby=psk
        auto=route
        keyexchange=ikev2
        lifetime=1h
        ikelifetime=8h
        ike=aes256-sha1-modp1024
        esp=aes256-sha1
        dpdaction=restart


-- 

BR, Kseniya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20181112/efa883de/attachment.html>