[HN Gopher] One bad apple can spoil your IPv6 privacy (2022)
___________________________________________________________________
One bad apple can spoil your IPv6 privacy (2022)
Author : whereistimbo
Score : 70 points
Date : 2024-04-26 10:23 UTC (3 days ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| betaby wrote:
| "Our results show that IoT devices contribute the most to this
| privacy leakage"
| ooterness wrote:
| It's like they say: the "S" in IoT stands for security.
| crest wrote:
| Good old Internet of Things that shouldn't be on the
| Internet.
| kstrauser wrote:
| 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?
| adriancr wrote:
| 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)
| szszrk wrote:
| 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.
| adriancr wrote:
| 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.
| craftkiller wrote:
| 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
| kstrauser wrote:
| 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.
| bb88 wrote:
| 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... :)
| kstrauser wrote:
| 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.
| dmitrygr wrote:
| > 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
| bb88 wrote:
| CG-NAT really isn't great.
| JohnFen wrote:
| > 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.
| noinsight wrote:
| > 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.
| JohnFen wrote:
| > 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.
| kstrauser wrote:
| Having managed both, it is absolutely, 100%, _not_ easier
| to manage NAT than a firewall. For example, here 's a
| valid OpenBSD pf configuration: pass out
| on $ext_if from any to any
|
| 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.
| JohnFen wrote:
| 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.
| kiririn wrote:
| 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
| p_l wrote:
| Or allowed one of the many NAT-busting methods to connect
| through.
| Arnavion wrote:
| 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
| JohnFen wrote:
| 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.
| Arnavion wrote:
| 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.
| JohnFen wrote:
| I wasn't suffering under that misunderstanding. I was
| just saying what my personal preference is for managing
| such a setup.
| kstrauser wrote:
| > 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.
| JohnFen wrote:
| I never said a thing about not using a firewall. My
| firewall is what protects my LAN, after all.
| kstrauser wrote:
| Then you're not getting any extra protection from a NAT.
| JohnFen wrote:
| 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.
| jeroenhd wrote:
| 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.
| nijave wrote:
| 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
| drdaeman wrote:
| 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.
| paul_funyun wrote:
| Ipv6 is a lot like a bios update - best avoided unless absolutely
| necessary. Potential mess with no upsides for end users.
| kstrauser wrote:
| 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.
| ibcj wrote:
| While I had an "ST412 reference" on my bingo card yesterday
| morning, sadly I do not have it today. Opportunity lost.
| yjftsjthsd-h wrote:
| > 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.
| crest wrote:
| 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.
| rdtsc wrote:
| 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.
| phh wrote:
| 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.
| cassianoleal wrote:
| > 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.
| rescbr wrote:
| 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.
| yesco wrote:
| 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"?
| jeroenhd wrote:
| 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.
| winstonprivacy wrote:
| This is the main reason we did not support IPv6 at Winston.
| jeroenhd wrote:
| 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.
___________________________________________________________________
(page generated 2024-04-29 23:01 UTC)