Discussion:
[strongSwan] question on ikev2 rekey
Kseniya Blashchuk
2018-11-12 11:44:01 UTC
Permalink
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
Tobias Brunner
2018-11-12 14:46:46 UTC
Permalink
Hi Kseniya,
Post by Kseniya Blashchuk
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?
You are not rekeying subnets but IPsec/CHILD_SAs. If your peer does not
support multiple traffic selectors per CHILD_SA you need to negotiate a
separate CHILD_SA for each combination of subnets (see [1]).

Regards,
Tobias

[1]
https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Multiple-subnets-per-SA
Kseniya Blashchuk
2018-11-12 15:22:27 UTC
Permalink
Thank you Tobias.

Honestly, I thought that for IKEv2 multiple traffic selectors are possible
anyway. Also, I was confused about the subnets because with ipsec statusall
it shows different rekey time values for different policies which include
traffic selectors (ip.net1 === ip.net2). Strongswan also prints "creating
rekey job for CHILD_SA ESP/0x12345678/" to the log file, which made me
think it should rekey only this particular SA, with a particular SPI,
matching specific source and destination (TS). Sorry if it's a stupid
question - but is it trying to rekey all CHILD_SAs instead when at least
one of them is expired?

We will contact our peer and if they don't support multiple traffic
selectors we will follow your example.
Thank you for your help.
Post by Tobias Brunner
Hi Kseniya,
Post by Kseniya Blashchuk
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?
You are not rekeying subnets but IPsec/CHILD_SAs. If your peer does not
support multiple traffic selectors per CHILD_SA you need to negotiate a
separate CHILD_SA for each combination of subnets (see [1]).
Regards,
Tobias
[1]
https://wiki.strongswan.org/projects/strongswan/wiki/FAQ#Multiple-subnets-per-SA
--
BR, Kseniya
Tobias Brunner
2018-11-12 15:48:57 UTC
Permalink
Honestly, I thought that for IKEv2 multiple traffic selectors
are possible anyway.
Unfortunately, there are implementations that don't support it.
Also, I was confused about the subnets because with
ipsec statusall it shows different rekey time values for different
policies which include traffic selectors (ip.net1 === ip.net2).
So you already have separate CHILD_SAs for these (possibly initiated by
the peer, or narrowed by it). But to make this work properly your
config has to reflects that.
Strongswan also prints "creating rekey job for CHILD_SA ESP/0x12345678/"
to the log file, which made me think it should rekey only this
particular SA, with a particular SPI, matching specific source and
destination (TS).
Single CHILD_SAs are rekeyed, but the complete local CHILD_SA config is
used for the proposal (i.e. multiple TS if that's what you have
configured locally). If a responder that doesn't support multiple TS
doesn't consider the TS of the rekeyed CHILD_SA, but just blindly uses
the first proposed TS, that's problematic (i.e. you must change the
config to reflect that limitation).

Regards,
Tobias
Kseniya Blashchuk
2018-11-12 16:39:29 UTC
Permalink
Understood, thank you very much for the clarification!
Post by Tobias Brunner
Post by Kseniya Blashchuk
Honestly, I thought that for IKEv2 multiple traffic selectors
are possible anyway.
Unfortunately, there are implementations that don't support it.
Post by Kseniya Blashchuk
Also, I was confused about the subnets because with
ipsec statusall it shows different rekey time values for different
policies which include traffic selectors (ip.net1 === ip.net2).
So you already have separate CHILD_SAs for these (possibly initiated by
the peer, or narrowed by it). But to make this work properly your
config has to reflects that.
Post by Kseniya Blashchuk
Strongswan also prints "creating rekey job for CHILD_SA ESP/0x12345678/"
to the log file, which made me think it should rekey only this
particular SA, with a particular SPI, matching specific source and
destination (TS).
Single CHILD_SAs are rekeyed, but the complete local CHILD_SA config is
used for the proposal (i.e. multiple TS if that's what you have
configured locally). If a responder that doesn't support multiple TS
doesn't consider the TS of the rekeyed CHILD_SA, but just blindly uses
the first proposed TS, that's problematic (i.e. you must change the
config to reflect that limitation).
Regards,
Tobias
--
BR, Kseniya
Loading...