netdev - Re: [PATCH iproute2] vxlan: add support for flowlab inherit

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: Sun, 28 Jan 2024 15:28:13 +0100
From: Vincent Bernat <vincent@...nat.ch>
To: Ido Schimmel <idosch@...sch.org>, David Ahern <dsahern@...il.com>
Cc: Alce Lafranque <alce@...ranque.net>, netdev@...r.kernel.org,
 stephen@...workplumber.org
Subject: Re: [PATCH iproute2] vxlan: add support for flowlab inherit

On 2024-01-28 13:35, Ido Schimmel wrote:
> On Fri, Jan 26, 2024 at 10:17:36AM -0700, David Ahern wrote:
>> On 1/25/24 11:28 PM, Vincent Bernat wrote:
>>> Honestly, I have a hard time finding a real downside. The day we need to
>>> specify both a value and a policy, it will still be time to introduce a
>>> new keyword. For now, it seems better to be consistent with the other
>>> protocols and with the other keywords (ttl, for example) using the same
>>> approach.
>>
>> ok. let's move forward without the new keyword with the understanding it
>> is not perfect, but at least consistent across commands should a problem
>> arise. Consistency allows simpler workarounds.
> 
> I find it weird that the argument for the current approach is
> consistency when the commands are already inconsistent:
[...]

It's still more consistent than adding a keyword. But we are OK to add a 
keyword if needed. It seems there is no agreement yet on this. David, do 
you prefer a keyword?

> I would also try to avoid sending the new 'IFLA_VXLAN_LABEL_POLICY' attribute
> for existing use cases: When creating a VXLAN device with a fixed flow label or
> when simply modifying an already fixed flow label. I would expect kernels
> 6.5-6.7 to reject the new attribute as since kernel 6.5 the VXLAN driver
> enforces strict validation. However, it's not the case:
[...]

This should be solved if there is a new keyword. If we do not introduce 
a new keyword, this means querying the current state before setting the 
new state as we need to know what the previous policy was.

> Regarding the comment about the
> "inherit-during-the-day-fixed-during-the-night" policy, I'm familiar
> with at least one hardware implementation that supports a policy of
> "inherit flow label when IPv6, otherwise set flow label to X" and it
> indeed won't be possible to express it with the single keyword approach.

Good example (better than mine).