Slashdot Mirror
Obsession With Firewalls Could Hinder IPv6
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."
Response: 'Obsession'?! I don't know what you're talking about.
*request identified as critical of host*
*request forwarded to port 6666*
*incoming request on port 6666, port reserved for criticism*
Response: Maybe I'm not the problem, maybe IPv6 is the problem? Shouldn't a solution to a problematic situation meet the needs of said situation, not the other way around?
*incoming request passed through network firewall, computer hardware firewall and finally rejected by software firewall, request complete*
--
Come on, this is like intercourse, sometimes girls/requests just require double or even triple bagging, the last thing you want is a virus. Some girls are regular port scanners ifyaknowwhatImean
My work here is dung.
So, they're saying the way to get security in IPv6 is to throw away the whole concept of firewalls and hope that the protocol won't leave us with out collective bums hanging out in the wind??
I can't see a widespread adoption of a protocol that wants to get rid of firewalls. Now, I guess it's entirely possible that the IPv6 would secure networks since I'm not really up to speed on it's details. But I'm going to need an awful lot of convincing before I put any machines onto a network without something physically between me and it.
Unless IPv6 is very different, the only way I'm going to be able to set up my own personal network (and secure it) is with NAT. I'll take 'hard to diagnose' over pwn3d any day.
This just sounds so wrong.
Cheers
Lost at C:>. Found at C.
"Today we learned, that lots of people who have thought of NAT as a security mechanism, are getting a hit with cluebat when they find out that the IPv4 NAT also implements a stateful firewall as a byproduct. Since there is no NAT with IPv6, you only have to implement stateful firewall without address translation."
/64 is a huge address space to scan and so on. The presentation I watched at IETF Prague was quite interesting: http://www3.ietf.org/proceedings/07mar/slides/v6op s-1/sld1.htm
Sigh.
This is a non-issue.
What IS an issue are the new IPv6-specific things related to security. You cannot do a network scan anymore since even a
There are some implementation issues, such as anycast addresses and stuff like that you need to take into account.
However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.
The issue isn't NAT. We're not talking about using NAT. You're so far behind the curve that you aren't even visible over the horizon any more. The issue is that many protocols today are based on more than just opening a single outgoing TCP connection, or just spraying some UDP. They require connections on multiple ports and often to a variety of hosts. If there is a single firewall it must dynamically configure firewall rules for these applications or they don't work properly. You have to have a single firewall for security; you can't just have incoming traffic on your corporate net without a firewall. For people with a small home network and just a couple of machines you could use just the firewalling on your system (especially if your system is *BSD or Linux.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I hereby announce I am giving up my obsession with firewalls and reverting to my earlier obsession with Halle Berry.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
You can have a firewall that does not use NAT. Both sides are publicly addressable but there is still a security device between you and the outside world.
"I use a Mac because I'm just better than you are."
Linux has already gone down this path - the old IP connection tracking code in the Linux iptables packet filter has already been reworked into a more general layer-3 connection tracking mechanism, with separate 'drivers' for tracking the IPv4 and IPv6 protocols and separate 'plugins' that can handle specialized protocols (FTP, IRC, H.323, PPTP and so on).
I suspect that commercial firewalls will probably follow suit.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
Is it a good idea to expect that whenever and wherever a mobile computing device connects to a network, there will be a properly configured firewall ready to protect it, or should computers and other networked devices be able to function securely without an external firewall to protect them?
Its a nonsensical situation that operating systems in general cannot be relied upon for the security of their own network interfaces - after all it is down to the operating system to accept or reject user logins. In the same way it should be the operating system that sets policy about whether to accept or reject packets from arbitrary locations.
A firewall is roughly equivalent to a plaster on an open wound - it serves a useful purpose, but nobody should expect to walk around with an open wound on a long term basis.
There is little if anything that a firewall can do that an operating system can't.
SURELY NOT!!!!!
I would say I personally am not obsessed with firewalls per se, I'm obsessed with privacy and security.
The firmware on a firewall also has a much smaller amount of code to debug in order to make sure that it will function properly all the time. I would never assume that my Windows XP machine was properly patched with enough confidence to plug it straight into a cable modem all the time.
I am also not interested in having each computer in my home being identified and tracked individually, and I don't pirate software or download music. As such, even if the need for NAT is removed, I would still be highly interested in purchasing a device to block incoming connections and mask my IP address (maybe by swapping with other devices within my home on certain connections).
It seems strange that people are arguing about getting rid of NAT devices and having unique IPs for every device without bringing up the privacy implications. It seems that having unique addresses for every device is a small step away from being able to track and monitor every device on the net. Without the ability to proxy or perform NAT services, every device would be exposed to the net, and would leave a reliable trail of activity. It seems that this would encourage governments to think that they can control and enforce the web, and deal a pretty strong blow to the level of anonymity granted by the current network topology. I just hope that if this does come to pass, that there will be solutions to mitigate this risk, to help obfuscate individual activity on the net. This hazard to troubleshooting network issues, as described in the summary, might be an important factor in ensuring privacy and a certain degree of anonymity on the web.
"I like systems, their application excepted", George Sand (French)
Since we have the attention of the IPv6 crowd, everyone should add this record to your forward zones:
aacs IN AAAA 09f9:1102:9d74:e35b:d841:56c5:6356:88c0
-CR
"So is the BSD licence even more 'free' (than GPLv2)? Yes. Unquestionably." --Linus Torvalds (TinyURL.com/2vugzl)
You can have a firewall without using NAT. Being able to assign every device a routable address means that you can implement a stateless firewall instead of a stateful firewall. For most purposes, a simple firewall that filtered incomming TCP connection requests and UDP packets on all ports except those specifically allowed would suffice. This has the advantage that the firewall wouldn't need to track the state of TCP connections, and would eliminate problems like firewalls deciding a connection has been idle too long and closing it.
For the home user, being able to assign a routable IP to every PC has other advantages. Do you have multiple PCs with Remote Desktop running that you want to access remotely? NAT makes this difficult since all the PCs share the same IP address and need to listen for connection requests on the same port. Assigning every machine a routable address makes this problem go away. Don't like that example? The same applies to a web server, or SIP phone, or Bittorrent, or a myriad of other applications.
This seems to be the kindergarten introduction to firewalls, written by someone who is feeling around in the dark, and doesn't really know what he's talking about...
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
maybe I'm missing something here as I admit I'm not fully aware of the low level details of network implementation
but wouldn't it be possible to still have a Firewall but without a NAT?
i.e. instead of devices pretending to be just the one IP address that's been assigned to the router via NAT, they instead each have they're own addresses
However all communication still physically goes through the router / firewall / same device to filter out any incoming dodgy packets via SPI, or put limits on incoming communications (port filtering for given IP ranges for internal devices) to make sure that access is only granted when requested instead of by default
I know you must be trolling, since configuring IPv6 is mostly identical to setting up IPv4. Type an address, a prefix length, and a gateway and go. What's so tricky about that?
Dewey, what part of this looks like authorities should be involved?
For a lot of settings (Corporate,home etc.) allowing random access into your network doesn't serve any purposes. If you need to provide services you can serve them through the firewall or you can make a DMZ outside the firewall but there is no need to allow random access to your network.
That being said I totally agree that OS's need to be more secure but thats just part of the equation to proper network security.
This isn't about NAT, it's about firewalling (blocking ports). You can have a firewall without NAT, but apparently allowing firewalls allows NAT too. Since NAT is bad design, and as you say unnecessary, we'd like to disallow it at the protocol level. However if you do that, you can't have a firewall which is a problem for some people. IMO, firewalls are bad design too. Close the ports you don't need, and use ACLs to limit access to the ports you do.
Sort of. By definition, a stateful firewall probably has the capability of performing NAT, but there's no reason why you'd want to, if you have enough external addresses for everything on your network.
I don't think that NAT is "disallowed at the protocol level," as much as just rendered unnecessary. You could still build an IPv6 NAT box, if you really wanted to, but it would be a bit stupid. It's like building a box that hides two Ethernet cards behind one MAC address -- sure, you could do it, but since they both already have unique identifiers, why would you want to? There's no shortage. (Okay, that may not be the best comparison in the world, but you get the idea.)
NAT is driven by a shortage of routable IP addresses. With v6, there's no longer a shortage. However, people are still going to want the security offered by stateful firewalls (NAT, in its most trivial 1:1 implementations, doesn't offer any security -- it's all in the firewall anyway), which if configured incorrectly or overzealously, could create almost as many problems themselves as NAT does currently.
However, I still think that IPv6 is a big improvement. Why? Because with v6, you have the option of not using the stateful firewall, on devices that are hindered by it, while still retaining the ability to use one and mimic IPv4 security behavior. With IPv4, unless you are wealthy enough to afford a static IP for everything in your house, you don't even have the option of exposing more than one device (per port) to the public Internet.
To me, this demonstrates that there's really no downside (besides the obvious implementation cost) to IPv6. People who just want nothing to change, can basically have nothing change. Their IPv6+Firewall network will behave just like an IPv4 one, but people who want to use the capabilities of IPv6 (for example, VoIP using SIP) will be able to, by reconfiguring their firewalls to be a bit smarter about incoming traffic.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
The media -- and the consumer anti-virus manufacturers -- feed our "obsession with firewalls," and I see it every day in the home-user world.
Computers sitting behind a NAT router, which is pretty much all the firewall most machines need, come factory-loaded with Norton Internet Security or McAfee Security Center. This makes it nearly impossible for the average home user to share files and printers, and (especially with Norton) makes it very likely that they will answer some of the hundreds of pop-up questions wrong and break something they want:
"MSIMN.exe is trying to access the Internet!
What do you want to do:
1. Permanently block it?
2. Dial 911?
3. Buy even more Norton crapware?
I try to explain to my customers that they want a hardware firewall (the router) and don't really need a software firewall other than the one-way jobbie that ships inside Windoze.
OTOH, one customer this morning still has an XP SP1 machine plugged directly into her cable modem... guess what happened to her machine?
Oh, well, I get paid to fix these kind of problems, so I guess I don't mind. God forbid they ever get it right!
``Running out of IP numbers'' is like ``running out of oil'': it'll happen, but crying wolf didn't help the cause. It's claimed IPv6 is Big In Japan but, like popular beat combos, that means ``dead elsewhere''. And I"m sit in a hotel room in Tokyo happily IPv6-free, and i've just come from a building owned by one of the largest IT companies in Japan which was entirely IPv4.
IPv6 has been ``next year'' for the last ten years. It's still no-where. What'sdriving it now that wasn't driving it five years ago?
ian
IPv4 sites can be accessed with IPv6; IPv6 addresses include IPv4 addresses as a subset. On IPv6, you can access the entire IPv4-only internet; it is the IPv6-only internet that you cannot access with IPv4. That currently constitutes a minuscule number of sites, so it is no great loss, but once IPv6 begins to take hold -- and it will, China, India and Japan do not have enough addresses given their populations -- people who insist on using IPv4 will begin to find that large swaths of the internet are inaccessible.
It's not like anyone is expecting an overnight change, as IPv6 was designed to co-exist with IPv4 for some years. But once the number of IPv6 sites reaches some critical mass, abandonment of IPv4 will be quick. Early adopters of IPv6 will absolutely not find themselves penalized, assuming that their ISP does in fact support IPv6, as they can do everything they can currently do with IPv4 with IPv6 and possibly more.
Software firewalls are a non-sequitor in my opinion. It's really an added layer of obscurity.
If someone installs a firewall and say "please block port 123" I can't help but ask "Why did you open port 123 in the first place, then build a wall in front of it?" The fact that these firewalls exist just shows how stupidly the operating-systems UI is that it is so complicated to determine what apps are listening on the network, and what apps aren't.
Blocking outgoing apps is a completely different issue, and software firewall might make sense for that, if you don't trust the applications on your machine (which is a sad state of affairs anyway)
A protocol that requires a firewall to be stateful just to allow it to pass, I would call broken. And yes, I have for years called FTP a broken protocol (acknowledging that this observation is hindsight). I'm not talking about statefulness for NAT purposes, but rather, statefulness to track permissions on related communications (e.g. the DATA connection in FTP). FTP was designed in the day when no one expected blocking of arbitrary ports. But this is something we will be doing apparently forever.
Let's fix the broken protocols and move forward. While we can use HTTP for many file transfer needs, a new protocol that conducts everything over a single TCP connection or a single SCTP session is where we need to go. Then a firewall can be simple in operation and probably more secure as a result.
now we need to go OSS in diesel cars
The problem with NAT and firewalling, both, is that they're broken by design. They're attempts to add features to the protocol/application/OS layer that are implemented at the network layer. It doesn't have the necessary information to do the job properly! So we end up with godawful mostly-kinda-works klugdes like timeouts on idle TCP connections, etc....
I spend a fair bit of time tracing down network-related application issues, and let me tell you, NAT and firewalling are the work of the devil. Look, I'm all for a Linksys in front of your home Windows box, but please please, can't we kill this nonsense off once and for all?
No?
(pounds head on desk)
When people talk about using NAT, 99% of the time they don't mean a 1:1 NAT, but a NAPT as found in home routers and configurable in many midsize routers and PC operating systems.
Such a NAPT does offer security because it disallows all uninvited incoming connections and thus shields "services" running on systems inside of the NAPT from access from the Internet.
Sure. But what they're really describing isn't NAT, but rather the stateful firewall that's inherent in all non-trivial implementations of NAT.
Since you can take just the stateful firewall part, and use it with IPv6, there's no security disadvantage there. All you lose is the kludgy NAT parts, and in trade you gain the ability to do much more complex and useful routing -- creating various subnets with different security levels, etc. It's nothing that hasn't been going on with big corporate networks for years (those companies that have Class A blocks and can afford to give every workstation a 'real' IP still have firewalls and security policies), but now home users can have the same flexibility, if they want it.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Sorry to rain on that parrade, but the (variants of) "IPv6 is secure because it's a 64 bit space and noone will ever guess your address" sound... surrealistic. It's security by obscurity of the worst kind. The kind that can't possibly work.
We live in an age where far larger combinations of bits -- e.g., email addresses or name/password combinations -- are sniffed, phished, compiled into lists and sold, etc. What on Earth makes people think that a fixed IPv6 address would be more secure? No, honestly, what's so special about an 8 byte IPv6 address that makes it un-sniffable?
The notion that your machine is only findable by raw brute-force scanning is pretty laughable. Yes, it's one of the easiest and most non-brainer methods, but it's not the only one.
As a counter-example, look at how email viruses work. Because they _do_ work without scanning and without looking for you speciffically. They just go through more hops, each hop sending itself further to everyone in your address book.
Guess what? The exact same can be trivially adapted to an IPv6 worm. Each pwned machine just continuously looks for incoming and outgoing connections, and tries to spread to those too.
Or how about lists of static addresses, the same as the lists of email addresses that spammers buy and sell. Only unlike email addresses, if you're unfirewalled, you can't keep yours secret. You _have_ to tell each visited site your address every time you connect to it, so it knows where to send the response packets.
So basically it's the setup for the easiest kind of phishing imaginable. It's like automatically giving your email address to every site you ever visited, except this time it's your IPv6 address. Someone just has to create or pwn a popular site, and just record all the IP's that connect to it. Voila, that's a nice list to sell to the hackers. No more brute force scanning needed.
We already have major corporations whose computers are spam bots. What makes you think none will host IP recording bots? How do you know none of the ecommerce sites or forums you visit could be pwned to record all those static IPv6 addresses?
Or it just takes one bored intern working at a major ISP to run a sniffer and get a huge list of all static IPv6 addresses that sent or received anything through their pipe. Remember, idiots exist everywhere. One guy sold the whole list of AOL addresses to spammers, for example. So are you _sure_ noone will sell the list of allocated/known IPv6 addresses?
And since it's static addresses (after all, the whole idea is to get rid of NAT, right? No more dynamic addresses and remapping, right?), you know that each address logged will be available for a long long time thereafter.
Basically let's stop using the whole "we're secure by obscurity" concept to rest already. If there are other security mechanisms in place, fine, I want to hear about them. But "noone will find your IPv6 address" is _not_ security. If you want to talk security, you start from the most paranoid scenarios imaginable, not from wishful thinking.
A polar bear is a cartesian bear after a coordinate transform.
If you take the firewall out of the equation, there is still one bit of evil left with NAT - applications that may want to set up and announce a listening port don't know what the correct IP address is. Often times they have to resort to bizarre workarounds, like asking a known external service what their own address is. Very byzantine. If nothing else, moving to IPv6 removes that headache. And if you have two machines behind a 1:n NAT that want to open up port 80, you're hosed. Without NAT, that's not a problem anymore. You'll have to tell your firewall that connections to port 80 on those machines are OK, but that's nothing more than what you would have had to do to your NAT box anyway (except that one of them would have to be port 81 or 8080 or some such nonsense).
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.
What'sdriving it now that wasn't driving it five years ago?
SIP.
Right now, most people haven't run into it, but there's no easy way to have multiple SIP VoIP "lines"* into your house, when you only have one IP address.
* I mean "lines" in the POTS sense, of independent full-duplex telephone circuits, each with their own numbers. And yeah, I know you can get this if you use protocols other than SIP, but they have their own problems.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Still doesn't mean I wouldn't want a NAT to offer a centralized location to manage my network. Right now I've got a NAT router forwarding most ports on my IP to my Mac Mini server (which has its own firewall), and a few gaming ports to my Powerbook. Managing a firewall in a single location would be a lot easier than managing a firewall on multiple devices.
And how will IPv6 affect broadband? Right now I'm only allowed one dynamic IP. Would all broadband providers be forced to monitor individual IPs across their network?
I'm in the hole of the broadband donut.
You might want to read this document from the IETF regarding privacy and IPv6. Ensuring privacy, or at least not eliminating it, was a major concern of theirs during the design of v6, and I think you'll find that your privacy is protected just as well or better than it is under IPv4 (which is to say, not really all that well, but if it gives you a warm fuzzy feeling to think so, enjoy).
http://playground.sun.com/ipv6/specs/ipv6-address
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
The problems don't come from having NAT or a stateful firewall, but from using poorly designed protocols. There is hardly a justification for using more than one TCP or UDP port, or dynamically assigned destination ports.
For example, compare IPSec with OpenVPN: the former requires various UDP ports plus a completely new IP protocol, while the latter runs over a single UDP port. Now guess which one is much easier to get through a firewall.
OS Reviews: Free and Open Source Software
Well, for one, an administrative account may set up firewalling rules on a box to overrule attempts made by a normal account to open listening sockets (mitigate a number of attacks that rely on users running exploitable network apps or certain opportunistic attacks that listen for a queue to give a third party access). Performing a function along the lines of 'chown' for ports. The way many applications are written, unfortunately, implementing a more obviously chmod-like facility for ports in which the process impacted is made aware of the other layers policy, many existing applications would break.
A good example could be synergy. Let's say I'm a user interested in the program. I'm semi-lazy so I like the quicksynergy front end. If you ever use synergy, you know that it doesn't in and of itself bother with meaningful authentication or encryption. Also, while the daemon itself supports being explicit in terms of which IP interfaces to bind to, the quicksynergy frontend does not expose the relevant configuration options. So while I know how to make use of ssh to port forward and authenticate for me, out of the box I still may leave synergy hanging out accepting any connections on the IP network. Considering synergy could effectively be a means to do keylogging (if user accidently moves mouse to wrong place for example), this is highly dangerous. Now, my distribution being fairly restrictive had placed hard and fast firewall rules in place to only allow blessed applications access in, except on lo. If I wanted to shoot myself in the foot with synergy, I'd now have to jump through some hoops and hopefully in the process learn why it's a bad idea. There probably exist poorly designed but useful network daemons that don't even allow interface-specific binding, in which case firewall rules bridge the gap. You can't always shut down a process that does foolish things in terms of listening on sockets you don't like without configurability to get around it, sometimes you need that process to run and the network to be denied by a layer the process can't mess with and even is unable to absolutely confirm exists.
Yes, well-written applications should not do inappropriate things with listening sockets without the ability to lock it down. However, the world is full of not-so-well-written applications. The key is letting those apps think they are doing what they want with the firewall ruleset under the covers establishing the reality in ways the application cannot see or change. Good frontends for 99% of usage out there exist (OSX I believe makes it obvious when enabling a service it is also futzing some firewall rule to complement that, so it is intrinsically linked in the dialog most anyone will deal with).
This is one aspect where I disagree with Ubuntu philosophy. Ubuntu philosophy is along your lines (don't bother with iptables rules by default, they just get in the way and the user knows what they are doing). This seems incongruous with the whole mission of linux for the masses that Ubuntu is about.
XML is like violence. If it doesn't solve the problem, use more.
Services that require secondary/back-connections are not all that common. FTP is obviously the most common but even $40 firewalls can handle it. BT doesn't count since it uses well known ports (i.e. no negotiation of which ephemeral ports to leverage). The firewalls that are present in environments which use RPC are more than capable of intercepting portmapper requests and opening ports.
I said "no easy way," not that it's completely impossible. You can do it, but traversing multiple SIP connections over NAT with a single public-facing IP address is almost stupidly complex and/or requires specialized SIP-aware NAT hardware, and it's far beyond what most people are capable of doing, just for the static case. I don't even want to think about the case of roaming wireless SIP clients, which is really the goal.
IPv4 is going to die, and NAT along with it, it's just going to take a very, very long time. The main problem with IPv6 has nothing to do with its core functionality, the problem is that it had a serious case of featureitis (e.g. IPSec); if the IETF cut out the crap and just let people implement the long addresses without the rest of the stuff better left to the application layer, it would probably get implemented a lot faster.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
First, stateful filtering is stateful filtering. Although NAT's have to be stateful in some way, they are not stateful filters by themselves as you correctly point out.
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.
LedgerSMB: Open source Accounting/ERP
NATing firewalls serve two security purposes and several non security purposes.
The non-security purposes are to multiplex routable IPs so that we don't have to have a public address for each network capable device. That's critical in IPv4, but irrelevant for IPv6 in the forseable future.
The other is so that we can arbitrarily assign IPs to LAN devices (often with DHCP) and be happy. Auto-configuration in IPv6 renders that irrelevant as well.
Now to the security purposes. First and foremost, they provide a default condition where incoming connections are summarily blocked while outgoing are permitted (after NATing). UDP is often configured similarly so that an outbound UDP packet opens a hole for replys to come in through (also after NATing). There is absolutely nothing in IPv6 to prevent the same rules from being configured minus NAT. As a side benefit, without UDP NAT randomizing the port number, two machines behind different firewalls may request a hole by sending UDP packets out iff the firewall is configured to permit it.
The second purpose is to obscure the structure of the LAN behind the firewall including the number of machines on the LAN. It is notable that with IPv6 autoconfig it is entirely possible to find out how many devices are behind the firewall and who made the network devices.
The real question is how valuable is obscuring the addresses of the machines on the LAN and how strongly does NAT guard against leaking that information.
My guess is that NAT doesn't really do a lot there. If the firewall is well configured, most attacks behind it will be the result of users getting viruses and trojans from email and web browsing. A well crafted trojan can easily phone home using an outbound (permitted by NAT) connection and tell the attacker all about what's behind the firewall anyway. The trojan can then act as a socks proxy and allow the attacker to effectively have a machine inside the firewall anyway.
In short, there's no reason for NAT at all in IPv6. Any real security benefits to NAT are side effects of it's primary purpose and easily enough implemented properly as security rules to provide security. Network security SHOULD be a process of adding deliberate and considered rules to a firewall. It should NOT be an ill-considered side effect of solving an entirely different class of problem.
The real question is how much do those firewall rules spoil the idea of everything having a routable address. My opinion is not all that much. A firewall is simply a sort of rules server device that offloads filtering (ideally as a first line of defense backed up on the machine being protected) and centralizes policy, even in the face of mis-configured machines. Those rules would (hopefully) still be there without the firewall (who wants random people sshing or VNCing to their desktop machine), so the effect is more or less nil as far as routability goes. After all, even servers running without a firewall are often configured with hosts.(allow|deny).
The problems that the article describes — FTP, IM file transfers, etc. — have exactly the same problems under NATless IPv4 stateful firewalls. The Internet hasn't fallen over yet, therefore the problem is overblown.
The solution in Linux has generally been application-specific kernel modules (ip_conntrack_ftp, ...) that tell the state engine (ip_conntrack) to expect related traffic. They might've finally added a user-mode interface since last time I looked, but that doesn't actually solve the problem since any user-mode program is still forced to sniff forwarded traffic for known applications.
The more elegant solution would be for each application to indicate a related connection in a way that all stateful firewalls along the route could understand. Sort of like UPnP, except UPnP only talks to a single local NAT, not every firewall along the route. However, this more elegant solution hasn't yet been invented, for IPv4 or IPv6.
Range Voting: preference intensity matters