> On Nov 20, 2021, at 19:47 , Joe Maimon <jmai...@jmaimon.com> wrote:
>
>
>
> Owen DeLong via NANOG wrote:
>
> (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
