NAT is an architecture level security hole

NAT is an architecture level security hole
Photo by Sigmund / Unsplash

Back when I made my first connection to the Internet, it was normal to ask for enough addresses to give a public IP to every computer in the organisation (and then some because they could only be allocated on classful octet boundaries). The organisation I worked for ended up with a couple of /16s; over 130,000 IP addresses. If we had stuck with that model, all of our lives would be a lot safer and more secure today.

Things changed. We didn't make the IP address space big enough on the original Internet to continue to allocate IP addresses at that rate. In any case some people argued that the vast majority of computing devices were clients only and it was actually insecure for these to be addressable on the global internet.

Private, non routable IP addresses started being deployed to create islands of connectivity with outbound only NAT to scarce public IP addresses. This broke a whole load of stuff, people said it wasn't "the Internet" anymore, but we worked around it, redesigned protocols or just accepted the breakage. In the end, we forgot how daft it was and NAT became the new normal. One of the arguments was that it was more secure.

Fast forward to today, I'm designing a new energy storage and generation system to improve the efficiency of my home. In order to make remote adaptive changes based on factors like predicted weather and dynamic grid energy cost, it seems the documented way is to use a remote cloud tool provided by the inverter vendor. That means allowing their software, hosted in the cloud, to control hardware in my house. That hardware manages getting on for 100 megajoules of energy.

It is reasonable to theorise that if a bad actor gains access to the cloud systems running on the vendors servers they could probably impact my physical safety by, for example, shutting the hardware down and turning my power off.

Actually that is at the benign end of the spectrum. I haven't analysed the threat in detail, but it seems plausible that with enough knowledge they may actually be able to instruct it to burn my house down. Maybe they could even use it to attack the electricity distribution network to harm my neighbours too.

That's just stupid, but surely it has nothing to do with NAT

What was the technical driver for all of our data and, increasingly, the keys to all of our physical things sitting inside cloud services?  It is NAT. NAT doesn't make it impossible to allow data and API calls to be pushed from other peers on the Internet to individual devices on our internal network, but those islands make it very hard to do in a generic, reliable way.

For IoT vendors, having a million devices contacting and exchanging data via their own cloud services from any and every service provider and firewall vendor in the world probably raises less support tickets than trying to arrange for one trusted peer to peer connection through an arbitrary firewall. NAT normalises cloud services as "easy" - the natural order of things, and peer to peer remote trust relationships as special and "hard". It makes all powerful (and dangerous) centralised cloud services the most sensible, user-friendly and easily supportable architecture choice for consumer devices.

If we could un-invent NAT, I do wonder if vendor cloud services with their dual "have to trust them" and "target on their back" attributes would be much less of a thing and the entire threat landscape consequently much easier to manage.

IPv6 gave us a chance, but it doesn't look like we are taking it.