To unleash the large potential of IoT, there is a need for new innovative solutions designed to meet the challenges of operating at “IoT scale”. This leads to requirements for managing services and devices in extremely large deployments, like the need for highly automated processes. At the same time, there can be no compromise to security and solutions must be applicable to a wide range of devices (from constrained to powerful).
One of these needs is the ability for devices to discover the data services or IoT platforms with which the devices will communicate, without relying upon any predefined configuration settings.
Today, most IoT devices are shipped with some level of hardcoded, static configurations. However, when an organization deploys devices across different environments, custom configurations are required. For example, a sensor installed in the home may connect to a centralized Web service while the same sensor deployed in a hospital may connect to a local, private service. Each batch of devices must be customized, depending upon deployment location. In another use case, the device could be activated several months or years after leaving the production line, and in the meantime the endpoint to which it should connect to will have changed.
Customizing and managing these changes are labor and cost intensive to implement, due to the sheer number of devices in the field. Since network environments are dynamic, connected devices need to be flexible and adaptable so that they can remain properly configured and avoid service disruption without manual intervention. Any form of dynamic device configuration must be secured to prevent a malicious actor from misdirecting a device.
Using the IETF DNS-SD standard (RFC 6763) and the IETF secure DNS, or DNSSEC, standard (RFCs 4033, 4034, and 4035), administrators can dynamically provision and publish service endpoint addresses, custom device configuration parameters, and connection information to support diverse and changing network environments.
Using Eclipse Tiaki, devices can securely discover this configuration over either the Internet or a private network and then validate the source of the configuration to ensure that it has come from a trusted party.
The aim of the Eclipse Tiaki Project is to provide a set of libraries implementing the IETF DNS-SD and DNSSEC standards to enable secure DNS lookup requests for service endpoint addresses, service types and connection information. Optionally, lookup requests may enforce the use of a specific DNS Server, validate its DNSSEC compliance and use a specific trust anchor for closed environments. Developers who use the Eclipse Tiaki Project can take advantage of the capability of these standards without needing to understand the details of DNS.
The Eclipse Tiaki project is comprised of two libraries.
The Discovery Library is a Java SDK that provides DNS lookup functionality that implements the IETF DNS-SD (RFC 6763) standard. It can be used as a Java Library to lookup PTR and associated SRV and TXT Resource Records within a DNS zone.
The second library, the Discovery CLI, is a command-line interface to the Discovery Library which allows the client to make use of the discovery functionality from a terminal session.
The dynamic and secure discovery of services for IoT devices is a critical step in any IoT deployment. A wider adoption by the community will increase the security of IoT on a global scale. The Eclipse IoT open source community is therefore an ideal host to promote this adoption.
Eclipse Tiaki fits well with a number of existing IoT Eclipse projects. Typically, Eclipse Kura gateways can utilize Tiaki to securely discover their message brokers without any hard coded configuration. Similarly, Eclipse Leshan could make use of Eclipse Tiaki to perform Client Initiated Bootstrap without pre-provisioning a Bootstrap server.
The initial source code for both libraries is already available from Verisign's GitHub account under
We will release equivalent libraries in C shortly.
In terms of new features, we are thinking of providing a functionality to look up arbitrary records from DNS (TLSA, etc.) and validate the associated DNSSEC Resource Records. Also, we would like to make use of DHCP Search Domains to retrieve default FQDNs.