Live data from Hacker News

IPv6 is not insecure because it lacks a NAT

johnmaguire.me

61–70 of 606 posts

Re: IPv6 is not insecure because it lacks a NAT

#61

Earlier quoted context omitted.

This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.

You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off. Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?

With NAT turned on nana's computer is still protected by the same Arris gateway.

Re: IPv6 is not insecure because it lacks a NAT

#62
post #37

Earlier quoted context omitted.

It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.

The first commercial NAT box was the PIX in 1994, which featured stateful session firewalling (not just NAT) in agreement with the above 1994 RFC. It was still the era of referring to classful networks, but I'm able to source documents from the time which state the opposite of your claims. 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'…

The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.

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.

Re: IPv6 is not insecure because it lacks a NAT

#63
post #38

Earlier quoted context omitted.

But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it. 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 connec…

It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.

Yes, but we've just successfully rewritten the article in the comment section as "it's not having NAT that provides the security itself, but other configuration any sane person would expect on a device doing NAT to prevent unexpected inbound connections" is exactly what the article set out to separate.

Re: IPv6 is not insecure because it lacks a NAT

#64
post #3

> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT. As I keep trying to explain each time this comes up: no, it doesn't and it won't. When your router receives incoming traffic that isn't matched by a NAT state…

[deleted]

Re: IPv6 is not insecure because it lacks a NAT

#65
post #52

Earlier quoted context omitted.

That's not the case at all. You could disable their NAT and they wouldn't lose any protection whatsoever.

Yes, it is the case. In the real world, there are malfunctioning ALGs, permissive defaults, and connectionless protocols that are poorly tracked by these sloppy, underpowered "SPI" devices.

It's not, because in the real world NAT only affects your outbound connections. That means that turning it off only changes the behavior of outbound connections, not inbound ones.

Any inbound connection that would have worked before you turned it off will still work afterwards, and any that wouldn't have worked before will still not work afterwards.

Re: IPv6 is not insecure because it lacks a NAT

#66
post #62

Earlier quoted context omitted.

The first commercial NAT box was the PIX in 1994, which featured stateful session firewalling (not just NAT) in agreement with the above 1994 RFC. It was still the era of referring to classful networks, but I'm able to source documents from the time which state the opposite of your claims. 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'…

The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful. 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…

> The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.

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.

Re: IPv6 is not insecure because it lacks a NAT

#67
post #62

Earlier quoted context omitted.

The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful. 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…

> The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful. 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 i…

The whole point of NAT firewalls is that the devices behind it don't have routable addresses. "Statefulness" improves the situation, but the translation itself provides a material control.

Re: IPv6 is not insecure because it lacks a NAT

#68

Agreed with the main message. ... but An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise. For non-NAT IPv6, s…

Disabled protection does not protect. This is UI/UX thing, not something in Internet-scale protocols. I can "curl https://somethingshady | bash -" but won't blame RFC1738.

Re: IPv6 is not insecure because it lacks a NAT

#69
post #67

Earlier quoted context omitted.

> The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful. 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 i…

The whole point of NAT firewalls is that the devices behind it don't have routable addresses. "Statefulness" improves the situation, but the translation itself provides a material control.

I suppose we fundamentally disagree that it's meaningful or material whether NAT can provide something the stateful firewalling has handled more completely since the first shipping implementation and that this defines what the purpose and introduction of NAT to the market was supposed to be.

Re: IPv6 is not insecure because it lacks a NAT

#70

The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default. This is kind of like writing an argument that motorcycles are not unsafe because they lack 4 wheels. This is true, but if you put my grandmother on one and ask her to drive across t…

France with >85% IPv6 adoption mostly made of grandmothers driving a motorcycles across the town manually delivering packets like in their youth.
Post reply on HN