IPv6 uptake (was: The Reg does 240/4)

Sun Feb 18 19:47:19 UTC 2024

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