psych0tik.blog

It is the on-coming storm. We’ve all heard about it; it’s big, scary, and new. Public IP addresses for all and tearing down those NAT-PT barriers excites and worries many. IPv6 is coming but it’s not as frightening as it’s made out to be; most concepts from IPv4 can be applied directly to it’s younger brother. One of the ideals that IPv6 was designed around is the restoration of end-to-end connectivity of all nodes on the Internet; this introduces a certain uncertainty to how we design our firewalls under v6. We have options now, from the completely open networks geeks would love, to NATesque heavily stateful firewalls, and everything in between.

With our current version of the Internet Protocol we use private addresses heavily on internal networks protected automatically by the one way nature of NAT-PT; it has given many of us the expectation that connections cannot venture into our networks without our explicit permission. These networks are often described as castles or walled gardens, analogies referring to the strong perimeters and minmally secured interiors. We feel comfortable and secure in our walled gardens and IPv6 seems like it may rip some of that security away but this need not be the case. Regardless, the IPv4 internet is running out of addresses and IPv6 is coming; as the boyscout motto goes, ‘Be prepared’.

The paradigm of NAT is no longer the default in IPv6, the default has become every node exposed to the entirety of the internet. One extreme of the new freedom in IPv6 would be to drop all perimeter firewalling and firewall at each node. This strategy is likely a bad one but not entirely without merit. The slightly less extreme strategy of doing minimal filtering at the perimeter, purely packets that simply should not be heading into or out of any network. Things such as neighbour discovery, multicast listener discovery, Windows netbios protocols, and others. With the detailed firewalling moved to the node much of the firewalling work is widely distributed (assuming an attack didn’t focus on a single host, in that case, throttling could be done at the perimeter). One of the problems with this approach is the host firewall which would be easily torn down if the machine was compromised, inbound and outbound would be at the mercy of whoever is in control of that node. In my opinion this strategy should be at least experimented with and is probably suited to networks populated by geeks and datacenters.

On the other extreme is the heavily fortified perimeter, a well known paradigm to anyone who’s been involved in network security to any degree in the past decade. We block and/or control everything at the perimeter. SIP gateways, web proxies, stateful NAT firewalls. All this can still be accomplished under the new protocol short of hiding internal network addresses, however this would break many innovations that depend on peer to peer access. On a well configured enterprise network internet scope multicast streams may make it through but on smaller less throughly configured networks under this paradigm it may not, at present I don’t know enough about multicast routing and firewalling to say anything even remotely conclusive. The slightly less extreme version of this setup would be the good old stateful outbound only behaviour that exists in so many consumer NAT gateways.

There exist in between these two extreme ends of the firewalling world a range of happy mediums. One strategy would be to allow a certain range of ports though the perimeter for peer to peer applications such as the shared white-board application in Windows Vista. IPSec also requires end to end connectivity in a certain way and provides a secure and authenticated way to allow connections into the perimeter as IPsec can authenticate traffic and provide privacy as well. Microsoft has integrated IPSec into a remote access technology that works in a similar way to a VPN and yet subtly different, built entirely on IPv6 and IPSec technologies Microsoft’s Direct Access is an excellent example of a happy medium in the permissiveness of a perimeter.

At the end of the day it all depends on what you want from your network. A business will probably a strong perimeter, security oriented geeks could probably benefit from a node oriented firewalling strategy to make their projects and servers more flexible, and everyone will want IPsec authenticated/encrypted traffic.

Update: The Internet Architecture Board is considering IPv6 NAT in RFC 5902 in July 2010 and is discussed in a blogpost by Jeremy Stretch

Files: I’m releasing a script I wrote to generate ip6tables rules as part of this blogpost. It’s only v0.1 but I hope it will prove usable and useful to others. Suggestions and patches welcome. carbfw6-0.1.tar