netdev - RE: [PATCH] IGMP: Inhibit reports for local multicast groups

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: <043c875965404398bc769cfce1209718@EMEAWP-EXMB12.corp.brocade.com>
Date:	Fri, 14 Aug 2015 08:55:38 +0000
From:	Philip Downey <pdowney@...cade.com>
To:	Thadeu Lima de Souza Cascardo <cascardo@...hat.com>,
	Andrew Lunn <andrew@...n.ch>
CC:	David Miller <davem@...emloft.net>,
	"kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH] IGMP: Inhibit reports for local multicast groups

Sorry for the duplication - I responded in a similar manner before seeing this.

Thanks

Philip

> -----Original Message-----
> From: Thadeu Lima de Souza Cascardo [mailto:cascardo@...hat.com]
> Sent: Thursday, August 13, 2015 7:08 PM
> To: Andrew Lunn
> Cc: Philip Downey; David Miller; kuznet@....inr.ac.ru; jmorris@...ei.org;
> yoshfuji@...ux-ipv6.org; kaber@...sh.net; linux-kernel@...r.kernel.org;
> netdev@...r.kernel.org
> Subject: Re: [PATCH] IGMP: Inhibit reports for local multicast groups
> 
> On Thu, Aug 13, 2015 at 07:01:37PM +0200, Andrew Lunn wrote:
> > On Thu, Aug 13, 2015 at 04:52:32PM +0000, Philip Downey wrote:
> > > Hi Andrew
> > > IGMP snooping is designed to prevent hosts on a local network from
> receiving traffic for a multicast group they have not explicitly joined.   Link-
> Local multicast traffic should not have an IGMP client since it is reserved for
> routing protocols.  One would expect that IGMP snooping needs to ignore
> local multicast traffic in the reserved range intended for routers since there
> should be no IGMP client to make "join" requests.
> >
> > The point of this patch is that Linux is sending out group membership
> > for these addresses, it is acting as a client. What happens with a
> > switch which is applying IGMP snooping to link-local multicast groups?
> > You turn on this feature, and you no longer get your routing protocol
> > messages.
> >
> > I had a quick look at RFC 3376. The only mention i spotted for not
> > sending IGMP messages is:
> >
> >    The all-systems multicast address, 224.0.0.1, is handled as a special
> >    case.  On all systems -- that is all hosts and routers, including
> >    multicast routers -- reception of packets destined to the all-systems
> >    multicast address, from all sources, is permanently enabled on all
> >    interfaces on which multicast reception is supported.  No IGMP
> >    messages are ever sent regarding the all-systems multicast address.
> >
> > IGMP v2 has something similar:
> >
> >    The all-systems group (address 224.0.0.1) is handled as a special
> >    case.  The host starts in Idle Member state for that group on every
> >    interface, never transitions to another state, and never sends a
> >    report for that group.
> >
> > But i did not find anything which says all other link-local addresses
> > don't need member reports. Did i miss something?
> >
> >       Andrew
> 
> From RFC 4541 (Considerations for Internet Group Management Protocol
> (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches):
> 
>  2) Packets with a destination IP (DIP) address in the 224.0.0.X range
>       which are not IGMP must be forwarded on all ports.
> 
>       This recommendation is based on the fact that many host systems do
>       not send Join IP multicast addresses in this range before sending
>       or listening to IP multicast packets.  Furthermore, since the
>       224.0.0.X address range is defined as link-local (not to be
>       routed), it seems unnecessary to keep the state for each address
>       in this range.  Additionally, some routers operate in the
>       224.0.0.X address range without issuing IGMP Joins, and these
>       applications would break if the switch were to prune them due to
>       not having seen a Join Group message from the router.
> 
> So, it looks like some hosts and routers out there in the field do not send
> joins for those local addresses. In fact, IPv4 local multicast addresses are
> ignored when Linux bridge multicast snooping adds a new group.
> 
> static int br_ip4_multicast_add_group(struct net_bridge *br, ...
> 	if (ipv4_is_local_multicast(group))
> 		return 0;
> 
> Cascardo.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html