netdev - Re: [RFC net-next] net: dsa: add support for MC

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: <20190629162945.GB17143@splinter>
Date:   Sat, 29 Jun 2019 19:29:45 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        nikolay@...ulusnetworks.com, linus.luessing@...3.blue
Cc:     Ido Schimmel <idosch@...lanox.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...nulli.us>,
        "andrew@...n.ch" <andrew@...n.ch>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [RFC net-next] net: dsa: add support for MC_DISABLED attribute

On Sun, Jun 23, 2019 at 10:44:27AM +0300, Ido Schimmel wrote:
> On Sun, Jun 23, 2019 at 08:26:05AM +0100, Russell King - ARM Linux admin wrote:
> > On Sun, Jun 23, 2019 at 07:09:52AM +0000, Ido Schimmel wrote:
> > > When multicast snooping is enabled unregistered multicast traffic should
> > > only be flooded to mrouter ports.
> > 
> > Given that IPv6 relies upon multicast working, and multicast snooping
> > is a kernel configuration option, and MLD messages will only be sent
> > when whenever the configuration on the target changes, and there may
> > not be a multicast querier in the system, who does that ensure that
> > IPv6 can work on a bridge where the kernel configured and built with
> > multicast snooping enabled?
> 
> See commit b00589af3b04 ("bridge: disable snooping if there is no
> querier"). I think that's unfortunate behavior that we need because
> multicast snooping is enabled by default. If it weren't enabled by
> default, then anyone enabling it would also make sure there's a querier
> in the network.

Linus, Nik,

I brought this problem in the past, but we didn't reach a solution, so
I'll try again :)

The problem:

Even if multicast snooping is enabled, the bridge driver will flood
multicast packets to all the ports if no querier was detected on the
link. The querier states (IPv4 & IPv6) are not currently reflected to
switchdev drivers which means that the hardware data path will only
flood unregistered multicast packets to mrouter ports (which can be an
empty list).

In default configurations (where multicast snooping is enabled and the
bridge querier is disabled), this can prevent IPv6 ping from passing, as
there are no mrouter ports and there is no MDB entry corresponding to
the solicited-node multicast address.

Is there anything we can do about it? Enable the bridge querier if no
other querier was detected? Commit c5c23260594c ("bridge: Add
multicast_querier toggle and disable queries by default") disabled
queries by default, but I'm only suggesting to turn them on if no other
querier was detected on the link. Do you think it's still a problem?

I would like to avoid having drivers take the querier state into account
as it will only complicate things further.

Thanks