On 2/17/24 11:27 AM, William Herrin wrote:
On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas <mike@mtcc.com> wrote:
I didn't hear about NAT until the late 90's, iirc. I've definitely not heard of Gauntlet. Then there are gaps in your knowledge.
Funny, I don't recall Bellovin and Cheswick's Firewall book discussing NAT. And mine too, since I hadn't heard of "Firewalls and Internet Security: Repelling the Wily Hacker" and have not read it.
I see that the book was published in 1994. In 1994 Gauntlet was calling their process "transparent application layer gateways," not NAT.
What was called NAT in 1994 was stateless 1:1 NAT, where one IP mapped to exactly one IP in both directions. Stateless 1:1 NAT had no impact on security. But that's not the technology we're talking about in 2024. Stateless 1:1 NAT is so obsolete that support was dropped from the Linux kernel a long time ago. That actually caused a problem for me in 2017. I had a use where I wanted 1:1 NAT and wanted to turn off connection tracking so that I could do asymmetric routing through the stateless translators. No go.
So it does not surprise me that a 1994 book on network security would not have discussed NAT. They'd have referred to the comparable contemporary technology, which was "transparent application layer gateways." Those behaved like what we now call NAT but did the job a different way: instead of modifying packets, they terminated the connection and proxied it.
I don't recall the book talking about proxies, but it's been a long time. It was mostly about (stateful) firewalls, iirc. The rapid expansion of the internet caused a huge need for a big band-aid, especially with shitty windows boxes emerging on the net shortly after. A stateful firewall walled off for incoming on client subnets was perfectly sufficient though, and need to provision clients with proxies and the necessary software. The book is not very long and honestly that's a feature as it seemed to mostly be trying to get the word out that we should be protecting ourselves at the borders until better security could get deployed. If NAT's supposed belt and suspenders security was such a big feature, I don't recall anybody talking about it that way back then. That's why it's always seemed like a post-hoc rationalization. When I was at Cisco, all of the internal networks were numbered in public address space and I never once heard any clamor for the client space to be renumbered into RFC 1918 space for security reasons. Admittedly anybody doing so would have faced fierce resistance, but if there were any debate at all it was that adding state to network flows was a Bad Thing. NAT has always been about overloading public IP addresses first and foremost. The supposed security gains are vastly dwarfed by the decrease in functionality that NAT brings with it. One only has to look at the mental gymnastics that goes into filling out SDP announcements for VoIP to know that any supposed security benefits are not worth the trouble that it brings. If it were only security, nobody would have done it. It was always about address conservation first and foremost. Mike