Discussion:
[strongSwan] multiple traffic selectors per child_sa
Marco Berizzi
2018-05-11 10:10:42 UTC
Permalink
Hello everyone,

Kindly I would like to ask, if there is a way to
know if a remote IKEv2 peer supports multiple
traffic selectors per CHILD_SA.

For example strongswan is going to log this kind
of message when tfc is not supported by the other
IKEv2 peer:

received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

TIA
Tobias Brunner
2018-05-14 09:52:46 UTC
Permalink
Hi Marco,

> Kindly I would like to ask, if there is a way to
> know if a remote IKEv2 peer supports multiple
> traffic selectors per CHILD_SA.

This is not a negotiated feature. You might just see a peer narrowing
the traffic selectors to only one the client proposed. But it could
also do that for other reasons (e.g. a mismatching configuration).
Support for multiple traffic selectors is a core feature of IKEv2, but
due to traffic selector narrowing it's easy to avoid having to implement
it I guess.

There is a notify that could be sent, ADDITIONAL_TS_POSSIBLE, which
indicates that some of the not selected TS could be applied in a
separate CHILD_SA (but which ones, or in which combination, is not
communicated). Not sure if anybody implements that (we currently don't
have any support for it). Another notify we don't support is
SINGLE_PAIR_REQUIRED, which indicates that the responder requires
separate CHILD_SAs for each pair of IP addresses that could match the
proposed ranges (but the RFC discourages its use and recommends to just
narrow the TS).

Regards,
Tobias
Marco Berizzi
2018-05-14 14:36:51 UTC
Permalink
Hi Tobias,

Thanks for the nice explanation.

> This is not a negotiated feature. You might just see a peer narrowing
> the traffic selectors to only one the client proposed. But it could
> also do that for other reasons (e.g. a mismatching configuration).
> Support for multiple traffic selectors is a core feature of IKEv2, but
> due to traffic selector narrowing it's easy to avoid having to implement
> it I guess.

> There is a notify that could be sent, ADDITIONAL_TS_POSSIBLE, which
> indicates that some of the not selected TS could be applied in a
> separate CHILD_SA (but which ones, or in which combination, is not
> communicated). Not sure if anybody implements that (we currently don't
> have any support for it). Another notify we don't support is
> SINGLE_PAIR_REQUIRED, which indicates that the responder requires
> separate CHILD_SAs for each pair of IP addresses that could match the
> proposed ranges (but the RFC discourages its use and recommends to just
> narrow the TS).

unfortunately I see only this endless log when my remote_ts is
like this on my swanctl.conf:

remote_ts = 10.213.56.0/21,10.213.100.0/24,10.213.14.0/23,10.213.10.0/23,10.213.29.0/24,10.213.118.0/24,10.213.124.0/24,10.213.249.0/24,10.213.16.0/24,10.213.126.0/24,10.213.154.0/24

May 11 08:58:48 Enceladus charon: 09[KNL] creating rekey job for CHILD_SA ESP/0xc3d57caa/205.223.229.254
May 11 08:58:48 Enceladus charon: 09[IKE] establishing CHILD_SA customer-networks{1890} reqid 248
May 11 08:58:48 Enceladus charon: 12[KNL] creating rekey job for CHILD_SA ESP/0xe2f3c155/91.240.166.5
May 11 08:58:48 Enceladus charon: 09[ENC] generating CREATE_CHILD_SA request 304 [ N(REKEY_SA) SA No KE TSi TSr ]
May 11 08:58:48 Enceladus charon: 09[NET] sending packet: from 205.223.229.254[500] to 91.240.166.5[500] (656 bytes)
May 11 08:58:48 Enceladus charon: 13[NET] received packet: from 91.240.166.5[500] to 205.223.229.254[500] (528 bytes)
May 11 08:58:48 Enceladus charon: 13[ENC] parsed CREATE_CHILD_SA response 304 [ SA No KE TSi TSr ]
May 11 08:58:48 Enceladus charon: 13[IKE] inbound CHILD_SA customer-networks{1890} established with SPIs c48dde95_i 3c072ec0_o and TS 10.28.157.0/24 === 10.213.56.0/21
May 11 08:58:48 Enceladus charon: 13[IKE] outbound CHILD_SA customer-networks{1890} established with SPIs c48dde95_i 3c072ec0_o and TS 10.28.157.0/24 === 10.213.56.0/21
May 11 08:58:48 Enceladus charon: 13[IKE] closing CHILD_SA customer-networks{1889} with SPIs c3d57caa_i (174062 bytes) e2f3c155_o (21692 bytes) and TS 10.28.157.0/24 === 10.213.56.0/21
May 11 08:58:48 Enceladus charon: 13[IKE] sending DELETE for ESP CHILD_SA with SPI c3d57caa
May 11 08:58:48 Enceladus charon: 13[ENC] generating INFORMATIONAL request 305 [ D ]
May 11 08:58:48 Enceladus charon: 13[NET] sending packet: from 205.223.229.254[500] to 91.240.166.5[500] (96 bytes)
May 11 08:58:48 Enceladus charon: 08[NET] received packet: from 91.240.166.5[500] to 205.223.229.254[500] (96 bytes)
May 11 08:58:48 Enceladus charon: 08[ENC] parsed INFORMATIONAL response 305 [ D ]
May 11 08:58:48 Enceladus charon: 08[IKE] received DELETE for ESP CHILD_SA with SPI e2f3c155
May 11 08:58:48 Enceladus charon: 08[IKE] CHILD_SA closed
May 11 08:58:49 Enceladus charon: 03[KNL] creating rekey job for CHILD_SA ESP/0xc48dde95/205.223.229.254
May 11 08:58:49 Enceladus charon: 03[IKE] establishing CHILD_SA customer-networks{1891} reqid 248
May 11 08:58:49 Enceladus charon: 09[KNL] creating rekey job for CHILD_SA ESP/0x3c072ec0/91.240.166.5
May 11 08:58:49 Enceladus charon: 03[ENC] generating CREATE_CHILD_SA request 306 [ N(REKEY_SA) SA No KE TSi TSr ]
May 11 08:58:49 Enceladus charon: 03[NET] sending packet: from 205.223.229.254[500] to 91.240.166.5[500] (656 bytes)
May 11 08:58:49 Enceladus charon: 13[NET] received packet: from 91.240.166.5[500] to 205.223.229.254[500] (528 bytes)
May 11 08:58:49 Enceladus charon: 13[ENC] parsed CREATE_CHILD_SA response 306 [ SA No KE TSi TSr ]
May 11 08:58:49 Enceladus charon: 13[IKE] inbound CHILD_SA customer-networks{1891} established with SPIs cd9fa1a2_i 803676f9_o and TS 10.28.157.0/24 === 10.213.56.0/21
May 11 08:58:49 Enceladus charon: 13[IKE] outbound CHILD_SA customer-networks{1891} established with SPIs cd9fa1a2_i 803676f9_o and TS 10.28.157.0/24 === 10.213.56.0/21
May 11 08:58:49 Enceladus charon: 13[IKE] closing CHILD_SA customer-networks{1890} with SPIs c48dde95_i (511517 bytes) 3c072ec0_o (69571 bytes) and TS 10.28.157.0/24 === 10.213.56.0/21
May 11 08:58:49 Enceladus charon: 13[IKE] sending DELETE for ESP CHILD_SA with SPI c48dde95
May 11 08:58:49 Enceladus charon: 13[ENC] generating INFORMATIONAL request 307 [ D ]
May 11 08:58:49 Enceladus charon: 13[NET] sending packet: from 205.223.229.254[500] to 91.240.166.5[500] (96 bytes)
[every second it will start again...]

However I will try to do another test and I will update
this thread with more detailed information.
Volodymyr Litovka
2018-10-03 07:11:43 UTC
Permalink
Hi Marco,

just FYI: if you've hit this problem with Cisco - then there is an issue
with both ASA and IOS models:
https://community.cisco.com/t5/cisco-bug-discussions/cscue42170-ikev2-support-multi-selector-under-the-same-child-sa/td-p/3203894

On 5/11/18 1:10 PM, Marco Berizzi wrote:
> Hello everyone,
>
> Kindly I would like to ask, if there is a way to
> know if a remote IKEv2 peer supports multiple
> traffic selectors per CHILD_SA.
>
> For example strongswan is going to log this kind
> of message when tfc is not supported by the other
> IKEv2 peer:
>
> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
>
> TIA

--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison
Loading...