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 17:19:14 -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:
>> Well guess then we need the global proc setting after all. With the
>> current misbehavior as a default applications need to be rebuilt and
> 
>         The current behavior, as either your or Vlad's RFC quotes pointed
> out as easily as the history to go with it, is exactly the expected behavior
> for decades. I think it is not misbehavior so much as your misconception,
> though a common one.
> 

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.

>> source code that is running on multiple OSes now would have to  customized
>> to special case for Linux.
> 
>         No, actually. If you write it for the current behavior, it'll work
> fine on an OS like Solaris that has departed from the original socket
> behavior. If you're sloppy and don't handle unexpected traffic, it'll be
> wrong on both-- you just won't know it until someone runs something with
> the same port and multicast address on your network and wrecks your app.

I'd have to reluctantly agree here.  Any application that expects original
multicast behavior will be broken by a system-wide change.  I think existing
applications have already figured out all the workarounds they need.

> 
>> So add a global proc setting to determine the initial setting of 
> IP_MULTICAST_ALL?
> 
>         This breaks unknown existing applications that are correctly
> written. I think it's clearly wrong to change the behavior of someone
> else's socket to match your idea of how it should've been done 25 years
> too late. An option that enables new behavior for your own socket, which
> must be a new app, is fine. Adding a socket option as part of a port
> is no great hurdle, and I'm guessing you aren't trying to run a Solaris
> binary on Linux. So what's the problem?
> 
>                                                                 +-DLS

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.

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