31–40 of 606 posts
Earlier quoted context omitted.
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
This probably has more to do with network engineers (and CCNP instructors) not being security engineers (or even conversant with Cisco's security SBU).
This is going to depend on the router and on IP distribution. My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through. NAT is not intended to be a security feature, for sure, but it creates security as a side effect . If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on m…
Maybe it’s because I don’t consider myself a super technical person, but I find it so hard to parse the title of this blog post. When I first read it, I thought it was saying something like, “The protocol is not insecure, and the reason is that it lacks a NAT”. However, after reading the blog post, it seems like it is intending a different meaning. The meaning I think is, “the protocol is not insecure just because it…
> 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…
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing. I believe the common knowledge is somewhat more nuanced than people would have you believe I present to you two separate high-value targets whose IP address has leaked: IPv4 Target: 192.168.0.1 IPv6 Target: 2001:1868:209:FFFD:0013:50FF…
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing. I believe the common knowledge is somewhat more nuanced than people would have you believe I present to you two separate high-value targets whose IP address has leaked: IPv4 Target: 192.168.0.1 IPv6 Target: 2001:1868:209:FFFD:0013:50FF…
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this. (IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https:…
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this. (IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
NAT absolutely does provide good security. It denies all incoming traffic that is not part of an established connection. Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules. So there is nothing about a lack of NAT in IPv6 that makes it less secure.
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 connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this. (IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https:…
Earlier quoted context omitted.
NAT absolutely does provide good security. It denies all incoming traffic that is not part of an established connection. Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules. So there is nothing about a lack of NAT in IPv6 that makes it less secure.
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…