netdev - Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware offloading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Jan 2019 11:54:37 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Raed Salem <raeds@...lanox.com>
CC:     Boris Pismenny <borisp@...lanox.com>,
        Yossi Kuperman <yossiku@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH ipsec] xfrm: fix non-GRO codepath for IPsec hardware
 offloading

On Fri, Jan 04, 2019 at 10:49:55AM +0000, Raed Salem wrote:
> > -----Original Message-----
> > From: Steffen Klassert [mailto:steffen.klassert@...unet.com]
> > > >
> > > > We currently don't support IPsec hardware offload without GRO enabled.
> > > > This is because the IPsec hardware offload does not decapsulate the
> > packet.
> > > > So the reverse policy check is done on the outer header instead of
> > > > the inner header for tunnel mode. This means that the reverse policy
> > > > check will fail for almost all tunnel mode configurations. The
> > > > packet must be decapsulated before we do the policy check, and that's
> > not the case without GRO.
> > > >
> > > > How did you test this?
> > > Used the iproute to configure IPsec hardware offload in transport mode
> > > with gro off, Running traffic using ping
> > 
> > How does your SA and policy database look like?
> Ip x s s:
> src 1.2.3.4 dst 1.2.3.5
>         proto esp spi 0x31fe38e7 reqid 838744295 mode transport
>         replay-window 0
>         aead rfc4106(gcm(aes)) 0x665aaa6855d6a0bcec53686c3c1cf6e68b96d8f7 128
>         anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
>         crypto offload parameters: dev enp4s0 dir out
>         sel src 0.0.0.0/0 dst 0.0.0.0/0
> src 1.2.3.5 dst 1.2.3.4
>         proto esp spi 0x1e9d4491 reqid 513623185 mode transport
>         replay-window 0
>         aead rfc4106(gcm(aes)) 0xb06d1980838185be356bfe9026c9735942369047 128
>         anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
>         crypto offload parameters: dev enp4s0 dir in
>         sel src 0.0.0.0/0 dst 0.0.0.0/0
> 
> ip x p s:
> src 1.2.3.5/32 dst 1.2.3.4/32
>         dir in priority 0 ptype main
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                 proto esp reqid 513623185 mode transport
> src 1.2.3.4/32 dst 1.2.3.5/32
>         dir out priority 0 ptype main
>         tmpl src 0.0.0.0 dst 0.0.0.0
>                 proto esp reqid 838744295 mode transport

Thanks!

I guess this works because of transport mode, here we don't have
different inner and outer IP headers. Can you please test this with
some tunnel mode configurations?