netdev - Re: [PATCH net-next 1/3] net/sched: Introduce action ct

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:   Thu, 13 Jun 2019 13:39:39 +0000
From:   Paul Blakey <paulb@...lanox.com>
To:     Florian Westphal <fw@...len.de>
CC:     Jiri Pirko <jiri@...lanox.com>, Roi Dayan <roid@...lanox.com>,
        Yossi Kuperman <yossiku@...lanox.com>,
        Oz Shlomo <ozsh@...lanox.com>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Aaron Conole <aconole@...hat.com>,
        Zhike Wang <wangzhike@...com>,
        Rony Efraim <ronye@...lanox.com>,
        "nst-kernel@...hat.com" <nst-kernel@...hat.com>,
        John Hurley <john.hurley@...ronome.com>,
        Simon Horman <simon.horman@...ronome.com>,
        Justin Pettit <jpettit@....org>,
        "pablo@...filter.org" <pablo@...filter.org>
Subject: Re: [PATCH net-next 1/3] net/sched: Introduce action ct


On 6/12/2019 10:55 PM, Florian Westphal wrote:
> Paul Blakey <paulb@...lanox.com> wrote:
>> +	/* The conntrack module expects to be working at L3. */
> It also expects that IP stack has validated ip(v6)
> headers and has pulled the ip header into linear area.
>
> What are your plans wrt. IP fragments? AFAICS right now they will
> not match which means they won't be NATed either.  Is that ok?

Right, I'll add defragment via nf_ct_ipv4_gather_frags and 
nf_ct_frag6_gather, which

is basically what conntrack_bridge and openvswitch/conntrack.c does with 
it's calls.

> For offloading connection tracking and NAT, I think the flowtable
> infrastructure is much better: it will allow any device to push packets
> that it can't deal with (fragmented, too large mtu, changed route, etc)
> to the software path and conntrack will be aware its dealing with a flow
> that was offloaded, e.g. it will elide sequence number checks.

That still be the case, Later, hardware offload for this tc rules will 
not offload fragmented packets (unless they somehow support it)

and they will be defragmented in act_ct.c and only then will pass this 
action.

Such offloaded connections will be marked as such and so netfilter can 
skip seq number checking.

> For connection tracking on L2, Pablo recently added conntrack for
> classic bridge (without the 'call-iptables' infrastructure), see
> net/bridge/netfilter/nf_conntrack_bridge.c (especially the defrag/refrag
> and header validation its doing).
>
> I suspect parts of that are also needed in the conntrack action (you
> might be able to reuse/export some of the functionality I think).