netdev - Re: [PATCH v2] net: bonding: alb disable balance for IPv6 multicast related mac

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, 08 Nov 2020 13:37:06 -0800
From:   Jay Vosburgh <jay.vosburgh@...onical.com>
To:     Jakub Kicinski <kuba@...nel.org>
cc:     LIU Yulong <liuyulong.xa@...il.com>, netdev@...r.kernel.org,
        LIU Yulong <i@...yulong.me>,
        Veaceslav Falico <vfalico@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>
Subject: Re: [PATCH v2] net: bonding: alb disable balance for IPv6 multicast related mac

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

>On Tue, 3 Nov 2020 13:05:59 -0800 Jakub Kicinski wrote:
>> On Mon,  2 Nov 2020 15:56:43 +0800 LIU Yulong wrote:
>> > According to the RFC 2464 [1] the prefix "33:33:xx:xx:xx:xx" is defined to
>> > construct the multicast destination MAC address for IPv6 multicast traffic.
>> > The NDP (Neighbor Discovery Protocol for IPv6)[2] will comply with such
>> > rule. The work steps [6] are:
>> >   *) Let's assume a destination address of 2001:db8:1:1::1.
>> >   *) This is mapped into the "Solicited Node Multicast Address" (SNMA)
>> >      format of ff02::1:ffXX:XXXX.
>> >   *) The XX:XXXX represent the last 24 bits of the SNMA, and are derived
>> >      directly from the last 24 bits of the destination address.
>> >   *) Resulting in a SNMA ff02::1:ff00:0001, or ff02::1:ff00:1.
>> >   *) This, being a multicast address, can be mapped to a multicast MAC
>> >      address, using the format 33-33-XX-XX-XX-XX
>> >   *) Resulting in 33-33-ff-00-00-01.
>> >   *) This is a MAC address that is only being listened for by nodes
>> >      sharing the same last 24 bits.
>> >   *) In other words, while there is a chance for a "address collision",
>> >      it is a vast improvement over ARP's guaranteed "collision".
>> > Kernel related code can be found at [3][4][5].  
>> 
>> Please make sure you keep maintainers CCed on your postings, adding bond
>> maintainers now.
>
>Looks like no reviews are coming in, so I had a closer look.
>
>It's concerning that we'll disable load balancing for all IPv6 multicast
>addresses now. AFAIU you're only concerned about 33:33:ff:00:00:01, can
>we not compare against that?

	It's not fixed as 33:33:ff:00:00:01, that's just the example.
The first two octets are fixed as 33:33, and the remaining four are
derived from the SNMA, which in turn comes from the destination IPv6
address.

	I can't decide if this is genuinely a reasonable change overall,
or if the described topology is simply untenable in the environment that
the balance-alb mode creates.  My specific concern is that the alb mode
will periodically rebalance its TX load, so outgoing traffic will
migrate from one bond port to another from time to time.  It's unclear
to me how the described topology that's broken by the multicast traffic
being TX balanced is not also broken by the alb TX side rebalances.

	-J

>The way the comparison is written now it does a single 64bit comparison
>per address, so it's the same number of instructions to compare the top
>two bytes or two full addresses.


---
	-Jay Vosburgh, jay.vosburgh@...onical.com