idnits 2.17.1 draft-silverajan-core-coap-protocol-negotiation-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 4, 2017) is 2520 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7641' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 437, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-10 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group B. Silverajan 3 Internet-Draft TUT 4 Intended status: Informational M. Ocak 5 Expires: November 5, 2017 Ericsson 6 May 4, 2017 8 CoAP Protocol Negotiation 9 draft-silverajan-core-coap-protocol-negotiation-05 11 Abstract 13 CoAP has been standardised as an application-level REST-based 14 protocol. When multiple transport protocols exist for exchanging 15 CoAP resource representations, this document introduces a way forward 16 for CoAP endpoints as well as intermediaries to agree upon alternate 17 transport and protocol configurations as well as URIs for CoAP 18 messaging, using the CoRE Resource Directory. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 5, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Overcoming Middlebox Issues . . . . . . . . . . . . . . . 4 57 2.2. Better resource caching and serving in proxies . . . . . 5 58 3. Node Types based on Transport Availability . . . . . . . . . 6 59 4. New Resource Directory Parameters . . . . . . . . . . . . . . 7 60 4.1. The 'at' RD parameter . . . . . . . . . . . . . . . . . . 7 61 4.2. The 'tt' RD parameter . . . . . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative References . . . . . . . . . . . . . . . . . 11 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 69 A.1. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 11 70 A.2. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 11 71 A.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 11 72 A.4. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 11 73 A.5. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The Constrained Application Protocol (CoAP) [RFC7252] allows clients, 79 origin servers and proxies, to exchange and manipulate resource 80 representations using REST-based methods over UDP or DTLS. CoAP 81 messaging is however being extended to use other alternative 82 underlying transports. These include reliable transports such as 83 TCP, WebSockets and TLS. In addition, the use of SMS as a CoAP 84 transport remains a possibility for simple communication in cellular 85 networks. 87 When CoAP-based endpoints and proxies possess the ability to perform 88 CoAP messaging over multiple transports, significant benefits can be 89 obtained if communicating client endpoints can discover that multiple 90 transport bindings may exist on an origin server over which CoAP 91 resources can be retrieved. This allows a client to understand and 92 possibly subsitute a different transport protocol configuration for 93 the same CoAP resources on the origin server, based on the 94 preferences of the communicating peers. Inevitably, if two CoAP 95 endpoints reside in distinctly separate networks with orthogonal 96 transports, a CoAP proxy node is needed between the two networks so 97 that CoAP Requests and Responses can be exchanged properly. 99 A URI in CoAP, however, serves two purposes simultaneously. It 100 firstly functions as a locator, by specifying the network location of 101 the endpoint hosting the resource, and the underlying transport used 102 by CoAP for accessing the resource representation. It secondly 103 identifies the name of the specific resource found at that endpoint 104 together with its namespace, or resource path. A single CoAP URI 105 cannot be used to express the identity of the resource independently 106 of alternate underlying transports or protocol configuration. 107 Multiple URIs can result for a single CoAP resource representations 108 if: 110 o the authority components of the URI differ, owing to the same 111 physical host exposing several network endpoints. For example, 112 "coap://example.org/sensors/temperature" and 113 "coap://example.net/sensors/temperature" 115 o the scheme components of the URI differ, owing to the origin 116 server exposing several underlying transport alternatives. For 117 example, "coap://example.org/sensors/temperature" and 118 "coap+tcp://example.org/sensors/temperature" 120 o the path components of the URI differ, should an origin server 121 also allow alternative transport endpoint such as the WebSocket 122 protocol, to be expressed using the path. For example, 123 "coap://example.org/sensors/temperature" and 124 "coap+ws://example.org/ws-endpoint/sensors/temperature" 126 Without a priori knowledge, clients would be unable to ascertain if 127 two or more URIs provided by an origin server are associated to the 128 same representation or not. Consequently, a communication mechanism 129 needs to be conceived to allow an origin server to properly capture 130 the relationship between these alternate representations or locations 131 and then subsequently supply this information to clients. This also 132 goes some way in limiting URI aliasing [WWWArchv1]. 134 In order to support CoAP clients, proxies and servers wishing to use 135 CoAP over multiple transports, this draft proposes the following: 137 o An ability for servers to register supported CoAP transports to a 138 CoRE Resource Directory [I-D.ietf-core-resource-directory] with 139 optional registration lifetime values 141 o A means for CoAP clients to interact with a CoRE resource 142 directory interface for requesting and discovering alternative 143 transports and locations of CoAP resources 145 o New Resource Directory parameter types enabling the above- 146 mentioned features. 148 (Note: Although previous versions of this draft provided a mechanism 149 for CoAP clients to directly interact with, discover, use and 150 possibly even negotiate an alternative transport for CoAP-based 151 communication directly with an origin server, discussions at the CoRE 152 Working Group yielded new insights about problems with the proposed 153 approach [CoREWG96]. The current version consequently adopts the 154 usage of the CoRE Resource Directory. Future work is planned on 155 performing discovery and negotiation without the RD as well.) 157 2. Aim 159 The following simple scenarios aim to better portray how CoAP 160 protocol negotiation benefits communicating nodes 162 2.1. Overcoming Middlebox Issues 164 Discovering which transports are available is important for a client 165 to determine the optimal alternative to perform CoAP messaging 166 according to its needs, particularly when separated from a CoAP 167 server via a NAT. It is well-known that some firewalls as well as 168 many NATs, particularly home gateways, hinder the proper operation of 169 UDP traffic. NAT bindings for UDP-based traffic do not have as long 170 timeouts as TCP-based traffic. 172 +-----------+ 173 | Resource | 174 +--4-->| Directory | 175 | +-----------+ 176 +---+ | ^ 177 +----4--->| |<---+ +---1----+ 178 +-------------+--V--+ | | +-V-----------------+ 179 | | |--2-->| |--2-->| | | 180 | | UDP | | N | | UDP | | 181 | | |<--3--| |<--3--| | | 182 | CoAP Client +-----+ | A | +-----+ CoAP Server | 183 | | |--5-->| |--5-->| | | 184 | | TCP | | T | | TCP | | 185 | | |<--6--| |<--6--| | | 186 +-------------+-----+ +---+ +-----+-------------+ 188 Figure 1: CoAP Client initially accesses CoAP Server over UDP and 189 then switching to TCP 191 Figure 1 depicts such a scenario. Step 1 depicts the CoAP Server 192 registering its transports to a Resource Directory. A CoAP client 193 uses UDP initially for accessing a CoAP Server in Step 2 and receives 194 a response in Step 3. Subsequently a CoAP client, residing behind a 195 NAT, performs a lookup on the Resource Directory in Step 4 to 196 discover alternative transports offered by the server. Steps 5 and 6 197 illustrate the client then deciding to use TCP for CoAP messaging 198 instead of UDP to set up an Observe relationship for a resource at 199 the CoAP Server, in order to avoid incoming packets containing 200 resource updates being discarded by the NAT. 202 2.2. Better resource caching and serving in proxies 204 Figure 2 outlines a more complex example of intermediate nodes such 205 as CoAP-based proxies to intelligently cache and respond to CoAP or 206 HTTP clients with the same resource representation requested over 207 alternative transports or server endpoints. As with the earlier 208 example, the CoAP Server registers its transports to a Resource 209 Directory (This is assumed to be performed beforehand and not 210 depicted in the figure, for brevity) 212 In this example, a CoAP over WebSockets client successfully obtains a 213 response from a CoAP forward proxy to retrieve a resource 214 representation from an origin server using UDP, by supplying the CoAP 215 server's endpoint address and resource in a Proxy-URI option. Arrow 216 1 represents a GET request to "coap+ws://proxy.example.com" which 217 subsequently retrieves the resource from the CoAP server using the 218 URI "coap://example.org/sensors/temperature", shown as arrow 2. 220 +---------+ 221 | CoAP+WS | +--------+-------+---+ +-----+---------+ 222 | Client |<-1->| Web | | |<-2->| | | 223 +---------+ | Socket | CoAP | U | | UDP | CoAP | 224 +---------+ +--------+ Proxy | D | +-----+ Server | 225 | HTTP |<-3->| HTTP | | P | | TCP | | 226 | Client |<-4->| | | | | | | 227 +---------+ +--------+-------+---+ +-----+---------+ 229 Figure 2: Proxying and returning a resource's alternate cached 230 representations to multiple clients 232 Subsequently, assume an HTTP client requests the same resource, but 233 instead specifies a CoAP over TCP alternative URI instead. Arrow 3 234 represents this event, where the HTTP client performs a GET request 235 to "http://proxy.example.com/coap+tcp://example.org/sensors/ 236 temperature". When the proxy receives the request, instead of 237 immediately retrieving the temperature resource again over TCP, it 238 first verifies from the Resource Directory whether the cached 239 resource retrieved over UDP is a valid equivalent representation of 240 the resource requested by the HTTP client over TCP. Upon 241 confirmation, the proxy is able to supply the same cached 242 representation to the HTTP client as well (arrow 4). 244 3. Node Types based on Transport Availability 246 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 247 devices, in terms of their resource constraints, energy limitations 248 and communication power. For this document, in addition to these 249 capabilities, it seems useful to also identify devices based on their 250 transport capabilities. 252 +-------+----------------------------+ 253 | Name | Transport Availability | 254 +-------+----------------------------+ 255 | T0 | Single transport | 256 | | | 257 | T1 | Multiple transports, with | 258 | | one or more active at any | 259 | | point in time | 260 | | | 261 | T2 | Multiple active and | 262 | | persistent transports | 263 | | at all times | 264 +-------+----------------------------+ 266 Table 1: Classes of Available Transports 268 Type T0 nodes possess the capability of exactly 1 type of transport 269 channel for CoAP, at all times. These include both active and sleepy 270 nodes, which may choose to perform duty cycling for power saving. 272 Type T1 nodes possess multiple different transports, and can retrieve 273 or expose CoAP resources over any or all of these transports. 274 However, not all transports are constantly active and certain 275 transport channels and interfaces could be kept in a mostly-off state 276 for energy-efficiency, such as when using CoAP over SMS. 278 Type T2 nodes possess more than 1 transport, and multiple transports 279 are simultaneously active at all times in a persistent manner. CoAP 280 proxy nodes which allow CoAP endpoints from disparate transports to 281 communicate with each other, are a good example of this. 283 4. New Resource Directory Parameters 285 In order to allow resource interactions between clients and servers 286 with multiple locations or transports, the registration, update and 287 lookup interfaces of the CoRE Resource Directory need to be extended. 288 In this section two new RD parameters, "at" and "tt" are introduced. 289 Both are optional CoAP features. If supported, they occur at the 290 granularity level of an origin server, ie. they cannot be applied 291 selectively on some resources only. When absent, it is assumed that 292 the server does not support multiple transports or locations. 294 4.1. The 'at' RD parameter 296 A CoAP server wishing to advertise its resources over multiple 297 transports does so by using a new "at" parameter to register a list 298 of CoAP alternative transport URIs during registration with a 299 Resource Directory. Such a URI would contain the schemes, addresses 300 as well as any ports or paths at which the server is available. 302 +-----------+-------+---------------+-------------------------------+ 303 | Name | Query | Validity | Description | 304 +-----------+-------+---------------+-------------------------------+ 305 | CoAP | at | URI | Comma separated list of URIs | 306 | Transport | | | (scheme, address, port, and | 307 | URI List | | | path) available at the server | 308 +-----------+-------+---------------+-------------------------------+ 310 Table 2: The "at" RD parameter 312 The "at" parameter extends the Resource Directory's Registration and 313 Update interfaces. 315 The following example shows a type T1 endpoint registering its 316 resources and advertising its ability to use TCP as an alternative 317 transport: 319 Req: POST coap:/rd.example.com/rd 320 ?ep=node1&at=coap+tcp://server.example.com,coap+ws://server.example.com:5683/ws/ 321 Content-Format: 40 322 Payload: 323 ;ct=41;rt="temperature-f";if="sensor", 324 ;ct=41;rt="door";if="sensor" 326 Res: 2.01 Created 327 Location: /rd/4521 329 The next example shows the same endpoint updating its registration 330 with a new lifetime and the availability of a single alternative 331 transport for CoAP (in this case WebSockets): 333 Req: POST /rd/4521?lt=600&at=coap+ws://server.example.com:5683/ws/ 334 Content-Format: 40 335 Payload: 336 ;ct=41;rt="temperature-f";if="sensor", 337 ;ct=41;rt="door";if="sensor" 339 Res: 2.04 Changed 341 4.2. The 'tt' RD parameter 343 A CoAP client wishing to perform a look-up on the Resource Directory 344 for CoAP servers supporting multiple transports does so by using a 345 new "tt" parameter to query for CoAP alternative transport URIs. 347 +-----------+-------+---------------+-------------------------------+ 348 | Name | Query | Validity | Description | 349 +-----------+-------+---------------+-------------------------------+ 350 | CoAP | tt | | Transport type | 351 | Transport | | | requested by | 352 | Type | | | the client | 353 +-----------+-------+---------------+-------------------------------+ 355 Table 3: The "tt" RD parameter 357 The "tt" parameter extends the Resource Directory's rd-lookup 358 interface. 360 The following example shows a client performing a lookup for 361 endpoints supporting TCP: 363 Req: GET /rd-lookup/ep?tt=tcp 365 Res: 2.05 Content 366 ;ep="node5", 367 ;ep="node7" 369 The next example shows a client performing a lookup for all 370 transports supported by a specific endpoint: 372 Req: GET /rd-lookup/ep?ep=node5&tt=* 374 Res: 2.05 Content 375 ;ep="node5", 376 ;ep="node5" 378 5. IANA Considerations 380 This document requests the registration of new RD parameter types 381 "at" and "tt". 383 6. Security Considerations 385 When multiple transports, locations and representations are used, 386 some obvious risks are present both at the origin server as well as 387 by requesting clients. 389 When a client is presented with alternate URIs for retrieving 390 resources, it presents an opportunity for attackers to mount a series 391 of attacks, either by hijacking communication and masquerading as an 392 alternate location or by using a man-in-the-middle attack on TLS- 393 based communication to a server and redirecting traffic to an 394 alternate location. A malicious or compromised server could also be 395 used for reflective denial-of-service attacks on innocent third 396 parties. Moreover, clients may obtain web links to alternate URIs 397 containing weaker security properties than the existing session. 399 7. Acknowledgements 401 Thanks to Klaus Hartke for comments and reviewing this draft, and 402 Teemu Savolainen for initial discussions about protocol negotations 403 and lifetime values. Zach Shelby provided significant suggestions on 404 how the Resource Directory can be employed and extended in place of 405 link attributes and relation types. 407 8. References 409 8.1. Normative References 411 [I-D.ietf-core-resource-directory] 412 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 413 Resource Directory", draft-ietf-core-resource-directory-10 414 (work in progress), March 2017. 416 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 417 Constrained-Node Networks", RFC 7228, 418 DOI 10.17487/RFC7228, May 2014, 419 . 421 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 422 Application Protocol (CoAP)", RFC 7252, 423 DOI 10.17487/RFC7252, June 2014, 424 . 426 [RFC7641] Hartke, K., "Observing Resources in the Constrained 427 Application Protocol (CoAP)", RFC 7641, 428 DOI 10.17487/RFC7641, September 2015, 429 . 431 8.2. Informative References 433 [CoREWG96] 434 https://www.ietf.org/proceedings/96/minutes/minutes- 435 96-core, "IETF96 CoRE minutes", July 2016. 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [WWWArchv1] 443 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 444 of the World Wide Web, Volume One", December 2004. 446 Appendix A. Change Log 448 A.1. From -04 to -05 450 Freshness update 452 A.2. From -03 to -04 454 Removed previously introduced link attribute and relation types 456 Initial foray with Resource Directory support 458 A.3. From -02 to -03 460 Added new author 462 Rewrite of "Introduction" section 464 Added new Aims Section 466 Added new Section on Node Types 468 Introduced "al" Active Lifetime link attribute 470 Added new Section on Observing transports and resources 472 Security and IANA considerations sections populated 474 A.4. From -01 to -02 476 Freshness update. 478 A.5. From -00 to -01 480 Reworked "Introduction" section, added "Rationale", and "Goals" 481 sections. 483 Authors' Addresses 485 Bilhanan Silverajan 486 Tampere University of Technology 487 Korkeakoulunkatu 10 488 FI-33720 Tampere 489 Finland 491 Email: bilhanan.silverajan@tut.fi 493 Mert Ocak 494 Ericsson 495 Hirsalantie 11 496 02420 Jorvas 497 Finland 499 Email: mert.ocak@ericsson.com