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.

Ah, I see what you're driving at.

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.

The PIX evidence above doesn't make it look like a retcon. Do you have something better to show about those hundreds of networks?

> 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.

No, you cannot get a connection to the device. It’s an un-routable block of RFC 1918 addresses.

> No, you cannot get a connection to the device.

...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.)

Im not sure why you’re digging in this way. The marketing material is clearly making security arguments. Whether or not you agree with them is entirely irrelevant because the statement was that NAT was marketed as a security feature.

> Im not sure why you’re digging in this way. The marketing material is clearly making security arguments.

Oh, I see where you're misunderstanding the claim I'm making, continued from what simoncion was saying.

Yes, the marketing is making security arguments. The PIX is a security device as one of its main functions.

The feature that was put in specifically for security is its firewall. The NAT isn't adding anything on top of that, security-wise.

> Whether or not you agree with them is entirely irrelevant because the statement was that NAT was marketed as a security feature.

The original claim is that companies generally saw NAT itself as a security feature. That goes beyond a single incoherent sentence in a piece of marketing about a device that had NAT and a firewall. Again, I accept that the sentence is some evidence for the idea but it's so weak. This is something that happened just a couple decades ago, there should be plenty of evidence of actual decisionmaking.

Also it occurs to me that the phrase "know which machine on the corporate network is using a Class C address" might be talking about NATing entire IPs, every port at once. In which case that's very much not a security feature. NAT like that puts the machine naked on the internet. It's about as secure as having your devices get publicly routable addresses out of DHCP. So if that's what they meant, that sentence is making unjustified claims. Did one easily disproven line in a pamphlet convince an industry?

I don’t know what to tell you dude. Back in 06 as an admin for campuses where more than half of the machines were XP pre service-pack 2, NAT was 100% used as a security feature.

For public WiFi networks and labs where we couldn’t control software on end devices, we put them behind NAT pools purely for security (we still had enough public v4 IPs to give them to printers).

You can hand wave however you want, but back then NAT was used for an easy first level of security.

“There existed a better thing in a pure stateful firewall” is not an argument against people using NAT instead.

"I have personal experience using it that way" is a much better argument than anything you said in previous posts. Thank you for saying that, no sarcasm.

Was there a reason you didn't firewall those devices? I mean, a basic firewall has to do less work to attain the same security, and needs less configuration.