Internet DRAFT - draft-amsuess-t2trg-rdlink

draft-amsuess-t2trg-rdlink







T2TRG                                                         C. Amsuess
Internet-Draft                                        September 23, 2019
Intended status: Experimental
Expires: March 26, 2020


        rdlink: Robust distributed links to constrained devices
                     draft-amsuess-t2trg-rdlink-01

Abstract

   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 March 26, 2020.

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



Amsuess                  Expires March 26, 2020                 [Page 1]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   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.




Amsuess                  Expires March 26, 2020                 [Page 2]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   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.



Amsuess                  Expires March 26, 2020                 [Page 3]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   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"):

coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa/.well-known/core

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. ]



Amsuess                  Expires March 26, 2020                 [Page 4]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   o  "ab": cryptmain is a 160bit number that represents an ed25519
      public key.

      A host proves being eligible to use this name by performing an
      EDHOC exchange in which the host demonstrates the ability to use
      that key as a Raw Public Key.

   o  "ac": cryptmain is the 256bit hash value of a certificate using
      hash algorithm TBD.  (Longer hashes would need changes in how this
      is put into DNS compatible names)

      A host proves being eligible to use this name by performing an
      EDHOC exchange in which it demonstrates possession of the secret
      key indicated in the certificate.

   o  "ad": Like "ac", but referring to any certificate in a chain.

      For this crypttype, the common names in a certificate chain are
      concatenated [ how exactly is TBD ] into an ext-ident.

      A host proves being eligible to use this name by performing an
      EDHOC exchange in which it demonstrates possession of any
      certificate together with a certificate chain to a certificate
      with the given hash where the certificate chain gives the claimed
      ext-ident name.

   [ 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:

   coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rd.link/.well-known/core

   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



Amsuess                  Expires March 26, 2020                 [Page 5]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   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:

   o  Key: the cryptident

   o  Value:

      *  URLs that are alternative transports to the entry's
         coap+at://...rdlink.arpa URI

      *  A time stamp of the registration and its lifetime

      *  If the cryptident alone is insufficient to verify signatuers
         from it: additional information on the cryptident, eg. a
         certificate (chain) for "ab" and "ac".

      *  If available in the crypttype: A signature on on the rest of
         the value, signed by the owner of the cryptident.

         As a registration helper can not provide such a signature,
         instead of a signature on the entry there can be a signed datum
         that proves that the announcer was contacted by the identified
         device at a given time using the RD registration interface.

   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




Amsuess                  Expires March 26, 2020                 [Page 6]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   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]:




Amsuess                  Expires March 26, 2020                 [Page 7]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


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

Res: 2.05 Content
<coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa>;rev="alternative-transport"

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".








Amsuess                  Expires March 26, 2020                 [Page 8]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


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







Amsuess                  Expires March 26, 2020                 [Page 9]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


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,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

10.2.  Informative References

   [I-D.amsuess-core-rd-replication]
              Amsuess, C., "Resource Directory Replication", draft-
              amsuess-core-rd-replication-02 (work in progress), March
              2019.

   [I-D.amsuess-core-resource-directory-extensions]
              Amsuess, C., "CoRE Resource Directory Extensions", draft-
              amsuess-core-resource-directory-extensions-01 (work in
              progress), July 2019.

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
              Amsuess, "CoRE Resource Directory", draft-ietf-core-
              resource-directory-23 (work in progress), July 2019.

   [I-D.ietf-hip-rfc4423-bis]
              Moskowitz, R. and M. Komu, "Host Identity Protocol
              Architecture", draft-ietf-hip-rfc4423-bis-20 (work in
              progress), February 2019.

   [I-D.jimenez-t2trg-drd]
              Jimenez, J., Liu, M., and E. Harjula, "A Distributed
              Resource Directory (DRD)", draft-jimenez-t2trg-drd-00
              (work in progress), March 2018.

   [I-D.silverajan-core-coap-protocol-negotiation]
              Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation",
              draft-silverajan-core-coap-protocol-negotiation-09 (work
              in progress), July 2018.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/info/rfc6690>.





Amsuess                  Expires March 26, 2020                [Page 10]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


Appendix A.  Change log

   Since -00:

   o  Add point about DNS as a substrate rather than RDs, and semi-
      hierarchical lookups

   o  Add point about name evolution (considering trackability)

   o  Add references to more prior art and involved parties

Appendix B.  Ideas for the future of this document

   o  Add a note on how to deal with PSK cases

      *  Often the PSKs will stem from a previous RPK or certificate
         process, in which case that base URI persists.

      *  If not, how did HIP deal with them?  We could sure look them up
         in the DHT, but anyone may spam them.

      *  If it gets established in EDHOC that the implicit Uri-Host
         values in an EDHOC-derived PSK pair are the original key
         material's (which'd make sense IMO), does this affect the
         usability of implicit base in Section 5.2?  (After all, the
         implicit role inversion address would be coap+hash:// then.)

   o  Add notes on TLS/DTLS

      Conceptually all of this should work on TLS/DTLS as well.

   o  Like CoAP RD is a way to access the DHT RD, so can be DNS if one
      wants to implement it and it is defined for coap+at; lookups would
      be just whatever coap+at does, and a helper can be implemented to
      accept DNS record updates.  Clients could use it just as well,
      verifying DHT participants would just need to check another proof
      type.

      *  Checking more proof types is something where using mobile code
         might at some point in time become interesting.

   o  Same principles can be applied to proving possession of other
      domains' names

      Domains might configure their DNS servers to serve a part of the
      cryptident (needs to be full authorities then) space, and announce
      in DNSSEC that say for $DEV.devices.example.com, the PoP for that
      name needs to follow some certificate chain.



Amsuess                  Expires March 26, 2020                [Page 11]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   o  Describe name evolution: server may announce "<:hash1>
      alternative-transport <:hash2>" for some time to authenticated
      clients, and at some point in time start announcing the latter and
      only announce the former (stable URIs vs. trackability)

      could also announce several addresses for different clients -
      describe trade-offs

Appendix C.  Existing approaches that don't solve the complete problem

   o  IPv6 stable mobile addresses

      Didn't take off.

   o  HIP / ORCHIDv2

      Feasible alternative, nice CIRI-compact addresses.  Stack support
      unclear.  Not extensible to sub-names (dev123.HASHHASHHASH - or
      can it, with notarized identities?).  Hard limit on hash lengths
      (eg.  Tor went from 80bit to 160bit, can't do that).

      Using them at application layer only might be an option (cf.
      [I-D.ietf-hip-rfc4423-bis] last paragraph of introduction) See
      whether HIP's DoS protection can be applied in EDHOC.

      Keep reading.

   o  RD-DNS-SD

      Hierarchical or limited to link-local.

   o  TOR

      basically got it right, just that we don't do onion routing here,
      and pull protocol negotiation in.

      (might even consider 1:1 using their addresses, or at least take
      much from the discussion at
      https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt ->
      ONIONADDRESS-REFS); given we're likely never to write addresses by
      hand, checksumming might be left out, and version move to
      "domain".

   o  IPFS / IPNS

      Doesn't integrate well into URIs.  Uses a concept of multihashes
      that has inspired the current cryptident design.




Amsuess                  Expires March 26, 2020                [Page 12]

Internet-Draftrdlink: Robust distributed links to constraiSeptember 2019


   o  RFC6920 (ni hashes):

      Only identifies the hashed or public-key-signed content, but does
      not make it usable for REST operations or short (relative) names
      of different resources provided by that content / host.

      Its named information hash registry could serve as a template, but
      is probably too specific as it rules out RPK identifiers.

   o  DIDs:

      Not used directly in addressing, but they may be usable as a
      replacement for cryptmain.crypttype.

C.1.  Links for further research

   o  GNS (eg. as presented on IETF104: https://youtu.be/xXWzgn-dxrk)
      can be valuable input, esp. on verifying results w/o reading them.
      They have both crypographic global identifiers and "trust-
      local"(?) ones, the latter are probably not relevant here.

   o  DINRG should possibly be involved.

Author's Address

   Christian Amsuess
   Hollandstr. 12/4
   1020
   Austria

   Phone: +43-664-9790639
   Email: christian@amsuess.com



















Amsuess                  Expires March 26, 2020                [Page 13]