Read the Data Communications article they provided:
PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
And what about hosts that should be recognizable from the Internet, such as mail servers? These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is config- ured to map one of the external addresses to the device not just for the duration of an application session but on a permanent basis.
At some point you're going to have to find a way to argue that the Cisco PIX was not a security device; again: it was the flagship product of the security SBU.
I was there at the time, doing IP network engineering (for a Chicagoland ISP). The PIX was a security device, and NAT was understood as a security feature (for sure, also an address depletion feature, but the argument that's being made in the post isn't merely that it was an address depletion thing, but also that it categorically wasn't a security feature, which is just obviously false.)
> At some point you're going to have to find a way to argue that the Cisco PIX was not a security device...
What? It's a firewall that can do NAT. The PIX is clearly a security device. NAT is clearly an address-depletion-mitigation technique.
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
Right. And you can achieve the exact same effect with a firewall on an edge router or on a host. I get that firewalls might have been much less common thirty-ish years ago and that doing packet filtering might have been pretty novel for many, leading folks to get confused when they encountered a combination firewall+NAT device.
I'm not sure I can be any clearer about the fact that NAT is both a security feature and an address management feature. I feel like people who weren't practitioners are the time are trying to reason axiomatically that every feature fits into precisely one bucket, or that a security feature isn't a true security feature if it can be replaced by one or more other "cleaner" security features. None of that is true. Practitioners at the time were not confused.
"You can achieve the same effect" doesn't mean anything in this discussion. If that's your argument, you've conceded the debate.
It's a security feature in the same way that a power-cut switch is a security feature. A power-cut switch's purpose is cut power to a machine so that it can -say- be safely worked on or relocated (or simply to not draw power when the machine's not in use), the machine also happens to be inaccessible while its power is cut.
Sure. It's not technically a lie to call a power-cut switch a security feature for most pieces of kit. I'd still laugh at the salesman that made the assertion. If I were feeling particularly cunty, I'd ask him if he injured himself from that great big stretch.
I can't emphasize enough how much of a retcon it is to say "it's not technically a lie" that NAT is a security feature. It was deployed in hundreds of networks specifically as a security feature, and it is part of the security posture of hundreds of thousands of home networks today. People who say "NAT isn't a security feature" are simply wrong.
There are lots of security features I personally don't like either. I don't claim they're not security features; I say they're bad security features.
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
This is a security feature ad, nothing else. And it’s 100% because of NAT, not anything else in the PIX feature set.
That came up earlier and I know it's a gray area but I agree with the idea that a line tossed into the marketing and not backed up by the manual weakens the importance. The firewall in the PIX is the security workhorse.
Also that sentence implies you can get a connection to a device, you just know less about which one it is. Is that really a meaningful security feature? To the extent that connections are actually blocked, it's not because of the NAT scrambling they quoted in the first half of that sentence. That sentence is somewhere between unhelpful and flat-out wrong.
...okay? I didn't say you can. I said that line in the marketing implies you can, as part of how it's wrong.
If that wrong line in the marketing is the strongest evidence for NAT being initially understood as a security feature, that's very weak evidence for the pile.
(If the way I worded things needs more clarification, let me try to elaborate. There is a way in which NAT would prevent the connection, but that aspect of NAT is not what the marketing sentence talked about. It incorrectly talked about a different aspect of NAT. While there could theoretically be a device that uses NAT for protection, this device uses the firewall for protection. Just like basically every other device that can do NAT.)
You've repeatedly re-emphasized your personal claim "this is how it was" while continually refusing to provide any external evidence, yet have the gumption to continue repeating it must be others letting their personal feelings get in the way of looking at what NAT was that leads to the disagreement about the history.
NAT does not care about anyone's personal feelings, one way or the other. Bringing up what you think other's personal feelings are does not help you redefine the original purpose and usage of NAT to be about security.
If you were solely arguing pure NAT could possibly be used today as (or that a few had eventually made poor attempts to use pure NAT as) a way to have better-than-nothing security then I'd agree. Instead you're insisting to rewrite history to make it sound like that's the way NAT was always intended to be used or what it was widely deployed for based on your personal recollection alone, other evidence be damned. If, e.g., the RFC had given more to say about being for security instead of address exhaustion, I highly doubt you would have completely ignored any reference to it in these ~dozen messages.
PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
And what about hosts that should be recognizable from the Internet, such as mail servers? These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is config- ured to map one of the external addresses to the device not just for the duration of an application session but on a permanent basis.
At some point you're going to have to find a way to argue that the Cisco PIX was not a security device; again: it was the flagship product of the security SBU.
I was there at the time, doing IP network engineering (for a Chicagoland ISP). The PIX was a security device, and NAT was understood as a security feature (for sure, also an address depletion feature, but the argument that's being made in the post isn't merely that it was an address depletion thing, but also that it categorically wasn't a security feature, which is just obviously false.)