So true in the kittens dept. The worst part is that while this situation has been developing, Stockholm syndrome has taken hold and half the battle is convincing people to be receptive to having real IP addresses again! Few people know the difference between a NAT box and firewall anymore, and "router" now means NAT box to many people.
In the case of many consumer/desktop machines, being behind a NAT is a very useful first tier security barrier. Every machine being fully reachable -- say via IPv6? I foresee many IT headaches and the Nortons/McAffees of the world raking in more money.
NAT != firewall. You can have a firewall without NAT.
Probably the sensible thing to do for IPv6 is to make the default to block the ports of specific applications people don't canonically expect to be visible from the internet, like Windows file sharing or telnet or HP JetDirect, but allow everything else so that VoIP and other P2P apps will all work properly.
Yes, NAT != firewall, but most consumer machines with static/world routable/reachable IPs have been particularly prone to attack over the years. Public access points (hotel, airport, etc) offer a similar level of risk -- yes Firewalls are important, but I'd pretty much make sure most machines/devices under my control in my home network (v6 or v4) not be world reachable. I'm just oldskool paranoid that way.
The only way you can make a device "not be world reachable" is to not connect it to the internet. It's silly to think that a vulnerable application invoking listen() is more dangerous than a vulnerable application invoking connect(). As soon as you connect to some cloud server you're exposed to any malformed data anyone can ask it to relay to you.
Of course you can do without a NAT. But the NAT has the advantage to make the firewall rules trivial to write.
Put "DROP all packets with destination 192.168.0.0/16 coming from the external interface", and a few other boilerplate rules of the same kind, and poof: you just secured 99.9% of the NAT-ed networks. No configuration required.
To do the same without a NAT, you need at the very least to adapt the rules to the IP addresses of the machines behind the firewall, which add complexity and increase the likelihood someone will screw up the configuration.
And, hu, please don't open ports by default. That's just a recipe for disaster. If apps really want to open a globally accessible port, make them explicitly signal that to the firewall so it opens access.
You know you could just drop all packets with destination of any valid address coming from an external interface. This isn't BGP, you're not going to really be routing the entire internet.
> being behind a NAT is a very useful first tier security barrier.
Misconception. being behind a NAT without a firewall is a very useful nothing in terms of security, because one is basically a static route away from being reachable. It just happens that masquerading is coupled with packet dropping in most appliances and configurations. Only the firewall protects you.
Even if I don't have a firewall, pretty much any competent ISP will configure its switches to drop any packet pointing to/from something that looks like private IP address space. Not to mention they wouldn't route it to me anyway.
So even if I don't have a firewall, you would probably need to physically plug yourself directly on the WAN port of my NAT box for your static route to work.
Not to say the firewall is useless, but even by itself, the combination NAT + private IP space prevents a lot of attacks. That's very different from what happens when you have no NAT and no firewall, where you are basically reachable by any kid on the other side of the earth.
Not a problem - all of the enterprise IPv6 networks I've seen (not that many, but some) have deployed their IPv6 in RFC 4193 and they use IPV6 NAT at the border.
Your average IT Enterprise director/VP has little to no interest in having end-end routing of IPv6 to their internal workstations.
I'm just wondering about how much will actually change with IPv6. I already have native IPv6 at home and it seems that my home router (a FritzBox) has a stateful firewall enabled for all IPv6 connections. I can manually exclude individual addresses from firewalling, but that's about it.
At first glance that looks like the right solution: People keep saying that instead of the NAT hack you should have native IPv6 with firewalling for the same or better level or protection. But doesn't a stateful IPv6 firewall introduce the same problems as NAT? Won't I still have to use keepalive packets or protocols like PCP to actually use P2P?
Of course real P2P is easily possible with IPv6 by simply opening up everything. But what are our options for having both security by default in home networks and no need for those workarounds we have in NAT now?
At least with IPv6 we won't have the mess of translation, requiring p2p apps to perform public address determination (and possibly port guessing). But you're right, the central problem remains.
> But doesn't a stateful IPv6 firewall introduce the same problems as NAT?
Depends on what it does and how it's configured. If the whole internet ends up running with default-deny stateful IPv6 firewalls, then that's a setback, but you still have global addressibility if not reachability.
> Won't I still have to use keepalive packets or protocols like PCP to actually use P2P?
Even IPv6 + PCP is a real improvement.
Default-allow on the consumer routers + host based firewalls would be much better though.
I remember the time of 56k modems. Port scans were fun back then. Sucked, would not dial-up again.
Host based firewalls: for some reason this sends the networking neckbeards into rage mode, god knows why. I'd say its slightly weaker than blocking everything on the router.
I worked in infosec for a while. Nearly every real-world threat we saw came in via HTTP, IMAP/POP3, or some other "pull" mechanism. Firewall might as well not have even been there. Anyone who thinks "firewall == security" is terribly out of date.
I'd say the only thing firewalls still provide protection against is pure remote vulnerabilities in common system services. Those still appear occasionally, but are more rare than they used to be. With better service isolation, coding standards, and authentication they'll become even rarer.
