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
| ||
|
Date: Mon, 17 Dec 2018 14:15:50 +0100 From: Linus Lüssing <linus.luessing@...3.blue> To: Ying Xu <yinxu@...hat.com> Cc: liuhangbin@...il.com, nikolay@...ulusnetworks.com, netdev@...r.kernel.org, roopa@...ulusnetworks.com, bridge@...ts.linux-foundation.org, davem@...emloft.net Subject: Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries Hi and thanks for your reply! On Fri, Dec 14, 2018 at 10:32:16AM +0800, Ying Xu wrote: > I think the scenario mentioned above is abnormal. Can we agree, that this scenario, if switch A and B were using the current bridge code, has issues right now which it did not have before that patch? I also do not quite understand what you mean with "abnormal". Do you think that it is unlikely to have two snooping switches and general queries with a 0.0.0.0 source? Note that with the current bridge code and according to RFC3376 and RFC2236, as soon as a query with a 0.0.0.0 source is sent somewhere in the broadcast domain, it will become the selected querier [*]. > The source of query indicats that is a real router or only a switch.(0.0.0.0 > means switch,non-zero means router). > In the scenario above,the switch A was selected to be a querier that means A > performs as a router, > so switch A should config its query source address to non-zero,and then Host A > can recieve the traffic from B. Even if in the described scenario switch A were configured to use a a non-zero source address to become a router, so that switch B would mark the port to switch A as a multicast router port, switch A would still loose in the querier election right now, as 0.0.0.0 is lower (RFC3376, RFC2236). So switch B would then become the selected querier with its 0.0.0.0 source and switch A would become silent even though it had a non-zero source address. And then we would have the same issue again, only swapped between host+switch A and host+switch B. Would you agree, does that make sense? Regards, Linus [*]: Looking at br_ip4_multicast_select_querier(): If previously selected querier were 0.0.0.0, it would accept any source as a new querier ("!br->ip4_querier.addr.u.ip4"). However, if the previously selected querier were non-zero, a query with 0.0.0.0 would win, too ("ntohl(saddr) <= ntohl(br->ip4_querier.addr.u.ip4)").
Powered by blists - more mailing lists