idnits 2.17.1 draft-amsuess-core-resource-directory-extensions-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 : ---------------------------------------------------------------------------- ** 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 6 instances of too long lines in the document, the longest one being 21 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 111: '... proxy) MUST come up with a "Proxy U...' RFC 2119 keyword, line 115: '... The Proxy URL SHOULD have no path c...' RFC 2119 keyword, line 120: '... The RD MAY mint several alternative...' RFC 2119 keyword, line 141: '...rminates, the RD SHOULD treat the regi...' RFC 2119 keyword, line 142: '...ifetime has not been exceeded) and MAY...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 10, 2019) is 1933 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 412 -- Looks like a reference, but probably isn't: '2' on line 414 == Outdated reference: A later version (-02) exists of draft-amsuess-core-rd-replication-01 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-18 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsuess 3 Internet-Draft January 10, 2019 4 Intended status: Experimental 5 Expires: July 14, 2019 7 CoRE Resource Directory Extensions 8 draft-amsuess-core-resource-directory-extensions-00 10 Abstract 12 [ See Introduction ] 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at https://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on July 14, 2019. 31 Copyright Notice 33 Copyright (c) 2019 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Reverse Proxy requests . . . . . . . . . . . . . . . . . . . 2 50 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.2. Registration . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2.1. Registration updates . . . . . . . . . . . . . . . . 4 53 2.2.2. On-Demand proxying . . . . . . . . . . . . . . . . . 4 54 2.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2.4. Notes on stability and maturity . . . . . . . . . . . 6 56 2.2.5. Security considerations . . . . . . . . . . . . . . . 6 57 3. Infinite lifetime . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Lookup across link relations . . . . . . . . . . . . . . . . 7 60 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5. Lifetime Age . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Zone identifier introspection . . . . . . . . . . . . . . . . 8 63 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 7.2. Informative References . . . . . . . . . . . . . . . . . 9 67 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 This document pools some extensions to the Resource Directory 73 [I-D.ietf-core-resource-directory] that might be useful but have no 74 place in the original document. 76 They might become individual documents for IETF submission, simple 77 registrations in the RD Parameter Registry at IANA, or grow into a 78 shape where they can be submitted as a collection of tools. 80 At its current state, this draft is a collection of ideas. 82 [ This document is being developed at https://gitlab.com/chrysn/ 83 resource-directory-extensions [1]. ] 85 2. Reverse Proxy requests 87 When a registrant registers at a Resource Directory, it might not 88 have a suitable address it can use as a base address. Typical 89 reasons include being inside a NAT without control over port 90 forwarding, or only being able to open outgoing connections (as 91 program running inside a web browser utilizing CoAP over WebSocket 92 [RFC8323] might be). 94 [I-D.ietf-core-resource-directory] suggests (in the Cellular M2M use 95 case) that proxy access to such endpoints can be provided, it gives 96 no concrete mechanism to do that; this is such a mechanism. 98 2.1. Discovery 100 An RD that provides proxying functionality advertizes it by 101 announcing the additional resource type "TBD1" on its directory 102 resource. 104 2.2. Registration 106 A client passes the "proxy=yes" or "proxy=ondemand" query parameter 107 in addition to (but typically instead of) a "base" query parameter. 109 A server that receives a "proxy=yes" query parameter in a 110 registration (or receives "proxy=ondemand" and decides it needs to 111 proxy) MUST come up with a "Proxy URL" on which it will act as a 112 reverse proxy for the registrant and which it uses as a Registration 113 Base URI for the present registration. 115 The Proxy URL SHOULD have no path component, as acting as a reverse 116 proxy in such a scenario means that any relative references in all 117 representations that are proxied must be recognized and possibly 118 rewritten. 120 The RD MAY mint several alternative Registration Base URIs using 121 different protocols to make the proxied content available; 122 [I-D.silverajan-core-coap-protocol-negotiation] can be used to 123 advertise them. 125 The registrant is not informed of the chosen public name by the RD. 127 If an explicit "base" paremter is given, the RD will forward requests 128 to the Proxy URL to that location. Otherwise, it forwards to the 129 registration's source address (which is the implied base parameter). 131 This mechanism is applicable to all transports that can be used to 132 register. If proxying is active, the restrictions on when the base 133 parameter needs to be present ([I-D.ietf-core-resource-directory] 134 Registration template) are relaxed: The base parameter may also be 135 absent if the connection originates from an ephemeral port, as long 136 as the underlying protocol supports role reversal, and link-local 137 IPv6 addresses may be used without any concerns of expressibility. 139 If the client uses the role reveral rule relaxation, it keeps that 140 connection open for as long as it wants to be reachable. When the 141 connection terminates, the RD SHOULD treat the registration as having 142 timed out (even if its lifetime has not been exceeded) and MAY 143 eventually remove the registration. 145 2.2.1. Registration updates 147 The "proxy" query parameter can not be changed or repeated in a 148 registration update; RD servers MUST answer 4.00 Bad Request to any 149 registration update that has a "proxy" query parameter. 151 As always, registration updates can explicitly or implicitly update 152 the Registration Base URI. In proxied registrations, those changes 153 are not propagated to lookup, but do change the forwarding address of 154 the proxy. 156 For example, if a registration is established over TCP, an update can 157 come along in a new TCP connection. Starting then, proxied requests 158 are forwarded along that new connection. 160 Note that transports can not be switched in a registration update, as 161 the protocol is part of the registration resource. 163 2.2.2. On-Demand proxying 165 If an endpoint is deployed in an unknown network, it might not know 166 whether it is behind a NAT that would require it to configure an 167 explicit base address, and ask the RD to assist by proxying if 168 necessary by registering with the "proxy=ondemand" query parameter. 170 A server receiving that SHOULD use a different source port to try to 171 access the registrant's .well-known/core file using a GET request 172 under the Registration Base URI. If that succeeds, it may assume 173 that no NAT is present, and ignore the proxying request. Otherwise, 174 it configures proxying as if "proxy=yes" were requested. 176 Note that this is only a heuristic [ and not tested in deployments 177 yet ]. 179 2.2.3. Examples 181 2.2.3.1. Registration through a firewall 182 Req from [2001:db8:42::9876]:5683: 183 POST coap://rd.example.net/rd?ep=node9876&proxy=ondemand 184 ;rt="example.x" 186 Req from rd.example.net:49152: 187 GET coap://[2001:db8:42::9876]/.well-known/core 189 Request blocked by stateful firewall around [2001:db8:42::] 191 RD decides that proxying is necessary 193 Res: 2.04 Created 194 Location: /reg/abcd 196 Later, lookup of that registration might say: 198 Req: GET coap://rd.example.net/lookup/res?rt=example.x 200 Res: 2.05 Content 201 ;rt="example.x 203 A request to that resource will end up at an IP address of the RD, 204 which will forward it using its the IP and port on which the 205 registrant had registered as source port, thus reaching the 206 registrant through the stateful firewall. 208 2.2.3.2. Registration from a browser context 210 Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes 211 ;rt="core.s" 213 Res: 2.04 Created 214 Location: /reg/123 216 The gyroscope can now not only be looked up in the RD, but also be 217 reached: 219 Req: GET coap://rd.example.net/lookup/res?rt=core.s 221 Res: 2.05 Content 222 ;rt="core.s" 224 In this example, the RD has chosen to do port-based rather than host- 225 based virtual hosting and announces its literal IP address as that 226 allows clients to not send the lengthy Uri-Host option with all 227 requests. 229 2.2.4. Notes on stability and maturity 231 Using this with UDP can be quite fragile; the author only draws on 232 own experience that this can work across cell-phone NATs and does not 233 claim that this will work over generic firewalls. 235 [ It may make sense to have the example as TCP right away. ] 237 2.2.5. Security considerations 239 An RD MAY impose additional restrictions on which endpoints can 240 register for proxying, and thus respond 4.01 Unauthorized to request 241 that would pass had they not requested proxying. 243 Attackers could do third party registrations with an attacked 244 device's address as base URI, though the RD would probably not 245 amplify any attacks in that case. 247 The RD MUST NOT reveal the address at which it reaches the registrant 248 except for adaequately authenticated and authorized debugging 249 purposes, as that address could reveal sensitive location data the 250 registrant may wish to hide by using a proxy. 252 Usual caveats for proxies apply. 254 3. Infinite lifetime 256 An RD can indicate support for infinite lifetimes by adding the 257 resoruce type "TBD2" to its list of resource types. 259 A registrant that wishes to keep its registration alive indefinitely 260 can set the lifetime value as "lt=inf". 262 Registrations with infinite lifetimes never time out. 264 Infinite lifetimes SHOULD only be used by commissioning tools, or for 265 proxy registrations over stateful connections. 267 3.1. Example 269 Had the example of Section 2.2.3.2 discovered support for infinite 270 lifetimes during lookup like this: 272 Req: GET coaps+ws://rd.example.net/.well-known/coer?rt=core.rd* 274 Res: 2.05 Content 275 ;rt="core.rd TBD1 TBD2";ct=40 276 it could register like that: 278 Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes<=inf 279 ;rt="core.s" 281 Res: 2.04 Created 282 Location: /reg/123 284 and never need to update the registration for as long as the 285 websocket connection is open. 287 (When it gets terminated, it could try renewing the registration, but 288 needs to be prepared for the RD to already have removed the original 289 registration.) 291 4. Lookup across link relations 293 Resource lookup occasionally needs execute multiple queries to follow 294 links. 296 An RD server (or any other server that supports [RFC6690] compatible 297 lookup), can announce support for following links in resource lookups 298 by announcing support for the TBD3 interface type on its resource 299 lookup. 301 A client can the query that server to not only provide the matched 302 links, but also links that are reachable over relations given in 303 "follow" query parameters. 305 4.1. Example 307 Assume a node presents the following data in its <.well-known/core> 308 resource (and submitted the same to the RD): 310 ;if="core.s";rt="example.temperature", 311 ;rel="calibration-protocol";anchor="/temp", 312 ;rel="describedby";anchor="/temp", 313 ;if="core.s";rt="example.humidity", 314 ;rel="calibration-protocol";anchor="/hum", 316 A lookup client can, in one query, find the temperature sensor and 317 its relevant metadata: 319 Req: GET /rd-lookup/res?rt=example.temperature&follow=calibration-protocol&follow=describedby 321 ;if="core.s";rt="example.temperature";anchor="coap://node1", 322 ;rel="calibration-protocol";anchor="coap://node1/temp", 323 ;rel="describedby";anchor="coap://node1/temp", 325 [ There is a better example [2] in an earlier stage of 326 [I-D.tiloca-core-oscore-discovery] ] 328 [ Given the likelihood of a CoRAL based successor to [RFC6690], this 329 lookup variant might easily be superseeded by a CoRAL FETCH format. 330 ] 332 5. Lifetime Age 334 This extension is described in [I-D.amsuess-core-rd-replication] 335 Section 5.2. 337 The "provenance" extension in Section 5.1 of the same document should 338 probably be expressed differently to avoid using non-target link 339 attributes. 341 6. Zone identifier introspection 343 The 'split-horizon' mechanism introduced in 344 [I-D.ietf-core-resource-directory] (-19) (that registrations with 345 link-local bases can only be read from the zone they registered on) 346 reduces the usability of the endpoint lookup interface for debugging 347 purposes. 349 To allow an administrator to read out the "show-zone-id" query 350 parameter for endpoint and resource lookup is introduced. 352 A Resource Directory that understands this parameter MUST NOT limit 353 lookup results to registrations from the lookup's zone, and MUST use 354 [RFC6874] zone identifiers to annotate which zone those registrations 355 are valid on. 357 The RD MUST limit such requests to authenticated and authorized 358 debugging requests, as registrants may rely on the RD to keep their 359 presence secret from other links. 361 6.1. Example 363 Req: GET /rd-lookup/ep?show-zone-id&et=printer 365 Res: 2.05 Content 366 ;base="coap://[2001:db8::1]";et=printer;ep="bigprinter", 367 ;base="coap://[fe80::99%wlan0]";et=printer;ep="localprinter-1234", 368 ;base="coap://[fe80::99%eth2]";et=printer;ep="localprinter-5678", 369 7. References 371 7.1. Normative References 373 [I-D.amsuess-core-rd-replication] 374 Amsuess, C., "Resource Directory Replication", draft- 375 amsuess-core-rd-replication-01 (work in progress), March 376 2018. 378 [I-D.ietf-core-resource-directory] 379 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 380 Amsuess, "CoRE Resource Directory", draft-ietf-core- 381 resource-directory-18 (work in progress), December 2018. 383 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 384 IPv6 Zone Identifiers in Address Literals and Uniform 385 Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, 386 February 2013, . 388 7.2. Informative References 390 [I-D.silverajan-core-coap-protocol-negotiation] 391 Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", 392 draft-silverajan-core-coap-protocol-negotiation-09 (work 393 in progress), July 2018. 395 [I-D.tiloca-core-oscore-discovery] 396 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 397 groups with the CoRE Resource Directory", draft-tiloca- 398 core-oscore-discovery-00 (work in progress), October 2018. 400 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 401 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 402 . 404 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 405 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 406 Application Protocol) over TCP, TLS, and WebSockets", 407 RFC 8323, DOI 10.17487/RFC8323, February 2018, 408 . 410 7.3. URIs 412 [1] https://gitlab.com/chrysn/resource-directory-extensions 414 [2] https://github.com/ace-wg/ace-oauth/ 415 issues/120#issuecomment-407997786 417 Author's Address 419 Christian Amsuess 420 Hollandstr. 12/4 421 1020 422 Austria 424 Phone: +43-664-9790639 425 Email: christian@amsuess.com