CoRE Working Group B. SilverajanInternet-Draft TUTIntended status: Informational M. OcakExpires: November 5, 2017 Ericsson May 4, 2017CoAP Protocol Negotiationdraft-silverajan-core-coap-protocol-negotiation-05Abstract 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, using the CoRE Resource Directory.Status of This Memo This Internet-Draft is submitted in full conformance with the provisions ofBCP 78 andBCP 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 athttp://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 November 5, 2017.Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 inSection 4.e ofSilverajan & Ocak Expires November 5, 2017 [Page 1]
Internet-Draft CoAP Protocol Negotiation May 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .22. Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42.1. Overcoming Middlebox Issues . . . . . . . . . . . . . . .42.2. Better resource caching and serving in proxies . . . . .53. Node Types based on Transport Availability . . . . . . . . .64. New Resource Directory Parameters . . . . . . . . . . . . . .74.1. The 'at' RD parameter . . . . . . . . . . . . . . . . . .74.2. The 'tt' RD parameter . . . . . . . . . . . . . . . . . .95. IANA Considerations . . . . . . . . . . . . . . . . . . . . .96. Security Considerations . . . . . . . . . . . . . . . . . . .107. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .108. References . . . . . . . . . . . . . . . . . . . . . . . . .108.1. Normative References . . . . . . . . . . . . . . . . . .108.2. Informative References . . . . . . . . . . . . . . . . .11Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . .11A.1. From -04 to -05 . . . . . . . . . . . . . . . . . . . . .11A.2. From -03 to -04 . . . . . . . . . . . . . . . . . . . . .11A.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . .11A.4. From -01 to -02 . . . . . . . . . . . . . . . . . . . . .11A.5. From -00 to -01 . . . . . . . . . . . . . . . . . . . . .12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .121. Introduction 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 is however being extended to use other alternative underlying transports. These include reliable transports such as TCP, WebSockets and TLS. In addition, the use of SMS as a CoAP transport remains a possibility for simple communication in cellular networks. 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 subsitute 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 orthogonalSilverajan & Ocak Expires November 5, 2017 [Page 2]
Internet-Draft CoAP Protocol Negotiation May 2017 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: o the authority components of the URI differ, owing to the same physical host exposing several network endpoints. For example, "coap://example.org/sensors/temperature" and "coap://example.net/sensors/temperature" o the scheme components of the URI differ, owing to the origin server exposing several underlying transport alternatives. For example, "coap://example.org/sensors/temperature" and "coap+tcp://example.org/sensors/temperature" o the path components of the URI differ, should an origin server also allow alternative transport endpoint such as the WebSocket protocol, to be expressed using the path. For example, "coap://example.org/sensors/temperature" and "coap+ws://example.org/ws-endpoint/sensors/temperature" 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: o An ability for servers to register supported CoAP transports to a CoRE Resource Directory [I-D.ietf-core-resource-directory] with optional registration lifetime values o A means for CoAP clients to interact with a CoRE resource directory interface for requesting and discovering alternative transports and locations of CoAP resourcesSilverajan & Ocak Expires November 5, 2017 [Page 3]
Internet-Draft CoAP Protocol Negotiation May 2017 o New Resource Directory parameter types enabling the above- mentioned features. (Note: Although previous versions of this draft provided a mechanism for CoAP clients to directly interact with, discover, use and possibly even negotiate an alternative transport for CoAP-based communication directly with an origin server, discussions at the CoRE Working Group yielded new insights about problems with the proposed approach [CoREWG96]. The current version consequently adopts the usage of the CoRE Resource Directory. Future work is planned on performing discovery and negotiation without the RD as well.)2. Aim The following simple scenarios aim to better portray how CoAP protocol negotiation benefits communicating nodes2.1. Overcoming Middlebox Issues 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.Silverajan & Ocak Expires November 5, 2017 [Page 4]
Internet-Draft CoAP Protocol Negotiation May 2017 +-----------+ | Resource | +--4-->| Directory | | +-----------+ +---+ | ^ +----4--->| |<---+ +---1----+ +-------------+--V--+ | | +-V-----------------+ | | |--2-->| |--2-->| | | | | UDP | | N | | UDP | | | | |<--3--| |<--3--| | | | CoAP Client +-----+ | A | +-----+ CoAP Server | | | |--5-->| |--5-->| | | | | TCP | | T | | TCP | | | | |<--6--| |<--6--| | | +-------------+-----+ +---+ +-----+-------------+ Figure 1: CoAP Client initially accesses CoAP Server over UDP and then switching to TCP Figure 1 depicts such a scenario. Step 1 depicts the CoAP Server registering its transports to a Resource Directory. A CoAP client uses UDP initially for accessing a CoAP Server in Step 2 and receives a response in Step 3. Subsequently a CoAP client, residing behind a NAT, performs a lookup on the Resource Directory in Step 4 to discover alternative transports offered by the server. Steps 5 and 6 illustrate the client then deciding 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.2.2. Better resource caching and serving in proxies 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" whichSilverajan & Ocak Expires November 5, 2017 [Page 5]
Internet-Draft CoAP Protocol Negotiation May 2017 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 from the Resource Directory 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).3. Node Types based on Transport Availability 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.Silverajan & Ocak Expires November 5, 2017 [Page 6]
Internet-Draft CoAP Protocol Negotiation May 2017 +-------+----------------------------+ | 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.4. New Resource Directory Parameters 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.4.1. The 'at' RD parameter A CoAP server wishing to advertise its resources over multiple transports does so by using a new "at" parameter to register a list of CoAP alternative transport URIs during registration with aSilverajan & Ocak Expires November 5, 2017 [Page 7]
Internet-Draft CoAP Protocol Negotiation May 2017 Resource Directory. Such a URI would contain the schemes, addresses as well as any ports or paths at which the server is available. +-----------+-------+---------------+-------------------------------+ | Name | Query | Validity | Description | +-----------+-------+---------------+-------------------------------+ | CoAP | at | URI | Comma separated list of URIs | | Transport | | | (scheme, address, port, and | | URI List | | | path) available 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 as an alternative transport: Req: POST coap:/rd.example.com/rd ?ep=node1&at=coap+tcp://server.example.com,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" Res: 2.01 Created Location: /rd/4521 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 WebSockets): Req: POST /rd/4521?lt=600&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" Res: 2.04 ChangedSilverajan & Ocak Expires November 5, 2017 [Page 8]
Internet-Draft CoAP Protocol Negotiation May 20174.2. The 'tt' RD parameter 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 <coap+tcp://[FDFD::123]:61616>;ep="node5", <coap+tcp://[FDFD::123]:61616>;ep="node7" The next example shows a client performing a lookup for all transports supported by a specific endpoint: Req: GET /rd-lookup/ep?ep=node5&tt=* Res: 2.05 Content <coap+tcp://[FDFD::123]:61616>;ep="node5", <coap+ws://[FDFD::123]:61616>;ep="node5"5. IANA Considerations This document requests the registration of new RD parameter types "at" and "tt".Silverajan & Ocak Expires November 5, 2017 [Page 9]
Internet-Draft CoAP Protocol Negotiation May 20176. Security Considerations 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.7. Acknowledgements Thanks to Klaus Hartke for comments and reviewing this draft, and Teemu Savolainen for 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.8. References8.1. Normative References [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Resource Directory",draft-ietf-core-resource-directory-10 (work in progress), March 2017. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks",RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)",RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)",RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.Silverajan & Ocak Expires November 5, 2017 [Page 10]
Internet-Draft CoAP Protocol Negotiation May 20178.2. Informative References [CoREWG96]https://www.ietf.org/proceedings/96/minutes/minutes-96-core, "IETF96 CoRE minutes", July 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",BCP 14,RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [WWWArchv1]http://www.w3.org/TR/webarch/#uri-aliases, "Architecture of the World Wide Web, Volume One", December 2004.Appendix A. Change LogA.1. From -04 to -05 Freshness updateA.2. From -03 to -04 Removed previously introduced link attribute and relation types Initial foray with Resource Directory supportA.3. From -02 to -03 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 populatedA.4. From -01 to -02 Freshness update.Silverajan & Ocak Expires November 5, 2017 [Page 11]
Internet-Draft CoAP Protocol Negotiation May 2017A.5. From -00 to -01 Reworked "Introduction" section, added "Rationale", and "Goals" sections.Authors' Addresses Bilhanan Silverajan Tampere University of Technology Korkeakoulunkatu 10 FI-33720 Tampere Finland Email: bilhanan.silverajan@tut.fi Mert Ocak Ericsson Hirsalantie 11 02420 Jorvas Finland Email: mert.ocak@ericsson.comSilverajan & Ocak Expires November 5, 2017 [Page 12]
draft-silverajan-core-coap-protocol-negotiation-05
| Document | Document type | This is an older version of an Internet-Draft whose latest revision state is "Expired". This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D isnot endorsed by the IETF and hasno formal standing in theIETF standards process. | |
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Authors | Bill Silverajan,Mert Ocak | ||
| RFC stream | (None) | ||
| Other formats |