(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
Here's an ad for it from Jan 1995 https://www.jma.com/The_History_of_the_PIX_Firewall/NTI_file.... Note by the 3rd paragraph it's saying
> corporate networkers are free to expand and reconfigure their TCP/IP networks without agonizing over the much publicized IP addressing crunch. It also spares them from having to upgrade all of their host and router software to run IP version 6
It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:
> 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 configured to map one of these external addresses to the device not just for the duration of the application session but on a permanent basis.
Looking past the marketing line and reading the manual, the reality was the PIX was always acting as a full stateful firewall and did not just rely on NAT itself to provide the inbound filtering. See the "PIX Firewall Adaptive Security" section on page 2 of this 1996 manual I managed to dig up as reference https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/.... Rule hits that missed a state match were even loggable (what a box for the time!)
Whether people saw the marketing and assumed it was NAT that provided security is precisely the bad assumption the article talks to, but at no point in history was NAT prevalent without being paired with a normal stateful firewall to provide the security - since the intent of NAT was not to fill that role, even in the beginning, as sourced by 3 references now vs your personal claims.
The point is that NAT was introduced as a kind of firewall. The PIX firewall was named by Network Translation, Inc., which was acquired as a security device --- and, indeed, the PIX was for many years the flagship security brand at Cisco.
I don't dispute that NAT is dispensable (though: dispensing with it in millions of residential prem deployments is another story altogether!), only that it's "not a security tool" --- it clearly is one, and a meaningful one (whether network snoots like it or not) in a huge number of networks.
That's not the distinction I, or TFA, set out to make.
It's not that NAT is a component of controls that could be replaced by others, it's that whether NAT was put in place for security or if it was always assumed you need an actual stateful firewall precisely because NAT was never intended or believed to provide meaningful security, even in the days of classful networking.
Not one of the references above makes claim that NAT was intended to provide security on its own. That the PIX launched with actual firewalling capabilities does not bolster that NAT=security, it actually bolsters that NAT was never believed or intended to provide security even further.
To turn this back around at you: The distinction you're drawing that NAT could have provided "something better than nothing" in terms of security if appliances like the PIX hadn't always shipped firewalling from day 1 isn't meaningful.
Network administrators (less so security engineers) don't want NAT to be a security feature, so they've retconned a principle of security engineering that doesn't exist. If people were honest about it and just said they'd prefer to work on networks where less distortive middlebox features provide the same security controls, I'd have nothing to argue about.
But this article makes the claim that "NAT isn’t actually a security feature". That's simply false. People need to stop rebroadcasting this canard.
What some people do or don't want in the 2020s has no relevance to the reasoning in the 1990s, nor does it redefine the purpose or use of NAT the same. The above is clearly and directly stated from the sourced material of the era itself: NAT was introduced in the mid 90s due to concerns about address space depletion and the need to move to IPv6. The security features of said introductory appliance never came from or were supposed to come from implementing NAT, but from implementing stateful firewalling and blocking inbound connections. There is no personal opinion or retconning in any of this, they aren't even the postings of anyone from this century.
I don't see where they do. I see them talking almost exclusively about working around address depletion.
Hell, look at Cisco's press release for its acquisition of Network Translation, Inc. [0] It's all about address depletion and resource efficiency; security is mentioned as an afterthought. I'll quote the relevant paragraphs (and leave in the line break mangling present in the original).
SAN JOSE, Calif., October 27, 1995 - Cisco Systems Inc. today announced anagreement to purchase privately-held Network Translation, Inc. (NTI), anetworking manufacturer of cost-effective, low maintenance network addresstranslation (NAT) and Internet firewall equipment. The investment isintended to broaden Cisco's offerings for security conscious networkadministrators who want to dynamically map between reusable private networkaddresses and globally unique, registered Internet addresses. Through itsacquisition, Cisco will gain NTI's Private Internet Exchange (PIX) solutionwhich helps network administrators resolve their growing need forregistered IP address space. NTI's 10 employees and products will beincorporated into Cisco's Business Development efforts reporting to VicePresident Ed Kozel. The financial terms of the purchase are not beingdisclosed. The transaction is expected to close by the end of November andis not subject to the Hart-Scott-Rodino filing.
The NTI investment is the second action by Cisco in recent months tostrengthen its expertise in resource-effective Internet access technology.NTI technology will interoperate with and integrate several functions ofthe Cisco Internetwork OperatingSystem(tm) (Cisco IOS) software,facilitating use throughout the enterprise. NTI addresses two of the morecompelling problems facing the IP Internet -- IP address depletion andInternet security. Customers using the NATalgorithm can take advantage ofa larger than assigned pool of addresses. NAT makes it possible to useeither your existing IP addresses or the addresses set aside in InternetAssigned Number Authority's (IANA) reserve pool (RFC 1597). Cisco's goal ofintegrating NTI's technology and personnel is to ease the complexity ofInternet access for applications including telecommuting and World Wide Webaccess.
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.)
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.
"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.
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.
This is a security feature ad, nothing else. And it’s 100% because of NAT, not anything else in the PIX feature set.
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.)
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?
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.
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.
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.
My first cable modem did not have a NAT, nor did my first ADSL modem. You'd use "Internet Connection Sharing" on Windows 98 SE to share the internet connection on your LAN. And you'd get badly hacked, and then also install a firewall. Sygate had a firewall and NAT combined. (Or, you'd use linux - and also get badly hacked, but for different reasons.)
As a response, ISPs started to ship modems with built-in NATs. They did not start to ship what we now call routers (modem+NAT) because they wanted to encourage people to share their internet connections out of the goodness of their hearts. They'd prefer to sell more cablemodems, or dial-up. They started shipping (NATted!) routers because it saved them a lot of support calls from hacked (and disconnected) customers. Instead they got support calls about port-forwarding, so uPnP was the next hot feature.
Was NAT originally intended to be a firewall? No. Did it effectively protect many innocents? It did. Is it still needed as an additional layer of security-through-side-effects? Let's hope not.
Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules.
So there is nothing about a lack of NAT in IPv6 that makes it less secure.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
> If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
This is generally going to be true, but it's not relevant to how NAT behaves when it receives inbound connections.
I recommend you setup a basic iptables NAT set of rules on linux to reflect what a home router does (masquerade) with ip forwarding enabled.
The inbound packets from the internet are to a public IP that belongs to the device performing NAT. If there is no entry in the conntrack table from a connection to translate that public IP to a private IP, there is nowhere it can be forwarded to. It’s already at the device that owns that destination IP.
Even if it spit the packet out a private interface (which makes no sense given the routing table), the destination IP would be a public IP that both cannot be ARPed for on the local network and will not be honored by any private device.
I think it's someone else's turn to do the test now.
> The inbound packets from the internet are to a public IP that belongs to the device performing NAT.
If the inbound packets are addressed to the router, they get delivered to the router. But you cannot just declare that that's where they'll be addressed. You aren't in control of what packets show up to your router, you're only in control of how you process them after they show up.
What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
> What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
Yep. It also happens when NAT is enabled. A router doing NAT is exactly the same thing as an open router -- it just has the additional property of editing outbound connections to appear to come from the IP of the router itself.
If NAT on its own blocked inbound connections, I would have seen that in my tests.