Comment by 1dom
1 month ago
John, your post opens saying it's addressing the point: “the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy.”
Your title is "IPv6 is not insecure because it lacks NAT"
I'm sure anyone who understands how NAT offers the equivalent of a default block rule also understands that the absence of NAT alone doesn't make IPv6 insecure. This makes the title feel a little clickbaity-strawmanny, sorry.
Your response seems to be: "most firewalls have a default block rule too meaning they're no worse than IPv4 w/ NAT."
There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
That doesn't make IPv6 insecure because no NAT. But it does mean - IMO - that the intrinsic block that comes with IPv4 NAT is a better security measure for making devices inaccessible than relying on default firewall rules.
What point are you trying to make here, and is it actually more useful than the point you say you're addressing?
> There's more security to be had in an intrinsic architectural feature
No, there is not. Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense, this claim doesn't make sense. If the invariant is that incoming connections are blocked by default, an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant. If the claim is that a misconfiguration of the gateway can make the system vulnerable, again, the two kinds of firewall configuration are equivalent: you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.
There's no basis for claiming the two schemes differ in the level of security provided.
> an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant
Yes, you're correct, on some level, they are equivalent: in both cases, packets don't reach the target machine. That is one of the few levels on which they are equivalent.
> There's no basis for claiming the two schemes differ in the level of security provided.
Yes there is, this is basic secure architecture and secure by design principals. If you understand these principals, you will understand that the equivalence level you're talking about above leaves space for other security issues to creep in.
> you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.
IPv4 & NAT config: takes effort to accidentally expose things behind it. It's not even physically possible to fully expose all the ports of more than 1 host behind it, assuming it's only got 1 public IP. For IPv6 and firewalls, you've just pointed out how easy it is to configure it to not have this security property.
I'm not arguing that IPv6 is not secure because it lacks NAT. My point was that this entire discussion is silly engagement bait: there's no clear right answer, but it's an easy topic for dogma and engagement. A holywars topic like NAT, IPv6 and security is prime for that. The author and submitter muddies the waters further by - probably not intentionally - choosing a strawman submission title.
> Yes there is, this is basic secure architecture and secure by design principals
The only principles at work here are the ones of superstition and magical thinking. The existence of a "disable security" button doesn't weaken the theoretical security properties of a system when that button isn't pressed, and NAT systems and pure firewalls alike have this button.
If anything, NAT systems are sometimes worse due to things like uPNP automating the button-pushing.
Look: I just don't accept the premise that making a system more flexible makes it less secure. If your threat model includes user error, then you have to be against user freedom to achieve security guarantees.
The amount of "effort" it takes to disable security measures has no bearing on the security of the system when properly configured, and how easy you make it to disable safeguards is a matter of UX design and the tolerance your users have for your paternalism, not something that we should put in a threat model.
3 replies →
You talked right past the key point which is valid:
> There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
One security property is architectural, one isn’t. They’re not the same.
> Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense
I must be misinterpreting this statement, are you arguing that you aren't sure whether "x is more secure than y" is inherently a valid thing to compare?
"X is more secure than Y" is usually an ill-formed statement. Secure against what threats? Does X provide every security guarantee Y does? Every single one? Then there's no proper superset relationship, and the best we can do is say that X and Y provide different security guarantees.
If we model security as a lattice, lots of systems end up being incommensurable. You have to talk about the specific threats.
Okay, suppose you want to flatten the lattice into a scalar score so we can apply the usual relational operators and statements like "more secure" make sense. How do we do that? Do we apply some kind of weighted average over security feature presence? With what coefficients? Are these coefficients invariant over time and between people? What if my use-case is different from yours and I have to model the "amount" of security differently?
If my router is written in 100% memory safe code but has a default password of "hunter2", is it more or less secure than your router, which might be a normal OpenWRT installation?
When people argue over whether something is "more" or "less" secure without specifying a use-case, they're haphazardly mixing feature matrix comparisons and (usually tacit) disagreements on prior probabilities of various attacks. The result is seldom a conversation that enlightens.
2 replies →