[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