Enterprise networks have been transforming over the last decade with the Internet now serving as the new de facto corporate network. With the shift to cloud-hosted applications, Software-Defined WAN (SD-WAN), Secure Access Service Edge (SASE), and a socially-distanced remote workforce, the corporate Internet perimeter is all but eroded. Enterprises can no longer assume that if the user is “on the internal corporate network” they are automatically trusted. Corporations are wisely moving from a “most privileged” to a “least privileged” security model. As a result, enterprises and security vendors have locked onto the term “Zero Trust“, which is rapidly becoming an overused and overloaded term for a what is essentially a perimeter-less (i.e., “no perimeter”) security model.
With so many of the enterprise end-user population working remotely, using 4G/5G wireless services and/or residential broadband, they could likely already be using IPv6—a fact their network or security administrators may be unaware of. Indeed, many organizations are still in denial of how much IPv6 usage there is on the Internet and how many employees, contractors, vendors, and suppliers are already using IPv6. This is a serious blind spot for security and network teams. But IPv6 has some unique characteristics that lend itself to new ways of thinking about network and host security and for facilitating the security of end users and application services.
Characteristics of a Zero-Trust Architecture
The concept of de-perimeterization was first introduced 15 years ago by The Open Group (formerly the Jericho Forum) which created the concept of an orbital security model wherein the inner rings contain the most important data assets and the outer rings contain the least-trusted or completely untrusted Internet. Concepts like the Cloud Security Alliance (CSA) Software-Defined Perimeter (SDP) evolved through the work of Google’s BeyondCorp. The term Zero-Trust was popularized by John Kindervag, while working at Forrester.
NIST released their Special Publication 800-207 titled “Zero Trust Architecture” in August 2020, which defines the key tenets of a ZTA and describes design components and deployment use cases. Key pillars of Zero-Trust include least-privilege access to applications and data, authentication of end users, validation of their location and device context, and deep visibility to both IPv4 and IPv6 communications.
Restoration of the End-to-End Communications Model and Zero-Trust Impacts
One of the important characteristics of IPv6 is its abundance of global IPv6 addresses, obsoleting the need for NAT to solve the public IPv4 depletion problem. Without NATs in the middle of client-server communications, the application server actually receives the unmodified connection from the source IPv6 address of the client. Coincidentally, the end-to-end model of IP communications was the original way the Internet was intended to function.
With the constraints of IPv4 addresses, NATs have become plentiful, thus obfuscating client IPv4 addresses. As a result, servers may not be able to validate the identity of client connections. Other forms of authenticating the end user become important. This creates problems for reputation filtering and for applications trying to use the client IPv4 address as a method of authentication or detecting and blocking fraudulent transactions. Now, IPv4 addresses have become only “locally significant” with the domain or zone where they are used. This makes us question the legitimacy of IPv4 connections and possibly consider IPv6 connections as somehow more trustworthy.
Using the IPv6 Address for Security
One of the unique characteristics of IPv6 is its incredibly large 128-bit addresses. The address space is so large that there is potential to use the last 64-bits of the address (the Interface Identifier or IID) for security purposes. These techniques are not feasible with the limited supply of IPv4 addresses. Methods of changing the IPv6 node’s IID frequently take a page from the network attacker’s playbook and “fast flux” techniques. An example of this is when temporary IPv6 IIDs change periodically to help preserve the privacy of the end-user. It is also likely that you might read an older book on IPv6 Security where the concepts of Secure Neighbor Discovery (SEND) (RFC 3971) and Cryptographically Generated Addresses (CGA) (RFC 3972) were used to leverage the IPv6 IID to provide privacy and authenticate locally-connected nodes. Neither of these methods were broadly adopted, however.
One innovative approach, illustrated below, is to have an IPv6-capable DNS service coordinate its responses with a web-tier application front-end. One example of this is a custom DNS function that works with web servers, or load balancers that can have Web Application Firewall (WAF) capabilities. The communication is initiated by a client asking its caching DNS resolver the address of a server’s fully-qualified domain name (FQDN). The authoritative DNS server returns a AAAA record response with an IPv6 address with a seemingly random IID (with a very low TTL value). The IID is actually a unique identifier that is solely specified for that particular client device (or DNS resolver). The authoritative DNS server coordinates the IID selected for the AAAA response with the front-end web-tier application service. The client makes the connection to the IPv6 address with the curated IID. When the connection from the client is initiated, the front-end web server knows that client is the device that made the connection. This method can be used to separate legitimate traffic from DDoS traffic. This technique could be extended to have the IID of the AAAA record response use some type of client-identifier for Zero-Trust application access or as part of a Cloud Access Security Broker (CASB) service.
Another example of how the IPv6 IID can be used for authenticating client connections is the Tosh SSH server. Tosh is an IPv6-only SSH server that uses the last 6 hex digits of the IID to create a Time-Based One-Time Password (TOTP) code that changes every 30 seconds. This uses the IID like a Two-Factor-Authentication (2FA) or Multi-Factor-Authentication (MFA) system whereby the server’s IPv6 address is the “something you know” part of MFA.
The idea of using the vastness of the IPv6 IID isn’t necessarily new. Back in 2011, Moving Target IPv6 Defense (MT6D) was a system created by graduate students in the IT Security Laboratory (ITSL) at Virginia Tech to obscure IPv6 addresses and prevent eavesdropping. It uses an algorithm that a pair of hosts use to change their IPv6 addresses dynamically and that allows the hosts to predict the other’s next IPv6 address. The IIDs of both ends of the communications change, based on some algorithm and key only known to the two nodes. This method makes interception of the communications more difficult and prevents any attacker from sending an IPv6 packet to either node because their IPv6 addresses are constantly changing. Moving Target Defense (MTD) methods have been considered for many years, but can now be realized with IPv6 because the IID offers far more potential than IPv4’s constrained address space. However, it would likely require that a full /64 be routed to the host to avoid potential neighbor exhaustion issues if many devices on the same /64 network were also using this technique.
Back in 2012, MITRE described a method of leveraging the IPv6 IID for security purposes in what it calls the “Identity-Based Internet Protocol (IBIP)”. This technique, described in their factsheet, uses Common Access Card (CAC) credentials to form a 40-bit user ID, and uses the computer’s Trusted Platform Module (TPM) to form a 40-bit host ID. These are used to create an IPv6 IID that uniquely identifies the client and is seemingly random, preserving the privacy of the end-user like privacy addresses (RFC 8981). This IBIP can be integrated with IEEE 802.1x, Software-Defined Perimeter (SDP), Single-Packet Authorization (SPA), and other security purposes.
Greenfield IPv6 deployments often start with a newly-minted and elegant IPv6 address plan. With the proper IPv6 addressing architecture, an enterprise can have cleaner, less-complicated boundary filters and more granular filtering that facilitates micro-segmentation and host isolation. This allow for security to be a key consideration in all IPv6 address planning endeavors.
Another creative approach could be to use multiple IPv6 addresses on a local segment. The local first-hop router could send an ICMPv6 type 134 Router Advertisement (RA) with two /64 IPv6 prefixes. One /64 prefix could be preferred for outbound Internet communications and a second, less-preferred /64 prefix could be used for administrative internal-only connectivity to sensitive applications. Alternatively, networks could use a single /64 prefix but nodes could configure multiple IIDs on their interfaces for various levels of trust.
Handling the Neighbor Cache Timeout
A key consideration with these types of methods, where the server’s IID is changing frequently, or for each individual connection, is that the neighbor cache of the server and its first-hop router will fill up quickly. For example, the Tosh SSH server’s IID changes every 30 seconds, so in 4 hours this would produce 480 neighbor cache entries. There are solutions to this problem, like limiting the number of neighbor-cache entries or setting a very short neighbor-cache timeout, among others.
On a Cisco router, you can limit the number of entries in the neighbor cache (100, in the example below) of a particular interface using the following command. Note: this command can be applied both to a particular interface (as shown here) or globally, which would apply it to all interfaces on the router.
interface GigabitEthernet0/0/0
ipv6 nd cache interface-limit 100
Another option is to reduce the neighbor cache timeout on the interface to less than the default 4 hours (14,400 seconds). Cisco calls this “Enhanced IPv6 Neighbor Cache Management“. The first of the following commands learns the neighbor cache entries from observed unsolicited NAs and the second command reduces the neighbor cache expire timeout to 60 seconds (before it expires and deletes STALE cache entries).
interface GigabitEthernet0/0/0
ipv6 nd na glean
ipv6 nd cache expire 60
Another possible solution to the problem of the server-side neighbor-cache filling up due to changing server IIDs is to dedicate an entire /64 prefix to the individual web server. There have been proposals to assign a /64 prefix to individual hosts to facilitate software containers inside that host/node, for improved host isolation, micro-segmentation, and to mitigate security issues like link-local IPv6 host reconnaissance (RFC 7707). This technique is defined in the IETF RFC titled “Unique IPv6 Prefix per Host” (RFC 8273). An example of this can be found in a recent AWS announcement whereby AWS now lets you assign an entire IPv4 or IPv6 prefix to a single EC2 instance.
Summary
For decades we have been constrained by the limited 32-bit IPv4 address space. We have endured and persevered with these limitations, used NAT heavily, and basically assumed this is how the world is and we are powerless to change it. Now, with IPv6, we can shed these old ways of thinking that IP addresses are a preciously scarce commodity. This liberating realization of IPv6’s address abundance allows us to think differently about how IPv6 addresses are used for securing client-server communications. It is certain that IPv6 will facilitate innovation and we will see many more techniques developed along these lines to improve security and help achieve Zero-Trust architectures.
I am the CTO of HexaBuild.io, an IPv6 consulting and training company. Follow HexaBuild on Twitter and LinkedIn.
