Bitcoin as the base layer

Many people have seen IPv6 as a simple addressing extension to the existing Internet and see few changes to the way we secure systems. These people cannot be further from the truth. IPv6 will change the way we think about security. We need to start planning now or we will be left in the dust.
This is another topic I will be addressing in the coming weeks and months (so many security topics, so little time).

IPv6 substantially changes how IP interacts with the link layer, in particular Ethernet. ARP will go away and be replaced by NDP, which is ICMPv6 based, and we also need to look to protocols such as SEND to secure NDP, or we will fall prey to the same class of attacks we faced in IPv4 over hub shared networks (and for that matter now in the world of wireless).

I will explain what SEND and NDP are in the next couple of posts this week. For now, I ask you to trust me when I say they are important.

First, I will discuss a couple of issues that we really need to start planning for. IPv6 has been around for a long time (15 plus years is a long time in IT), but it is only just starting to be widely deployed. The issues we will face need to be addressed now, or we will discover holes in our networks and systems, and these will be exploited before we even note that they are a concern.

Many of the issues in security and risk are really about managing problems before they grow to large. IPv6 is just this, a potential issue and a potential benefit. How we manage it determines the outcome.

IPv6 Improvements
There are many improvements to IPv6 when considered against IPv4. Some of the commonly noted ones include:

• Expanded address space.
• Extended routing (more levels of addressing hierarchy, simple auto-configuration of addresses).
• Improved scalability of multicast routing.
• Simplified header (lesser header fields compared to IPv4 to lower processing costs, dropped header fields are now available as optional extension headers).
• Support for optional extension headers (allows for faster processing because extension headers are not examined by routers, allows for arbitrary length of IPv6 header).
• Support for authentication and privacy through encryption.
• Support for source routes (Source Demand Routing Protocol (SDRP)).
• Quality of service capabilities.

There are also some less commonly discussed security enhancements that we will cover in the forthcoming posts:

• New privacy-extended IPv6-addresses generated CGA (cryptographically generated addresses)

1. maintain privacy
2. where accountability is possible by link administrators

• New: host ID can be used as a token to access to a network.

For today, we will discuss a couple of topics that many people have overlooked.

IPv6 and scanning
The new addressing scheme being implemented with IPv6 implies that the number of available and allocated addresses is REALLY big. So big that the existing methods of brute force / random scanning make no sense [RFC5157].

There are ways to discover hosts… but they are not based on random scanning any more.
The typical IP/v6 network is issued with a (/64) CIDR. This is why scanning is in practice much less feasible. Also automated attacks, e.g. network worms that pick random host addresses to propagate to, are going to be hampered. When there are 1.84467+19 (this is 1.8 with 19 zeros) host addresses, finding a host in an IPv6 network is 10 billion times more difficult than scanning the entire deployed IPv4 Internet!

Worse, even if we could, it would either end as a DDoS or detection very quickly. From this, we can see that random scanning network worms will not be feasible. They have been disappearing in any event, but IPv6 spells the end of the random scanning worm.

In IPv6, every subnet size is much larger. As noted, default subnets in IPv6 have 2⁶⁴ addresses. Exhaustive scan on every address on a subnet is no longer reasonable (1,000,000 address per second mean > 500,000 years to scan), and even NMAP support for IPv6 network scanning is limited.
Worse, the new privacy extended CGA IPv6 addresses are regenerated faster than they can be scanned. We will cover this in coming posts.

IPv6 scanning methods HAVE to change.

Public servers will still need to be DNS reachable giving some attacker hosts to attack. As such, DNS will become even more of a target than it ever has been. Not only is DNS an attack vector, it is one of the few means to recon hosts. DNSSec is critical now.

Zone transfer and interception attacks will be more and more common when IPv6 starts to be widely deployed. It is one of the simplest methods of discovering hosts. It is about time we start to deny DNS zone transfers! DNS splitting is more important than ever with IPv6.

The next issue is human as always. Administrators may adopt easy-to-remember addresses (::1,::2,::53, or simply IPv4 last octet) to simplify management as they did with IPv4. This is a bad approach. In IPv6 we need to start using the multicast registration controls, and learn to manage systems by their multicast groups.

Other unthought-of scanning methodologies will come, as EUI-64 address has “fixed part” and the Ethernet card vendors address (the MAC) can be guessed. The 48 bits in a MAC are not random, and the pool of numbers in this are far smaller than the implied 2⁴⁸ bits.

This also means we will find new techniques to harvest addresses being developed by attackers. Addresses can be harvested from logs and DNS zones, and these will become the target of attacks in their own right.

Further, in compromising routers at key transit points in a network, an attacker can learn new addresses to scan. The difficult part of scanning in IPv6 is finding the host. Once the host is discovered, it can be attacked as normal (with some exceptions based on mobility controls).

The multicast groups also great a target. A new attack vector is created in order to discover routers; then we look at multicast groups such as “All node/router …. addresses”. IPv6 supports new multicast addresses that can enable an attacker to identify key resources on a network and attack them. For example,

• all nodes (FF02::1),
• all routers (FF05::2), and
• all DHCP servers (FF05::5).

If multicasts are not secured, the attacker can recon a network and bypass the need to discover hosts the hard way. As a result, it is really important that these addresses are filtered at the border in order to make them unreachable from the outside. This should be set as a default if no IPv6 multicasting is enabled. The difficulty here is that IPv6 creates diffused networks.

Firewalls will also change in radical ways.

The death of SSL
Next, there is one area I have seen very little (if anything) on so far. This is how IPv6 will destroy the notion of application-based security.

I will address this in more depth tomorrow, but the thing to think about is that IPv6 has mandatory support for IPv6 and a cryptographically based host-identification and authorisation scheme.

This makes SSL, TLS, and other protocol redundant.

More, application-layer encryption is based on the encryption stack in the application. Each time we re-deploy the same crypto requirements over and over, we add more avenues for mistakes. Crypto is hard. If we can do it once in the O/S and not at each layer, we all win.

The conclusion…. for today
Basically, IPv6 can make us more secure, but only if we do it right. Web attacks will not go away, and NULL (or 0-bit encryption cyphers) can still be deployed by unobservant administrators, but there is a way forward if we start planning now.