One bad apple can spoil your IPv6 privacy (2022)
https://arxiv.org/abs/2203.08946
Automated Summary
The article introduces arXivLabs, a platform for collaborators to create and share new features on arXiv's website. To engage with arXivLabs, individuals and organizations must follow the values of openness, community, excellence, and user data privacy. The platform is committed to these principles and partners with those who adhere to them. The article invites readers to propose projects that will benefit arXiv's community through arXivLabs.
What this says is IOT devices leak their MAC within their IPv6 address.
Quick solution would be DHCPv6 so they don't have a choice in what address they use.
Going further, NAT and hide all these devices behind a single external IP.
Going even further, NAT the whole network by default and only give global addresses to endpoints that need it (local servers and such)
Going further still, forget all the NAT breakage and require all devices to actually use the privacy extensions described in RFC 4941 17 years ago. A router could auto-block an IPv6 address that's been in use too long, with a whitelist for servers.
There are reasons you might want your desktop to have the same address for a long time. I can't think of any reason why I'd want that for a light bulb.
NAT is broken by design. And CG-NAT can't do any kind of port forwarding on the routers. And adding more NAT is just breaking more networks.
RFC 4941 is currently old enough to be taking it's SAT's and preparing itself for college... :)
I’m thrilled to have good end-to-end connectivity to the degree I’m willing to configure my firewall for it.
When I hear people in other threads talking about the “security advantages” of NAT, I imagine someone filling their car’s engine with walnuts and talking about how it protects them from speeding tickets.
That's the thing, you don't have good end-to-end connectivity if you configure the firewall as you should and block everything similar to what NAT does.
After which, you have a question, how can you configure end-to-end connectivity securely?, which host(s) do you open up ports towards?
You don't have good end-to-end connectivity with NAT, right?
With CG-NAT my IP address is the same one that infected computers are using, so I'm often treated like a second class citizen on the internet.
> You don't have good end-to-end connectivity with NAT, right?
I do, I have a public IPv4 that I manage as I wish. Open ports on firewall and forward where needed. No issues so far.
> With CG-NAT my IP address is the same one that infected computers are using, so I'm often treated like a second class citizen on the internet.
Where are you from and what provider are you using?
That is just a crappy provider, you should switch to competition and get a separate IP with no CG-NAT. (never had CG-NAT on home connection, although I avoided providers that did that)
If you're a student in a uni campus/dorms you won't really have an option and it is what it is, it used to be CG-NAT 15-20 years ago too. Even with IPv6 they'd likely firewall everything off and the range would have bad reputation.
> A router could auto-block an IPv6 address that's been in use too long, with a whitelist for servers.
So… I’m not saying you don’t want to do that, but I do want to expand on this a bit:
4941 is not the only way to avoid having your MAC address in your IPv6 address. In fact RFC 3972 (from 2005! Almost old enough to buy beer!) describes a method for stable “cryptographic” addresses which enable the host to attest to the address’s authenticity in ND. That’s a really powerful feature because it means that another host can’t impersonate you like they can with ARP on v4. RFC 3972 is what macOS uses for the “non temporary” address (the one ifconfig labels “secured”). One of the things everyone should know about 3972 addresses is that a host will generate different addresses on different prefixes (so you can’t correlate a host moving between networks like you could with a MAC-derived address).
It is expected and normal that a host should have at least two “non temporary” addresses: a link local one, plus one generated by 3972 (or DHCPv6 or some other mechanism), in addition to one or more 4941 temporary addresses.
One way to block MAC-derived addresses without breaking e2e connectivity is to add a firewall rule blocking addresses with “FFFE” in the middle.
> NAT and hide all these devices behind a single external IP.
If/when I'm forced to shift my LAN to IPv6, this is the approach I'll take. I don't want any random machines behind my router to be able to open ports to the internet at large. I want a single point of presence that handles that and forwards to whichever machine I want to handle that traffic.
For those who are excited about IPv6, I hear you and your use cases are legit. I just don't share them and want the most restrictive network setup that I can tolerate.
> I don't want any random machines behind my router to be able to open ports to the internet at large.
The solution to this is a firewall, not NAT. As has always been.
NAT is not a security feature and never has been. The fact that it blocks uninitiated inbound connectivity is an implementation detail, not its purpose.
Firewalls don’t fail safe, NAT does.
With a disabled/broken/misconfigured firewall, there is a good chance that everything works sans security. With a disabled/broken/misconfigured NAT, you may as well have unplugged the ethernet cable
Or allowed one of the many NAT-busting methods to connect through.
> NAT is not a security feature and never has been.
True, and I don't think of it as such -- after all, NAT or not, it's my firewall doing the protecting. What NAT would buy me here is convenience, not security.
I could have the same level of security without NAT, but managing it properly is easier and less error-prone with it.
Having managed both, it is absolutely, 100%, not easier to manage NAT than a firewall. For example, here's a valid OpenBSD pf configuration:
That's it. That's the entire stateful firewall config: Don't allow anything inbound at all, except directly in response to an outbound connection.If your firewall has a GUI, it'll be as easy to configure that as it is the NAT. If your firewall has a CLI, I guarantee there's no NAT in the world that's easier to configure than the above stateful firewall.
Well, it's not quite that simple given my LAN's topology -- but you're right that it isn't incredibly complicated. I just prefer to manage it a different way. The end result is the same, so I'm not sure what the issue is here.
Depending on your threat level and exact firewall configuration, any bidirectional connection can be used to punch through in some way.
It doesn't even do that much. NAT is something you apply to outbound connections, not to inbound ones. Unless there's a firewall blocking it, you can connect inwards over a router that's NATing its outbound connections.
> I don't want any random machines behind my router to be able to open ports to the internet at large.
While it's hypothetically possible to have NAT without a firewall, I've never personally touched or seen such a thing. I can confidently state that if you have NAT, you also have a firewall. Use it.
Because of NAT ALGs, most consumer NAT devices actually allow plaintext protocols to bypass the internet-facing firewalls inside routers.
Unless you program your own ALGs, you basically get to pick between "SIP, FTP, and a bunch of other protocols don't work without port forwards" or "your public firewall is off for almost anyone who can make your computer load an ad".
NAT breaks internet protocols and as a result we got firewall-evading workarounds.
> "SIP, FTP, and a bunch of other protocols don't work without port forwards"
Do you really want to open SIP/FTP to a bunch of random devices on your network?, that's just extra attack surface and stuff that needs to be kept up to date and secure when you might not even be able to control them
1:1 NAT or floating IPs. I've only ever seen those to simplify server setups where a subset of servers need a public IP
I never said a thing about not using a firewall. My firewall is what protects my LAN, after all.
Then you’re not getting any extra protection from a NAT.
True! I wasn't claiming that I was. What I am claiming is that doing it this way is more convenient for me.
Since IPv6 doesn't give any benefits that matter to me, the only reason I'd do it is to maintain the ability to talk to my ISP. So my goal would be to make the transition as quick and easy for me as possible.
NAT is actually less restrictive for inbound connections, because it allows people to connect with just the correct port and not the correct IP+port. Instead of needing to provide the correct 80-bit number to connect, they only need the correct 16-bit number, which is small enough to brute-force.
NAT doesn't even stop machines opening ports; it's your firewall doing that. It's not NAT giving you a single point of presence, that's your router. It doesn't normally restrict outbound connections either, so what's the point? All it's doing is presenting your servers in a way that makes them easier to find.
NAT doesn't do any of the things you've claimed to need it for.
Since every IPv6 discussion on HN has to repeat this misunderstanding, I'll just link to what I posted last time: https://news.ycombinator.com/item?id=39997078
What misunderstanding? I am familiar with what you wrote, and am not disagreeing. There is nuance here that seems to get lost whenever this topic comes up.
The misunderstanding that "I don't want any random machines behind my router to be able to open ports to the internet at large. I want a single point of presence that handles that and forwards to whichever machine I want to handle that traffic." is something that happens with v4 and not with v6, or that it has anything at all to do with NAT.
I wasn't suffering under that misunderstanding. I was just saying what my personal preference is for managing such a setup.
>Quick solution would be DHCPv6 so they don't have a choice in what address they use.
Android doesn't support DHCPv6.
https://issuetracker.google.com/issues/36949085
I think the real question is "what the hell IoT is doing on a globally-routable network?" Put it on an isolated VLAN with no Internet connectivity. Or a minimal connectivity only to what's absolutely necessary (e.g. I haven't seen IoT devices that need inbound connections, so drop any inbound packets unless conntrack says otherwise). There there will be probably no need for weird NAT66 contraptions or anything like that - just old good plain drop-by-default firewall.
But then, the article is about consumer tech, and most consumers aren't gonna set up any VLANs, firewalls or complex NAT systems, they don't know anything about those. They got one single flat WiFi network and that's about it. So, I guess, all the technical suggestions here are not really relevant.
> Put it on an isolated VLAN with no Internet connectivity.
It's hardly an Internet of Things if your Things aren't connected to the Internet :p
From the very first paragraph of Wikipedia's article on IoT:
> "Internet of things" has been considered a misnomer because devices do not need to be connected to the public internet; they only need to be connected to a network[6] and be individually addressable.[7][8]
I just use ipv4 in my network.
it's my personal network (and my personal opinion/solution).
I turn off ipv6. I don't want to maintain two sets of firewall rules, or have some weird routing problem that lets packets in or out.
I add this to my linux kernel command line:
sometimes in /etc/sysctl.d/00-nov6.conf: in macos I do: helps me be more organized.I'm wondering what are you referring to when you mention NAT in the context of IPv6. I thought there is no widely adopted implementation.
Nothing is preventing you from doing NAT in IPv6. There is the Unique Local Address[0] range which is analogous to the RFC-1918 addresses from IPv4. That being said, there are very few reasons to do this in IPv6 (the only that comes to my mind is running virtual machines on a laptop connected via wifi).
[0] https://en.wikipedia.org/wiki/Unique_local_address
You can easily enable IPv6 masquerading on openwrt and linux in general:
https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6
This has been available for a long time.
You can also do static NAT and anything that you were used to on IPv4.
> Going even further, NAT
Yup, and having lost any and all reasons to use IPv6, go back to what has already been working just fine: IPv4
CG-NAT really isn't great.
Everytime IPv6 comes up there's back and forth on NAT vs firewall etc etc.
That's easy. IPv6 has more flexibility. You do what you want and leave everyone else to do what they want. Networking stuff will break sure, but hasn't it always...
I haven't gone to IPv6 at home because working with an IPv6 string is so much harder.
I can't always copy'n'paste addresses. I often shout/phone an address to someone else to type in. And talking to 3rd parties (ISP , anyone controlling outside WAN) etc IPv4 is a known quantity.
It's that chicken vs egg problem. I don't want to touch IPv6 at home until other admins have figured out how to make this easy.
> I haven't gone to IPv6 at home because working with an IPv6 string is so much harder.
Setup DNS, configure something mdns based like Avahi, or use the hosts file.
> I can't always copy'n'paste addresses. I often shout/phone an address to someone else to type in.
This is weird and not a normal need on a well-run network, or if you have the above working.
So uh, this seems to imply that ISP rotating ipv6 prefix is "obvious", but uh. Really? I don't think I've ever seen this implemented willingly (many have dynamic allocation, but it's changing so slowly that it looks more like a bug than a feature). Does some people have other experience?
I was wondering what kind of IoT could be widespread enough to pose a significant problem or if it was rather statistical, but they mention TVs. And uh yeah, TVs during their lifetime discuss with a huge range of providers, so this indeed broadcasts to
The privacy handling of the article writing isn't great imo. Only an ISP should have access to those data, not external researchers. I even fail to see how it can be GPDR compliant. That being said, operators won't spontaneously write those articles, so well, this one is usefl.
Overall this is an interesting article. I think ISPs doing prefix rotations can easily detect devices and warn the user and/or isolate the bad device (through symmetric NAT for instance -- I think this is an okay compromise, it's not a horrible hack), which this article shines light on. Cool.
My ISP assign changes the IPv4 /32 and IPv6 prefix every PPPoE authentication. This is so annoying and breaks routing every couple days or so that I ended up running NPT (NAT for IPv6) and using a ULA block for my LAN.
I've seen reports saying you can request a specific prefix as hints to Prefix Delegation and it keeps it mostly static but it is not guaranteed.
I'm a little confused why you would need NPT to resolve this? Why not just create a separate local prefix for your local networking needs? Unless you mean something else by "breaks routing"?
Let's say you get delegated prefix abcd::/64, and you distribute it in your LAN with DHCP.
Now, every PPPoE authentication gets you a different prefix, so if your PPPoE session gets dropped somehow, the clients in the LAN won't get the new IPv6 address until the next DHCP renewal.
In this case, let's say the PPPoE session got dropped, and you got a new delegated prefix of dcba::/64. Your client's IP still has the abcd:: IP, while the router now only knows how to route the dcba:: prefix.
The only way I found to make it work is to give clients a ULA prefix and NPT the ULA with the dynamic delegated prefix from my ISP.
> this seems to imply that ISP rotating ipv6 prefix is "obvious", but uh. Really?
Please no. That would mean constantly having to check PD and updating DNS, wireguard endpoints, etc. accordingly.
ISPs charging extra for a static IP seem to rotate IPv6 prefixes. It's just a scam to squeeze a little bit of extra money out of their customers.
Ipv6 is a lot like a bios update - best avoided unless absolutely necessary. Potential mess with no upsides for end users.
And by that analogy, the previous BIOS version was released in 1981, and modern networking is hamstrung by its design which assumed "4 billion addresses ought to be enough for anybody" and that it needed to be manageable by an 8-bit OS with 64KB of RAM.
IPv4 is a brilliant protocol for having been published 43 years ago. There aren't a whole lot of technologies that old still widely used. I mean, I'm glad my NVMe drive doesn't have to shove bits through an ST412 interface.
While I had an "ST412 reference" on my bingo card yesterday morning, sadly I do not have it today. Opportunity lost.
> And by that analogy, the previous BIOS version was released in 1981, and modern networking is hamstrung by its design which assumed "4 billion addresses ought to be enough for anybody" and that it needed to be manageable by an 8-bit OS with 64KB of RAM.
I'm not sure if it makes the analogy better or worse, but this is what happened; BIOS was born in ~1981 (I think), had severe shortcomings that were partially mitigated over time but you can only mitigate so much, UEFI is a better replacement, BIOS->UEFI was a somewhat rocky migration, that migration was made worse by extra stuff getting bundled in (secure boot), and this led to a significant chunk of the population deliberately avoiding it at least for a while. The only real difference is that UEFI has long since become standard, while IPv6 is still fighting for adoption.
Fighting for adoption? The majority of Internet traffic is now IPv6 and we're almost starting to see eyeball networks without any IPv4 at all, so I hope your boss is aware you're blocking potential customers from visiting your website.
I really wanted to disagree with you but sadly that's how it was treated in secure environments a few years ago: "ipv6.disable=1". Everything that's not in needed would be disabled. Nobody wanted to be the first to "need it" and learn all that stuff, if it works with ipv4, stick with it.
Sure, one can figure out the split DNS, tunneling/no tunneling, DHCPv6, multiple addresses per interface, additional filtering rules, or just you know "ipv6.disable=1" and worry about in a few more years perhaps.
I suspect you haven't read the errata sheets for any modern EFI or even worse BMC? There is so much buggy crap in there that users are likely to run into that patching your firmware is a good idea just for stability and performance before you even consider integrity and privacy.
This is the main reason we did not support IPv6 at Winston.
You went with IPv4-only because users with IoT devices could reduce IPv6 privacy back to the trackability of IPv4? That seems rather counter productive to me.
"Our results show that IoT devices contribute the most to this privacy leakage"
I didn't read the paper. For anyone who did: How would that work exactly? It looks like the general problem is that an IoT device can use SLAAC and its MAC to generate an address like `prefix1::87:65:43:21`. Then the household's prefix can change and the IoT device can create a new address with the same local portion, like `prefix2::87:65:43:21`. Then an attacker could see that `prefix1` and `prefix2` are very likely to have been used by the same person.
How would an attacker get that information? If the IoT device is janky and malicious it could ping a bunch of malicious websites and wait for me to access them, I suppose. What would that give an attacker? It's not clear to me how that'd be worse than, say, the current IPv4 situation. And if the device is compromised and no firewall is blocking its outbound Internet access, there are other things I'd be more worried about.
If Amazon or Google make the device, then it could just report that back directly to them whenever its Alexa or Google Home bridge reports back. Their logs would show that "bridge 0x1234 connected from `prefix1::` yesterday, and `prefix2::` today, and it's owned by user kstrauser". I don't think anything in this paper could make it less private than that, surely?
It's like they say: the "S" in IoT stands for security.
Good old Internet of Things that shouldn't be on the Internet.
[flagged]