| CoRE Working Group | B. Silverajan |
| Internet-Draft | TUT |
| Intended status: Informational | M. Ocak |
| Expires: September 6, 2018 | Ericsson |
| March 5, 2018 |
CoAP Protocol Negotiation
draft-silverajan-core-coap-protocol-negotiation-08
CoAP 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.
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 September 6, 2018.
Copyright (c) 2018 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.
The Constrained Application Protocol (CoAP) [RFC7252] allows clients, origin servers and proxies, to exchange and manipulate resource representations using REST-based methods over UDP or DTLS. CoAP messaging however can use other alternative underlying transports [I-D.silverajan-core-coap-alternative-transports].
When CoAP-based endpoints and proxies possess the ability to perform CoAP messaging over multiple transports, significant benefits can be obtained if communicating client endpoints can discover that multiple transport bindings may exist on an origin server over which CoAP resources can be retrieved. This allows a client to understand and possibly substitute a different transport protocol configuration for the same CoAP resources on the origin server, based on the preferences of the communicating peers. Inevitably, if two CoAP endpoints reside in distinctly separate networks with orthogonal transports, a CoAP proxy node is needed between the two networks so that CoAP Requests and Responses can be exchanged properly.
A URI in CoAP, however, serves two purposes simultaneously. It firstly functions as a locator, by specifying the network location of the endpoint hosting the resource, and the underlying transport used by CoAP for accessing the resource representation. It secondly identifies the name of the specific resource found at that endpoint together with its namespace, or resource path. A single CoAP URI cannot be used to express the identity of the resource independently of alternate underlying transports or protocol configuration. Multiple URIs can result for a single CoAP resource representations if:
Without a priori knowledge, clients would be unable to ascertain if two or more URIs provided by an origin server are associated to the same representation or not. Consequently, a communication mechanism needs to be conceived to allow an origin server to properly capture the relationship between these alternate representations or locations and then subsequently supply this information to clients. This also goes some way in limiting URI aliasing [WWWArchv1].
In order to support CoAP clients, proxies and servers wishing to use CoAP over multiple transports, this draft proposes the following:
The following simple scenarios aim to better portray how CoAP protocol negotiation benefits communicating nodes
Discovering which transports are available is important for a client to determine the optimal alternative to perform CoAP messaging according to its needs, particularly when separated from a CoAP server via a NAT. It is well-known that some firewalls as well as many NATs, particularly home gateways, hinder the proper operation of UDP traffic. NAT bindings for UDP-based traffic do not have as long timeouts as TCP-based traffic.
+-------------+-----+ +---+ +-------------------+
| | |--1-->| |--1-->| | |
| | UDP | | N | | UDP | |
| | |<--2--| |<--2--| | |
| CoAP Client +-----+ | A | +-----+ CoAP Server |
| | |--3-->| |--3-->| | |
| | TCP | | T | | TCP | |
| | |<--4--| |<--4--| | |
+-------------+-----+ +---+ +-----+-------------+
Figure 1: CoAP Client initially accesses CoAP Server over UDP and then switching to TCP
Figure 1 depicts such a scenario, where a CoAP client residing behind a NAT uses UDP initially for accessing a CoAP Server, and engages in discovering alternative transports offered by the server. The client subsequently decides to use TCP for CoAP messaging instead of UDP to set up an Observe relationship for a resource at the CoAP Server, in order to avoid incoming packets containing resource updates being discarded by the NAT.
Figure 2 outlines a more complex example of intermediate nodes such as CoAP-based proxies to intelligently cache and respond to CoAP or HTTP clients with the same resource representation requested over alternative transports or server endpoints. As with the earlier example, the CoAP Server registers its transports to a Resource Directory (This is assumed to be performed beforehand and not depicted in the figure, for brevity)
In this example, a CoAP over WebSockets client successfully obtains a response from a CoAP forward proxy to retrieve a resource representation from an origin server using UDP, by supplying the CoAP server's endpoint address and resource in a Proxy-URI option. Arrow 1 represents a GET request to "coap+ws://proxy.example.com" which subsequently retrieves the resource from the CoAP server using the URI "coap://example.org/sensors/temperature", shown as arrow 2.
+---------+
| CoAP+WS | +--------+-------+---+ +-----+---------+
| Client |<-1->| Web | | |<-2->| | |
+---------+ | Socket | CoAP | U | | UDP | CoAP |
+---------+ +--------+ Proxy | D | +-----+ Server |
| HTTP |<-3->| HTTP | | P | | TCP | |
| Client |<-4->| | | | | | |
+---------+ +--------+-------+---+ +-----+---------+
Figure 2: Proxying and returning a resource's alternate cached representations to multiple clients
Subsequently, assume an HTTP client requests the same resource, but instead specifies a CoAP over TCP alternative URI instead. Arrow 3 represents this event, where the HTTP client performs a GET request to "http://proxy.example.com/coap+tcp://example.org/sensors/temperature". When the proxy receives the request, instead of immediately retrieving the temperature resource again over TCP, it first verifies either from the Resource Directory or directly from the server, whether the cached resource retrieved over UDP is a valid equivalent representation of the resource requested by the HTTP client over TCP. Upon confirmation, the proxy is able to supply the same cached representation to the HTTP client as well (arrow 4).
Figure 3 illustrates discovery and communication between a CoAP client and an energy-constrained CoAP Server. Such a server aims at conserving its energy unless a need arises otherwise. The figure first depicts the server registering itself to a Resource Directory over IP, and also supplies its alternative CoAP transport endpoints (in this case, SMS), in steps 1 and 2. The server can subsequently disable communication radio interfaces requiring greater energy (such as for IP-based comunication), powering it up sporadically for maintenance activities like registration renewals. At other times, it maintains communication in a low-power state by listening only for incoming SMS messages.
+---------+
| CoRE |
+-->| RD |<--+
| +-+---------+-+ |
3| | | |1
| |4 2| |
| v v |
+---------------+ +---------------+
| | | | | |
| CoAP | UDP | | UDP | CoAP |
| Client +-----+ 5 +-----+ Server |
| | SMS +------>| SMS | |
| | +<------+ | |
+---------------+ 6 +---------------+
Figure 3: CoAP client interacting with RD to discover a server's SMS-based endpoint
A CoAP client wishing to perform CoAP operations with an energy-constrained CoAP server may query a resource directory for the SMS-based endpoint of the server (steps 3 and 4). Subsequently, SMS-based CoAP communication can occur between the endpoints as shown by arrows 5 and 6. Alternatively, the incoming SMS can be also used by the server as a triggering event to temporarily power up its radio interface so that UDP or other transport-based CoAP communication can instead be employed for low latency communication with the client.
In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for devices, in terms of their resource constraints, energy limitations and communication power. For this document, in addition to these capabilities, it seems useful to also identify devices based on their transport capabilities.
+-------+----------------------------+
| Name | Transport Availability |
+-------+----------------------------+
| T0 | Single transport |
| | |
| T1 | Multiple transports, with |
| | one or more active at any |
| | point in time |
| | |
| T2 | Multiple active and |
| | persistent transports |
| | at all times |
+-------+----------------------------+
Table 1: Classes of Available Transports
Type T0 nodes possess the capability of exactly 1 type of transport channel for CoAP, at all times. These include both active and sleepy nodes, which may choose to perform duty cycling for power saving.
Type T1 nodes possess multiple different transports, and can retrieve or expose CoAP resources over any or all of these transports. However, not all transports are constantly active and certain transport channels and interfaces could be kept in a mostly-off state for energy-efficiency, such as when using CoAP over SMS.
Type T2 nodes possess more than 1 transport, and multiple transports are simultaneously active at all times in a persistent manner. CoAP proxy nodes which allow CoAP endpoints from disparate transports to communicate with each other, are a good example of this.
In order to allow resource interactions between clients and servers with multiple locations or transports, the registration, update and lookup interfaces of the CoRE Resource Directory need to be extended. In this section two new RD parameters, "at" and "tt" are introduced. Both are optional CoAP features. If supported, they occur at the granularity level of an origin server, ie. they cannot be applied selectively on some resources only. When absent, it is assumed that the server does not support multiple transports or locations.
A CoAP server wishing to advertise its resources over multiple transports does so by using one or more "at" parameters to register CoAP alternative transport URIs with a Resource Directory. Such a URI would contain the scheme, address as well as any port or paths at which the server is available.
+-----------+-------+---------------+-------------------------------+
| Name | Query | Validity | Description |
+-----------+-------+---------------+-------------------------------+
| CoAP | at | URI | URI (scheme, address, port |
| Transport | | | and path) available |
| URI List | | | at the server |
+-----------+-------+---------------+-------------------------------+
Table 2: The "at" RD parameter
The "at" parameter extends the Resource Directory's Registration and Update interfaces.
The following example shows a type T1 endpoint registering its resources and advertising its ability to use TCP and WebSockets as alternative transports:
Req: POST coap://rd.example.com/rd?ep=node1
&at=coap+tcp://[2001:db8:f1::2]&at=coap+ws://server.example.com
Content-Format: 40
Payload:
</temperature>;ct=0;rt="temperature";if="core.s"
Res: 2.01 Created
Location: /rd/1234
An endpoint lookup would just reflect the registered attributes:
Req: GET /rd-lookup/ep
Res: 2.05 Content
</rd/1234>;ep="node1";con="coap://[2001:db8:f1::2]:5683";
at="coap+tcp://[2001:db8:f1::2]";at="coap+ws://server.example.com"
The next example shows the same endpoint updating its registration with a new lifetime and the availability of a single alternative transport for CoAP (in this case TCP):
Req: POST /rd/1234?lt=600
&at=coap+tcp://[2001:db8:f1::2]
Content-Format: 40
Payload:
</temperature>;ct=0;rt="temperature";if="core.s"
Res: 2.04 Changed
If a lookup is performed on the same endpoint only 1 alternative transport is indicated:
Req: GET /rd-lookup/ep
Res: 2.05 Content
</rd/1234>;ep="node1";con="coap://[2001:db8:f1::2]:5683";
at="coap+tcp://[2001:db8:f1::2]"
A UDP client would then see the following in a resource lookup:
Req: GET /rd-lookup/res?rt=temperature
Res: 2.05 Content
<coap://[2001:db8:f1::2]/temperature>;ct=0;rt="temperature";if="core.s";
anchor="coap://[2001:db8:f1::2]"
A CoAP client wishing to perform a look-up on the Resource Directory for CoAP servers supporting multiple transports does so by using a new "tt" parameter to query for CoAP alternative transport URIs.
+-----------+-------+---------------+-------------------------------+
| Name | Query | Validity | Description |
+-----------+-------+---------------+-------------------------------+
| CoAP | tt | | Transport type |
| Transport | | | requested by |
| Type | | | the client |
+-----------+-------+---------------+-------------------------------+
Table 3: The "tt" RD parameter
The "tt" parameter extends the Resource Directory's rd-lookup interface.
The following example shows a client performing a lookup for endpoints supporting TCP:
Req: GET /rd-lookup/ep?tt=tcp
Res: 2.05 Content
</rd/1234>;con="coap+tcp://[2001:db8:f1::2]";ep="node1";ct="40"
The following example shows a client performing a resource lookup for endpoints supporting TCP:
Req: GET /rd-lookup/res?rt=temperature&tt=tcp
Res: 2.05 Content
<coap+tcp://[2001:db8:f1::2]/temperature>;ct=0;rt="temperature";
if="core.s";anchor="coap+tcp://[2001:db8:f1::2]"
The following example shows a client performing a lookup for endpoints supporting SMS i.e. discovering SMS transports for sleepy nodes and using SMS to communicate with the endpoint:
Req: GET /rd-lookup/ep?et=oic.d.switch&tt=sms
Res: 2.05 Content
</rd/2345>;con="coap+sms://0015105550101/";ep="node5";
et="oic.d.switch";ct="40",
</rd/4521>;con="coap+sms://0015105550202/";ep="node8";
et="oic.d.switch";ct="40"
The CoAP Alternative-Transport Option can be used by CoAP clients and CoAP servers in both Request and Response messages in constrained environments where a CoRE Resource Directory is not present.
Figure 4 depicts the properties of the Alternative-Transport Option.
+-----+---+---+---+---+------------------------+--------+--------+----------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+------------------------+--------+--------+----------+
| 66 | | x | - | x | Alternative-Transport | string | 0-1034 | (none) |
+-----+---+---+---+---+------------------------+--------+--------+----------+
C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable
Figure 4: The Alternative-Transport Option
When included in a Request message, this option is used by the client in 2 possible ways. In the first case, a CoAP client can include the Option with Length 0 to retrieve all alternative transports from a CoAP server. In response to the client, the server includes base URI for each transport in its own Option. In the second case, a CoAP client can include the Option with a specific value in a CoAP Request, and the CoAP server returns the base URI(s) for the specified transport. If the specified transport by a CoAP client returns multiple results on a CoAP server, the server returns all base URIs of the transport in the response, each base URI in its own Option.
A CoAP client can also use this Option to retrieve several transports at once by including multiple Options in the request to a CoAP server. If any of the specified transports is supported by the server, the server returns all base URIs in its own option. There can be more than 1 result for any of the transports so that each transport base URI is still included in the response in its own option.
Figure 5 describes a simple interaction between a client and a server, in which the client uses an Alternative-Transports Option with a null value to discover and retrieve all the available transports from the server, as part of a GET operation to retrieve a resource representation. The server responds with a CoAP Response message which contains the resource representation as a payload. In addition, the server also supplies multiple Alternative-Transport Options in the message, with each Option containing the base URI for an available transport. In this case the base URIs returned for TCP-based and WebSocket transports indicate their availability over a non-standard port.
Client Server
+ |
| GET /temperature |
| Token: 0x64 |
| Alternative-Transport: (null) |
+-------------------------------------->|
| |
| 2.05 Content |
| Token: 0x64 |
| Payload: 21.0 Cel |
| Alternative-Transport: |
| coap+tcp://example.org:5555/ |
| Alternative-Transport: |
| coaps+tcp://example.org:6666/ |
| Alternative-Transport: |
| coap+sms://0015105550101/ |
| Alternative-Transport: |
| coap+ws://example.org:8080/ |
| |
|<--------------------------------------+
| |
Figure 5: Requesting all available alternative transports on the server, and their locations
Alternatively, a client can also request for the availability of a specific transport on the server, as shown in Figure 6. Here, the CoAP Request contains an Alternative-Transport Option with the value set to request the Base URIs for TCP-based endpoints.
Client Server
+ |
| GET /temperature |
| Token: 0x64 |
| Alternative-Transport: tcp |
+-------------------------------------->|
| |
| 2.05 Content |
| Token: 0x64 |
| Payload: 21.0 Cel |
| Alternative-Transport: |
| coap+tcp://example.org:5555/ |
| Alternative-Transport: |
| coaps+tcp://example.org:6666/ |
| |
|<--------------------------------------+
| |
Figure 6: Requesting TCP-based alternative transports on the server, and their locations
A client may also request a subset of available transports on the server, by providing multiple Options, each having a single transport identifier. The server likewise responds to the client request by supplying the requested transport information. This is shown in Figure 7.
Client Server
+ |
| GET /temperature |
| Token: 0x64 |
| Alternative-Transport: ws |
| Alternative-Transport: sms |
+-------------------------------------->|
| |
| 2.05 Content |
| Token: 0x64 |
| Payload: 21.0 Cel |
| Alternative-Transport: |
| coap+sms://0015105550101/ |
| Alternative-Transport: |
| coap+ws://example.org:8080/ |
| |
|<--------------------------------------+
| |
Figure 7: Requesting WebSocket- and SMS-based alternative transports on the server, and their locations
In the majority of cases, it is expected that an origin server would expose all its resources uniformly on its available transports or endpoint addresses. Exceptions can exist however, where alternate locations are made available on a per-resource basis. For such cases, a new 'ol' ("other locations") attribute is provided. One or more 'ol' attributes are used to provide base URIs from which a specific resource can be reached. Allowing per-resource endpoint or transport availability enables specific functions such as firmware updates or hardware-specific operations. It also facilities mapping to and from OCF-based resource-specific endpoint descriptions.
REQ: GET /.well-known/core
RES: 2.05 Content
</sensors/temp>;ct=41;rt="temperature-f";if="sensor",
</sensors/door>;ct=41;rt="door";if="sensor",
</sensors/light>;if="sensor"; ol="http://[FDFD::123]:61616";
ol="coap://server2.example.com"
Req: POST coap:/rd.example.com/rd
?ep=node1&at=coap+tcp://server.example.com&at=coap+ws://server.example.com:5683/ws/
Content-Format: 40
Payload:
</sensors/temp>;ct=41;rt="temperature-f";if="sensor",
</sensors/door>;ct=41;rt="door";if="sensor",
</sensors/light>;if="sensor"; ol="http://[FDFD::123]:61616";
ol="coap://server2.example.com"
Res: 2.01 Created
Location: /rd/4521
This document requests the registration of new RD parameter types "at" and "tt".
The following entry needs to be added to the CoAP Option Numbers Registry:
+--------+------------------------+------------------+
| Number | Name | Reference |
+--------+------------------------+------------------+
| 66 | Alternative-Transports | (this document) |
+--------+------------------------+------------------+
When multiple transports, locations and representations are used, some obvious risks are present both at the origin server as well as by requesting clients.
When a client is presented with alternate URIs for retrieving resources, it presents an opportunity for attackers to mount a series of attacks, either by hijacking communication and masquerading as an alternate location or by using a man-in-the-middle attack on TLS-based communication to a server and redirecting traffic to an alternate location. A malicious or compromised server could also be used for reflective denial-of-service attacks on innocent third parties. Moreover, clients may obtain web links to alternate URIs containing weaker security properties than the existing session.
Thanks to Jaime Jimenez, Christian Amsuess and Klaus Hartke for comments and reviewing this draft. Teemu Savolainen was involved in initial discussions about protocol negotations and lifetime values. Zach Shelby provided significant suggestions on how the Resource Directory can be employed and extended in place of link attributes and relation types.
| [I-D.ietf-core-resource-directory] | Shelby, Z., Koster, M., Bormann, C., Stok, P. and C. Amsuess, "CoRE Resource Directory", Internet-Draft draft-ietf-core-resource-directory-13, March 2018. |
| [RFC7252] | Shelby, Z., Hartke, K. and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014. |
| [I-D.silverajan-core-coap-alternative-transports] | Silverajan, B. and T. Savolainen, "CoAP Communication with Alternative Transports", Internet-Draft draft-silverajan-core-coap-alternative-transports-11, March 2018. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7228] | Bormann, C., Ersue, M. and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014. |
| [WWWArchv1] | http://www.w3.org/TR/webarch/#uri-aliases, "Architecture of the World Wide Web, Volume One", December 2004. |
Added example of energy constrained CoAP server
Updated examples of using "at" and "tt"
"at" and "ol" are no longer comma-separated URI lists.
Added support for 'ol' Link attribute
Added support for CoAP Alternative-Transports Option
Freshness update
Removed previously introduced link attribute and relation types
Initial foray with Resource Directory support
Added new author
Rewrite of "Introduction" section
Added new Aims Section
Added new Section on Node Types
Introduced "al" Active Lifetime link attribute
Added new Section on Observing transports and resources
Security and IANA considerations sections populated
Freshness update.
Reworked "Introduction" section, added "Rationale", and "Goals" sections.