netdev - Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented

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]

Date:	Wed, 7 Jan 2015 16:02:48 -0800
From:	Tom Herbert <therbert@...gle.com>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	Jesse Gross <jesse@...ira.com>, David Miller <davem@...emloft.net>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Pravin B Shelar <pshelar@...ira.com>,
	Linux Netdev List <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: Re: [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented

On Wed, Jan 7, 2015 at 3:24 PM, Thomas Graf <tgraf@...g.ch> wrote:
> On 01/07/15 at 02:45pm, Jesse Gross wrote:
>> My concern is that having multiple (and potentially overlapping)
>> extensions is going to make the VXLAN code very messy and hard to
>> follow. I think there's already quite a big of complexity there from
>> the DOVE extensions (which are basically dead at this point to the
>> best of my knowledge). We already see this some with the discussion
>> over the header struct but that's just the beginning - can you imagine
>> the code that checks a single bit for several different
>> interpretations?
>
> I'm not disagreeing with you Jesse. I think it's manageable though.
> I don't think the code as proposed is overly difficult to understand
> or messy. I'm glad to adjust the struct definition if the union style
> is considered messy, no problem.
>
> We have these reserved bits in a widely used protocol and it is our
> choice to make use of these bits or not. My opinion is that we should.
> Good candidates to me seem to be GBP for security labels, RCO for
> checksumming and GPE for non-L2 over VXLAN.
>
Do you know how could GPE work with GBP they want to use the same bits
in header for data? Seems like these are mutually exclusive
extensions. RCO should be fine with either :-)

> I would love for everybody to switch over to Geneve or GUE and as you
> know I'm highly interested in pushing it forward. Reality is that it
> might be another couple of years for it to become fully established.
>
>> Not to mention the fact that the location of the bits
>> in some of these proposals has already been shuffled several times. It
>> seems very painful...
>
> I don't really want to defend the process behind these drafts. I
> believe that code defines the standard, in particular open source code.
> As for GBP, we are the authors of the draft and this has been deployed
> to hardware as well so this won't change.
--
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