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] [day] [month] [year] [list]

Date:   Mon, 9 Nov 2020 18:03:50 +0800
From:   LIU Yulong <liuyulong.xa@...il.com>
To:     Jay Vosburgh <jay.vosburgh@...onical.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, 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

Yes, the 33:33:ff:00:00:01 is just an example, the destination MAC address
can be various. The code of current solution is simple but indeed may need
have more attentions on the real world topologys.

The current solution refers to the action of ARP protocol in IPv4 [1].
While the IPv4 diabled the ARP tx balance, for the IPv6 we disable
the all-nodes multicast [2] (when there are no multicast domain, it
can be considered as all, aka broadcast [3]). But please note, the
MAC "33:33:00:00:00:01" for IPv6 RA (Router Advertisement) destination.

I have an alternative which is to verify the packet type, if it is the
ICMPv6 and the type is 135(Neighbor Solicitation), we disable the tx
balance. A new if-conditon will be added right below the all-nodes
multicast check.

[1] https://github.com/torvalds/linux/blob/master/drivers/net/bonding/bond_alb.c#L1423
[2] https://github.com/torvalds/linux/blob/master/drivers/net/bonding/bond_alb.c#L1431
[3] https://en.wikipedia.org/wiki/Solicited-node_multicast_address

On Mon, Nov 9, 2020 at 5:37 AM Jay Vosburgh <jay.vosburgh@...onical.com> wrote:
>
> 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