NAT/PAT as a standard is very limited in its ability to protect against incoming messages. They can not log errors, they do not process unknown responses, they do not process unknown ‘responses’ that are really attacks. No verification that incoming messages have valid formats, minimal or no handling of DoS. Some configurations (NAT without PAT) will intentionally and directly expose all ports on an internal machine to the outside world. And even from an obscurity perspective, it is trivial (and standard!) for servers to be able to distinguish between and identify different machines inside of a NAT/PAT network.
In practice, it should and common home implementations will provide at least some obscurity, but bad firmware and software configuration has and will continue to leave incoming ports open. Even best-case implementations only provide similar protection as a limited (incoming-only) packet filter, which is really not enough protection for the average system. You should always run a stateful firewall—and once you have a stateful firewall, NAT/PAT can not provide excess security. If you absolutely can’t have a firewall, then NAT/PAT is better than nothing… but it’s still not very good or even good enough.
IPv6 does have unique local addresses and a NAT-like feature called NPT, which may be the sort of thing you’re thinking about. But it does so by avoiding many of the worst issues of NAT/PAT configurations, and it does so for ease-of-configuration and ease-of-transfer purposes, with security falling to the security-focused tools.
NAT/PAT does provide some utility, both in that most (good) NAT/PAT implementations at least give default-deny behavior and it makes configuring a network easier. But there are a huge number of resulting issues. The problem is that there isn’t a distinction between “internal networks” and “public servers” or between “public servers” and home machines. They’re not merely a bad metaphor, but an actively misleading one. The internet /requires/ all devices be addressable. If your home machine can access any website, it does so by making itself distinguishable from others on the same internal network and leaving itself exposed to return messages.
NAT works well enough in a www-focused environment—TCP, short connection duration, limited number of expected simultaneous applications, at least one machine not behind NAT—but that’s not all or even most of the internet. Long-lasting connections, ‘connectionless’ messages, any sort of serve-from-home configuration, all require fairly complicated work-arounds.
It’s not merely forced folk to go up one abstraction layer, but to go to some vastly suboptimal designs. Connection-oriented protocols like TCP aren’t very good solutions when latency matters, or where you’re expecting to send only short messages—but they’re essentially required for any ‘server’-to-‘host’ communication. Heartbeat messages should be much more specialized than they currently are: they’re common because the typical NAT/PAT will drop a connection mapping if you take long at all. Middleware servers and psuedo-VPNs like Hamachi are about the worst possible way to handle secure communications between ‘internal networks’, but they’re an industry because NAT/PAT makes full configuration of sane tools very complicated. And the less said about STUN or uPNP, the better.
NAT/PAT as a standard is very limited in its ability to protect against incoming messages.
Of course, since it’s not its function. Firewalls exist for a reason.
The problem is that there isn’t a distinction between “internal networks” and “public servers” or between “public servers” and home machines. They’re not merely a bad metaphor, but an actively misleading one.
I disagree. “Home machine” is a silly name which doesn’t mean much, but the distinction between internal networks and public servers is rather obvious to me.
The internet /requires/ all devices be addressable.
No, I don’t think it does. IP protocol requires an IP address, but that’s not the same thing as requiring devices be addressable. Network bridges and intrusion-detection boxes, for example, are devices that are commonly set up as non-addressable.
If your home machine can access any website, it does so by making itself distinguishable from others on the same internal network and leaving itself exposed to return messages.
Let’s leave home machines out of it and talk about boxes on an internal LAN. The mapping between IP addresses and machines can be established by middleware and doesn’t have to be long-term or permanent. In some cases (e.g. VMs, high availability environments) the end point of a connection can change without the public server being aware of anything at all.
NAT/PAT as a standard is very limited in its ability to protect against incoming messages. They can not log errors, they do not process unknown responses, they do not process unknown ‘responses’ that are really attacks. No verification that incoming messages have valid formats, minimal or no handling of DoS. Some configurations (NAT without PAT) will intentionally and directly expose all ports on an internal machine to the outside world. And even from an obscurity perspective, it is trivial (and standard!) for servers to be able to distinguish between and identify different machines inside of a NAT/PAT network.
In practice, it should and common home implementations will provide at least some obscurity, but bad firmware and software configuration has and will continue to leave incoming ports open. Even best-case implementations only provide similar protection as a limited (incoming-only) packet filter, which is really not enough protection for the average system. You should always run a stateful firewall—and once you have a stateful firewall, NAT/PAT can not provide excess security. If you absolutely can’t have a firewall, then NAT/PAT is better than nothing… but it’s still not very good or even good enough.
IPv6 does have unique local addresses and a NAT-like feature called NPT, which may be the sort of thing you’re thinking about. But it does so by avoiding many of the worst issues of NAT/PAT configurations, and it does so for ease-of-configuration and ease-of-transfer purposes, with security falling to the security-focused tools.
NAT/PAT does provide some utility, both in that most (good) NAT/PAT implementations at least give default-deny behavior and it makes configuring a network easier. But there are a huge number of resulting issues. The problem is that there isn’t a distinction between “internal networks” and “public servers” or between “public servers” and home machines. They’re not merely a bad metaphor, but an actively misleading one. The internet /requires/ all devices be addressable. If your home machine can access any website, it does so by making itself distinguishable from others on the same internal network and leaving itself exposed to return messages.
NAT works well enough in a www-focused environment—TCP, short connection duration, limited number of expected simultaneous applications, at least one machine not behind NAT—but that’s not all or even most of the internet. Long-lasting connections, ‘connectionless’ messages, any sort of serve-from-home configuration, all require fairly complicated work-arounds.
It’s not merely forced folk to go up one abstraction layer, but to go to some vastly suboptimal designs. Connection-oriented protocols like TCP aren’t very good solutions when latency matters, or where you’re expecting to send only short messages—but they’re essentially required for any ‘server’-to-‘host’ communication. Heartbeat messages should be much more specialized than they currently are: they’re common because the typical NAT/PAT will drop a connection mapping if you take long at all. Middleware servers and psuedo-VPNs like Hamachi are about the worst possible way to handle secure communications between ‘internal networks’, but they’re an industry because NAT/PAT makes full configuration of sane tools very complicated. And the less said about STUN or uPNP, the better.
Of course, since it’s not its function. Firewalls exist for a reason.
I disagree. “Home machine” is a silly name which doesn’t mean much, but the distinction between internal networks and public servers is rather obvious to me.
No, I don’t think it does. IP protocol requires an IP address, but that’s not the same thing as requiring devices be addressable. Network bridges and intrusion-detection boxes, for example, are devices that are commonly set up as non-addressable.
Let’s leave home machines out of it and talk about boxes on an internal LAN. The mapping between IP addresses and machines can be established by middleware and doesn’t have to be long-term or permanent. In some cases (e.g. VMs, high availability environments) the end point of a connection can change without the public server being aware of anything at all.