idnits 2.17.00 (12 Aug 2021) /tmp/idnits31514/draft-amsuess-core-rd-replication-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1160 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 842 == Outdated reference: A later version (-05) exists of draft-amsuess-core-resource-directory-extensions-00 == Outdated reference: A later version (-14) exists of draft-ietf-core-dynlink-08 == Outdated reference: draft-ietf-core-object-security has been published as RFC 8613 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsuess 3 Internet-Draft March 11, 2019 4 Intended status: Informational 5 Expires: September 12, 2019 7 Resource Directory Replication 8 draft-amsuess-core-rd-replication-02 10 Abstract 12 Discovery of endpoints and resources in M2M applications over large 13 networks is enabled by Resource Directories, but no special 14 consideration has been given to how such directories can scale beyond 15 what can be managed by a single device. 17 This document explores different ways in which Resource Directories 18 can be scaled up from single network to enterprise and global scale. 19 It does not attempt to standardize any of those methods, but only to 20 demonstrate the feasibility of such extensions and to provide 21 terminology and exploratory groundwork for later documents. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 12, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Goals of upscaling . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Large numbers of registrations . . . . . . . . . . . . . 3 61 3.2. Large number of requests . . . . . . . . . . . . . . . . 3 62 3.3. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Shared authority . . . . . . . . . . . . . . . . . . . . 4 65 4.2. Plain caching . . . . . . . . . . . . . . . . . . . . . . 5 66 4.3. RD-aware caching . . . . . . . . . . . . . . . . . . . . 6 67 4.3.1. Potential for improvement . . . . . . . . . . . . . . 7 68 4.4. Distinct registration points . . . . . . . . . . . . . . 7 69 4.4.1. Redundancy and handover . . . . . . . . . . . . . . . 8 70 4.4.2. Loops between RDs and proxies . . . . . . . . . . . . 8 71 5. Proposed RD extensions . . . . . . . . . . . . . . . . . . . 9 72 5.1. Provenance . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.2. Lifetime reporting . . . . . . . . . . . . . . . . . . . 10 74 6. Example scenarios . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Redundant and replicated resource lookup (anycast) . . . 11 76 6.2. Redundant and replicated resource lookup (distinct 77 registration points) . . . . . . . . . . . . . . . . . . 12 78 6.2.1. Variation: Large number of registrations, localized 79 queries . . . . . . . . . . . . . . . . . . . . . . . 15 80 6.2.2. Variation: Combination with anycast . . . . . . . . . 15 81 6.3. Anonymous global endpoint lookup . . . . . . . . . . . . 16 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 7.1. Informative References . . . . . . . . . . . . . . . . . 18 84 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 [ See abstract for now. ] 91 This document is being developed in a git based workflow. Please see 92 https://github.com/chrysn/resource-directory-replication [1] for more 93 details and easy ways to contribute. 95 2. Terminology 97 This document assumes familiarity with [RFC7252] and 98 [I-D.ietf-core-resource-directory] and uses terminology from those 99 documents. 101 Examples in which URI paths like "/rd" or "/rd-lookup/res" are used 102 assume that those URIs have been obtained before by an RD Discovery 103 process; these paths are only examples, and no implementation should 104 make assumptions based on the literal paths. 106 3. Goals of upscaling 108 The following sections outline different reasons why a Resource 109 Directory should be scaled beyond a singe device. Not all of them 110 will necessarily apply to all use cases, and not all solution 111 approaches might be suitable for all goals. 113 3.1. Large numbers of registrations 115 Even at 1kB of link data per registration, modern server hardware can 116 easily keep the data of millions of registrations in RAM 117 simultaneously. Thus, the mere size of registration data is not 118 expected to be a factor that requires scaling to multiple nodes. 120 The traffic produced when millions of nodes with the default 24h 121 lifetime amounts to dozens of exchanges per second, which is doable 122 with equal ease at central network equipment. 124 However, if the directory has additional interaction with its 125 registered nodes, for example because it provides proxying to 126 registered endpoints, resources like file descriptors can be 127 exhausted earlier, and the traffic load on the registration server 128 grows with the traffic it is proxying for the endpoint. 130 3.2. Large number of requests 132 Not all approaches to constrained restful communication use the 133 Resource Directory only in the setup stage; some are might also 134 utilize a Resource Directory in more day-to-day operation. 136 [ TODO: get some numbers on how many requests a single RD can deal 137 with. ] 139 3.3. Redundancy 141 With the RD as a central part of CoRE infrastructures, outages can 142 affect a large number of users. 144 A decentralized RD should be able to deal both with scheduled 145 downtimes of hosts as well as unexpected outages of hosts or parts of 146 the network, especially with network splits between the individual 147 parts of the directory. 149 4. Approaches 151 In this section, two independent chains of approaches are presented. 152 The "shared authority" approach (using anycast or DNS aliases), and 153 proxy-based caching (in stages from using generic proxies to RD 154 replication that only bears little resemblance to proxies). 156 In the remainder of this document, the term "proxy" always refers to 157 a device which a client can access as if it were a resource 158 directory, and forwards the request to an actual RD. 160 Elements from those chains can be mixed. 162 4.1. Shared authority 164 With this approach, a single host and port (or "authority" component 165 in the generic URI syntax) is used for all interactions with the RD. 167 This can be implemented using a host name pointing to different IP 168 addresses simultaneously or depending on the requester's location, 169 using IP anycast addresses or both. 171 From the client's or proxy's point of view, all interaction happens 172 with same Origin Server. 174 In this setup, the replication is hidden from the REST interactions, 175 and takes place inside the RD server implementation or its database 176 backend. 178 Compared to the other approaches, this is more complex to set up when 179 it involves managing anycast addresses: Running an IPv4 anycast 180 network on Internet scale requires running an Autonomous System. In 181 either variation, all server instances are tightly coupled; they need 182 shared administration and probably need to run the same software. 184 The replication characteristics are laregly inherited from the 185 underlying backend. 187 As registering endpoints only store the URI constructed from the 188 Location-Path option to their registration request, registration 189 updates can end up at any instance of the server, though they are 190 likely to reach the same one as before most of the time. 192 Spontaneous failure of individual nodes can interrupt endpoints' 193 registrations in scenarious that do not use anycast addresses until 194 the unusable addresses have left DNS caches. 196 4.2. Plain caching 198 Caching reverse proxies that are not particularly aware of a Resource 199 Directory can be used to mitigate the effect of large numbers of 200 requests on a single RD server. In this approach, there exists a 201 single central RD server instance, but proxies are placed in front of 202 it to reduce its load. 204 Caching is applicable only to the lookup interfaces; the POST request 205 used in registration and renewal are not cacheable. 207 A prerequisite for successful caching is that fresh copies exist in 208 the cache; this is likely to happen only if there are many alike 209 requests to the Resource Directory. The proxy can than serve cached 210 copies, and might find it advantageous to observe frequent queries. 212 The simplest way to set up such proxying is to have the proxies 213 forward all requests to the central RD and to advertise only the 214 proxies' addresses. 216 Due to the discovery process of the RD, operators can also limit the 217 proxies to the lookup interfaces and advertise the central server for 218 registration purposes. A sample exchange between a node and its 219 6LoWPAN border router could be: 221 Req: GET coap://[fe80::1]/.well-known/core?rt=core.rd* 223 Res: 2.05 Content 224 ;rt="core.rd", 225 ;rt="core.rd-lookup-res", 226 ;rt="core.rd-lookup-ep" 228 Special care should be taken when a reverse proxy is not accessed by 229 the client under the same address as the origin server, as relative 230 references change their meaning when served from there. This can be 231 ignored completely on the resource lookup interface (as long as the 232 provenance extension is not used); ignoring it on the endpoint lookup 233 interface gives the client "wrong" results, though that is likely to 234 only matter to applications that use both the lookup and the 235 registration interface, like Commissioning Tools could do. Proxies 236 can be configured to do content transcoding (cf. [RFC8075] 237 Section 6.5.2) to preserve the lookup responses' original meanings. 239 This approach does not help at all with large numbers of 240 registrations. It can mitigate issues with large numbers of lookup 241 requests, provided that many identical requests arrive at the proxy. 242 The effect on the redundancy goal is negligible: The proxy can 243 provide lookup results only for as long as the cache is fresh during 244 a central server outage, which is 60 seconds unless the RD server 245 says otherwise. 247 This approach can be run with off-the-shelf RD servers and proxies. 248 The only configuration required is for the proxy to have a forwarding 249 address, and for the RD (or its announcer) tho know which lookup 250 addresses to advertise. 252 4.3. RD-aware caching 254 Similar to the above, specialized proxies can be employed that are 255 aware that their target is an RD lookup address. 257 The "plain caching" approach is limited in that it requires a small 258 set of lookups to be frequently performed. A proxy that is aware 259 that the address it is forwarding to is of the Resource Type 260 "core.rd-lookup-*" can utilize knowledge of how an RD works to serve 261 more specialized requests as well from fresh generic content. 263 For example, assume that the proxy frequently receives requests of 264 the shape 266 Req: GET /rd-lookup/res?rt=core.s&rt=ex.temperature&ex.building=8341&title=X 268 for arbitrary values of X. Then it can use the following request to 269 keep a fresh cache: 271 Req: GET coap://rd.example.com/rd-lookup/res?rt=core.s&rt=ex.temperature 272 &ex.building=8341 273 Observe: 1 275 and from that serve filtered responses to individual requests. 277 This method shares the advantages of plain caching, with reduced 278 limitations but requiring specialized proxying software. The 279 software does not necessarily need more configuration: A general- 280 purpose proxy is free to explore the origin server's ".well-known/ 281 core" information, and can decide to enable RD optimizations after 282 discovering that the frequently accesses resources are of resource 283 type "core.rd-lookup-*". 285 4.3.1. Potential for improvement 287 Observing a large lookup result is relatively inefficient as the 288 complete document needs to be transferred when a change happens. 289 Serializations of web links that are suitable for expressing small 290 deltas are expected to be developed for PATCH operations on 291 registration resources. If those formats are compatible with 292 observation, they can be applied directly. Otherwise, the proxy can 293 try to establish a "push" dynamic link ([I-D.ietf-core-dynlink]) to 294 receive continuous PATCH updates on its resource. 296 The applicability of the RD-aware approach is further limited to 297 query parameters of which the proxy knows that they are not subject 298 to lookup filtering on other entities than the queried one. In the 299 example above, were the variable part the "d" attribute (of 300 endpoints, as opposed to the "title" of resources), the proxy could 301 not do the filtering on its own becaus it would not have the required 302 information. Even the above example does not allow for fully 303 accurate replication, as the endpoint _might_ register with a "title" 304 endpoint attribute, even though no such attribute is specified right 305 now. Also, annotating the links in the endpoint lookup with 306 information about which registration they belong to would help the 307 proxy keep all the data around to solve more complex queries. The 308 provenance extension is proposed for that purpose. 310 In its extreme form, the proxy can observe the complete endpoint 311 lookup resource of the Resource Directory. and run a dedicated 312 observation for each registration. It can then answer all queries on 313 its own based on the continuously fresh state transferred in the 314 observations. 316 For such proxies, it can be suitable to configure them to use stale 317 cache values for extended periods of time when the RD becomes 318 intermittently unavailable. 320 4.4. Distinct registration points 322 Caching proxies that are aware of RD semantics could be extended to 323 gather information from more than one Resource Directory. 325 When executing queries, they would consider candidates from all 326 configured upstream servers and report the union of the respective 327 query results. At this stage, it is highly recommended that content 328 transcoding takes place. 330 With this approach, many distinct registration URIs can be 331 advertised, for example due to geographic proximity. 333 Unlike the other proxying approaches, this helps with the "large 334 number of registrations" goal. If that number is unmanageable for 335 single devices, proxies need not keep full copies of all the RDs' 336 states but rather send out queries to all of their upstreams, 337 behaving more like the "plain caching" proxies. This multiplies the 338 lookup traffic, but allows for huge numbers of registrations. The 339 problems of "too many lookups" versus "too many registrations" can be 340 traded off against each other if the proxies keep parts of the RDs' 341 states locally at hand while forwarding more exotic requests to all 342 RDs. 344 4.4.1. Redundancy and handover 346 This approach also tackles the redundancy goal. When an endpoint 347 registeres at its RD, the RD updates its endpoint and resource lookup 348 results and includes the registration data until further notice (for 349 correct operation, the "Lifetime Age" extension is useful). 351 If at some point in time that RD server becomes unavailable, the 352 proxies can keep the cached information around. Before the lifetime 353 expires, the endpoint will attempt to renew its registration and find 354 that the RD is unavailable. It will then go through discovery again, 355 find the most recently advertised registration URI or pick another 356 one out of a set and start a new registration there. 358 If the lookup proxies do not evict the old (and soon-to-time-out) 359 registration when the new one on a different RD with the same 360 endpoint name and domain arrives, at worst there will be the same 361 information twice from two registration resources available for 362 lookup. 364 4.4.2. Loops between RDs and proxies 366 In this configuration, it can be tempting to run a Resource Directory 367 and a lookup proxy (aimed at multiple resource directories) on the 368 same host. 370 [ It might be easier to recommend simply using different hosts, at 371 least host names, in those cases, or anything else that allows direct 372 and not publically advertised access to the real RDs' lookups. ] 374 In such a setup, other aggregating lookup proxies must take care to 375 only select locally registered entries. With the current filtering 376 rules, observing the resources "/rd-lookup/ep?href=/*" and "/rd- 377 lookup/res?provenance=/*" crudely provides that kind of filtering. 379 5. Proposed RD extensions 381 5.1. Provenance 383 In order for an RD-aware proxy to serve resource lookup requests that 384 filter on endpoint parameters, the proxy needs a way to tell which 385 endpoint registration submitted that link. That information might 386 also be useful for other purposes. 388 This introduces a new link attribute "provenance". Its value is a 389 URI reference as described by [RFC3986] Section 4.1. The URI is to 390 be interpreted by the same rules that apply to the "anchor" 391 attribute, namely by resolving the reference relative to the 392 requested document's URI. The attribute should not be repeated, and 393 in presence of multiple attributes, only the last should be 394 considered. 396 [ TODO: If a something link-format-ish comes up during the 397 development of this document which allows setting base-hrefs in-line, 398 evaluate whether it really makes sense to inherit anchor's rules or 399 whether it's better to phrase it in a way that the requested base URI 400 always counts. A composite CoRAL endpoint-and-resource lookup on the 401 RD might make this extension proposal obsolete. ] 403 The URI given in the "provenance" attribute describes where the 404 information in the link was obtained from. An aggregator of links 405 can thus declare its sources for each link. 407 It is recommended that a Resource Directory adds the URI of the 408 registration resource to resource lookups. Thus, if an endpoint 409 registers as 411 Req: POST /rd?ep=node1 412 Payload: 413 ;if="core.s" 415 Res: 2.01 Created 416 Location: /reg/1234 418 then a lookup will add a provenance attribute: 420 Req: GET /rd-lookup/res?if=core.s 422 Res: 2.05 Content 423 Payload: 424 ;if="core.s";anchor="coap://..."; 425 provenance="/reg/1234" 427 This is not an IANA consideration as there is no established registry 428 of link attributes. 430 By itself, the provenance attribute does not need to be registered in 431 the RD Parameters Registry because it is just another link attribute. 432 If it is desired that provenance information is only shown on request 433 (eg. by RD-aware proxies), a parameter can be introduced there: 435 o Full name: Link provenance 437 o short: provenance 439 o Validity: URI 441 o Use: Resource lookup only 443 o Description: If "provenance" or any string starting with 444 "provenance=" is given as one of the ampersand-delimited query 445 arguments, the RD is instructed to add the provenance attribute to 446 all looked up links; otherwise, the RD will not present them. The 447 filtering rules still apply: If there is a "=" sign in the query 448 argument, only links with matching provenance will be reported. 450 5.2. Lifetime reporting 452 The result of an endpoint lookup as a whole has inhomogenous cache 453 properties that would determine its Max-Age: 455 o The document can change at any time when a new endpoint registers. 457 o The document can change at any time when an endpoint deregisters. 459 o Each record can be expected to not change until its lifetime has 460 expired. 462 As currently specified, a lookup client has no way to tell where in 463 its lifetime an endpoint is. Therefore, a new link attribute is 464 suggested that allows the RD to share that information: 466 The new link attribute Lifetime Remaining (lt-remaining) is described 467 for use in RD Endpoint Lookups. Valid values are integers from 0 to 468 the lifetime of the registration. The value indicates how many 469 seconds have passed since the endpoint last renewed its registration. 471 Care has to be taken when replicating this value in caches, as the 472 caching agent might be unaware of the attribute's semantics and not 473 update it. (This is unlike the Max-Age attribute, which a caching 474 agent needs to understand and reduce accordingly when serving from 475 the cache). It should therefore only be used with responses that 476 carry the default Max-Age of 60 or less. 478 Clients that use the lookup interface (especially RD-aware proxies) 479 are free to treat that record and its corresponding resource records 480 as fresh until after lt-remaining seconds have passed since the 481 endpoint lookup result was obtained, especially if the origin server 482 has become unavailable. 484 Security considerations: Given that this leaks information about the 485 endpoint's communication patterns, it may be prudent for an RD only 486 to reveal this information on a need-to-know basis. 488 6. Example scenarios 490 6.1. Redundant and replicated resource lookup (anycast) 492 This scenario describes a setup where millions of devices register in 493 a company-wide Resource Directory. 495 The directory is scaled using the shared authority / anycast 496 approach, and the RD implementation is backed by a NoSQL-style 497 distributed database. 499 /'''''''\______/'''''\__/''''''''\ 500 /- -\ 501 |, NoSQL database | 502 \,,, ,~'' 503 \_____/'''\__________/'''' \ 504 / | \ 505 /''''''\ /''''''\ /''''''\ 506 | RD-A | | RD-B | | RD-C | 507 \______/ \______/ \______/ 508 / | | \ / | | | \ | | | 509 E E C E E E E E C C C C 511 ("E" and "C" represent endpoints and lookup clients, respectively) 513 Both endloints and lookup clients receive the RD address 514 "2001:db8::an1:ca57" is announced to all devices on the network using 515 the RDAO option in IPv6 Neighbor Discovery. Any packages to that 516 addresses are routed by the network to the closest of the three RD 517 instances A, B and C. Discovery invariably looks like this: 519 Req: GET coap://[2001:db8::an1:ca57/.well-known/core?rt=core.rd* 521 Res: 2.05 Content 522 ;rt="core.rd", 523 ;rt="core.rd-lookup-res", 524 ;rt="core.rd-lookup-ep" 526 An endpoint close to B would therefore register with 528 Req: POST coap://[2001:db8::an1:ca57]/rd?ep=endpoint1& 529 d=facility23.eu.example.com 530 Payload: 531 ;if="core.s" 533 Res: 2.01 Created 534 Location: /reg/123e4567-e89b-12d3-a456-426655440000 536 Any client could immediately see that the endpoint is registered by 537 issuing 539 Req: GET coap://[2001:db8::an1:ca57]/rd-lookup/ep?ep=endpoint1& 540 d=facility23.eu.example.com 542 Res: 2.05 Content 543 Payload: 544 ;ep="endpoint1"; 545 d="facility23.eu.example.com";con="coap://[2001:db8:23::1]" 547 If at any point in time the RD instance B becomes unavailable, the 548 registering endpoint's renewal requests will be routed to the next 549 available instance, for example A. That instance can update the 550 shared database with renewed lifetime just as B would have done. 552 How this performs under a net split depends on the database backend. 553 Registration resources based on UUIDs were chosen in this example 554 because those would allow the system to keep accepting new 555 registrations even in a netsplit situation; the risk of the 556 registration request not being idempotent towards a node that 557 switches sides during such a split is considered acceptable. 559 6.2. Redundant and replicated resource lookup (distinct registration 560 points) 562 This scenario takes place in the same environment as the previous 563 one. 565 Rather than a shared database, distinct registration points are 566 advertised. The advertised registration points are called RD-A to 567 RD-C; independent of them are lookup proxies LP-X to LP-Z. Some of 568 them run on the same hosts. 570 /'''''''\______/'''''\__/''''''''\ 571 /- -\ 572 |, | 573 \,,, ,~'' 574 \_____/'''\__________/'''' \ 575 | | \ 576 /''''''\ | /''''''\ | /''''''\ | /''''''\ 577 | RD-A |--+ | RD-B |--+--| RD-C | +--| LP-Z | 578 | LP-X | | | LP-Y | | | | | | | 579 \_____1/ | \_____2/ | \____3/ | \_____4/ 580 | | | 581 +--+--+ +--+--+ +--+ 582 E E C E E E C C 584 The lookup proxies in this scenario are constantly observing the 585 "/rd-lookup/ep?href=/*" and "/rd-lookup/res?provenance=/*" resources 586 of known RDs on other hosts, and might get updated internally with 587 state from a co-hosted RD or observe that using an internal 588 interface. As there is no really suitable content format and 589 observation mechanism for those yet, the exchanges are partially 590 described in words here. 592 RDAO announcements point to the nearest host (whose IP address ends 593 with the numbers of the respective box in the figure), and hosts that 594 do not serve both functions provide lookup as follows: 596 Req: GET coap://[2001:db8:23::3]/.well-known/core?rt=core.rd* 598 Res: 2.05 Content 599 Payload: 600 ;rt="core.rd", 601 ;rt="core.rd-lookup-ep", 602 ;rt="core.rd-lookup-res" 604 When a client then registers as 606 Req: POST coap://[2001:db8:23::3]/rd?ep=endpoint1& 607 d=facility23.eu.example.com 608 Payload: 609 ;if="core.s" 611 Res: 2.01 Created 612 Location: /reg/42 613 the RD at 3 sends notifications to the observing lookup proxies X, Y 614 and Z: 616 Res: Patch Result 617 Add one record: ;ep="endpoint1";d="facility23.eu.example.com"; 618 con="coap://[2001:db8:23::1]";lt-remaining=90000 620 As soon as that is processed, clients can query LP-Z 622 Req: GET coap://[2001:db8:4::4]/rd-lookup/ep?ep=endpoint1& 623 d=facility23.eu.example.com 625 Res: 2.05 Content 626 Payload: 627 ;ep="endpoint1"; 628 d="facility23.eu.example.com";con="coap://[2001:db8:23::1]" 630 (Note that lt-remaining is elided to the client as per the security 631 considerations for that information). 633 When a net split happens that cuts LP-Z's site off the rest, it keeps 634 that information available until the lt-remaining runs out. 636 When RD-C unexpectedly becomes unavailable, endpoint1 fails to renew 637 its registration. It then starts the RD discovery process again, 638 picks the next available RD (this time B) and gets a new registration 639 from that. 641 RD-B then sends an update to the proxies: 643 Res: Patch Result 644 Add one record: ;ep="endpoint1";d="facility23.eu.example.com"; 645 con="coap://[2001:db8:23::1]";lt-remaining=90000 647 The proxies remove C's registration "/reg/42" based on the duplicate 648 name and now answer requests like this: 650 Req: GET /rd-lookup/ep?ep=endpoint1&d=facility23.eu.example.com 652 Res: 2.05 Content 653 Payload: 654 ;ep="endpoint1"; 655 d="facility23.eu.example.com";con="coap://[2001:db8:23::1]" 657 Req: GET /rd-lookup/res?if=core.s&d=facility23.eu.example.com 659 Res: 2.05 Content 660 Payload: 661 ;if="core.s"; 662 anchor="coap://[2001:db8:23::1]/sensors/temp"; 663 provenance="coap://[2001:db8:23:2]/reg/11", 664 ... 666 6.2.1. Variation: Large number of registrations, localized queries 668 If the lookup proxies are not capable of keeping track of all the 669 registered data, they can opt to forward requests to all the RDs 670 instead. In this example, queries are often localized (queries 671 within a building are often limited to the same building), so LP-Y 672 could decide to only keep two particular observations active to each 673 RD: 675 o "/rd-lookup/ep?href=/*&d=facility23.eu.example.com" 677 o "/rd-lookup/res?provenance=/*&d=facility23.eu.example.com" 679 With those observed, it could still accurately respond to the above 680 queries without calling out to the other RDs. 682 If a query came in as "/rd-lookup/res?if=core.s", it would still need 683 to forward that query to all RDs to build an overview of all sensors 684 in the network for the requester. 686 6.2.2. Variation: Combination with anycast 688 In a variation of this, all the RDs and LPs can use a shared anycast 689 address. They would be then advertised as in the anycast/NoSQL 690 example. 692 All RDs would need to be configured such that they encode their host 693 name in their path (eg. "/reg/rd-c/42"). Nodes must then have proxy 694 forwarding rules set up such that 696 o "/rd" is served from the local RD if there is one, or forwarded to 697 any (the closest) RD 699 o "/reg/*" requests are served if hosted locally, otherwise 700 forwarded to the appropriate RD, or respond with a 5.04 Gateway 701 timeout if that is not available any more 703 o Lookup request are served from the local lookup proxy, or 704 forwarded to the closest one on RD-only hosts. 706 Such a setup is easier if all hosts provide both registration and 707 lookup functionality. 709 6.3. Anonymous global endpoint lookup 711 This scenario describes a way to provide connectivity into devices in 712 difficult network situations based on identifiers of their 713 cryptographic keys, in this case the (sufficently long) ID context 714 plus recipient ID of OSCORE ([I-D.ietf-core-object-security]). A 715 global network of untrusted Resource Directory servers is built, and 716 the individual servers provide network relaying services for 717 endpoints that operate behind NAT or firewalls. 719 It assumes the existance of two other hypothetical mechanisms: 721 o The "proxy" parameter from 722 [I-D.amsuess-core-resource-directory-extensions] 724 o A URI scheme called "oscore". 726 A URI of the form "oscore://VGhh...2aWNl/sensor/temp" refers to a 727 resource "/sensor/temp/" on any OSCORE capable host with which the 728 client has a key established under the KID context and recipient 729 ID given by the base64 string in the authority component. 731 To resolve the URI to a concrete protocol and socket, a form of 732 Resource Directory assisted protocol negotiation is used. 734 RD servers join a global pool of servers using a protocol that is not 735 further described here, but could conceivably be based on distributed 736 hash tables (DHTs). 738 Endpoints register only with a key derived name, and usually do not 739 provide any links because those would be accessible only to 740 authenticated requesters. 742 They register at any of a set of preconfigured DNS names for finding 743 a Resource Directory. Those names resolve to any of the currently 744 active RD servers, where geographic proximity could play a role in 745 the choice of address returned. 747 When the endpoint discovers the registration URI (for which it uses 748 coap+tcp to make later proxying more stable), the server returns 749 links to its explicit IP address: 751 ;rt="core.rd", 752 ;rt="core.rd-lookup-ep" 754 (This avoids conflict when the DNS assignment flips and a different 755 host (on which the registration resource is unknown) is returned. 756 Alternatively, the servers could use a unified scheme of registration 757 resource naming like "/reg/${name}" or a UUID-based scheme.) 759 The endpoint then registers: 761 Req: POST coap+tcp://[2001:db8:1:2::3]/rd?proxy&ep=VGhhdCdzIHRoZSB\ 762 LZXlJZENvbnRleHQgdXNlZCB3aXRoIHRoaXMgZGV2aWNl 763 Payload: empty 765 Res: 2.01 Created 766 Location: /reg/123 768 When a client wants to talk to that registered server, its RD 769 discovery process will yield another instance, which it then queries: 771 Req: GET coap://[2001:db8:4:5::6]/rd-lookup/ep?ep=VGhhdCdzIHRoZSBL\ 772 ZXlJZENvbnRleHQgdXNlZCB3aXRoIHRoaXMgZGV2aWNl 774 The server will look up the given ep name in the backing DHT, and 775 forward the request right to the (precisely: any) RD server that has 776 announced that ep value, which then answers: 778 Res: 2.05 Created 779 Payload: 780 ;ep="VGhh...2aWNl"; 781 con="coap://[2001:db8:1:2::3]:10123"; 782 at="coap+tcp://[2001:db8:1:2::3]:10123" 784 (This particular server uses multiple ports to tell traffic for 785 different endpoints apart; it could just as well use a catch-all DNS 786 record, do name based virtual hosting and announce 787 "con="coap://reg123.server3.example.com" instead.) 789 The client will then use the discovered address to direct its OSCORE 790 requests to, and the RD server will proxy for it. 792 Note that while this setup _can_ serve as a generic RD and answer 793 resource requests as well, it is doubtful whether there would be any 794 interest in it given the data becomes public, and is limited by the 795 necessity to have an "ep=" filter in all requests lest the network be 796 flooded with requests. 798 7. References 800 7.1. Informative References 802 [I-D.amsuess-core-resource-directory-extensions] 803 Amsuess, C., "CoRE Resource Directory Extensions", draft- 804 amsuess-core-resource-directory-extensions-00 (work in 805 progress), January 2019. 807 [I-D.ietf-core-dynlink] 808 Shelby, Z., Koster, M., Groves, C., Zhu, J., and B. 809 Silverajan, "Dynamic Resource Linking for Constrained 810 RESTful Environments", draft-ietf-core-dynlink-08 (work in 811 progress), March 2019. 813 [I-D.ietf-core-object-security] 814 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 815 "Object Security for Constrained RESTful Environments 816 (OSCORE)", draft-ietf-core-object-security-16 (work in 817 progress), March 2019. 819 [I-D.ietf-core-resource-directory] 820 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 821 Amsuess, "CoRE Resource Directory", draft-ietf-core- 822 resource-directory-19 (work in progress), January 2019. 824 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 825 Resource Identifier (URI): Generic Syntax", STD 66, 826 RFC 3986, DOI 10.17487/RFC3986, January 2005, 827 . 829 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 830 Application Protocol (CoAP)", RFC 7252, 831 DOI 10.17487/RFC7252, June 2014, 832 . 834 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 835 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 836 the Constrained Application Protocol (CoAP)", RFC 8075, 837 DOI 10.17487/RFC8075, February 2017, 838 . 840 7.2. URIs 842 [1] https://github.com/chrysn/resource-directory-replication 844 Author's Address 846 Christian Amsuess 847 Hollandstr. 12/4 848 1020 849 Austria 851 Phone: +43-664-9790639 852 Email: christian@amsuess.com