netdev - Re: [PATCH net-next 0/5] net: Extend address label support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Mar 2023 14:26:56 +0100
From:   Petr Machata <petrm@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
CC:     Petr Machata <petrm@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, <netdev@...r.kernel.org>,
        David Ahern <dsahern@...nel.org>,
        Shuah Khan <shuah@...nel.org>,
        Ido Schimmel <idosch@...dia.com>, <mlxsw@...dia.com>
Subject: Re: [PATCH net-next 0/5] net: Extend address label support

Jakub Kicinski <kuba@...nel.org> writes:

> On Fri, 10 Mar 2023 12:44:53 +0100 Petr Machata wrote:
>> IPv4 addresses can be tagged with label strings. Unlike IPv6 addrlabels,
>> which are used for prioritization of IPv6 addresses, these "ip address
>> labels" are simply tags that the userspace can assign to IP addresses
>> arbitrarily.
>> 
>> IPv4 has had support for these tags since before Linux was tracked in GIT.
>> However it has never been possible to change the label after it is once
>> defined. This limits usefulness of this feature. A userspace that wants to
>> change a label might drop and recreate the address, but that disrupts
>> routing and is just impractical.
>> 
>> IPv6 addresses lack support for address labels (in the sense of address
>> tags) altogether.
>> 
>> In this patchset, extend IPv4 to allow changing the label defined at an
>> address (in patch #1). Then, in patches #2 and #3, extend IPv6 with a suite
>> of address label operations fully analogous with those defined for IPv4.
>> Then in patches #4 and #5 add selftest coverage for the feature.
>
> Feels a bit like we're missing motivation for this change.
> I thought address labels were legacy cruft.

The immutability and lack of IPv6 support is seriously limiting, so the
fact nobody is using this is not that surprising.

> Also the usual concern about allowing to change things is that some
> user space will assume it's immutable. The label could until this 
> set be used as part of a stable key, right?

Maybe. But to change a label, you need to be an admin, so yeah, you can
screw things up if you want to. You could e.g. delete the address
outright. In the end it should be on me as an admin to run a stack that
is not stumbling over itself.

As for the motivation: the use case we are eying in particular is
advertisement of MLAG anycast addresses. One label would be used to mark
anycast addresses if they shouldn't be advertised by the routing stack
yet, a different label for those that can be advertised. Which labels
mean what would be a protocol between the two daemons involved.

Other userspace stacks might use this to their own ends to annotate sets
of addresses according to their needs. Like they can today, if the sets
only involve IPv4 addresses that never migrate from set to set :)