netdev - Re: [PATCH iproute2 2/2] tc: m_tunnel

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]

Message-ID: <20170615102110.7e740c3e@griffin>
Date:   Thu, 15 Jun 2017 10:21:10 +0200
From:   Jiri Benc <jbenc@...hat.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org, Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>
Subject: Re: [PATCH iproute2 2/2] tc: m_tunnel_key: add csum/nocsum option

On Wed, 14 Jun 2017 13:38:07 -0700, Stephen Hemminger wrote:
> Does this change the default? Before your patches what was the checksum
> setting for the new tunnel.

Yes, it does. See the kernel patches.

I realize it's a user visible change; however, given that the real
reason act_tunnel_key was introduced is offloading of openvswitch and
openvswitch doesn't use it yet and I very much doubt there are other
users, I'm still proposing the change. It makes things aligned between
the non-lwt tunnels, tc and even the current openvswitch (which
includes the csum by default as well). When someone someday starts
using lwtunnels with tc for other uses, this will make it much less
surprising and will prevent user errors. Not mentioning performance
which is in general going to be better with the csum.

Furthermore, the only use case for nocsum is a compatibility with
broken VTEPs from hw vendors. This is not a setup act_tunnel_key is
going to be used in: in such case, you pretty much want the VXLAN
internal control plane, not an external one.

We're also not breaking existing Linux setups, even if there were any.
Even with udp6zerocsumrx, the non-zero csumed packets are still
accepted.

I was notified about the current confusing behavior by Red Hat QA when
they were trying to test the tunnel_key action and couldn't make it
work for IPv6. When those guys needed a help of the kernel developer
and the kernel developer in question had to insert a few printks to
realize what's going on, no regular user would be able to use it ;-)
(Of course, that's "fixable" by documentation.)

 Jiri