IoT deployments may include very large numbers of devices that roam across large geographic areas. These devices also display heterogenous data traffic patterns, sometimes participating in consistent flows and sometimes appearing inactive while in areas without connectivity.
Monitoring and tracking assets in such scenarios is a major impediment to large-scale IoT adoption. However, maintaining persistent identification of these assets is critical both for remote access to the devices as well as data provenance concerns (for example, GDPR laws).
Traditionally, networked assets are identified via their routable IP address. This allows easy correlation of the asset’s identity with the routable destination for command-and-control access and with the source of data generated by the asset.
However, the dispersed, mobile devices characteristic of IoT deployments have their IP addresses assigned by their respective connectivity providers. As the devices roam or their DHCP leases expire, these assigned IP addresses change. This is of particular concern when using LTE Internet service.
With changing IP addresses, the benefits of using these addresses as identities disappear. Attempting to track and manage these shifting addresses as part of an IoT architecture is extremely complex.
A common approach for mitigating this issue is to purchase public IP addresses from the connectivity provider to be statically assigned to the devices. In addition to being costly, this approach significantly increases the vulnerability of these devices by making them visible on the public Internet. Since the centralized security of an enterprise firewall or VPN cannot secure such assets, they must instead be secured individually, a daunting task at scale.
The overall IoT solution is forced to use a heterogenous address scheme, make security policies more complex and harder to maintain. In-field devices and backend servers use addressed managed by different entities, namely connectivity providers and the enterprise. Further, the public IP addresses change when a new connectivity providers is used or the device temporarily roams on a different network.
To avoid these problems and keep the identity management fully within the hands of the IoT solution owner, a different approach is to skip network-layer addresses and use the identities native to the application-layer.
This is a natural approach, keeping the device’s owner focused only on the one application protocol and seemingly consistent with the important end-to-end principle. For application protocols that support symmetric duplex communication, this also allows the correlation between the identity and its routable destination, as with the usage of IP addresses above.
However, this approach falls apart once the IoT architecture requires multiple data streams, all of which cannot travel via the one application protocol. A common example of this is a solution that uses a publish-subscribe (pub/sub) application protocol for typical data exchange, but also requires SSH access into the in-field devices for management. The application-layer cannot support this access, and correlating the identities used in the application protocol with IP addresses usable for SSH access is a major burden.
As an IPv6 overlay network, the Xaptum ENF uses IPv6 addresses as persistent identities that are independent of the IP addresses assigned to devices by their connectivity provider. This is a cryptographically-bound identity (the device proves ownership of that identity via its unique, hardware-protected private key) that remains assigned to the device for its lifetime.
This identity is routable, and so offers the same benefits as the traditional approach utilizing public IP addresses assigned by the connectivity provider. However, Xaptum IPv6 addresses are not publicly visible on the public Internet. And because the user has full control of the management and assignment of these IPv6 addresses, all of their devices use a uniform identity scheme no matter the nature of the device (using LTE, using Wifi, in the data center, in a public cloud, etc.).
As an IPv6 address, this identity is carried by all traffic in or out of that device, no matter the type of traffic. So whether it’s application data, remote access, secure firmware updating, or anything else, and even if the application protocol is changed, the user can identify the asset with a single persistent address.
As mentioned above, tracking the shifting last-mile addresses of diverse assets and correlating them to a persistent identity is an extremely complex task, one to which Xaptum has devoted a large engineering effort. This means the user of the ENF has a uniform identity scheme for all of their assets, no matter where an asset is located or how it’s connecting to the Internet, without having to manage the underlying complexity.