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:17:33 +0000
From:   Raed Salem <raeds@...lanox.com>
To:     Steffen Klassert <steffen.klassert@...unet.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



> -----Original Message-----
> From: Steffen Klassert [mailto:steffen.klassert@...unet.com]
> Sent: Friday, January 04, 2019 12:55 PM> 
> 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?
Sure,
Works with the following SA and policy DB:
ip x s s:
src 1.2.3.4 dst 1.2.3.5
        proto esp spi 0x56c8245e reqid 1455957086 mode tunnel
        replay-window 0
        aead rfc4106(gcm(aes)) 0xae41773f260e9fbda4cd9f117d8d5fb42d4a4a68 128
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        crypto offload parameters: dev p6p1 dir in
        sel src 1.2.3.4/32 dst 1.2.3.5/32
src 1.2.3.5 dst 1.2.3.4
        proto esp spi 0xd94ba134 reqid 3645612340 mode tunnel
        replay-window 0
        aead rfc4106(gcm(aes)) 0x55a5136bec858fcb6944b8596fc73aa0ca553bf7 128
        anti-replay context: seq 0x0, oseq 0xd, bitmap 0x00000000
        crypto offload parameters: dev p6p1 dir out
        sel src 1.2.3.5/32 dst 1.2.3.4/32
ip x p s:
src 1.2.3.4/32 dst 1.2.3.5/32
        dir fwd priority 0 ptype main
        tmpl src 1.2.3.4 dst 1.2.3.5
                proto esp reqid 1455957086 mode tunnel
src 1.2.3.4/32 dst 1.2.3.5/32
        dir in priority 0 ptype main
        tmpl src 1.2.3.4 dst 1.2.3.5
                proto esp reqid 1455957086 mode tunnel
src 1.2.3.5/32 dst 1.2.3.4/32
        dir out priority 0 ptype main
        tmpl src 1.2.3.5 dst 1.2.3.4
                proto esp reqid 3645612340 mode tunnel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ