[strongSwan] SHA1 vs SHA256

[Noel Kuntze]

Okay, then it's probably the kernel. Upgrade it.

On 05.08.2017 02:11, Dusan Ilic wrote:
> No, not according to loaded plugins in ipsec statusall
> 
> 
> Den 2017-08-04 kl. 21:44, skrev Noel Kuntze:
>> Okay. Is kernel-pfkey loaded?
>>
>> On 04.08.2017 21:31, Dusan Ilic wrote:
>>> Yep, both endpoints have loaded kernel-netlink.
>>> However, the Strongswan versions is 5.2.2 and the other is 5.5.2.
>>>
>>>
>>> Den 2017-08-04 kl. 21:15, skrev Noel Kuntze:
>>>> Hi Dusan,
>>>>
>>>> That is unreliable.
>>>> Check the list of loaded plugins in the output of `ipsec stausall` or `swanctl --status`.
>>>>
>>>> Kind regards
>>>>
>>>> Noel
>>>>
>>>> On 04.08.2017 21:11, Dusan Ilic wrote:
>>>>> Hi Noel,
>>>>>
>>>>> I think I'm already using kernel-netlink on both endpoints.
>>>>>
>>>>> cat /etc/strongswan.d/charon/kernel-netlink.conf | grep load
>>>>>       # Whether to load the plugin. Can also be an integer to increase the
>>>>>       load = yes
>>>>>
>>>>>
>>>>> Den 2017-08-04 kl. 21:00, skrev Noel Kuntze:
>>>>>> Hi,
>>>>>>
>>>>>> If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default truncation length.
>>>>>> It is not possible to choose the truncation length using pfkey.
>>>>>> If XFRM over netlink socket is used to configure XFRM, one can choose the truncation length. strongSwan uses the 128 bit truncation length for HMAC-SHa256.
>>>>>>
>>>>>> Since 5.5.3, one can choose the truncation length on a per-conn basis.
>>>>>>    From the roadmap[3]:
>>>>>>
>>>>>> With the sha256_96 compatibility option it's possible to locally configure 96-bit truncation
>>>>>> for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the official
>>>>>> algorithm identifier (12). This is only useful for compatibility with peers that incorrectly
>>>>>> use this shorter truncation as the actual truncation length is not negotiated.
>>>>>>
>>>>>> So the solution is to try using kernel-netlink instead of kernel-pfkey with strongSwan in an attempt to force the kernel to
>>>>>> use the 128 bit truncation length, which strongSwan chooses by default.
>>>>>>
>>>>>> Kind regards
>>>>>>
>>>>>> Noel
>>>>>>
>>>>>> [1] https://wiki.strongswan.org/issues/2301
>>>>>> [2] https://wiki.strongswan.org/issues/2391
>>>>>> [3] https://wiki.strongswan.org/versions/65
>>>>>> On 04.08.2017 20:50, Andreas Steffen wrote:
>>>>>>> Hi Dusan,
>>>>>>>
>>>>>>> the only workaround I see is to either upgrade your Linux 2.6
>>>>>>> kernel or fall back to a SHA-1 based ESP HMAC.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>> On 04.08.2017 20:46, Dusan Ilic wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Unfortunately, I'm not following you guys :)
>>>>>>>> Could someone please clarify?
>>>>>>>>
>>>>>>>>
>>>>>>>> Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> IIRC pfkey still uses the old truncation (It's mentioned in some
>>>>>>>>> relatively recent ticket).
>>>>>>>>> Try using kernel-netlink instead.
>>>>>>>>>
>>>>>>>>> Kind regards
>>>>>>>>>
>>>>>>>>> Noel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 04.08.2017 19:02, Andreas Steffen wrote:
>>>>>>>>>> Hi Dusan,
>>>>>>>>>>
>>>>>>>>>> hmmm, our documentation says that the correct ESP SHA256_128 HMAC
>>>>>>>>>> truncation was introduced with the 2.6.33 kernel but your kernel
>>>>>>>>>> might not be a vanilla 2.6.36 kernel:
>>>>>>>>>>
>>>>>>>>>>      https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
>>>>>>>>>>
>>>>>>>>>>      (ESP integrity algorithm footnote n)
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> Andreas
>>>>>>>>>>
>>>>>>>>>> On 04.08.2017 16:41, Dusan Ilic wrote:
>>>>>>>>>>> Hi Andreas
>>>>>>>>>>>
>>>>>>>>>>> One side is 2.6.36 and the other 3.10.20
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
>>>>>>>>>>>> Hi Dusan,
>>>>>>>>>>>>
>>>>>>>>>>>> this is a Linux kernel issue. Which kernel versions are you running
>>>>>>>>>>>> on the two endpoints?.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> Andreas
>>>>>>>>>>>>
>>>>>>>>>>>> On 04.08.2017 12:41, Dusan Ilic wrote:
>>>>>>>>>>>>> Hi Noel,
>>>>>>>>>>>>>
>>>>>>>>>>>>> One side is Strongswan 5.2.2 and the other is 5.5.2.
>>>>>>>>>>>>> How do I switch?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
>>>>>>>>>>>>>> the remote peer probably uses the DRAFT variant of sha2-256, which
>>>>>>>>>>>>>> uses 96 bit truncation. strongSwan uses the actual standardized
>>>>>>>>>>>>>> variant that truncates to 128 bit.
>>>>>>>>>>>>>> You can switch between the two in the newest version of strongSwan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 04.08.2017 12:23, Dusan Ilic wrote:
>>>>>>>>>>>>>>> Hello!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a strange issue, with both settings below the tunnel goes up
>>>>>>>>>>>>>>> as it should, but only with SHA1 in ESP traffic goes through.
>>>>>>>>>>>>>>> When I
>>>>>>>>>>>>>>> ping the remote client with ESP SHA256 it times out, even though
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> tunnel reports as being up by Strongswan.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Traffic working:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>>>>>>>> esp=aes128-sha1-modp2048!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Traffic not working:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>>>>>>>> esp=aes256-sha256-modp2048!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Below combo doesn't work either:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>>>>>>>> esp=aes128-sha256-modp2048!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Also, are above settings good? I'm having AES128 on ESP because
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> AES256 I loose too much througput. Do you have any suggestions for
>>>>>>>>>>>>>>> change?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170805/fbc593fb/attachment.sig>