> This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.)
So ... any distinction between two different things is a single-bit difference and therefore largely theoretical? I am not sure I follow ...
> But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.
Which is the important point, in particular in this context where the common argument essentially is "because I consider dropping packets a function of a NAT, NAT is good to have", where the whole argument only hinges on the definition, not on any real-world facts about network devices.
> Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?
I don't know, I have never investigated that, as I don't tend to use off the shelf network gadgets. However, there is no need to use raw sockets, just install Linux and use the kernel's netfilter, which behaves in exactly that way: If you only configure NAT rules but no filtering rules to prevent inbound connections, your LAN is wide open. And that is not bad design, that is the obvious way to implement this as a matter of separating concerns.
Now, Linux is (was?) a popular OS for off the shelf home routers, and some of them at some point even use(d?) netfilter for their NAT. If you consider what kinds of completely moronic security holes have been and still are being found in those kinds of devices (shell injection in the web interface, trivial buffer overflows, backdoors with hard-coded passwords, ...), that does not make me particularly optimistic that they are careful when putting together the actual network setup on those devices. Not configuring the filtering of inbound connections is exactly the kind of mistake that I would expect to happen in an environment that produces that kind of garbage: Unless you are competent and do invest in quality assurance, that is exactly the kind of problem that noone will notice, as it does not affect day-to-day operation, and noone in the target market will notice if you screw it up because even the supposed experts think that the NAT implies that they are safe.
I suspect other network stacks or even ASICs have similar separation of concerns in order to be usable for a broader market than "home routers", so I suspect you can make the same mistake on other platforms used for implementing home routers.
So, do I know that there are devices out there that do NAT but don't filter? No. Would I be surprised if there were? No, definitely not.
However, if you do away with NAT, that makes it much more likely that a home router lacking a filter wouldn't go unnoticed for long, because it's trivial to check whether it does filter or not. So, it's not only that NAT does not logically imply a firewall and that a firewall does not necessitate NAT, but that not having a NAT makes it actually more likely that your device does in fact have a firewall.
So ... any distinction between two different things is a single-bit difference and therefore largely theoretical? I am not sure I follow ...
> But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.
Which is the important point, in particular in this context where the common argument essentially is "because I consider dropping packets a function of a NAT, NAT is good to have", where the whole argument only hinges on the definition, not on any real-world facts about network devices.
> Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?
I don't know, I have never investigated that, as I don't tend to use off the shelf network gadgets. However, there is no need to use raw sockets, just install Linux and use the kernel's netfilter, which behaves in exactly that way: If you only configure NAT rules but no filtering rules to prevent inbound connections, your LAN is wide open. And that is not bad design, that is the obvious way to implement this as a matter of separating concerns.
Now, Linux is (was?) a popular OS for off the shelf home routers, and some of them at some point even use(d?) netfilter for their NAT. If you consider what kinds of completely moronic security holes have been and still are being found in those kinds of devices (shell injection in the web interface, trivial buffer overflows, backdoors with hard-coded passwords, ...), that does not make me particularly optimistic that they are careful when putting together the actual network setup on those devices. Not configuring the filtering of inbound connections is exactly the kind of mistake that I would expect to happen in an environment that produces that kind of garbage: Unless you are competent and do invest in quality assurance, that is exactly the kind of problem that noone will notice, as it does not affect day-to-day operation, and noone in the target market will notice if you screw it up because even the supposed experts think that the NAT implies that they are safe.
I suspect other network stacks or even ASICs have similar separation of concerns in order to be usable for a broader market than "home routers", so I suspect you can make the same mistake on other platforms used for implementing home routers.
So, do I know that there are devices out there that do NAT but don't filter? No. Would I be surprised if there were? No, definitely not.
However, if you do away with NAT, that makes it much more likely that a home router lacking a filter wouldn't go unnoticed for long, because it's trivial to check whether it does filter or not. So, it's not only that NAT does not logically imply a firewall and that a firewall does not necessitate NAT, but that not having a NAT makes it actually more likely that your device does in fact have a firewall.