I http ward an interesting rumour regarding Symantec.cloud (formerly MessageLabs) at InfoSec Europe about the implications of IPv6 rollout.
One of the methods currently used for combating spam is through blacklisting of IP addresses. In the new IPv6 world, Symantec will be whitelisting the IPs of mail servers. It’s understandable why but I suspect it will generate a lot of debate when people realise the implications.
There’s been a lot of discussion about the advantages of IPv6 in the press in recent months, focusing mainly on the huge increase in address space that a migration will give. But there are other features of IPv6 that are both a boon for the individual user and a headache for an IT department. Like many things, it’s a bit of a double-edged sword, one that cannot be ignored indefinitely.
IPv4 is one version of the “Internet Protocol“, an integral part of TCP/IP which was developed in the mid-1970s as a set of scalable communications protocols. The intention was to keep it as simple as possible, allowing any type of equipment with the right protocol stack installed to communicate with any other device, regardless of what those devices were. In those days, four billion addresses seemed like “enough”.
One of the consequences of this design strategy was to include no provision for security in general, with unencrypted networks, no authentication and any number of potential ways of attacking a victim. To be fair, in those days, people had a very different attitude to these networks; it was never envisaged that anyone would want to attack someone else. It just wasn’t “the done thing”.
Fast forward 30 years and a number of things have happened: an explosion in the number of devices connecting to the Internet, malicious software, Denial of Service attacks holding on-line companies hostage and the fear of being snooped on by anyone who has access to your data connection (anyone from the Government to Phorm).
The issue of a fast-reducing available address space was identified, and to some extent mitigated by using Network Address Translation, to allow organisations to use reserved IPv4 address ranges, (192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8) and only use a limited number of properly routable addresses on the Internet, effectively hiding the machines they have on their internal networks; all consumer equipment these days is configured to use NAT.
In 1998, the IETF published RFC2460 that outlined IPv6 which had a number of features not included in IPv4, including:
These are real advances over IPv4. However, there are some things that companies do routinely that may become a whole lot more complicated:
Penetration testing: LSE, for example, has been allocated an IPv6 address space which has more available addresses than are available in IPv4 in total. The length of time to scan a space of this size is enormous.
Firewalling: subnetting works differently in IPv6 to IPv4 and there is provision for frequent address changes. In addition, having every outbound connection effectively opening up a VPN into an organisation’s network means that banned traffic can be transparently tunnelled through a firewall which would otherwise block it.
Deep packet inspection: this becomes very difficult if all packets are encrypted
Web filtering: again, with packet-layer encryption, how can traffic be inspected before it hits the end device?
SSL has always been difficult to monitor on IPv4 networks, with companies needing to inspect this traffic having to simulate a man-in-the-middle attack to terminate a connection from a user on a device and re-establish a secured connection to the requested resource, e.g. a bank, to create a break in the session to inspect the traffic. It’s a messy solution and doesn’t go down well with users. In a full IPv6 world, this type of challenge will be with us every day.
There’s a really great paper on some of these issues here.
Stephan's Ramblings 