idnits 2.17.1 draft-amsuess-t2trg-rdlink-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 60 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 147: '...rust model: They MUST either have obta...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2019) is 1852 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-amsuess-core-resource-directory-extensions-00 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-20 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T2TRG C. Amsuess 3 Internet-Draft March 25, 2019 4 Intended status: Experimental 5 Expires: September 26, 2019 7 rdlink: Robust distributed links to constrained devices 8 draft-amsuess-t2trg-rdlink-00 10 Abstract 12 Thing to thing communication in Constrained RESTful Environments 13 (CoRE) relies on URIs to link to servers. Next to hierarchical 14 configuration and short-lived IP addresses, this document introduces 15 a naming scheme for devices based on cryptographic identifiers. A 16 special purpose domain is reserved for expressing those identifiers, 17 and mechanisms for constrained devices to announce their names and to 18 look them up are described. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 26, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 Communication between constrained devices using the CoAP protocol 55 largely happens in either of two scenarios at the moment: local 56 networks with static IP addresses, and communication mediated by 57 dedicated servers. 59 Direct communication between constrained devices across the Internet 60 is currently an exceptional setup, and usually involves static 61 configuration or bespoke mechanisms. 63 Direct communication with a CoAP severs is often guided by web links 64 which point to the URI that both names the server (and a resource on 65 it), and indicates how that server can be reached. Such links often 66 indicate registered name which is typically looked up in the DNS 67 hierarchy and thus relies on the operator to own and administer a 68 domain, If they don't, they indicate an IP address; such links are of 69 limited use for stable identifiers, e.g. due to mobile endpoints. 71 This document introduces a special purpose domain (rdlink.arpa) along 72 the mechanisms with which it is used (employing a Distributed Hash 73 Table (DHT)). 75 Constrained devices can announce and look up addresses without direct 76 interaction with the DHT by interacting with a distributed resource 77 directory ([I-D.ietf-core-resource-directory]). 79 Resolvable names are provided for compatibility with applications 80 that are unaware of these provisions. 82 2. Terminology 84 2.1. Participants 86 This document uses several roles of devices: 88 named server A CoAP server owns a name in the special purpose 89 domain. 91 name user A CoAP client that needs to resolve a name in the special 92 purpose domain. 94 registration helper A server that assists constrained named servers 95 in announcing their names. 97 lookup helper A serve rthat assists constrained name users in 98 finding the named server. 100 DHT participant Any device that is a node in the DHT overlay 101 network. 103 Often, named servers act as name users towards other servers. The 104 roles of registration helper, lookup helper and DHT participant are 105 expected to be implemented together in typical use cases. 107 Note that a named server can act as a CoAP client towards a name user 108 that has ongoing communication with it without being a name user on 109 its own by just addressing the client on its own. 111 3. Auxiliary Mechanisms 113 This section describes mechanisms that are expected to be specified 114 in different documents, which will then only be referenced. 116 3.1. The coap+at scheme 118 It is assumed that the CoRE working group at IETF will register a URI 119 scheme "coap+at://" that can be used with DNS names, and that allows 120 expressing CoAP URIs independent of the used transport. 122 The mechanisms outlined in 123 [I-D.silverajan-core-coap-protocol-negotiation] are assumed to be one 124 way of finding protocol URIs (e.g. "coap+tcp://...") that correspond 125 to "coap+at" URIs when they are known to a Resource Directory. 127 3.2. The alternative-transport Link Relation Type 129 It is assumed that [I-D.silverajan-core-coap-protocol-negotiation] 130 will have a parameter equivalent to the following: 132 This defines the "alternate-transport" Link Relation Type. 134 A link from a context resource to a target resource typed with the 135 "alternative-transport" type declares that for any relative refernce 136 of the path-noscheme or path-empty form (see [RFC3986] Section 4.2.), 137 the reference's resolution with the context as a Base URI can be 138 substituted with the reference's resolution with the target as a Base 139 URI. 141 The expression "can be substituted with" means that for every REST 142 operation conducted on the original resource, the same operation on 143 the new resource will give equivalent responses and have equivalent 144 side effects. 146 Applications interpreting "alternative-transport" links need to 147 carefully consider their trust model: They MUST either have obtained 148 the statement from a source that is trusted to speak for the context 149 authority, or make additional demands on the target when connecting 150 to it (e.g. ask the target to identify as the context authority). 152 [ If applications are defined for both CoAP and HTTP, and advertised 153 the same way, hosts can onlly advertise alternatives if cross- 154 proxying is possble; needs good generic phrasing. ] 156 This link relation is roughly equivalent to the "at" RD parameter 157 introduced in [I-D.silverajan-core-coap-protocol-negotiation], but 158 suitable for multicast discovery. 160 4. The rdlink.arpa special purpose domain 162 The domain rdlink.arpa is reserved to represent devices by their 163 cryptographic identifer (described using the "cryptident" ABNF of the 164 next section). 166 The rdlink.arpa domain does not provide DNS records for those names, 167 but serves as a plain name for devices eligible to use their 168 cryptident. 170 hostname = cryptident ".rdlink.arpa" 172 Names from this domain should probably only be used with the 173 "coap+at" scheme, like this (assuming a host's cryptident is 174 "nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab"): 176 coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa/.well-known/core 178 4.1. cryptident construction 180 cryptident = [ ext-ident "." ] cryptmain "." crypttype 182 The "cryptident" component describes a name under and describes a 183 cryptographic identity the host can show, e.g. a public key, or the 184 hash of a certificate. 186 The cryptmain component is base32 encoded binary data (as in 187 [RFC4648], but lower case and without padding). 189 The crypttype is a registered designator for the meaning of cryptmain 190 and ext-indent, which initially only has one value: 192 [ Names are currently given with the same encoding as cryptmain to 193 map to numbers, that may be a good or a bad idea. ] 194 o "ab": cryptmain is a 160bit number that represents an ed25519 195 public key. 197 A host proves being eligible to use this name by performing an 198 EDHOC exchange in which the host demonstrates the ability to use 199 that key as a Raw Public Key. 201 o "ac": cryptmain is the 256bit hash value of a certificate using 202 hash algorithm TBD. (Longer hashes would need changes in how this 203 is put into DNS compatible names) 205 A host proves being eligible to use this name by performing an 206 EDHOC exchange in which it demonstrates possession of the secret 207 key indicated in the certificate. 209 o "ad": Like "ac", but referring to any certificate in a chain. 211 For this crypttype, the common names in a certificate chain are 212 concatenated [ how exactly is TBD ] into an ext-ident. 214 A host proves being eligible to use this name by performing an 215 EDHOC exchange in which it demonstrates possession of any 216 certificate together with a certificate chain to a certificate 217 with the given hash where the certificate chain gives the claimed 218 ext-ident name. 220 [ Whether OSCORE's "ID_CRED_x" can be used in encoding this, or 221 whether those can be substituted by a concept from HIP is up to 222 further research; the rest of the document does not depend on the 223 details of this construction. ] 225 4.2. Equivalent resolvable names 227 For compatibility with devices that do not support the role of a 228 constrained name user or even the coap+at scheme, resolvable names 229 can be provided under a regular domain: 231 coap://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rd.link/.well-known/core 233 Note that a domain can only support a single non-coap+at scheme, as 234 the addresses used by a named server for coap and coap+tcp may 235 differ. The name servers for this domain would use the method 236 described in Section 6.1 to arrive at A/AAAA results. 238 Any equivalent URIs here create the issue of aliasing (see [RFC3986] 239 Section 6). No more than two different names should be available for 240 a device when this document has stabilized (and even that number 241 would need to be justified, e.g. because one version leads to 242 enhanced backwards compatibility while the other has different 243 benefits). 245 5. Announcing addresses 247 A named server has several ways of making itself available to 248 clients: 250 5.1. Direct announcement 252 Protocol-qualified transport addresses for cryptidents are announced 253 by placing an entry in a global Distribuetd Hash Table (DHT). 255 The details of this are not yet laid out for this document, but 256 [I-D.jimenez-t2trg-drd] already describes such a mechanism. 258 Entries in the DHT would contain: 260 o Key: the cryptident 262 o Value: 264 * URLs that are alternative transports to the entry's 265 coap+at://...rdlink.arpa URI 267 * A time stamp of the registration and its lifetime 269 * If the cryptident alone is insufficient to verify signatuers 270 from it: additional information on the cryptident, eg. a 271 certificate (chain) for "ab" and "ac". 273 * If available in the crypttype: A signature on on the rest of 274 the value, signed by the owner of the cryptident. 276 As a registration helper can not provide such a signature, 277 instead of a signature on the entry there can be a signed datum 278 that proves that the announcer was contacted by the identified 279 device at a given time using the RD registration interface. 281 DHT participants and lookup helpers should verify the signatures on 282 entries they propagate, but may do so only occasionally, or only when 283 they detect duplicate entries. 285 For the signatures in which the registration helper creates a signed 286 datum, it may make sense to use an unpredictable timestamping scheme 287 (eg. the latest headlines from a widespread newspaper, or the head 288 hash of a given block chain) to prevent malicious RD servers from 289 staying in control of the route to a given cryptident even after that 290 device has picked a different RD server. 292 5.2. Announcement via a registration helper 294 Constrained named servers can enter their announcement by executing 295 the RD registration operation ([I-D.ietf-core-resource-directory] 296 Section 5) on a registraiton helper. 298 The registrant (= constrained named server) does not need to send a 299 cryptident or other endpoint identifier; the helper will construct 300 the cryptident from the chosen authentication method and construct an 301 endpoint name from it. 303 The registrant may send a base URI (but may just as well rely on the 304 RD (= the registration helper) to announce its network address). An 305 alternative transport option (at=; 306 [I-D.silverajan-core-coap-protocol-negotiation] Section 4.1) 307 indicating the coap+at rdlink.arpa URI constructed from the 308 cryptident is implicitly configured by the RD. 310 While performing the authentication step, the RD ensures that the 311 registrant signs a timestamp and its IP address by embedding them in 312 the "OSCORE C_V". [ Or something similar, this part is still very 313 experimental. ] 315 The registrant may submit discovereble resources with its 316 registration, but it is exepcted that most clients will only reveal 317 them later to authenticated clients. 319 5.2.1. Finding a registration helper 321 The registrant can find a registration helper at the anycast address 322 TBDv4 or TBDv6. The helpers work in "distinct registration point" 323 mode (cf. [I-D.amsuess-core-rd-replication] Section 6.2), but do not 324 implement the anycast variation suggested there in Section 6.2.2, but 325 rather give their explicit unicast addresses in a full URI during 326 path discovery to ensure that updates wind up with them. [ That 327 should be added there in an updated rd-replication document ]. 329 5.3. Local announcement 331 To enable the use of coap+at rdlink.arpa URIs even in absence of an 332 announcement server (eg. on ad-hoc networks), endpoints should join 333 the link- and site-local All CoAP Nodes groups, provide an 334 alternative-transport link to their own address, and answer to 335 filtered multicast requests as described in [RFC6690]: 337 Req: GET coap://ff02::fd/.well-known/core?href=coap+arpa://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa&rev=alternative-transport 339 Res: 2.05 Content 340 ;rev="alternative-transport" 342 5.4. Not announcing addresses 344 A named server is under no obligation to make its name publicly 345 visible, especially when it is not expecting to host services. 347 The generated name can still be of use: It can be used in direct 348 communication that the device has initiated in the role of a CoAP 349 client with a different server. When that server accesses the named 350 server under role reversal, it can address it by a rdlink.arpa name. 352 6. Lookup of rdlink.arpa URIs 354 A name user has several ways of finding transports of an rdlink.arpa 355 URI: 357 6.1. Direct lookup 359 Alternative transport URLs for a given coap+at rdlink.arpa URI can be 360 looked up in the DHT described in Section 5.1; this mechanism is only 361 conveniently usable by unconstrained devices. 363 6.2. RD lookup based 365 Analogous to Section 5.2, clients can perform endpoint lookup to find 366 alternative transport URLs for a given coap+at rdlink.arpa URI. 368 Clients look up actual transport addresses based on a filter on the 369 alternative transport attribute (eg. by requesting 370 "coap://[2001:db8::1]/rd-lookup/ 371 ep?at=coap+at://nbswy3dpo5xxe3denbswy3dpo5xxe3de.ab.rdlink.arpa"), 372 and can specify the transport they are looking for using the 373 transport type query parameter (tt=; 374 [I-D.silverajan-core-coap-protocol-negotiation] Section 4.2). 376 Note that due to the distributed nature of this directory, lookups 377 that do not specify an cryptident based URI can not be performed (as 378 that would mean iterating through all published entries in the DHT); 379 such requests are probably best answered with 4.00 "Bad Request". 381 6.3. Local lookup 383 Alternative transports to a coap+at URI can be discovered using 384 multicast; see Section 5.3 for an example. 386 7. Operation considerations 388 While the DHT can be run with very little management (probably just 389 managing bootstrap servers), running the helpers at the anycast 390 addresses will need some degree of management. 392 Steps to involve multiple parties in hosting such RD servers and 393 policies that guide which of these servers are announced on the 394 anycast addresses are to be developed in parallel to this document. 396 Device vendors may operate their servers under additional addresses, 397 but are encouraged to join in the server pool. Devices may be 398 configured to query such vendor servers by default, but need to use 399 the public ones at least as a fallback. 401 Note that in private networks, operators may run their own helpers at 402 the anycast addresses. If communication with other DHT nodes is not 403 possible or administratively prohibited, discovery across such border 404 is blocked, but the addresses used are still persistent, and 405 discovery between services on the local network is unaffected. 407 While helpers may offer the proxy extension 408 ([I-D.amsuess-core-resource-directory-extensions]), it is not 409 expected that the public RD servers will offer that feature. 411 8. IANA considerations 413 [ TBD: alternative-transport ] 415 9. Security considerations 417 Alternative transports: "trusted to speak for" is usually not any 418 resource on the device 420 [ ... ] 422 ... 424 10. References 425 10.1. Normative References 427 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 428 Resource Identifier (URI): Generic Syntax", STD 66, 429 RFC 3986, DOI 10.17487/RFC3986, January 2005, 430 . 432 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 433 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 434 . 436 10.2. Informative References 438 [I-D.amsuess-core-rd-replication] 439 Amsuess, C., "Resource Directory Replication", draft- 440 amsuess-core-rd-replication-02 (work in progress), March 441 2019. 443 [I-D.amsuess-core-resource-directory-extensions] 444 Amsuess, C., "CoRE Resource Directory Extensions", draft- 445 amsuess-core-resource-directory-extensions-00 (work in 446 progress), January 2019. 448 [I-D.ietf-core-resource-directory] 449 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 450 Amsuess, "CoRE Resource Directory", draft-ietf-core- 451 resource-directory-20 (work in progress), March 2019. 453 [I-D.ietf-hip-rfc4423-bis] 454 Moskowitz, R. and M. Komu, "Host Identity Protocol 455 Architecture", draft-ietf-hip-rfc4423-bis-20 (work in 456 progress), February 2019. 458 [I-D.jimenez-t2trg-drd] 459 Jimenez, J., Liu, M., and E. Harjula, "A Distributed 460 Resource Directory (DRD)", draft-jimenez-t2trg-drd-00 461 (work in progress), March 2018. 463 [I-D.silverajan-core-coap-protocol-negotiation] 464 Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", 465 draft-silverajan-core-coap-protocol-negotiation-09 (work 466 in progress), July 2018. 468 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 469 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 470 . 472 Appendix A. Ideas for the future of this document 474 o Add a note on how to deal with PSK cases 476 * Often the PSKs will stem from a previous RPK or certificate 477 process, in which case that base URI persists. 479 * If not, how did HIP deal with them? We could sure look them up 480 in the DHT, but anyone may spam them. 482 * If it gets established in EDHOC that the implicit Uri-Host 483 values in an EDHOC-derived PSK pair are the original key 484 material's (which'd make sense IMO), does this affect the 485 usability of implicit base in Section 5.2? (After all, the 486 implicit role inversion address would be coap+hash:// then.) 488 o Add notes on TLS/DTLS 490 Conceptually all of this should work on TLS/DTLS as well. 492 Appendix B. Existing approaches that don't solve the complete problem 494 o IPv6 stable mobile addresses 496 Didn't take off. 498 o HIP / ORCHIDv2 500 Feasible alternative, nice CIRI-compact addresses. Stack support 501 unclear. Not extensible to sub-names (dev123.HASHHASHHASH - or 502 can it, with notarized identities?). Hard limit on hash lengths 503 (eg. Tor went from 80bit to 160bit, can't do that). 505 Using them at application layer only might be an option (cf. 506 [I-D.ietf-hip-rfc4423-bis] last paragraph of introduction) See 507 whether HIP's DoS protection can be applied in EDHOC. 509 Keep reading. 511 o RD-DNS-SD 513 Hierarchical or limited to link-local. 515 o TOR 517 basically got it right, just that we don't do onion routing here, 518 and pull protocol negotiation in. 520 (might even consider 1:1 using their addresses, or at least take 521 much from the discussion at 522 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt -> 523 ONIONADDRESS-REFS); given we're likely never to write addresses by 524 hand, checksumming might be left out, and version move to 525 "domain". 527 o IPFS / IPNS 529 Doesn't integrate well into URIs. Uses a concept of multihashes 530 that has inspired the current cryptident design. 532 Author's Address 534 Christian Amsuess 535 Hollandstr. 12/4 536 1020 537 Austria 539 Phone: +43-664-9790639 540 Email: christian@amsuess.com