(snips for brevity and reply relevancy)
This is a common fallacy… The real concept here isn’t “universal reachability”, but universal transparent addressing. Policy then decides about reachability.
Think stateful firewall without NAT.
No, NAT is not a firewall. The stateful inspection that NAT depends on is a firewall.
You can do all of the exact same things without needing NAT. You just get additional capabilities without NAT that you didn’t have with NAT due to the limitations of shared addressing.
You an do stateful inspection and reject unwanted packets without having to mutilate the packet header in the process.
Owen
You are completely correct in theory.
However, in IPv4 there is a generally true assumption that there are all these sorts of devices that will be deployed in a somewhat secure fashion and not by virtue of any particular efforts on the part of their manufactures, because they are rarely deployed without a NAT in front of them simply due to address scarcity, where NAT becomes a feature of network functionality and not of network security.
This is a fallacy which has repeatedly been proven false by numerous security researchers. It’s time to educate beyond this silly assertion and recognize that NAT is an obfuscation tool, not a security tool.
They are at least as secure behind a non-NAT stateful firewall as they are behind NAT.
The hope that there will be equivalent pervasiveness of a statefull deny-any layer in front of these classes of devices or that they will be deployed|developed with sufficient/equivalent security without that layer is not nearly as re-assuring.
Virtually all home gateways today ship with a stateful default deny-all policy for IPv6, so it’s not a hope, it’s current reality.
There is hope that manufacturers will eventually start improving security as well, but I agree that depending on that at this stage is rather perilous.
OTOH, it’s also perilous to believe that NAT provides adequate protection for their failures in this arena.
Worse, with the assumption of NAT induced security in place its all too logical to predict and expect that these devices are woefully under-equipped to protect themselves in any way without it.
NAT does not induce security. It induces headaches. It induces difficulties in troubleshooting. It induces difficulties in correlating logs and audit trails. It induces all manner of things that make it harder to address security incidents. It does NOT induce security.
Further, 100% of the alleged or perceived security gains attribute to NAT come from stateful inspection, not NAT itself. As such, no, there’s no need for NAT to have equivalent security even if you just assume a stateful default deny-all in the gateway vs. assuming NAT.
I agree that the idea of producing a home gateway without a stateful default deny-any inbound policy should be (and basically is, frankly) as unrealistic as producing a home gateway for IPv4 without NAT, but once that’s the case (and really, from what I have seen of current market entrants, it is), there’s no meaningful difference in the security level between the two options. The non-NAT option does provide greater choice and freedom in controlling your security and permitting things in, but not significantly more dangerous than current port forwarding setups with NAT.
Best case scenario is that practically all SOHO v6 gateways default configuration is statefull deny-any. In which case all you can hope to get from theoretical E2E is less packet mangling.
That’s already the case from my observations. OpenWRT, Linksys, Netgear, D-Link, Belkin, and several others all default this way already.
(Packet mangling is a good test case for protocols who needlessly commit layering violations by embedding lower layer addressing directly or implicitly into their behavior, so NAT has actually been beneficial in this manner)
If you want to put packet mangling capability into test equipment in SQA environments, by all means, feel free, but it has no useful place in the modern internet once we move forward from restricted addressing.
The security conscious are better off deploying these devices with IPv6 turned off. Much less chance of them accidentally becoming individually responsible for their own protection due to any network changes that may not take their existence or particularly sensitive and vulnerable state into consideration.
We can agree to disagree here. The security conscious are better off deploying these products IPv6-only where they can get proper audit and log correlation with transparent addressing and making sure that the upstream router(s) have adequate protection configured. That’s at least as good as having a NAT upstream, given that a NAPT port forward can be just as dangerous to these devices as a transparent permit.
Further, security track records as they are suggest that security will never become the prime focus or even more than an afterthought for the producers of these classes of devices.
I can’t effectively argue against this, but my hope is that we can eventually arrive at a place where manufacturers face real liability for damages inflicted by the insecurity of these products. Kind of a “unsafe at any bandwidth” equivalent of the “unsafe at any speed” campaign to improve automotive safety and get seatbelt mandates and the like. Much of that happened through product liability law.
We can all wish that were not the case but it would be naive to assume otherwise.
It’s naive to assume it’s otherwise today. I do have hope that real progress will be made in liability laws helping to remedy the situation in the future.
Nothing says “fix your broken security” like a multi-million dollar jury verdict against your unlucky competitor.
Nonetheless, even with that remaining the case, I still believe that a stateful inspection without header mutilation is better security than a NAPT.
Owen