netdev - Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled

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: <20190216203719.GC25057@otheros>
Date:   Sat, 16 Feb 2019 21:37:19 +0100
From:   Linus Lüssing <linus.luessing@...3.blue>
To:     nikolay@...ulusnetworks.com
Cc:     Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org,
        roopa@...ulusnetworks.com, wkok@...ulusnetworks.com,
        anuradhak@...ulusnetworks.com, bridge@...ts.linux-foundation.org,
        davem@...emloft.net, stephen@...workplumber.org
Subject: Re: [PATCH RFC] net: bridge: don't flood known multicast traffic
 when snooping is enabled

On Sat, Feb 16, 2019 at 09:27:26PM +0200, nikolay@...ulusnetworks.com wrote:
> >>The no querier condition is not currently reflected via switchdev, so
> >>the behavior you're proposing in your patch is what actually happens
> >in
> >>the data plane.
> >>
> >>We already hit the problem Linus mentioned in commit b00589af3b04
> >>("bridge: disable snooping if there is no querier"). Namely, IPv6 ND
> >>broke because a port joined before the bridge was created.
> >>
> >>I introduced a workaround in commit 9d45deb04c59 ("mlxsw: spectrum:
> >>Treat IPv6 unregistered multicast as broadcast"). I'm interested to
> >>know
> >>what other vendors are doing. Can you elaborate?
> >>
> >
> >Exactly like your fix. :) Flood it, this patch unfortunately breaks it 
> >because of mrouters flag, but we can retain the behaviour
> >by forwarding only known mdsts to their ports and flooding
> >unregistered mcast when there is no querier. I think that is 
> >what others do by default too, actually I think they flood with querier
> >as well. Maybe unknown mcast flooding should be controlled by a flag
> >when a querier is present
> >because we've had this behaviour for a long time, personally I'd have
> >it on
> >by default. 
> 
> Ugh, mispoke please read the above statement to be only about no querier. 
> I meant flooding v6 link-local always. 

And for routable IPv6 multicast, how would you detect multicast
listeners on the local link in absence of a querier?