On 2/17/24 11:27 AM, William Herrin wrote:
On Sat, Feb 17, 2024 at 10:34 AM Michael Thomas <m...@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
