Hacker News new | past | comments | ask | show | jobs | submit login

You're trying to piece this together axiomatically, but you can just read the history of the Cisco PIX firewall to see that the story is not as simple as you want it to be. One of the first and clearly the most popular NAT middlebox products of the 1990s was a firewall, and Cisco made a whole big deal about how powerful NAT was as a security feature.



You’re working backwards here from Cisco’s marketing material. Just because someone in Cisco’s marketing team was smart enough to realise they could market NAT as a security feature, doesn’t mean it was designed to be a firewall.

Apple advertises their iPads as “computer replacements”, that doesn’t mean the iPad was originally designed to be a computer replacement, and it certainly doesn’t make iPads a good computer replacement for many people.

I would also highlight that Cisco PIX had a dedicated firewall layer in addition to its NAT layer, which provided much more capabilities than the NAT layer alone. The fact that these two layers intelligently built on each other is just good implementation engineering, it doesn’t change the fundamental fact that NAT isn’t, and never has been, a proper security tool.


I'm working forwards from my experience at the time as a security engineer working with products that claimed NAT was a security feature, since it allowed for machines to access the Internet without being routable from the Internet for initiated connections, which is why the first commercial PIX product, after Cisco bought Network Translation (which named PIX), was a firewall.

People confuse the fact that NAT is not an especially powerful or coherent security feature with the idea that it isn't a security feature, which leads you to the crazy rhetorical position of having to argue that PIX, the first mainstream NAT product, was not a security product. I have friends who worked on PIX, for many years. I assure you: they were in the Security BU.

I think this position is pretty hopeless, though if you want to drag us around through the network security marketing of the mid-1990s, I'm happy to do so, just for nostalgia's sake. NAT is absolutely a security feature, and was originally deployed as one, in an era where it was still feasible to get routable allocations for individual workstations.


> NAT was a security feature, since it allowed for machines to access the Internet without being routable from the Internet for initiated connections

I'm sure you also know, that any stateful firewall can achieve the same result without having to provide NAT capabilities. Sure Cisco PIX may have been a security appliance, but that doesn't make NAT's a firewall. You don't need Network Address Translation to create a firewall that allows devices to connect to the internet, but makes those machines unrouteable to unsolicited requests. For your claim that NATs are meant to be a firewall, you need to provide an explanation as to why we don't use NATs with IPv6.

Why would increasing the IP address space so that it's once again possible to get routable allocation for indivual workstations, result in people not deploying IPv6 NATs, when apparently they're an important security tool for IPv4, in even in the days when "it was still feasible to get routable allocations for individual workstations"?


Now you're arguing that NAT isn't a good security feature. We agree. There's no reason for us to drill for things to disagree about.


No I’m arguing that NAT isn't a security feature, and wasn’t meant to be a security feature. The fact people sold it as a security feature, and the fact that it might incidentally behave like a poor firewall, doesn’t change the fact that NAT isn’t and never was meant to be a security feature, good or bad.


I feel like I've provided black-letter proof that it was meant to be a security feature; the commercial product of its inventor was a firewall that advertised NAT as a security feature. I don't really understand how you can argue around that.

Nobody's reading this thread anymore, so why don't we leave our arguments where they stand.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: