netdev - Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast

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: <1409650573.1808.11.camel@jlt4.sipsolutions.net>
Date:	Tue, 02 Sep 2014 11:36:13 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC] net: ipv4: drop unicast encapsulated in L2 multicast

On Wed, 2014-08-27 at 11:53 +0200, Hannes Frederic Sowa wrote:

> > I don't know if that's really useful? OTOH, there surely must have been
> > a reason for this to be in the IPv4 RFC, so maybe for that same reason
> > it should also be in the IPv6 RFC?
> 
> Either it is an oversight, but RFC6085 3) tries to at least clarify the
> multicast destination with LL unicast address. So there must have been
> people trying to enfore a relationship between LL address and IPv6 one.

That seems to allow a multicast IPv6 frame in a unicast LL address,
which is a different situation but still ...

> I think it would be OK to drop it by default in case we don't break any
> other assumptions in the stack (e.g. CLUSTERIP).

Fair enough.

> > The question now is, in the absence of such a latter required check (and
> > indeed, in the case of CLUSTERIP), how we implement such a check.
> > Perhaps a sysctl is needed after all?
> 
> Yeah, unfortunate situation.
> 
> One could add those IP addresses as broadcast addresses (/32) to the
> routing table, so the brd_input jump would be taken.
> 
> But this would still break users of CLUSTERIP until they install those
> routes. :(

I'm not even sure I understand this part :)

Any suggestions?

As long as IPv6 doesn't mandate it in the RFCs I'm not really sure we
should just drop it, even if we think it won't cause any problems?

CLUSTERIP seems like a special configuration, but I'm not sure it can be
detected and automatically allowed?

johannes

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