netdev - Re: [gluon] Re: [RFC PATCH net-next] bridge: Implement MLD Querier wake-up calls / Android bug workaround

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:   Mon, 17 Aug 2020 15:24:38 +0100
From:   Daniel Golle <daniel@...rotopia.org>
To:     Sven Eckelmann <sven@...fation.org>
Cc:     gluon@...beck.freifunk.net,
        Linus Lüssing <linus.luessing@...3.blue>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        netdev@...r.kernel.org, Roopa Prabhu <roopa@...ulusnetworks.com>,
        bridge@...ts.linux-foundation.org, openwrt-devel@...ts.openwrt.org,
        "David S . Miller" <davem@...emloft.net>,
        Bjørn Mork <bjorn@...k.no>
Subject: Re: [gluon] Re: [RFC PATCH net-next] bridge: Implement MLD Querier
 wake-up calls / Android bug workaround

On Mon, Aug 17, 2020 at 03:17:37PM +0200, Sven Eckelmann wrote:
> On Monday, 17 August 2020 10:39:00 CEST Bjørn Mork wrote:
> > Linus Lüssing <linus.luessing@...3.blue> writes:
> [...]
> > This is not a bug.  They are deliberately breaking IPv6 because they
> > consider this a feature.  You should not try to work around such issues.
> > It is a fight you cannot win.  Any workaround will only encourage them
> > to come up with new ways to break IPv6.
> 
> Who are "they" and where is this information coming from? And what do they 
> gain from breaking IPv6? Wouldn't it be easier for them just to disable IPv6 
> than adding random looking bugs?

They are Google and they want IPv6 to be used in a way which exposes
as much user data as possible to their servers (that's my guess).
Every additional identifying bit is like gold for them (that's their
business model).
Hence they like SLAAC and addressing schemes which reflect the network
topology and are enforcing that direction beyond good reason (that
should be obvious[1] to everyone[2] by now[3], no matter what the
reasons for that are).
You may say, hey, SLAAC also allows me to use Privary Extension and I'm
sure your browser will make use of that. But does the DNS resolver?
And what about all those Google services running in background? I'm not
sure all of them instruct the kernel to open every single socket using
a privacy source address...
Simply, when relying on SLAAC + Privary Extensions it's up to the
(mobile) client to avoid being very easily tracked.
When using DHCPv6 the situation is like it was for v4 (ok, it's still
a bit worse because you can distinguish clients much better).

As a work-around, I've been limiting source EUI-64 addresses from
leaving my local network -- but that's surely not what everyone would
want to make sure their local devices MAC addresses aren't leaked and
also just breaking v6 in yet another way.
I don't consider NAT66 an option and would like to avoid even
connection-tracking on v6 as it was promissed :). Tethering should
work using DHCPv6 prefix delegation imho rather than ND-proxy or
NAT66 which are both quite a burden for the battery-powered device
offering the tethering gateway (ie. each forwarded packet then needs
CPU intervention, I can't see anything great about that).

[1]: https://www.nullzero.co.uk/android-does-not-support-dhcpv6-and-google-wont-fix-that/

[2]: https://www.techrepublic.com/article/androids-lack-of-dhcpv6-support-frustrates-enterprise-network-admins/

[3]: https://lostintransit.se/2020/05/22/its-2020-and-androids-ipv6-is-still-broken/