| Message ID | 20230127183845.597861-1-vladbu@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Allow offloading of UDP NEW connections via act_ct | expand |
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.
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?