4 ms·
Is there a better way to not unnecessarily leak addressing metadata to adversarial remote nodes and middle boxes? IPv6 with assigning end users a whole /64 and
by mindslight 3y ago
Is there a better way to not unnecessarily leak addressing metadata to adversarial remote nodes and middle boxes?
IPv6 with assigning end users a whole /64 and end-devices continually churning through privacy addresses is a start. But even then some form of NAT is still required to nimbly use source prefixes from different horizon providers - eg to avoid spilling your geographic location or opening yourself up to low-effort legal shakedowns.
An example: on my local network I've got an everyday web browsing VM and a torrent VM. They each have static 192.168.x.x addresses, both so I can ssh in for administration and also to control their view of network services. They each see a completely different Internet horizon through the router - the web browsing goes out from a rotating datacenter IP, and the torrent one goes out from a consumer VPN. Each of those outgoing horizons uses NAT - any of my hosts using that rotating data center IP appears the same, and any of my host using the consumer VPN appears the same as every other customer using that same VPN node.
What is the no-NAT equivalent of this? Make that rotating data center IP and VPN external IP into subnet allocations, somehow feed that addressing information back to the hosts that are using it, and dual-home each VM with two routable addresses? For equivalent mixing on the consumer VPN there would also need to be some ARP-like protocol that let me continually rotate the address.
- jandrese 3y agoWhy not just use a VPN in both cases? That’s more or less what your NAT solution is doing, except without the encryption to the data center.
- mindslight 3y agoIt is a wireguard tunnel to the data center, but my comment was focused on the addressing.
- 3np 3y ago> What is the no-NAT equivalent of this? At least for web-browsing and other HTTP/TCP use-cases: Cut off internet from your hosts and use centralized local proxies for all outgoing connections. Presumably you already have reverse proxies in place for the incoming. There is no need for NAT if all the traffic is taken care of in higher layers. This reduces your consideration to the internet-facing forward- and reverse-proxies only. Sounds like you already have bittorrent figured out via VPN (Wireguard I guess? Well there we have one more UDP exit-point to consider). BTW, I largely agree with your sentiment: Benefit of (especially migrating to) IPv6/DS for individual networks is often unclear or questionable and metadata privacy is a valid consideration where I believe correct solutions are not readily available and understood even by your well-intentioned and seasoned senior admins. Maybe globally the number of people who will get this right ranges in the 1000s? 10,000s if we're lucky? How many networks do we need to migrate again for "IPv4 to die"? I guess the only way forward is for more people to do that migration and share their findings and solutions, though ;)
- mindslight 3y agoThe general ignorance of the privacy benefits of NAT are what I'm reacting against too. It's certainly regrettable that end users are forced into NAT [0], but since then a shameless surveillance industry has cropped up, looking to exploit every bit of identifying information that it can. And it seems that calls for native IPv6 with everything having its own distinct address generally just ignore the practical privacy implications. It certainly seems possible to get a NAT-equivalent privacy from properly set up SLAAC. Although a sibling comment says that the proposal for variable length prefixes was just submitted this year?!? Equivalent privacy would also require things like consumer VPN providers allowing you to request a few new addresses every few minutes, whereas NAT makes a shared uniform distribution the default. Using a proxy instead of NAT is a good point, although there are certainly reasons I moved towards managing egress flows at the packet level with VMs rather than configuring software to play nice with proxies. And spiritually I would say that a proxy is an even more heavyweight version of NAT one layer up. [0] Although I don't personally think the web would have developed any less centralized without NAT as many people like to imagine