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

Antony Antony antony at phenome.org
Wed Jun 28 07:39:55 UTC 2017


On Wed, Jun 28, 2017 at 05:31:06AM +0000, Ilan Tayari wrote:
> > -----Original Message-----
> > From: Antony Antony [mailto:antony at phenome.org]
> > Subject: Re: [Swan-dev] [PATCH libreswan] Add support for IPSec HW-offload
> > on the NIC
> > 
> > I guess this is could be applied. However, please hold on, lets update
> > xfrm.h first.
> > 
> > I plan to update linux26/xfrm.h with history from kernel commits.
> > It should happen before this patch. Otherwise it hard to know how upto
> > date
> > xfrm.h is.
> 
> Yes, I suppose xfrm.h update should come separately and before.
> I don't mind rebasing and re-submitting after you do that.
> Do you have an approximation when this would happen?

I am working on it. I tested an updated xfrm.h on F25 and was going to push 
changes this morning then I noticed it break on Fedora 22. F22 is our 
testing environment. I have to resolve this first. Possibly breaks on 
RHEL/CentOS 6.x too.

In file included from 
/home/build/libreswan/programs/pluto/linux26/xfrm.h:4:0,
		 from 
/home/build/libreswan/programs/pluto/kernel_netlink.c:47:
/usr/include/netinet/in.h:99:5: error: expected identifier before numeric 
constant
     IPPROTO_HOPOPTS = 0,   /* IPv6 Hop-by-Hop options.  */
     ^

> > Another comment. It would be nice to add whack option?
> 
> I'll take some time to understand whack better and come up with something.
> You're talking about the command line tool, right?

yes.

> > 
> > How would XFRM_MSG_GETSA work? I am guessing you have a running system.
> > Could you share output of
> > 
> > ipsec whack --trafficstatus
> 
> # ipsec whack --trafficstatus                                                                    
> 006 #24: "myconn", type=ESP, add_time=1498620457, inBytes=13407272, outBytes=288772244, id='192.168.7.11'
>

This looks good.
 
> iproute2 does show it, btw:
> 
> # ip x s
> src 192.168.7.11 dst 192.168.7.1
>         proto esp spi 0xe1fe6a81 reqid 16389 mode tunnel
>         replay-window 32 flag af-unspec
>         aead rfc4106(gcm(aes)) 0xcb294e1c525e72b11f4e80bd0fffe854775e0a171660aefe0dd618ad074dc50fecf7d087 128
>         anti-replay context: seq 0x3ef28, oseq 0x0, bitmap 0xffffffff
>         crypto offload parameters: dev ens8 dir in

something like the above line could be added to ipsec status output.
I could possibly help you with this if you could test it.

-antony


More information about the Swan-dev mailing list