strongSwan

Thanks for response.

I use 4.4.0-31 kernel.

1. uname -ar
   Linux ubnt-113 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Maybe your kernel uses SHA2 with 96 bit truncation for that identifier

Can you tell how to check this ? Is it SADB_X_AALG_SHA2_256HMAC

Use kernel-netlink. With netlink, it seems, you can use both the 128 bit and 96 truncation by specifying the corresponding >hmac's keyword in the cipher settings.

Shall try it but currently i need to use kernel-pfkey.

Sudheer Anumolu wrote:

1. uname -ar
   Linux ubnt-113 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

That's relatively new. I'm surprised that happens.

Maybe your kernel uses SHA2 with 96 bit truncation for that identifier

Can you tell how to check this ? Is it SADB_X_AALG_SHA2_256HMAC

Well, you'll have to check the pfkeyv2.h header file and the kernel against the strongSwan source code and the kernel source code for pfkeyv2 and xfrm.
But again, only the one identifier for HMAC256 in pfkey.

Use kernel-netlink. With netlink, it seems, you can use both the 128 bit and 96 truncation by specifying the corresponding >hmac's keyword in the cipher settings.

Shall try it but currently i need to use kernel-pfkey.

Well, good effort then.

Could this 'icv_truncbits = 96' be a problem ?

http://lxr.free-electrons.com/source/net/xfrm/xfrm_algo.c

{
239 .name = "hmac(sha256)",
240 .compat = "sha256",
241
242 .uinfo = {
243 .auth = {
244 .icv_truncbits = 96,
245 .icv_fullbits = 256,
246 }
247 },
248
249 .pfkey_supported = 1,
250
251 .desc = {
252 .sadb_alg_id = SADB_X_AALG_SHA2_256HMAC,
253 .sadb_alg_ivlen = 0,
254 .sadb_alg_minbits = 256,
255 .sadb_alg_maxbits = 256
256 }
257 },

I doubt that file is recent. Get the source for your kernel and read that.

On 4.4.1 kernel, I modified in net/xfrm/xfrm_algo.c as below and issue is solved. With kernel-pfkey entry also, truncation length is 128.

{
.name = "hmac(sha256)",
.compat = "sha256",

.uinfo = {
                .auth = {
-                       .icv_truncbits = 96,
+                       .icv_truncbits = 128,
                        .icv_fullbits = 256,
                }
        },

Thanks for all the support.

Thanks
Sudheer

This is weird. I'd expect there to be a second version of HMAC-256 to be somewhere in XFRM, because both 96 and 128 bit truncation are supported and can be used at the same time (for different SAs obviously). I wonder where the 128 bit version comes from?

This is weird. I'd expect there to be a second version of HMAC-256 to be somewhere in XFRM, because both 96 and 128 bit truncation are supported and can be used at the same time (for different SAs obviously). I wonder where the 128 bit version comes from?

Via XFRM the truncation length can be set explicitly to an arbitrary value (source:src/libcharon/plugins/kernel_netlink/kernel_netlink_ipsec.c#L1485). But PF_KEYv2 is not XFRM (it's basically a wrapper around it). It does not provide that flexibility and uses a static list of algorithms with predefined truncation lengths (see the structure Sudheer cited above - these SADB_X_* constants are the PF_KEYv2 algorithm identifiers). Unfortunately, the truncation length in that structure, which is also used as default for XFRM if no explicit truncation length is specified, has never been changed (probably due to concerns regarding backwards compatibility). This is only one of the limitations of that interface. Basically, there is absolutely no reason to use PF_KEYv2 on Linux, ever.

Thanks for explanation.