IPsec Security In IPv6

IPv6 is starting to show up in around the Internet. Adoption is slow, but with the magic number of 4 billion- plus IPv4 addresses about to be reached, IPv6 will see a much faster pace of adoption as the IoE gains momentum.

There is a lot of excitement about all the enhancements within IPv6. Some even claim it is the answer to Internet security. But so far it has not lived up to that promise. “IPv6 is built with scalability and compliance in mind, not only in terms of available address space but also when it comes to handling multicast communications, for example,” notes Santiago Pontiroli, security researcher at Kaspersky Labs. “In addition, having a conforming IPv6 implementation means supporting IPSec by default, which from a security standpoint is something we already had in IPv4. But its use was optional, and generally sparse,” he adds.

IPsec
IPv6’s security element is something called IPsec. The Internet Engineering Task Force (IETF) developed IPsec to secure network communications encapsulated in the Internet Protocol (IP). IPsec is a suite of protocols designed to authenticate and encrypt the IP packets of a communication session. It is a framework of open standards that define the policies for secure communication within a net, by ensuring the integrity, confidentiality, nonrepudiation, and authentication of data communications over IP networks. It also describes how to enforce these policies and can detect replay attacks.

IPsec works at the OS kernel level. It is a modification to the IP implementation within the TCP/IP protocol suite, i.e. a modification to the kernel of modern operating systems. Figure 1 is a block diagram of the IPsec architecture.

Fig. 1: IPsec Architecture, courtesy of Cavium.

The protocols within IPsec are designed to do two things—establish mutual authentication between agents at the beginning of the session, and negotiation session cryptographic keys. IPsec also can be used to protect data and block data. These become very important issues with the IoE.

“The problem of security in IPv4 was simpler because of reuse of addresses,” says Jim Aralis, Microsemi’s CTO. “With IPv6, the problem multiplies because of so many more connected devices. Because there will be so many dumb and semi-dumb devices sitting on the network, they can, inherently, have huge effects if they do not protect keys and data.”

So these two security items must be implemented in any IoE devices. One example of these two parameters would be that IPsec can be set to require data passing between computers use an IPsec-negotiated transport session. Another would be that it can be used to block data by implementing an IPsec blocking policy to block all access except specific ports, say port 80 (HTTP), and port 443 (HTTPS), for example.

IPsec uncovered
A drill-down of IPv6 can be found here. This article will focus on the IPsec part of IPv6 only.

Table 1: IPvX table of characteristics.

IPsec literally stands for Internet protocol security. It exists in IPv4, as well, but has been reworked for IPv6. Table 1 is a recap of the two protocols, and the difference between them.

Under the covers, IPsec has two modes of operation: transport and tunnel.

In transport mode, only the payload is encrypted; the header is untouched. The source and destination hosts perform whatever cryptographic operations are required. A single tunnel is created using Layer 2 Tunneling Protocol (L2TP) over which the encrypted data is sent. Essentially, a ciphertext is created at the source end, which is then retrieved by the host at the destination. Such a configuration creates is an end-to-end security link, where the actual endpoints are the source and destination IP addresses. This mode is generally, used for host-to-host-type communications where the network is known and additional security is maintained at the endpoints. The vulnerability is that, while the data contents are protected, the general network traffic does not have any encryption.

Tunnel mode is the most secure. Special gateways are in place that perform cryptographic processing along the hops. In addition, there is cryptography performed by source and destination hosts. This methodology establishes gateway-to-gateway security so, unlike the transport mode, the entire network is secure (see Figure 2).

Fig. 2: Generic VPN tunnel diagram. Courtesy: RockSecure.

One thing to note with either mode is that when implementing it, all gateways need to be able to verify that a packet is real, as well as be capable of authenticating the packet at both ends. If any packets are found to be invalid, the must be dropped, regardless of the packet protocol.

Data Packet Encoding
On of IPsec’s strong suits is its ability to implement data encoding. IPsec’s protocol implements two types of data packet encoding (DPE) for security. One is the authentication header (AH). The second is the encapsulating security payload (ESP). This particular encoding scheme provides network-level security for the data, and is one of the key elements for many of the IoE devices that will run with minimum security (low-end appliances, simple sensors, wearables, etc.).

The function of the AH header is to provide integrity and authenticity of the packet, via keyed hash functions, also known as message authentication codes (MACs). The header can establish security between multiple gateways and hosts implementing AH, as well. It also prevents illegal modification, and optionally, provides anti-replay security.

The function of the ESP header is to provide data encapsulation, encryption, and data confidentiality. The data confidentiality segment is offered via symmetric key encryption.

One of the more important elements of IPsec is what is called the security association (SA). SA adds a layer of security with something called the security parameter index. The SPI number is contained within the AH and ESP, to determine which SA was used for the packet. Additionally, an IP destination address is included that points to the endpoint, which may be a router, firewall, or even the end user.

Finally the SA uses a security policy to tell the router what it needs to do with the packet. Options include dropping packets, substituting a different SA, and dropping the SA altogether. A security policy database is used to store the policies in use.

IPsec: Great, But Not Perfect
IPsec raises the bar on Internet communications security. “IPSec doesn’t directly solve the problem because IPV6 doesn’t deal with the issue of key management, which is critical as many ‘things’ on the IoE will be in environments where there is the possibility of tampering,” says Philip Lewer, marketing director for IoT and Smart Home at NXP Semiconductors. “So the use of asymmetric keys with secure storage is needed in IoT IPv4 networks and will continue to be needed in IPv6 networks.”

There are other imperfections, as well. IPsec isn’t the cocoon that wraps communications in a security-tight blanket. While it has great flexibility, that flexibility comes at a price, particularly complexity. As an extremely flexible platform, it can get confusing. Some security experts have said that these options, and the accompanying volume of documentation, has led to resistance in implementing it. In a nutshell, IPv6 security differs from IPv4 in subtle as well as drastic methodologies. Understanding and deploying it correctly can be confusing for security vendors, organizations, and end users. This means there is a huge potential for deployments to be full of security holes or weak implementations.

A Weak Spot Exposed
Let’s take a look at an inter-domain or large, distributed system. In such a case, there is likely to be a diversified security policy that can interfere with IPsec’s security policy.

A simple example might be between two hosts, where one of them is using a firewall with a security policy that instructs it to deny any encrypted traffic. At one point, the two hosts build a direct tunnel, but are not aware of the firewall’s security policy. This is a plausible scenario at this point because of the flexibility of IPsec, and the fact that it has so many configuration possibilities. And back to the confusion issue, the installing parties may be just doing the bare minimum to get the connection established. While it can take into account the firewall’s policies, it may not simply because it was too complex to work them in.

In this scenario all encrypted traffic that hits the firewall will be dropped. The irony of this is that each hop is flawlessly implementing its security policies. Singularly they work as designed, but in conjunction, they fail. This is a rather old scenario that was used for simplicity, but there are still plenty of cases where similar or parallel configuration have problems.

Where Things Can Go Wrong
While IPsec is going to happen, global deployment has some issues. IPsec will be instrumental in guarding the IoE and providing a secure platform for the multi-billions of IoE devices that will come on-line in the next few years. However, to do that, a couple of things need to be addressed.

First of all, it is sparsely deployed. That means that early deployments can present the risk bugs and design flaws until the learning curve is tamed. After all, many security holes and back doors are simply exploits that result from inexperienced programming rather than deliberate sabotage.

There is another security risk as well. “Every system with IPv6 enabled has a ‘link-local’ address that any other machine on the local network can communicate with,” says HD Moore, chief research officer at Rapid7. “This allows an intruder with access to the local network — directly or through a compromised IPv4 system — to access and attack the IPv6 interfaces of other local machines.”

Next, IPv4 and IPv6 cannot directly communicate. That means that there will be a slew of dual-stacked networks running both versions until the transition phase is complete. And running dual stacks means all functions must be duplicated at each stack. That doubles the error potential, doubles the security issues, and doubles the chances for mistakes.

In the middle of all of this will be the gateway. “One major challenge is going to be in the capability of the gateways,” says NXP’s Lewer. “These gateways will not only need to be able to bridge between IPV6 and 6LoWPAN, for example, but as long as there are IPv4 nodes on the network the gateways will need to support dual stacks as well as IPV4-IPV6 network address translation (NAT).”

Furthermore, such stacks also increase the risk that there can be “hidden” content because it may be wrapped within one protocol to pass though the other. This is a recipe for inserting malware somewhere along the pipeline. IPsec can be used to help secure these stacks, but its implementation differs from IPv4 to IPv6. Therefore a uniform application methodology has to be developed and implemented across the board.

All this translates into what will likely be a bumpy ride while the transition takes place. And, of course, there will be issues discovered that haven’t surfaced yet as well.

Missive
While IPv6 has been around for quite a number of years, it is one of those protocols that just hasn’t garnered the momentum it could have simply because there was no pressing need for it—yet. It is a relatively complex platform with a lot of options, which makes it somewhat daunting to tackle. Moreover, there have been no comprehensive, wide-scale training or testing programs that have been implemented.

The bottom line is that we are just now beginning to take a hard look at IPsec. Fortunately, we still have a bit of time…some time, not all the time. If the industry starts thinking about the conversion soon, there will be plenty of time to make an orderly and smooth transition. We will be able to be proactive, not reactive with training engineers, IPsec tweaks and fine tuning, and meaningful platform evolution. But the question remains: Will we?