T2TRG C. Amsüss
Internet-Draft March 25, 2019
Intended status: Experimental
Expires: September 26, 2019

rdlink: Robust distributed links to constrained devices


Thing to thing communication in Constrained RESTful Environments (CoRE) relies on URIs to link to servers. Next to hierarchical configuration and short-lived IP addresses, this document introduces a naming scheme for devices based on cryptographic identifiers. A special purpose domain is reserved for expressing those identifiers, and mechanisms for constrained devices to announce their names and to look them up are described.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 26, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

Communication between constrained devices using the CoAP protocol largely happens in either of two scenarios at the moment: local networks with static IP addresses, and communication mediated by dedicated servers.

Direct communication between constrained devices across the Internet is currently an exceptional setup, and usually involves static configuration or bespoke mechanisms.

Direct communication with a CoAP severs is often guided by web links which point to the URI that both names the server (and a resource on it), and indicates how that server can be reached. Such links often indicate registered name which is typically looked up in the DNS hierarchy and thus relies on the operator to own and administer a domain, If they don’t, they indicate an IP address; such links are of limited use for stable identifiers, e.g. due to mobile endpoints.

This document introduces a special purpose domain (rdlink.arpa) along the mechanisms with which it is used (employing a Distributed Hash Table (DHT)).

Constrained devices can announce and look up addresses without direct interaction with the DHT by interacting with a distributed resource directory ([I-D.ietf-core-resource-directory]).

Resolvable names are provided for compatibility with applications that are unaware of these provisions.

2. Terminology

2.1. Participants

This document uses several roles of devices:

named server
A CoAP server owns a name in the special purpose domain.
name user
A CoAP client that needs to resolve a name in the special purpose domain.
registration helper
A server that assists constrained named servers in announcing their names.
lookup helper
A serve rthat assists constrained name users in finding the named server.
DHT participant
Any device that is a node in the DHT overlay network.

Often, named servers act as name users towards other servers. The roles of registration helper, lookup helper and DHT participant are expected to be implemented together in typical use cases.

Note that a named server can act as a CoAP client towards a name user that has ongoing communication with it without being a name user on its own by just addressing the client on its own.

3. Auxiliary Mechanisms

This section describes mechanisms that are expected to be specified in different documents, which will then only be referenced.

3.1. The coap+at scheme

It is assumed that the CoRE working group at IETF will register a URI scheme coap+at:// that can be used with DNS names, and that allows expressing CoAP URIs independent of the used transport.

The mechanisms outlined in [I-D.silverajan-core-coap-protocol-negotiation] are assumed to be one way of finding protocol URIs (e.g. coap+tcp://...) that correspond to coap+at URIs when they are known to a Resource Directory.

3.2. The alternative-transport Link Relation Type

It is assumed that [I-D.silverajan-core-coap-protocol-negotiation] will have a parameter equivalent to the following:

This defines the alternate-transport Link Relation Type.

A link from a context resource to a target resource typed with the alternative-transport type declares that for any relative refernce of the path-noscheme or path-empty form (see [RFC3986] Section 4.2.), the reference’s resolution with the context as a Base URI can be substituted with the reference’s resolution with the target as a Base URI.

The expression “can be substituted with” means that for every REST operation conducted on the original resource, the same operation on the new resource will give equivalent responses and have equivalent side effects.

Applications interpreting alternative-transport links need to carefully consider their trust model: They MUST either have obtained the statement from a source that is trusted to speak for the context authority, or make additional demands on the target when connecting to it (e.g. ask the target to identify as the context authority).

[ If applications are defined for both CoAP and HTTP, and advertised the same way, hosts can onlly advertise alternatives if cross-proxying is possble; needs good generic phrasing. ]

This link relation is roughly equivalent to the at RD parameter introduced in [I-D.silverajan-core-coap-protocol-negotiation], but suitable for multicast discovery.

4. The rdlink.arpa special purpose domain

The domain rdlink.arpa is reserved to represent devices by their cryptographic identifer (described using the “cryptident” ABNF of the next section).

The rdlink.arpa domain does not provide DNS records for those names, but serves as a plain name for devices eligible to use their cryptident.

hostname = cryptident ".rdlink.arpa"

Names from this domain should probably only be used with the “coap+at” scheme, like this (assuming a host’s cryptident is “nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab”):


4.1. cryptident construction

cryptident = [ ext-ident "." ] cryptmain "." crypttype

The cryptident component describes a name under and describes a cryptographic identity the host can show, e.g. a public key, or the hash of a certificate.

The cryptmain component is base32 encoded binary data (as in [RFC4648], but lower case and without padding).

The crypttype is a registered designator for the meaning of cryptmain and ext-indent, which initially only has one value:

[ Names are currently given with the same encoding as cryptmain to map to numbers, that may be a good or a bad idea. ]

[ Whether OSCORE’s ID_CRED_x can be used in encoding this, or whether those can be substituted by a concept from HIP is up to further research; the rest of the document does not depend on the details of this construction. ]

4.2. Equivalent resolvable names

For compatibility with devices that do not support the role of a constrained name user or even the coap+at scheme, resolvable names can be provided under a regular domain:


Note that a domain can only support a single non-coap+at scheme, as the addresses used by a named server for coap and coap+tcp may differ. The name servers for this domain would use the method described in Section 6.1 to arrive at A/AAAA results.

Any equivalent URIs here create the issue of aliasing (see [RFC3986] Section 6). No more than two different names should be available for a device when this document has stabilized (and even that number would need to be justified, e.g. because one version leads to enhanced backwards compatibility while the other has different benefits).

5. Announcing addresses

A named server has several ways of making itself available to clients:

5.1. Direct announcement

Protocol-qualified transport addresses for cryptidents are announced by placing an entry in a global Distribuetd Hash Table (DHT).

The details of this are not yet laid out for this document, but [I-D.jimenez-t2trg-drd] already describes such a mechanism.

Entries in the DHT would contain:

DHT participants and lookup helpers should verify the signatures on entries they propagate, but may do so only occasionally, or only when they detect duplicate entries.

For the signatures in which the registration helper creates a signed datum, it may make sense to use an unpredictable timestamping scheme (eg. the latest headlines from a widespread newspaper, or the head hash of a given block chain) to prevent malicious RD servers from staying in control of the route to a given cryptident even after that device has picked a different RD server.

5.2. Announcement via a registration helper

Constrained named servers can enter their announcement by executing the RD registration operation ([I-D.ietf-core-resource-directory] Section 5) on a registraiton helper.

The registrant (= constrained named server) does not need to send a cryptident or other endpoint identifier; the helper will construct the cryptident from the chosen authentication method and construct an endpoint name from it.

The registrant may send a base URI (but may just as well rely on the RD (= the registration helper) to announce its network address). An alternative transport option (at=; [I-D.silverajan-core-coap-protocol-negotiation] Section 4.1) indicating the coap+at rdlink.arpa URI constructed from the cryptident is implicitly configured by the RD.

While performing the authentication step, the RD ensures that the registrant signs a timestamp and its IP address by embedding them in the OSCORE C_V. [ Or something similar, this part is still very experimental. ]

The registrant may submit discovereble resources with its registration, but it is exepcted that most clients will only reveal them later to authenticated clients.

5.2.1. Finding a registration helper

The registrant can find a registration helper at the anycast address TBDv4 or TBDv6. The helpers work in “distinct registration point” mode (cf. [I-D.amsuess-core-rd-replication] Section 6.2), but do not implement the anycast variation suggested there in Section 6.2.2, but rather give their explicit unicast addresses in a full URI during path discovery to ensure that updates wind up with them. [ That should be added there in an updated rd-replication document ].

5.3. Local announcement

To enable the use of coap+at rdlink.arpa URIs even in absence of an announcement server (eg. on ad-hoc networks), endpoints should join the link- and site-local All CoAP Nodes groups, provide an alternative-transport link to their own address, and answer to filtered multicast requests as described in [RFC6690]:

Req: GET coap://ff02::fd/.well-known/core?href=coap+arpa://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa&rev=alternative-transport

Res: 2.05 Content

5.4. Not announcing addresses

A named server is under no obligation to make its name publicly visible, especially when it is not expecting to host services.

The generated name can still be of use: It can be used in direct communication that the device has initiated in the role of a CoAP client with a different server. When that server accesses the named server under role reversal, it can address it by a rdlink.arpa name.

6. Lookup of rdlink.arpa URIs

A name user has several ways of finding transports of an rdlink.arpa URI:

6.1. Direct lookup

Alternative transport URLs for a given coap+at rdlink.arpa URI can be looked up in the DHT described in Section 5.1; this mechanism is only conveniently usable by unconstrained devices.

6.2. RD lookup based

Analogous to Section 5.2, clients can perform endpoint lookup to find alternative transport URLs for a given coap+at rdlink.arpa URI.

Clients look up actual transport addresses based on a filter on the alternative transport attribute (eg. by requesting coap://[2001:db8::1]/rd-lookup/ep?at=coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa), and can specify the transport they are looking for using the transport type query parameter (tt=; [I-D.silverajan-core-coap-protocol-negotiation] Section 4.2).

Note that due to the distributed nature of this directory, lookups that do not specify an cryptident based URI can not be performed (as that would mean iterating through all published entries in the DHT); such requests are probably best answered with 4.00 “Bad Request”.

6.3. Local lookup

Alternative transports to a coap+at URI can be discovered using multicast; see Section 5.3 for an example.

7. Operation considerations

While the DHT can be run with very little management (probably just managing bootstrap servers), running the helpers at the anycast addresses will need some degree of management.

Steps to involve multiple parties in hosting such RD servers and policies that guide which of these servers are announced on the anycast addresses are to be developed in parallel to this document.

Device vendors may operate their servers under additional addresses, but are encouraged to join in the server pool. Devices may be configured to query such vendor servers by default, but need to use the public ones at least as a fallback.

Note that in private networks, operators may run their own helpers at the anycast addresses. If communication with other DHT nodes is not possible or administratively prohibited, discovery across such border is blocked, but the addresses used are still persistent, and discovery between services on the local network is unaffected.

While helpers may offer the proxy extension ([I-D.amsuess-core-resource-directory-extensions]), it is not expected that the public RD servers will offer that feature.

8. IANA considerations

[ TBD: alternative-transport ]

9. Security considerations

Alternative transports: “trusted to speak for” is usually not any resource on the device

[ … ]

10. References

10.1. Normative References

[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006.

10.2. Informative References

[I-D.amsuess-core-rd-replication] Amsuess, C., "Resource Directory Replication", Internet-Draft draft-amsuess-core-rd-replication-02, March 2019.
[I-D.amsuess-core-resource-directory-extensions] Amsuess, C., "CoRE Resource Directory Extensions", Internet-Draft draft-amsuess-core-resource-directory-extensions-00, January 2019.
[I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P. and C. Amsuess, "CoRE Resource Directory", Internet-Draft draft-ietf-core-resource-directory-20, March 2019.
[I-D.ietf-hip-rfc4423-bis] Moskowitz, R. and M. Komu, "Host Identity Protocol Architecture", Internet-Draft draft-ietf-hip-rfc4423-bis-20, February 2019.
[I-D.jimenez-t2trg-drd] Jimenez, J., Liu, M. and E. Harjula, "A Distributed Resource Directory (DRD)", Internet-Draft draft-jimenez-t2trg-drd-00, March 2018.
[I-D.silverajan-core-coap-protocol-negotiation] Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", Internet-Draft draft-silverajan-core-coap-protocol-negotiation-09, July 2018.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012.

Appendix A. Ideas for the future of this document

Appendix B. Existing approaches that don’t solve the complete problem

Author's Address

Christian Amsüss Hollandstr. 12/4 1020 Austria Phone: +43-664-9790639 EMail: christian@amsuess.com

Table of Contents