netdev - Re: IGMP v3 reponse

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: <4CA12DF3.6050608@rincon.com>
Date:	Mon, 27 Sep 2010 16:51:15 -0700
From:	Bob Arendt <rda@...con.com>
To:	David Stevens <dlstevens@...ibm.com>
CC:	Christoph Lameter <cl@...ux.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"netdev-owner@...r.kernel.org" <netdev-owner@...r.kernel.org>
Subject: Re: IGMP v3 reponse

On 09/27/10 15:01, David Stevens wrote:
> Bob Arendt<rda@...con.com>  wrote on 09/27/2010 01:54:36 PM:
>> And it turns out that  force_igmp_version=2 doesn't fully work.
>> If the host sees a IGMPv3 query, it still responds with a v3 Join
>> despite the flag.  Bug report and candidate patch here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=18212
>
>          This is a special case. The "correct" alternative is to drop
> the query and not send any report at all. Sending an answer in the
> originating protocol doesn't hurt anything here, because MC routers
> are required to use the earlier version too; there should be no such
> thing as an "IGMPv3-only querier" as in that report. IGMPv3 compliance
> *requires* falling back to IGMPv2 if there is a v2 query by another
> router.
>          By answering instead of dropping, it allows fuller filter
> information from a manual query to be returned even if the network
> is using v2 MC routers, but dropping and ignoring the query as
> required by RFC does not fix the bug&  patch submitter's problem.
> Which is why I also NACKed that patch.
>
>                                                          +-DLS
>
>
Per rfc 2236, the v2 client *can't* drop the IGMPv3 query.  From para 2.5:
   2.5.  Other fields
    Note that IGMP messages may be longer than 8 octets, especially
    future backwards-compatible versions of IGMP.  As long as the Type is
    one that is recognized, an IGMPv2 implementation MUST ignore anything
    past the first 8 octets while processing the packet.  However, the
    IGMP checksum is always computed over the whole IP payload, not just
    over the first 8 octets.

The IGMPv3 query *is* a valid v2 query with extra crap at the end (it's
backward compatible).  Per rfc 2236 p2.5, the v3 query has to be regarded
as a valid v2 query if you're correctly implementing IGMPv2.  Some switch
vendors (Cisco for one) only generate v3 queries when operating as an
IGMP snooping switch, since a proper v2 client will respond with IGMPv2
packets and it handles this properly.  However, we're seeing some switches
get confused when a client initial joins with v2, then responds to a query
with v3.  It ends up creating 2 entries, and only one is cleared by the
leave message.  This is also an issue when the primary (querier) switch
only generates v3 queries, and some intermediate switches only support v2.
We set all the Linux clients to v2 .. but they respond the v2 query with
v3 protocols, which could be missed by the intermediate switch.

I believe the intent of the bug 18212 patch is correct.

-Bob Arendt
--
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