netdev - Re: [net-next RFC] net: ipv4: Send IGMP messages from highest scoped address

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: <20150818133641.GB4381@lunn.ch>
Date:	Tue, 18 Aug 2015 15:36:41 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [net-next RFC] net: ipv4: Send IGMP messages from highest scoped
 address

On Mon, Aug 17, 2015 at 09:31:58PM -0700, David Miller wrote:
> From: Andrew Lunn <andrew@...n.ch>
> Date: Mon, 17 Aug 2015 18:09:24 +0200
> 
> > This is RFC because i personally don't know if this is the best fix.
> > The patch restores previous behavior, while still keeping the bug fix.
> > 
> > It is not obvious what is the correct source address for an IGMP
> > message when an interface has multiple addresses. IGMP messages are
> > sent either spontaneously, or as a result of a query. It could be
> > argued that when replying to a query, an address take from the same
> > subnet as the querier should be used. Doing this adds complexity for a
> > corner case which does not seem to effect people. In the spontaneous
> > case, there is no such hint, so an address has to be picked some other
> > way. Taking the highest scope address seems reasonable, and works for
> > me.
> 
> Yes, unfortunately almost no guidance is given in this area in the
> various RFCs.
> 
> Except that one recommended way to avoid forged IGMPs is to reject
> any IGMP that has a source address no on that interface's subnet.
> 
> And if people actually do that, then the link scope address is the
> best address to use and that is what we do now if I understand things
> correctly.

Hi David

We currently take the first address from the interface which is scope
link or higher.

Historically, the global scope address would of been used, but my
previous fix, which stopped it taking a global scope address from a
different interface altogether under some conditions, changed this
behaviour.

The first address from the interface, then broke one of my use
case. The querier is only in one of the subnets on this interface, and
using an address from the global scope address range. It then drops
the membership reports when they are sent from the first address on
the interface. This is why i want to restore the previous behaviour,
take the global scope address from this interface.

The patch works for me and is restoring previous behaviour, but is
that sufficient to make it correct?

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