CoRE Resource Directory ExtensionsHollandstr. 12/41020Austria+43-664-9790639christian@amsuess.com
Internet
CoRECoRE, Web Linking, Resource Discovery, Resource Directory, Proxy[ See Introduction ]This document pools some extensions to the 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.
]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 might be). 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.This mechanism is intended to be a last-resort option to provide connectivity.
Where possible, direct connections are preferred.
Before registering for proxying,
the registrant should attempt to obtain a publicly available port,
for example using PCP ().The same mechanism can also be employed by clients that want to conceal their network address from its clients.An RD that provides proxying functionality advertises it by announcing the additional resource type “TBD1” on its directory resource.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 accepts requests,
and which it uses as a Registration Base URI for lookups on 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;
can be used to advertise them.The registrant is not informed of the chosen public name by the RD.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
( 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 reversal 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.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.The RD operates as a reverse-proxy as described in Section 5.7.3 at the announced Proxy URL(s),
where it decides based on the requested host and port
to which registrant endpoint to forward the request.The address the incoming request are forwarded to is the base address of the registration.
If an explicit “base” paremter is given,
the RD will forward requests to that location.
Otherwise, it forwards to the registration’s source address
(which is the implied base parameter).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 IP address 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 ].Later, lookup of that registration might say: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.The gyroscope can now not only be looked up in the RD, but also be reached: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.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. ]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.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.Had the example of discovered support for infinite lifetimes during lookup like this:it could register like that: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.)Resource lookup occasionally needs execute multiple queries to follow links.An RD server
(or any other server that supports 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.Assume a node presents the following data in its <.well-known/core> resource
(and submitted the same to the RD):A lookup client can, in one query,
find the temperature sensor
and its relevant metadata:[
There is a better example in an earlier stage of
][
Given the likelihood of a CoRAL based successor to ,
this lookup variant might easily be superseeded by a
CoRAL FETCH format.
]This extension is described in 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.The ‘split-horizon’ mechanism introduced in (-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 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.Multicast requests are hard to forward at a proxy:
Even if a media type is used
in which multiple responses can be aggregated transparently,
the proxy can not reliably know when all responses have come in.
Section 2.9 destribes the difficulties in more detail.A proxy MAY expose an interface compatible with the RD lookup interface,
which SHOULD be advertised by a link to it that indicates the resource types
core.rd-lookup-res and TBD4.The proxy sends multicast requests to All CoAP Nodes ( Section 12.8)
requesting their .well-known/core files
either eagerly (ie. in regular intervals independent of queries)
or on demand
(in which case it SHOULD limit the results by applying query filtering;
if it has received multiple query parameters it should forward the one it deems most likely to limit the results,
as .well-known/core only supports a single query parameter).In comparison to classical RD operation,
this RD behaves roughly as if it had received a simple registration
with a All CoAP Nodes address as the source address,
if such behavior were specified.
The individual registrations that result from this
neither have an explicit registration resource
nor an explicit endpoint name;
given that the endpoint lookup interface is not present on such proxies,
neither can be queried.Clients that would intend to do run a multicast discovery operation behind the proxy
can then instead query that resource lookup interface.
They SHOULD use observation on lookups,
as an on-demand implementation MAY return the first result before others have arrived,
or MAY even return an empty link set immediately.At the same time, the proxy sends out multicast requests on its interfaces:upon receipt of which it sends out a notification to the websocket client:CoRE Resource DirectoryIn many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined.Resource Directory ReplicationDiscovery of endpoints and resources in M2M applications over large networks is enabled by Resource Directories, but no special consideration has been given to how such directories can scale beyond what can be managed by a single device. This document explores different ways in which Resource Directories can be scaled up from single network to enterprise and global scale. It does not attempt to standardize any of those methods, but only to demonstrate the feasibility of such extensions and to provide terminology and exploratory groundwork for later documents.Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource IdentifiersThis document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id> in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly.The Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.CoAP (Constrained Application Protocol) over TCP, TLS, and WebSocketsThe Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.Port Control Protocol (PCP)The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.CoAP Protocol NegotiationCoAP has been standardised as an application-level REST-based protocol. When multiple transport protocols exist for exchanging CoAP resource representations, this document introduces a way forward for CoAP endpoints as well as intermediaries to agree upon alternate transport and protocol configurations as well as URIs for CoAP messaging. Several mechanisms are proposed: Extending the CoRE Resource Directory with new parameter types, introducing a new CoAP Option with which clients can interact directly with servers without needing the Resource Directory, and finally a new CoRE Link Attribute allowing exposing alternate locations on a per-resource basis.Constrained RESTful Environments (CoRE) Link FormatThis specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]Discovery of OSCORE Groups with the CoRE Resource DirectoryGroup communication over the Constrained Application Protocol (CoAP) can be secured by means of Object Security for Constrained RESTful Environments (OSCORE). At deployment time, devices may not know the exact OSCORE groups to join, the respective Group Manager, or other information required to perform the joining process. This document describes how a CoAP endpoint can use the CoRE Resource Directory to discover OSCORE groups and acquire information to join them through the respective Group Manager. A given OSCORE group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of OSCORE groups based on the ACE framework for Authentication and Authorization in constrained environments.Group Communication for the Constrained Application Protocol (CoAP)The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.Since -00:Add multicast proxy usage patternondemand proxying: Probing queries must be sent from a different addressproxying: Point to RFC7252 to describe how the actual proxying happensproxying: Describe this as a last-resort options and suggest attempting PCP first[ Reviews from: Jaime Jimenez ]