[ovs-dev] [CONNTRACK] Discussions at OvS 2017
Tiago Lam
tiagolam at gmail.com
Sat Nov 25 17:47:11 UTC 2017
Hi Aaron (and all),
Thank you for your email, I found it to be informative.
Would you mind elaborating a bit more on point number 5 below?
With regards to SIP (don't know about SCTP), a module [1] seems to already
exist for the kernel, integrating with Netfilter / conntrack.
So, in terms of support for SIP in OVS' userspace conntrack (or any other new
protocol for that matter, but I'm most familiar with SIP), would OVS be
looking for a port, or a "from scratch" implementation? Or what would be the
preference here?
Thanks and regards,
Tiago.
[1] https://people.netfilter.org/chentschel/docs/sip-conntrack-nat.html
On 11/20/2017 06:21 PM, Aaron Conole wrote:
> (NOTE: This is a resend - I fat-fingered the ovs email. Apologies to
> those who got duplicates).
>
> This email is meant to summarize some of the discussions we had at OvS
> conference.
>
> The interest in the userspace conntrack is heating up. That's a good
> thing, but it means that we'll probably have some growing pains as it
> relates to features and usages. These are the topics and some
> additional information that we came up with.
>
> 1. Making EST state match between linux kernel conntrack and userspace
> conntrack. We will need to make sure that the windows datapath
> conntrack also matches. The issue came down to the distinction about
> whether commit action should also imply that the connection is
> established.
>
> 2. Disabling conntrack helpers 'on by default' in the userspace
> datapath. This represents possible security issue; users will want
> to disable helpers (or enable helpers) at their own discretion.
> One proposed resolution to this is simply disabling the helpers, and
> relying on the 'alg=' specifier in the conntrack action. Complicating
> this solution is existing users who rely on the existing solution -
> specifically those users with the tftp helper and pxe booting in an
> large data center.
>
> 3. Performance analysis deep-dive. We'd like to get input on the
> performance of the userspace conntrack path. There was discussion
> that the performance was suffering - anything here like additional
> tests people have, or data that can be shared is good. The
> development community is interested in knowing what it means.
>
> 4. Hardware offload. What will we need to present from that standpoint?
> Are there counters or other information that software will need to
> expose? What does it mean for the userspace datapath to be aware of
> hardware offload for conntrack?
>
> 5. Additional protocol support and helpers. We think SCTP, and SIP are
> important. Any others? Anyone think this is useful work to do?
>
> Thanks all for the presentations and discussions.
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
More information about the dev
mailing list