netdev - Re: PATCH: Multicast: Filter multicast traffic per socket mc

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]

Date:	Thu, 16 Apr 2009 20:01:38 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	David Stevens <dlstevens@...ibm.com>
CC:	Christoph Lameter <cl@...ux.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org, Neil Horman <nhorman@...driver.com>
Subject: Re: PATCH: Multicast: Filter multicast traffic per socket mc_list

David Stevens wrote:
> Vlad Yasevich wrote on 04/16/2009 02:19:14 PM:
> 
>> What seems to be happening though, is that there is an expectation that
>> this behavior would change with advent of IGMPv3, which adds the 
> additional
>> filtering text.  Now, we could point out that there is no normative text
>> that requires this filtering on groups, only on sources, but the 
> expectation
>> is still there.
> 
>         I have no such expectation. :-) The additional filters are 
> (already)
> applied per-socket, but existing apps not using source filters behave as
> they did before IGMPv3. That's what I'd expect.
>         The RFC you quoted for SSM applies to only the SSM address space,
> mentions this behavior explicitly as the norm for outside of that space,
> and Linux doesn't support that RFC. If it did, it would include an
> address range check as part of it.

Yes, after reading more of SSM spec, it definitely only applies to SSM
addresses that we don't support yet.  Just to clear this one item up,
I think the expectation comes from the IGMPv3 spec:

     Filtering of packets based upon a socket's multicast reception
     state is a new feature of this service interface.  The previous
     service interface [RFC1112] described no filtering based upon
     multicast join state; rather, a join on a socket simply caused the
     host to join a group on the given interface, and packets destined
     for that group could be delivered to all sockets whether they had
     joined or not.

I could be inferred from this rather vague text that in addition to source
filtering, group filters should be done.  Thus the expectation that we've
been dealing with.

That's the last I'll mention this, since most salient points have been
agreed on.

Thanks
-vlad

> 
>> I wonder how BSD and Solaris got away with it?  They both filter on 
> multicast
>> groups and source addresses.  This is not meant as rhetorical or 
> provocative,
>> just genuinely wondering.
> 
>         I think in practice, it doesn't come up much. That's why people
> seem so surprised to learn it works this way, and not the way they
> thought it did after using it, sometimes for years. But the documentation
> doesn't say a join limits what you receive on a socket, or that it
> has to be the same socket you're doing I/O on; people simply assume it.
> 
>                                                                 +-DLS
> 

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