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: <ZRv0IolLA28HlIkP@shredder>
Date: Tue, 3 Oct 2023 13:59:46 +0300
From: Ido Schimmel <idosch@...dia.com>
To: Alce Lafranque <alce@...ranque.net>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org,
	vincent@...nat.ch
Subject: Re: [PATCH net-next] vxlan: add support for flowlabel inherit

On Sat, Sep 30, 2023 at 09:28:19AM -0500, Alce Lafranque wrote:
> By default, VXLAN encapsulation over IPv6 sets the flow label to 0, with an
> option for a fixed value. This commits add the ability to inherit the flow
> label from the inner packet, like for other tunnel implementations.

Please add motivation to the commit message. At first glance it's not
clear why this is needed given that the entropy is encoded in the UDP
source port (unlike ip6gre, for example). I assume the motivation is
related to devices that can't calculate ECMP/RSS hash based on L4
headers, but I prefer not to guess :)

Regarding the netlink interface, I think we should introduce a new u8
attribute that encodes the flow label policy:

0 - Fixed. Taken from IFLA_VXLAN_LABEL. This is the default.
1 - Inherit. Copy if packet is IPv6, otherwise set to 0.

This will allow us to add more policies in the future:

2 - Hash. Set the flow label according to the hash of the inner packet.
Useful when inner packet is not IPv6.
3 - Inherit with hash fallback. Copy if packet is IPv6, otherwise set
according to the hash of the inner packet.

This already exists in at least one hardware implementation that I'm
familiar with, so I see no reason not to create provisions for this in a
software implementation. We can implement the last two policies if/when
someone asks for them.

The command line interface can remain as you have it now:

 # ip link add vxlan1 type vxlan id 100 flowlabel inherit remote 2001:db8::1 local 2001:db8::2

But unlike the current implementation, user space will be able to change
it on the fly:

 # ip link set vxlan1 type vxlan flowlabel 5
 # ip link set vxlan1 type vxlan flowlabel inherit

Unless iproute2 is taught to probe for the new policy attribute, then
when setting the flow label to a fixed value iproute2 shouldn't default
to sending the new attribute as it will be rejected by old kernels.
Instead, the kernel can be taught that the presence of IFLA_VXLAN_LABEL
implies the default policy.

The JSON output can mimic the netlink structure and add a new key for
the new policy attribute.

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ