Obsession With Firewalls Could Hinder IPv6 278
DosIgriegas writes "The obsession with firewalls in IPv6 may result in some of the quirks of IPv4 reappearing. Ars Technica has an article looking at the topic in depth, exploring the technical challenges of securing the new protocol, and looking a the re-emergence of old problems in new guises. 'Ironically, what's required to make IPv6 work through a stateful firewall is almost identical to what's required to make IPv4 work though NAT. This means the IETF's efforts to keep IPv6 NAT-free in order to make protocols do their job without messy workarounds are defeated by the notion that everything should be firewalled.' If we decide to stick with firewalls in IPv6, we'll see many of the same hard-to-diagnose network problems that we have with IPv4."
Re:Defective by design? (Score:5, Interesting)
The old-style stateless firewall will work just fine.
Re:Defective by design? (Score:1, Interesting)
Not at all. The idea is to get rid of the hack that is NAT (as there are plenty of address to go round), and keep the firewall. However, it might not be that much of an improvement because troubleshooting a firewall router isn't that much different from troubleshooting a NAT one.
Re:Defective by design? (Score:3, Interesting)
But, who is going to trust an application to determine network policy? The first malicious application to come along will bork the whole system, won't it? I mean, 'random' hosts is the perfect invitation for badness.
Maybe I'm just (once again) demonstrating my ignorance of such things, but this sounds like it will introduce more problems than it fixes.
Cheers
Re:Firewall != NAT (Score:1, Interesting)
My brain hurts... (Score:4, Interesting)
So what's the point of the pages full of irrelevant details about how Vista and ZoneAlarm works?
Stateful firewalls require you to explicitly allow incoming connections certain ports, even with IPv6. That's it. Nothing else there.
What he completely misses is that this is worlds better than NAT, which also requires assigning a unique port on the single IP address... You're screwed if you want more than one machine to access the same service, which doesn't allow you to use a non-default port.
Want two web servers running (on port 80)? Want two machines to be able to receive VoIP calls? Want multiple machines to be able to play some online game? Too bad. It's only with the multiple addresses IPv6 offers that it's really possible.
Re:Defective by design? (Score:2, Interesting)
The current scanning networks and such works because of one thing, you can almost count on hitting some IP addresses at any given block on the IPv4 network. Also because like 90% of computers are running windows you can probably scan for vulnerabilities and attack almost as quickly.
Re:Translation (Score:5, Interesting)
There are also some features of NAT that I would like to keep even when using IPv6, the main one being the ability to hide the topology of my networks from the outside world. So in a way, I do want to have some connectivity issues.
For example, I currently maintain a firewall and NAT box that has a pool of several public IP addresses (Internet access) on one of its interfaces, and 3 additional network cards connected to different networks. Each of these 3 networks contains a number of machines and some servers for various protocols that are mapped to some of the public IP addresses. One of these private networks is rather open (with protocols such as NIS and NFS used by most hosts) and another one is rather secure (no host trusts any other host on the same subnet). I do not want to allow an external attacker to guess on which network a given server could be. Maybe this extra level of security through obscurity is not really necessary, but I want to maximize my chances in case of an attack (e.g., zero-day exploits). Some services that I mapped to an external IP address and port may go to a server on one network, while the same IP address but a different port may go to a different network. I do not want to reveal too much information about the topology of my networks, that's why I like NAT.
NAT causes some connectivity issues, but I consider some of them as features, not problems. Oh, and I know that some people claim that the network hiding brought by NAT is just some false security and that IPv6 with its much larger address space will also make it difficult to scan hosts on a network. But that's not the point here: hiding the topology is just one of the many layers of security that I use, and the larger address space of IPv6 will not prevent some information from being disclosed in routing table updates, etc.
Re:Defective by design? (Score:3, Interesting)
NAT is bad (Score:4, Interesting)
I can't wait for the home networking routers that are so popular to implement 6to4. There's no reason they can't do that right now. Even if it were off by default, having it there would give people more options at little or no cost to the manufacturers. All of the major OSes out there shipping today support IPv6 natively.
Re:IPv6 Needed? (Score:5, Interesting)
Virtualization. Where you once had one machine serving several applications, it's now become trivial to separate applications into differing vm's for security, simplicity and scalability. You'll still want to adress the unique vm's, and ipv6 is a great way to do it.
Fast forward ten years and you'll have applications the way you have VM's today. Instead of deploying an app on a specific platform, you'll be able to deploy a VM image like you fork a process today. If you thought you needed IP's today, wait 'til your processes not only require their own PID but also their own IP address.
Re:IPv6 Needed? (Score:5, Interesting)
I think this discussion is misguided (Score:4, Interesting)
However, ipv6 has a major change which can cause massive headaches for firewall administrators: IPSec is now mandatory. IPSec provides two optional means of security: AH (which provides antitampering) and ESP (which provides encryption and antitampering). Neither of these were designed to pass through a NAT. The reason is not that NATs are bad design but rather that they break the end-to-end security that IPSec offers (i.e. any packet tampering invalidates the packet, and NATs by definition tamper with the packets).
Sounds all right so far, but with ESP, the entire payload is encrypted. This means that a party in the middle cannot evesdrop on the connection (including the TCP headers). You don't know what ports are involved. You just know what two computers are involved. If you try to use FTP over an ESP-protected connection, however, the firewall will not be able to determine the state of the data connection. Same with H.323 (though I for one welcome the death of any OSI-decended protocol). In fact H.323 would become essentially impossible to allow via ESP to arbitrary hosts without opening up the whole network because of how the control protocol works.
Hence you run into stateful filtering issues with ESP which are not possible to sort out. In practice, you have the choice of simply allowing ESP as a protocol or not allowing it, or possibly allowing it to a whitelisted set of end-points.
Oddly enough this was not discussed in the article, which seemed to spend way too much time confusing NAT and stateful filtering.