CoRE Resource Directory Extensions
draft-amsuess-core-resource-directory-extensions-00

Abstract

[ See Introduction ]

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 July 14, 2019.

Copyright Notice

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

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

Table of Contents

• 1. Introduction
• 2. Reverse Proxy requests
• 2.1. Discovery
• 2.2. Registration
• 2.2.1. Registration updates
• 2.2.2. On-Demand proxying
• 2.2.3. Examples
• 2.2.4. Notes on stability and maturity
• 2.2.5. Security considerations
• 3. Infinite lifetime
• 3.1. Example
• 4. Lookup across link relations
• 4.1. Example
• 5. Lifetime Age
• 6. Zone identifier introspection
• 6.1. Example
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Author's Address

1. Introduction

This document pools some extensions to the Resource Directory [I-D.ietf-core-resource-directory] that might be useful but have no place in the original document.

They might become individual documents for IETF submission, simple registrations in the RD Parameter Registry at IANA, or grow into a shape where they can be submitted as a collection of tools.

At its current state, this draft is a collection of ideas.

[ This document is being developed at https://gitlab.com/chrysn/resource-directory-extensions. ]

2. Reverse Proxy requests

When a registrant registers at a Resource Directory, it might not have a suitable address it can use as a base address. Typical reasons include being inside a NAT without control over port forwarding, or only being able to open outgoing connections (as program running inside a web browser utilizing CoAP over WebSocket [RFC8323] might be).

[I-D.ietf-core-resource-directory] suggests (in the Cellular M2M use case) that proxy access to such endpoints can be provided, it gives no concrete mechanism to do that; this is such a mechanism.

2.1. Discovery

An RD that provides proxying functionality advertizes it by announcing the additional resource type “TBD1” on its directory resource.

2.2. Registration

A client passes the “proxy=yes” or “proxy=ondemand” query parameter in addition to (but typically instead of) a “base” query parameter.

A server that receives a “proxy=yes” query parameter in a registration (or receives “proxy=ondemand” and decides it needs to proxy) MUST come up with a “Proxy URL” on which it will act as a reverse proxy for the registrant and which it uses as a Registration Base URI for the present registration.

The Proxy URL SHOULD have no path component, as acting as a reverse proxy in such a scenario means that any relative references in all representations that are proxied must be recognized and possibly rewritten.

The RD MAY mint several alternative Registration Base URIs using different protocols to make the proxied content available; [I-D.silverajan-core-coap-protocol-negotiation] can be used to advertise them.

The registrant is not informed of the chosen public name by the RD.

If an explicit “base” paremter is given, the RD will forward requests to the Proxy URL to that location. Otherwise, it forwards to the registration’s source address (which is the implied base parameter).

This mechanism is applicable to all transports that can be used to register. If proxying is active, the restrictions on when the base parameter needs to be present ([I-D.ietf-core-resource-directory] Registration template) are relaxed: The base parameter may also be absent if the connection originates from an ephemeral port, as long as the underlying protocol supports role reversal, and link-local IPv6 addresses may be used without any concerns of expressibility.

If the client uses the role reveral rule relaxation, it keeps that connection open for as long as it wants to be reachable. When the connection terminates, the RD SHOULD treat the registration as having timed out (even if its lifetime has not been exceeded) and MAY eventually remove the registration.

2.2.1. Registration updates

The “proxy” query parameter can not be changed or repeated in a registration update; RD servers MUST answer 4.00 Bad Request to any registration update that has a “proxy” query parameter.

As always, registration updates can explicitly or implicitly update the Registration Base URI. In proxied registrations, those changes are not propagated to lookup, but do change the forwarding address of the proxy.

For example, if a registration is established over TCP, an update can come along in a new TCP connection. Starting then, proxied requests are forwarded along that new connection.

Note that transports can not be switched in a registration update, as the protocol is part of the registration resource.

2.2.2. On-Demand proxying

If an endpoint is deployed in an unknown network, it might not know whether it is behind a NAT that would require it to configure an explicit base address, and ask the RD to assist by proxying if necessary by registering with the “proxy=ondemand” query parameter.

A server receiving that SHOULD use a different source port to try to access the registrant’s .well-known/core file using a GET request under the Registration Base URI. If that succeeds, it may assume that no NAT is present, and ignore the proxying request. Otherwise, it configures proxying as if “proxy=yes” were requested.

Note that this is only a heuristic [ and not tested in deployments yet ].

2.2.3. Examples

2.2.3.1. Registration through a firewall

Req from [2001:db8:42::9876]:5683:
POST coap://rd.example.net/rd?ep=node9876&proxy=ondemand
</some-resource>;rt="example.x"

Req from rd.example.net:49152:
GET coap://[2001:db8:42::9876]/.well-known/core

Request blocked by stateful firewall around [2001:db8:42::]

RD decides that proxying is necessary

Res: 2.04 Created
Location: /reg/abcd

Later, lookup of that registration might say:

Req: GET coap://rd.example.net/lookup/res?rt=example.x

Res: 2.05 Content
<coap://node987.rd.example.net/some-resource>;rt="example.x

A request to that resource will end up at an IP address of the RD, which will forward it using its the IP and port on which the registrant had registered as source port, thus reaching the registrant through the stateful firewall.

2.2.3.2. Registration from a browser context

Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes
</gyroscope>;rt="core.s"

Res: 2.04 Created
Location: /reg/123

The gyroscope can now not only be looked up in the RD, but also be reached:

Req: GET coap://rd.example.net/lookup/res?rt=core.s

Res: 2.05 Content
<coap://[2001:db8:1::1]:10123/gyroscope>;rt="core.s"

In this example, the RD has chosen to do port-based rather than host-based virtual hosting and announces its literal IP address as that allows clients to not send the lengthy Uri-Host option with all requests.

2.2.4. Notes on stability and maturity

Using this with UDP can be quite fragile; the author only draws on own experience that this can work across cell-phone NATs and does not claim that this will work over generic firewalls.

[ It may make sense to have the example as TCP right away. ]

2.2.5. Security considerations

An RD MAY impose additional restrictions on which endpoints can register for proxying, and thus respond 4.01 Unauthorized to request that would pass had they not requested proxying.

Attackers could do third party registrations with an attacked device’s address as base URI, though the RD would probably not amplify any attacks in that case.

The RD MUST NOT reveal the address at which it reaches the registrant except for adaequately authenticated and authorized debugging purposes, as that address could reveal sensitive location data the registrant may wish to hide by using a proxy.

Usual caveats for proxies apply.

3. Infinite lifetime

An RD can indicate support for infinite lifetimes by adding the resoruce type “TBD2” to its list of resource types.

A registrant that wishes to keep its registration alive indefinitely can set the lifetime value as “lt=inf”.

Registrations with infinite lifetimes never time out.

Infinite lifetimes SHOULD only be used by commissioning tools, or for proxy registrations over stateful connections.

3.1. Example

Had the example of Section 2.2.3.2 discovered support for infinite lifetimes during lookup like this:

Req: GET coaps+ws://rd.example.net/.well-known/coer?rt=core.rd*

Res: 2.05 Content
</rd>;rt="core.rd TBD1 TBD2";ct=40

it could register like that:

Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes&lt=inf
</gyroscope>;rt="core.s"

Res: 2.04 Created
Location: /reg/123

and never need to update the registration for as long as the websocket connection is open.

(When it gets terminated, it could try renewing the registration, but needs to be prepared for the RD to already have removed the original registration.)

4. Lookup across link relations

Resource lookup occasionally needs execute multiple queries to follow links.

An RD server (or any other server that supports [RFC6690] compatible lookup), can announce support for following links in resource lookups by announcing support for the TBD3 interface type on its resource lookup.

A client can the query that server to not only provide the matched links, but also links that are reachable over relations given in “follow” query parameters.

4.1. Example

Assume a node presents the following data in its <.well-known/core> resource (and submitted the same to the RD):

</temp>;if="core.s";rt="example.temperature",
</t-prot>;rel="calibration-protocol";anchor="/temp",
<http://vendor.example.com/temp9000>;rel="describedby";anchor="/temp",
</hum>;if="core.s";rt="example.humidity",
</h-prot>;rel="calibration-protocol";anchor="/hum",

A lookup client can, in one query, find the temperature sensor and its relevant metadata:

Req: GET /rd-lookup/res?rt=example.temperature&follow=calibration-protocol&follow=describedby

<coap://node1/temp>;if="core.s";rt="example.temperature";anchor="coap://node1",
<coap://node1/t-prot>;rel="calibration-protocol";anchor="coap://node1/temp",
<http://vendor.example.com/temp9000>;rel="describedby";anchor="coap://node1/temp",

[ There is a better example in an earlier stage of [I-D.tiloca-core-oscore-discovery] ]

[ Given the likelihood of a CoRAL based successor to [RFC6690], this lookup variant might easily be superseeded by a CoRAL FETCH format. ]

5. Lifetime Age

This extension is described in [I-D.amsuess-core-rd-replication] Section 5.2.

The “provenance” extension in Section 5.1 of the same document should probably be expressed differently to avoid using non-target link attributes.

6. Zone identifier introspection

The ‘split-horizon’ mechanism introduced in [I-D.ietf-core-resource-directory] (-19) (that registrations with link-local bases can only be read from the zone they registered on) reduces the usability of the endpoint lookup interface for debugging purposes.

To allow an administrator to read out the “show-zone-id” query parameter for endpoint and resource lookup is introduced.

A Resource Directory that understands this parameter MUST NOT limit lookup results to registrations from the lookup’s zone, and MUST use [RFC6874] zone identifiers to annotate which zone those registrations are valid on.

The RD MUST limit such requests to authenticated and authorized debugging requests, as registrants may rely on the RD to keep their presence secret from other links.

6.1. Example

Req: GET /rd-lookup/ep?show-zone-id&et=printer

Res: 2.05 Content
</reg/1>;base="coap://[2001:db8::1]";et=printer;ep="bigprinter",
</reg/2>;base="coap://[fe80::99%wlan0]";et=printer;ep="localprinter-1234",
</reg/3>;base="coap://[fe80::99%eth2]";et=printer;ep="localprinter-5678",

7. References

7.1. Normative References

7.2. Informative References

Author's Address