From: Vlad Buslov <vladbu@nvidia•com>
To: Pablo Neira Ayuso <pablo@netfilter•org>
Cc: <davem@davemloft•net>, <kuba@kernel•org>, <pabeni@redhat•com>,
<netdev@vger•kernel.org>, <netfilter-devel@vger•kernel.org>,
<jhs@mojatatu•com>, <xiyou.wangcong@gmail•com>,
<jiri@resnulli•us>, <ozsh@nvidia•com>,
<marcelo.leitner@gmail•com>, <simon.horman@corigine•com>
Subject: Re: [PATCH net-next v5 0/7] Allow offloading of UDP NEW connections via act_ct
Date: Sat, 28 Jan 2023 18:04:40 +0200 [thread overview]
Message-ID: <87ilgqej6h.fsf@nvidia.com> (raw)
In-Reply-To: <Y9VEdYnSLH8YKTZA@salvia>
On Sat 28 Jan 2023 at 16:51, Pablo Neira Ayuso <pablo@netfilter•org> wrote:
> On Fri, Jan 27, 2023 at 07:38:38PM +0100, Vlad Buslov wrote:
>> Currently only bidirectional established connections can be offloaded
>> via act_ct. Such approach allows to hardcode a lot of assumptions into
>> act_ct, flow_table and flow_offload intermediate layer codes. In order
>> to enabled offloading of unidirectional UDP NEW connections start with
>> incrementally changing the following assumptions:
>>
>> - Drivers assume that only established connections are offloaded and
>> don't support updating existing connections. Extract ctinfo from meta
>> action cookie and refuse offloading of new connections in the drivers.
>>
>> - Fix flow_table offload fixup algorithm to calculate flow timeout
>> according to current connection state instead of hardcoded
>> "established" value.
>>
>> - Add new flow_table flow flag that designates bidirectional connections
>> instead of assuming it and hardcoding hardware offload of every flow
>> in both directions.
>>
>> - Add new flow_table flow "ext_data" field and use it in act_ct to track
>> the ctinfo of offloaded flows instead of assuming that it is always
>> "established".
>>
>> With all the necessary infrastructure in place modify act_ct to offload
>> UDP NEW as unidirectional connection. Pass reply direction traffic to CT
>> and promote connection to bidirectional when UDP connection state
>> changes to "assured". Rely on refresh mechanism to propagate connection
>> state change to supporting drivers.
>>
>> Note that early drop algorithm that is designed to free up some space in
>> connection tracking table when it becomes full (by randomly deleting up
>> to 5% of non-established connections) currently ignores connections
>> marked as "offloaded". Now, with UDP NEW connections becoming
>> "offloaded" it could allow malicious user to perform DoS attack by
>> filling the table with non-droppable UDP NEW connections by sending just
>> one packet in single direction. To prevent such scenario change early
>> drop algorithm to also consider "offloaded" connections for deletion.
>
> If the two changes I propose are doable, then I am OK with this.
>
> I would really like to explore my proposal to turn the workqueue into
> a "scanner" that iterates over the entries searching for flows that
> need to be offloaded (or updated to bidirectional, like in this new
> case). I think it is not too far from what there is in the flowtable
> codebase.
I'm not sure I'm following. In order to accommodate your suggestions
I've already coded the algorithm in v4 in a way that always updates flow
to its current actual state according to conntrack atomic flags and
doesn't require any follow-up updated if state had been changed
concurrently. What else is missing?
prev parent reply other threads:[~2023-01-28 16:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 18:38 [PATCH net-next v5 0/7] Allow offloading of UDP NEW connections via act_ct Vlad Buslov
2023-01-27 18:38 ` [PATCH net-next v5 1/7] net: flow_offload: provision conntrack info in ct_metadata Vlad Buslov
2023-01-27 18:38 ` [PATCH net-next v5 2/7] netfilter: flowtable: fixup UDP timeout depending on ct state Vlad Buslov
2023-01-28 15:27 ` Pablo Neira Ayuso
2023-01-28 16:03 ` Vlad Buslov
2023-01-28 19:09 ` Pablo Neira Ayuso
2023-01-28 19:30 ` Vlad Buslov
2023-01-27 18:38 ` [PATCH net-next v5 3/7] netfilter: flowtable: allow unidirectional rules Vlad Buslov
2023-01-27 18:38 ` [PATCH net-next v5 4/7] netfilter: flowtable: save ctinfo in flow_offload Vlad Buslov
2023-01-27 18:38 ` [PATCH net-next v5 5/7] net/sched: act_ct: set ctinfo in meta action depending on ct state Vlad Buslov
2023-01-27 18:38 ` [PATCH net-next v5 6/7] net/sched: act_ct: offload UDP NEW connections Vlad Buslov
2023-01-28 15:26 ` Pablo Neira Ayuso
2023-01-28 15:31 ` Vlad Buslov
2023-01-28 19:09 ` Pablo Neira Ayuso
2023-01-28 19:28 ` Vlad Buslov
2023-01-27 18:38 ` [PATCH net-next v5 7/7] netfilter: nf_conntrack: allow early drop of offloaded UDP conns Vlad Buslov
2023-01-28 15:51 ` [PATCH net-next v5 0/7] Allow offloading of UDP NEW connections via act_ct Pablo Neira Ayuso
2023-01-28 16:04 ` Vlad Buslov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilgqej6h.fsf@nvidia.com \
--to=vladbu@nvidia$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=jhs@mojatatu$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=kuba@kernel$(echo .)org \
--cc=marcelo.leitner@gmail$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=netfilter-devel@vger$(echo .)kernel.org \
--cc=ozsh@nvidia$(echo .)com \
--cc=pabeni@redhat$(echo .)com \
--cc=pablo@netfilter$(echo .)org \
--cc=simon.horman@corigine$(echo .)com \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox