Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Tiaki
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)[1] 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 Discovery library leverages the DNSJava[2] and DNSSECJava libraries to look up and validate the DNS Resource Records’ authenticity.
It has been tested against Bind 9 DNS Server [3]
[1] https://www.ietf.org/rfc/rfc6763.txt
[2] http://dnsjava.org/
[3] https://www.isc.org/downloads/bind/
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.
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.
The initial source code for both libraries is already available from Verisign's GitHub account under
- https://github.com/verisign/iot-discovery-services
- https://github.com/verisign/iot-discovery-jcli
Eclipse Kura / Eurotech (early discussions)
Sierra Wireless (Julien Vermillard)
Bosch Software Innovation (Kai Hudalla)
The com.verisign.iot.discovery.services.DnsDiscovery interface provides the entry point to the Discovery Library functionalities.
- listServiceTypes: looks up DNS for all available service types in a a given domain name (DNS Zone)
- listServiceInstances: looks up DNS for all available service instances for a given service type and domain name (DNS Zone)
- listServiceRecords: looks up DNS for all available service records for a given service type and domain name (DNS Zone)
- listTextRecords : looks up DNS for all available TXT records for a given domain name (DNS Zone)
Each of these methods takes a boolean parameter, secValidation, which indicates whether or not the DNSSEC validation must be performed.
The com.verisign.iot.discovery.domain.Fqdn class, which represents a Fully Qualified Domain Name, is used as a parameter to all of these functions. Its value represents the DNS Zone under which the lookup is performed.
The iot-discovery-jcli library provides a command-line interface to the Discovery Library. It can be used as follows:
Usage: java -jar iot-discovery-jcli-1.0.jar [<command>[<arg>]] [options]
Commands:
-h, --help Display this usage and quit.
-i, --list-instances Detailed display of service instances; -s and -d are required.
-l, --list-services Display the service types; -d is required.
-c [domain], --dnssec-status [domain] Check the DNSSEC status of 'domain'; if not specified, check against the default one.
-x [port:protocol], --tlsa [port:protocol] Display the TLSA records referring to the couple 'port:protocol' (default ones if not specified); -d and -s are required.
-t <label>, --text-record <label> Display the text records having 'label'; -d is required.
Options
-e, --insecure Inhibit the DNSSEC validation upon lookup.
-v, --verbose Display a verbose output of the resolution.
-n <resolvers>, --servers <resolvers> Comma-separated list of resolver servers, overriding the default ones.
-u <filename>, --trust-anchor <filename> Specify the file containing the trust anchor.
-d <domain>, --domain <domain> Specify the domain name to use upon resolution process.
-s <label>, --supplement <label> Specify a supplementary 'label' to concatenate/use to query for.
All code copyright Verisign Inc 2015
DNSSECJava : Eclipse Public License 1.0
DNSJava : BSD
Log4J : Apache 2.0
JUnit : Eclipse Public License 1.0
JoptSimple: MIT Public License
- Log in to post comments
- Log in to post comments
Alternative DNS-SD implementation in ECF
Submitted by Markus Kuppe on Wed, 06/10/2015 - 03:35
FWIW, ECF also has a DNS-SD implementation [1][2] based on DNSJava. Thus, there might be a chance to collaborate in some areas.
[1] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/providers/bundles/org.eclipse.ecf.provider.dnssd
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=310580