[Swan-dev] [PATCH libreswan] Add support for IPSec HW-offload on the NIC

[Ilan Tayari]

> > > The conclusion from all the above, is that on failure to add_sa with
> > > offload, we may retry add_sa without offload.
> > > But then again some users may want to engineer their systems to only
> add
> > supported SAs. They will not want to tolerate fallback to non-offload.
> > > Maybe this could be another configuration option?
> >
> > not sure what would be a good solution. In some sense less knobs the
> > beter!
> > My intention is to make sure there is clear logging when add_sa failis.
> > So the user know what failed.
> 
> I did just:
> -    phase2alg=aes_gcm256-null
> 
> And it doesn't work ofcourse.
> 
> /var/log/secure shows:
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: initiating
> Main Mode
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: transition
> from state STATE_MAIN_I1 to state STATE_MAIN_I2
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1:
> STATE_MAIN_I2: sent MI2, expecting MR2
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: transition
> from state STATE_MAIN_I2 to state STATE_MAIN_I3
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1:
> STATE_MAIN_I3: sent MI3, expecting MR3
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: Main mode
> peer ID is ID_IPV4_ADDR: '192.168.7.11'
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1: transition
> from state STATE_MAIN_I3 to state STATE_MAIN_I4
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #1:
> STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256
> integ=sha group=MODP2048}
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2: initiating
> Quick Mode
> PSK+ENCRYPT+TUNNEL+PFS+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+
> ESN_NO {using isakmp#1 msgid:6f21bad0 proposal=defaults pfsgroup=MODP2048}
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2: ERROR:
> netlink response for Get SA esp.9195dc7a at 192.168.7.11 included errno 3: No
> such process

I figured out why pluto doesn't complain about NEWSA failure...

This line
https://github.com/libreswan/libreswan/blob/master/programs/pluto/kernel_netlink.c#L474

quiets it because the expected response is NLMSG_NOOP.

Do you know why this condition is so? If I remove the NOOP condition then
it complains properly about failure to add:

"myconn" #2: ERROR: netlink response for Add SA esp.fc8faa72 at 192.168.7.1 included errno 22: Invalid argument


> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2: transition
> from state STATE_QUICK_I1 to state STATE_QUICK_I2
> Jun 29 14:53:07 gen-l-vrt-103-005 pluto[28569]: "myconn" #2:
> STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
> {ESP=>0x9195dc7a <0xfee4040d xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none
> DPD=passive}
> Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: initiate on demand from
> 192.168.7.1:8 to 192.168.7.11:0 proto=1 because: acquire
> Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: "myconn" #3: initiating
> Quick Mode
> PSK+ENCRYPT+TUNNEL+PFS+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+
> ESN_NO {using isakmp#1 msgid:b52ce458 proposal=defaults pfsgroup=MODP2048}
> Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: "myconn" #3: transition
> from state STATE_QUICK_I1 to state STATE_QUICK_I2
> Jun 29 14:53:08 gen-l-vrt-103-005 pluto[28569]: "myconn" #3:
> STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode
> {ESP=>0x9cb505f5 <0x27cc5e2d xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none
> DPD=passive}
> 
> Apparently it was going for AES with HMAC-SHA1, which is not supported for
> offload.
> But the log doesn't indicate where the problem is or that
> MSG_NEWSA/UPDATESA failed.
> 
> dmesg warning reveals it:
> [ 8852.735900] mlx5_core 0000:00:08.0 ens8: Cannot offload authenticated
> xfrm states
>