netdev - Re: [PATCH 1/2 net-next] vxlan: Be liberal on receive and only require the I bit to be set

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: <20140714081802.GA19186@casper.infradead.org>
Date:	Mon, 14 Jul 2014 09:18:02 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Tom Herbert <therbert@...gle.com>
Cc:	Linux Netdev List <netdev@...r.kernel.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	nicolas.dichtel@...nd.com, Pravin B Shelar <pshelar@...ira.com>,
	xiyou.wangcong@...il.com, Or Gerlitz <ogerlitz@...lanox.com>,
	Daniel Borkmann <dborkman@...hat.com>,
	"Pritesh Kothari (pritkoth)" <pritkoth@...co.com>,
	Madhu Challa <challa@...ronetworks.com>
Subject: Re: [PATCH 1/2 net-next] vxlan: Be liberal on receive and only
 require the I bit to be set

On 07/13/14 at 03:08pm, Tom Herbert wrote:
> On Fri, Jul 11, 2014 at 9:59 AM, Thomas Graf <tgraf@...g.ch> wrote:
> > The VXLAN receive code is currently conservative in what it accepts and
> > will reject any frame that uses any of the reserved fields. The VXLAN
> > draft specifies that "reserved fields MUST be set to zero on transmit
> > and ignored on receive." though.
> >
> > Be liberal in only requiring the I bit to allow for VXLAN extensions
> > to be implemented.
> >
> This is not robust (this is a problem in the VXLAN spec not your
> patch). There is no requirement that the VXLAN bits are optional. For
> example, if a receiver accepts a GPE packet but doesn't implement it
> the packet will be misinterpreted. I've already pointed this out to
> the VLXAN folks on nvo3 list. Dropping packets with unknown bits set
> is the only sane approach.

I agree, it's a mess.

At least VXLAN-gpe has realized this and will reserve an individual
port number. The port number is not yet fixed so it can't be enforced
yet but once that is done, gpe frame acceptance can be bound to the use
of that particular UDP port.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html