How legacy IPv6 addresses can spoil your network privacy
- Reference: 1647938354
- News link: https://www.theregister.co.uk/2022/03/22/legacy_ipv6_addressing_standard_enables/
- Source link:
In a research paper titled "One Bad Apple Can Spoil Your IPv6 Privacy," Said Jawad Saidi, of the Max-Planck-Institut für Informatik at Saarland University in Germany; Oliver Gasser, also of the MPI-INF; and Georgios Smaragdakis, of TU Delft in the Netherlands describe how the use of legacy IPv6 addressing standard EUI-64, aka Extended Unique Identifier, by just one device potentially degrades privacy to every device on that network.
Their [1]paper is scheduled to be published next month in ACM SIGCOMM Computer Communication Review, Volume 52, Issue 2.
[2]
IPv6 was [3]introduced in 1998 as the successor to IPv4, the internet addressing protocol that [4]emerged from DARPA in 1981. IPv6 is still being rolled out – about [5]38 percent of those connecting to Google.com currently do so over IPv6 connections. But IPv6 is necessary to allow new devices to be added to the internet as IPv4 addresses become scarce.
[6]
[7]
Depending on your ISP, router, and so on, you might find that on your home network, your laptops, phones, and other devices have their own local IPv6 addresses, and each have a public-facing IPv6 address when connecting to websites and other stuff online. These addresses should be regularly swapped out with new ones so that when you visit a website today, and visit it again tomorrow, it's not clear to the website from your IPv6 address alone that your device has returned, granting you some level of privacy. According to this research, if you have a device on your network with EUI-64, you lose this.
IPv6, the paper explains, relies either on DHCPv6 or stateless address auto-configuration (SLAAC) to assign client addresses. With SLAAC, a router will send a prefix – in a way, the network identifier in an address – to the client, and the client will then select an IPv6 address within that prefix – known as the host part the address, or interface identifier (IID).
[8]
The IID used to be based on an encoding of the device's hardware MAC address, known as EUI-64
[9]PDF
. It subsequently became clear that [10]EUI-64 should be considered harmful to privacy because it exposes hardware identifiers at the network layer.Back in 2007, IPv6 privacy extensions [11]were proposed to randomize the host portion of the address. And ISPs got into the habit of rotating IPv6 address prefixes as an additional privacy defense.
Sadly, some hardware makers – largely Internet-of-Things vendors – missed the memo and still use EUI-64 to generate a device's IID.
[12]Microsoft Azure DevOps revives TLS 1.0/1.1 with rollback
[13]Nominet suspends 'single digit' number of Russian dot-UK domain registrars
[14]Network operating system Dent 2.0 targets smaller firms
[15]IPv6 is built to be better, but that's not the route to success
What the paper's authors have found is that it just takes a single device using EUI-64 to deny privacy to every device on the network. Almost a fifth (19 percent) of all end-user prefixes at a large ISP were found to be affected by this privacy leak and, it's claimed, a slightly smaller percentage (17 percent) can be monitored by large internet companies and hyperscalers.
"By analyzing passive data from a large ISP, we find that around 19 percent of end-users’ privacy can be at risk," the authors state in their paper. "When we investigate the root causes, we notice that a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix — even if other devices use IPv6 privacy extensions."
[16]
The paper describes an example involving two devices, a laptop using IPv6 privacy extensions, and a smart TV using EUI-64, both using a home network gateway router with IPv6 connectivity upstream and SLAAC in use. The diagram below, taken from the paper, is given to illustrate this scenario.
[17]
Diagram from the paper illustrating the privacy leak ... Credit: Saidi et al
The TV and the laptop are, on day one, given the same end-user prefix (2001:db80:1111:b000) and then their own host portions to form a public-facing IPv6 address. By the next day, another prefix is generated (2001:db80:3333:fff1) though the EUI-64-based TV gets the same host portion while the laptop gets a fresh one. The laptop has an entirely new IPv6 address whereas the TV only has a new prefix.
If the TV and laptop on day one interact with CDNs and internet giants, and then interact with those providers again on day two, one or more of those large networks can work back from the TV's unchanged host portion (8e8f:90ff:fe12:3456) and new prefix to link the laptop's latest IPv6 address with its previous address. Thus, the laptop can be tracked, with the TV's host portion effectively becoming a tracking ID.
This only works if the TV and the laptop both access the same cloud or CDN providers – such as Google, Meta, or Netflix, or something like a DNS or NTP provider – and if those backends care enough to match up people's IPv6 addresses and then use that information for something. It's perhaps unlikely though the mechanism is there. In the above diagram, CPE refers to the customer premise equipment aka the broadband gateway box. If this doesn't have the same end-user prefix as the devices on the network, it can't be tracked via this method.
"Since the smart TV is not using privacy extensions, it allows CDNs and other large players in the internet to track not only the smart TV itself, but all devices within that end user prefix," the paper added.
The MAC address can also be extracted from the EUI-64 portion of the IPv6 address and used to determine the device maker, via the Organization Unique Identifier (OUI) part of the MAC address. Devices not using EUI-64 could not be identified this way, even though they could be tracked using the common IID.
The boffins said about 39 percent of the network prefixes hosting EUI-64 devices correspond to companies making only IoT devices. About 32 percent correspond to companies making various devices, including IoT, computers, and mobile hardware.
In this second category, the paper's authors observe, while Apple enables privacy extensions by default in their products, other vendors do not.
"Unfortunately, at the time of writing, many Linux distributions do not activate privacy extensions by default," the paper says. "Products using Linux derivatives in their software are likely unknowingly putting their users’ privacy at risk."
The authors speculate that this may be due to the fact that the original [18]privacy extensions specification recommended deactivating them by default, which is no longer the case in the [19]current standard .
They also urge regulators to require that vendors certify their products for IPv6 privacy compliance and ISPs to check their gateway routers for privacy issues before shipping them to customers. ®
Get our [20]Tech Resources
[1] https://arxiv.org/abs/2203.08946
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YjmsYEbD@cJMCWPDjHgBHwAAANY&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://datatracker.ietf.org/doc/html/rfc2460
[4] https://datatracker.ietf.org/doc/html/rfc791
[5] https://www.google.com/intl/en/ipv6/statistics.html
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YjmsYEbD@cJMCWPDjHgBHwAAANY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YjmsYEbD@cJMCWPDjHgBHwAAANY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YjmsYEbD@cJMCWPDjHgBHwAAANY&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf
[10] https://arxiv.org/abs/1902.08968
[11] https://datatracker.ietf.org/doc/html/rfc4941
[12] https://www.theregister.com/2022/03/15/microsoft_azure_tls/
[13] https://www.theregister.com/2022/03/15/nominet_suspends_russian_registrars/
[14] https://www.theregister.com/2022/03/08/dent_os_2/
[15] https://www.theregister.com/2022/01/24/opinion_column_ipv6/
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/networks&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YjmsYEbD@cJMCWPDjHgBHwAAANY&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[17] https://regmedia.co.uk/2022/03/22/handout_fig1_prefixes.jpg
[18] https://datatracker.ietf.org/doc/html/rfc4941
[19] https://datatracker.ietf.org/doc/html/rfc8981
[20] https://whitepapers.theregister.com/
Re: Underwhelming
I have to agree. Very ho-hum. Given how rarely IPv4 addresses change (and you want this) and a fixed IPv4 address is common, I don't really see this is massively worse. Also my IoT devices (hopefully) talk to their single AWS cloud services, so not really leaking to lots of Internet sites, a TV a little more but still a very limited pool of sites. Phones and things that actually leave my house are all random assignment.
Besides I have a fixed PD delegation anyway, knowing my end device isn't a big further hole.
To be honest, I'd personally love to us pure DHCPv6 and not SLAAC at home, but Android doesn't support it! Due to a super awkward Android developers with an obsession that we should all use SLAAC and nothing else...
https://issuetracker.google.com/issues/36949085?pli=1
I don't care what the experts say....
For my home network I will always run NAT for the "users". I mean some machines might be have a routeable external address but that's about it.
Is there really a need to devices to register an IP address for notifications?
Re: I don't care what the experts say....
To be honest you can do really smart on IPv6 with Prefix Translation, because you have so many external addresses you can have 1-to-1 mapping of external to internal addresses, it should work great. Much better than IPv4 port hackery.
Sadly there is a big BUT coming, the private addresses you can assign officially in IPv6 ULAs (fd00::/8) will NEVER be used for Internet traffic (I believe usually hard coded into the stacks and will drop back to IPv4 if you try, so I have read (not tried it)). So your choice is to use an unused piece of the real address space, it's unused this week, so this may well come back to bite you.
Sadly the Ivory Tower people that architect these sort of things have made NAT IPv6 hard to do well.
A bit analogous to the Ivory Tower people that don't want to give out a decent set of private top-level domain names for internal use....
Re: I don't care what the experts say....
There is no NAT for ipv6.
Re: I don't care what the experts say....
I'll stick to ipv4 then. Well I'm going to have to for quite a while because my ISP doesnt use 6 and I cant find anyone else to supply me here for anything realistic. Currently IPV6 offers me nothing and until it offers me something and in a way that means I can configure it securely and know exactly what I'm doing its not happening.
Re: I don't care what the experts say....
Strange, my linux boxen seem to support this with kernel versions 3.x something. Something tells me there is less entropy in a single IP address rather than having a uniquely identifiable ip address for every freaking device.
ip6tables -v -n -t nat --list POSTROUTING
Chain POSTROUTING (policy ACCEPT 12 packets, 960 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all * wl+ ::/0 ::/0
0 0 MASQUERADE all * tun+ ::/0 ::/0
0 0 MASQUERADE all * ppp+ ::/0 ::/0
0 0 MASQUERADE all * wg+ ::/0 ::/0
Networks are seldom private
The research makes one point: never use local hardware addresses (MAC) as part of global addressing, simply because it is an information leak. But randomization of the local address part is highly overrated.
The assumption of privacy with randomization is on rather shaky grounds because you can track based on behavior, regardless 4/6 protocol. In the IPv4 space you often share one single address. You can identify individual devices, even though there is only one one address, be means of behavioral patterns (like timing and access spread). The IPv6 prefix is not a secret. The rest is just noise, which can be ignored if you look at the traffic patterns. There is effectively no difference between IPv4 address and IPv6 prefix tracking. You can also use NAT in an IPv6 setting.
But giving away local network information freely, with embedding the MAC address is, of course, a very bad idea.
yet another case for NAT
IPv6 tried to bury NAT and actively discourages NAT
see RFC 4864 which nicely details how IPv6 is designed to not use NAT
https://datatracker.ietf.org/doc/html/rfc4864
NAT would hide that IID behind the gateway public address, get a new public prefix and suddenly the IID is worthless.
yes there is NAT for IPv6 but things like ipv6-ipv6 won't help as that just swaps the prefix and does nothing for the IID
https://blogs.infoblox.com/ipv6-coe/you-thought-there-was-no-nat-for-ipv6-but-nat-still-exists/
IPv6 still needs to mature.
funny how its the big content providers like Google & Meta who are pushing ipv6 largely as they have the most to gain, plus they often have hardware in peoples homes so can always track the prefix anyway, which is not too dissimilar from the current arrangement in ipv4 but ipv6 is meant to be better but has issues.
They will continue to find glaring issues in ipv6 as its adoption rises.
newer is not always better.
Every molecule can have its own IP address
Wasn't that the selling point of v6? If we have to randomize our v6 IP address on a daily/hourly basis to avoid tracking, doesn't that greatly diminish the value of having such an expansive address space? I guess if we can hide all that inside the ISP connection point (normally, an ISP-provided router), then we can just use NAT on all home devices and be done with it. As long as we can continue to use v4 inside the house for ease of use, and NAT that to v6 on the ISP router, that should cover the majority of use cases for home users.
Professionals get paid to deal with these headaches, so I'm not too concerned about the hoops that they have to jump through with all this.
Re: Every molecule can have its own IP address
Every molecule can have its own IP address
the issue is that with the story in this article its trivial to determine which if those molecules belong to you even when you hand them over to someone else which is not meant to be the case.
NAT'ing IPv4 to IPv6 is not trivial and effectively is proxying as the IPv4 packet & IPv6 packet are not compatible and needs rewriting. you could encapsulate an ipv4 packet within ipv6 if you wanted but that needs the other side to know about it so it can unpack it like when doing GRE or a VPN.
https://en.wikipedia.org/wiki/IVI_Translation
There are a number of different solutions, I've never used any and have no idea on their effectiveness or popularity.
Its safe to say there are obviously limitations else we would not be writing about it and would all be on ipV6 if they where effective.
if they just did a feature complete version of IPv4 NAT on IPv6 I think we'd all be using IPv6 by now.
IPv6 has too many artificial limitations that have prevented adoption,.
Re: Every molecule can have its own IP address
"NAT'ing IPv4 to IPv6 is not trivial" if that really is the case then I'm sorry, IPV6 WILL have to be re-written until it is.
I'm not quite sure I understand
While I do understand the information leak, the article doesn't make it clear to me how the tracker knows when it has a MAC address in the local part and hence to use this to track everything from that router. Is this done using a database for MAC addresses?
As it is, although my router is using IPv6 to talk upstream, it's also using a 4 to 6 tunnel to do so because so much of the outside world is stil IPv4 only.
But I also wonder if the bigger risk isn't being tracked, I think our consumer devices and own behaviour make it pretty easy to identify us whatever mitigation we try, but information about the network providing information for potential hacking.
"ISPs got into the habit of rotating IPv6 address"
Good luck with dynamic prefixes and networks renumbering...
The real problem is SLAAC - which should become deprecated - it's no surprise Google is trying to avoid DHCPv6 as much as it can.
Underwhelming
I was expecting something jaw-dropping when I started the article but on reaching the end I can't help feeling "ho-hum". It the kind of thing that's fairly obvious if you think about it. Of course, like many of these obvious "new" threats the claims are over-egged.
The persistent host portion allows network prefix randomisation to be unscrambled, it do not allow further tracking of other devices in the network. In the example given you can't confirm the laptop is the same machine as yesterday, only that it is a system on the same network.