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: <57f72e6a6f024628bd18ef4b139ac31e@EMEAWP-EXMB12.corp.brocade.com>
Date:	Thu, 13 Aug 2015 14:48:23 +0000
From:	Philip Downey <pdowney@...cade.com>
To:	David Miller <davem@...emloft.net>
CC:	"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

Hi David
Thanks for taking the time to review and comment.
This is my first upstream request so please forgive any ignorance on my part.   I have added a new proposed commit wording below with a view to agreeing the content before resubmitting the patch.
I hope it is sufficient to address your concerns.

   IGMP: Inhibit reports for local multicast groups
    
    The range of addresses between 224.0.0.0 and 224.0.0.255
    inclusive, is reserved for the use of routing protocols and other
    low-level topology discovery or maintenance protocols, such as
    gateway discovery and group membership reporting.  Multicast
    routers should not forward any multicast datagram with   destination
    addresses in this range, regardless of its TTL.

    Currently, IGMP reports are generated for this reserved range of
    addresses even though a router will ignore this information since
    it has no purpose.  However, the presence of reserved group
    addresses in an IGMP membership report uses up network bandwidth
    and can also obscure addresses of interest when inspecting
    membership reports using packet inspection or debug messages.

    IGMP reports for local multicast groups can now be inhibited by means
    of a system control variable (setting the value to zero).
    
    To retain backwards compatibility the previous behaviour is retained by
    default on system boot.
    
    Signed-off-by: Philip Downey <pdowney@...cade.com>


Regards

Philip

> -----Original Message-----
> From: David Miller [mailto:davem@...emloft.net]
> Sent: Thursday, August 13, 2015 12:45 AM
> To: Philip Downey
> Cc: 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
> 
> From: Philip Downey <pdowney@...cade.com>
> Date: Wed, 12 Aug 2015 17:13:53 +0100
> 
> > IGMP reports are generated for link local multicast groups (224.0.0.1
> > - 224.0.0.255) used by the routing protocols such as RIP, OSPF etc.
> > In general routers do not generate reports for local multicast groups.
> >
> > IGMP reports for local multicast groups can now be inhibited by means
> > of a system control variable (setting the value to zero).
> >
> > To retain backwards compatibility the previous behaviour is retained
> > by default on system boot.
> >
> > Signed-off-by: Philip Downey <pdowney@...cade.com>
> 
> I'm always hesitent to apply patches like this.
> 
> I can't even understand from your explanation:
> 
> 1) what about local reporting behavior is so bad
> 
> 2) why you want to inhibit them at all
> 
> For example, this:
> 
> > In general routers do not generate reports for local multicast groups.
> 
> Doesn't tell me anything.  You need to go into more detail about this, and
> explain the situation sufficiently.
--
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