idnits 2.17.1 draft-silverajan-core-coap-protocol-negotiation-04.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 (October 31, 2016) is 2728 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7641' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 436, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-08 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: May 4, 2017 Ericsson 6 October 31, 2016 8 CoAP Protocol Negotiation 9 draft-silverajan-core-coap-protocol-negotiation-04 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 May 4, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 69 A.1. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 10 70 A.2. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 11 71 A.3. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 11 72 A.4. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 The Constrained Application Protocol (CoAP) [RFC7252] allows clients, 78 origin servers and proxies, to exchange and manipulate resource 79 representations using REST-based methods over UDP or DTLS. CoAP 80 messaging is however being extended to use other alternative 81 underlying transports. These include reliable transports such as 82 TCP, WebSockets and TLS. In addition, the use of SMS as a CoAP 83 transport remains a possibility for simple communication in cellular 84 networks. 86 When CoAP-based endpoints and proxies possess the ability to perform 87 CoAP messaging over multiple transports, significant benefits can be 88 obtained if communicating client endpoints can discover that multiple 89 transport bindings may exist on an origin server over which CoAP 90 resources can be retrieved. This allows a client to understand and 91 possibly subsitute a different transport protocol configuration for 92 the same CoAP resources on the origin server, based on the 93 preferences of the communicating peers. Inevitably, if two CoAP 94 endpoints reside in distinctly separate networks with orthogonal 95 transports, a CoAP proxy node is needed between the two networks so 96 that CoAP Requests and Responses can be exchanged properly. 98 A URI in CoAP, however, serves two purposes simultaneously. It 99 firstly functions as a locator, by specifying the network location of 100 the endpoint hosting the resource, and the underlying transport used 101 by CoAP for accessing the resource representation. It secondly 102 identifies the name of the specific resource found at that endpoint 103 together with its namespace, or resource path. A single CoAP URI 104 cannot be used to express the identity of the resource independently 105 of alternate underlying transports or protocol configuration. 106 Multiple URIs can result for a single CoAP resource representations 107 if: 109 o the authority components of the URI differ, owing to the same 110 physical host exposing several network endpoints. For example, 111 "coap://example.org/sensors/temperature" and 112 "coap://example.net/sensors/temperature" 114 o the scheme components of the URI differ, owing to the origin 115 server exposing several underlying transport alternatives. For 116 example, "coap://example.org/sensors/temperature" and 117 "coap+tcp://example.org/sensors/temperature" 119 o the path components of the URI differ, should an origin server 120 also allow alternative transport endpoint such as the WebSocket 121 protocol, to be expressed using the path. For example, 122 "coap://example.org/sensors/temperature" and 123 "coap+ws://example.org/ws-endpoint/sensors/temperature" 125 Without a priori knowledge, clients would be unable to ascertain if 126 two or more URIs provided by an origin server are associated to the 127 same representation or not. Consequently, a communication mechanism 128 needs to be conceived to allow an origin server to properly capture 129 the relationship between these alternate representations or locations 130 and then subsequently supply this information to clients. This also 131 goes some way in limiting URI aliasing [WWWArchv1]. 133 In order to support CoAP clients, proxies and servers wishing to use 134 CoAP over multiple transports, this draft proposes the following: 136 o An ability for servers to register supported CoAP transports to a 137 CoRE Resource Directory [I-D.ietf-core-resource-directory] with 138 optional registration lifetime values 140 o A means for CoAP clients to interact with a CoRE resource 141 directory interface for requesting and discovering alternative 142 transports and locations of CoAP resources 144 o New Resource Directory parameter types enabling the above- 145 mentioned features. 147 (Note: Although previous versions of this draft provided a mechanism 148 for CoAP clients to directly interact with, discover, use and 149 possibly even negotiate an alternative transport for CoAP-based 150 communication directly with an origin server, discussions at the CoRE 151 Working Group yielded new insights about problems with the proposed 152 approach [CoREWG96]. The current version consequently adopts the 153 usage of the CoRE Resource Directory. Future work is planned on 154 performing discovery and negotiation without the RD as well.) 156 2. Aim 158 The following simple scenarios aim to better portray how CoAP 159 protocol negotiation benefits communicating nodes 161 2.1. Overcoming Middlebox Issues 163 Discovering which transports are available is important for a client 164 to determine the optimal alternative to perform CoAP messaging 165 according to its needs, particularly when separated from a CoAP 166 server via a NAT. It is well-known that some firewalls as well as 167 many NATs, particularly home gateways, hinder the proper operation of 168 UDP traffic. NAT bindings for UDP-based traffic do not have as long 169 timeouts as TCP-based traffic. 171 +-----------+ 172 | Resource | 173 +--4-->| Directory | 174 | +-----------+ 175 +---+ | ^ 176 +----4--->| |<---+ +---1----+ 177 +-------------+--V--+ | | +-V-----------------+ 178 | | |--2-->| |--2-->| | | 179 | | UDP | | N | | UDP | | 180 | | |<--3--| |<--3--| | | 181 | CoAP Client +-----+ | A | +-----+ CoAP Server | 182 | | |--5-->| |--5-->| | | 183 | | TCP | | T | | TCP | | 184 | | |<--6--| |<--6--| | | 185 +-------------+-----+ +---+ +-----+-------------+ 187 Figure 1: CoAP Client initially accesses CoAP Server over UDP and 188 then switching to TCP 190 Figure 1 depicts such a scenario. Step 1 depicts the CoAP Server 191 registering its transports to a Resource Directory. A CoAP client 192 uses UDP initially for accessing a CoAP Server in Step 2 and receives 193 a response in Step 3. Subsequently a CoAP client, residing behind a 194 NAT, performs a lookup on the Resource Directory in Step 4 to 195 discover alternative transports offered by the server. Steps 5 and 6 196 illustrate the client then deciding to use TCP for CoAP messaging 197 instead of UDP to set up an Observe relationship for a resource at 198 the CoAP Server, in order to avoid incoming packets containing 199 resource updates being discarded by the NAT. 201 2.2. Better resource caching and serving in proxies 203 Figure 2 outlines a more complex example of intermediate nodes such 204 as CoAP-based proxies to intelligently cache and respond to CoAP or 205 HTTP clients with the same resource representation requested over 206 alternative transports or server endpoints. As with the earlier 207 example, the CoAP Server registers its transports to a Resource 208 Directory (This is assumed to be performed beforehand and not 209 depicted in the figure, for brevity) 211 In this example, a CoAP over WebSockets client successfully obtains a 212 response from a CoAP forward proxy to retrieve a resource 213 representation from an origin server using UDP, by supplying the CoAP 214 server's endpoint address and resource in a Proxy-URI option. Arrow 215 1 represents a GET request to "coap+ws://proxy.example.com" which 216 subsequently retrieves the resource from the CoAP server using the 217 URI "coap://example.org/sensors/temperature", shown as arrow 2. 219 +---------+ 220 | CoAP+WS | +--------+-------+---+ +-----+---------+ 221 | Client |<-1->| Web | | |<-2->| | | 222 +---------+ | Socket | CoAP | U | | UDP | CoAP | 223 +---------+ +--------+ Proxy | D | +-----+ Server | 224 | HTTP |<-3->| HTTP | | P | | TCP | | 225 | Client |<-4->| | | | | | | 226 +---------+ +--------+-------+---+ +-----+---------+ 228 Figure 2: Proxying and returning a resource's alternate cached 229 representations to multiple clients 231 Subsequently, assume an HTTP client requests the same resource, but 232 instead specifies a CoAP over TCP alternative URI instead. Arrow 3 233 represents this event, where the HTTP client performs a GET request 234 to "http://proxy.example.com/coap+tcp://example.org/sensors/ 235 temperature". When the proxy receives the request, instead of 236 immediately retrieving the temperature resource again over TCP, it 237 first verifies from the Resource Directory whether the cached 238 resource retrieved over UDP is a valid equivalent representation of 239 the resource requested by the HTTP client over TCP. Upon 240 confirmation, the proxy is able to supply the same cached 241 representation to the HTTP client as well (arrow 4). 243 3. Node Types based on Transport Availability 245 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 246 devices, in terms of their resource constraints, energy limitations 247 and communication power. For this document, in addition to these 248 capabilities, it seems useful to also identify devices based on their 249 transport capabilities. 251 +-------+----------------------------+ 252 | Name | Transport Availability | 253 +-------+----------------------------+ 254 | T0 | Single transport | 255 | | | 256 | T1 | Multiple transports, with | 257 | | one or more active at any | 258 | | point in time | 259 | | | 260 | T2 | Multiple active and | 261 | | persistent transports | 262 | | at all times | 263 +-------+----------------------------+ 265 Table 1: Classes of Available Transports 267 Type T0 nodes possess the capability of exactly 1 type of transport 268 channel for CoAP, at all times. These include both active and sleepy 269 nodes, which may choose to perform duty cycling for power saving. 271 Type T1 nodes possess multiple different transports, and can retrieve 272 or expose CoAP resources over any or all of these transports. 273 However, not all transports are constantly active and certain 274 transport channels and interfaces could be kept in a mostly-off state 275 for energy-efficiency, such as when using CoAP over SMS. 277 Type T2 nodes possess more than 1 transport, and multiple transports 278 are simultaneously active at all times in a persistent manner. CoAP 279 proxy nodes which allow CoAP endpoints from disparate transports to 280 communicate with each other, are a good example of this. 282 4. New Resource Directory Parameters 284 In order to allow resource interactions between clients and servers 285 with multiple locations or transports, the registration, update and 286 lookup interfaces of the CoRE Resource Directory need to be extended. 287 In this section two new RD parameters, "at" and "tt" are introduced. 288 Both are optional CoAP features. If supported, they occur at the 289 granularity level of an origin server, ie. they cannot be applied 290 selectively on some resources only. When absent, it is assumed that 291 the server does not support multiple transports or locations. 293 4.1. The 'at' RD parameter 295 A CoAP server wishing to advertise its resources over multiple 296 transports does so by using a new "at" parameter to register a list 297 of CoAP alternative transport URIs during registration with a 298 Resource Directory. Such a URI would contain the schemes, addresses 299 as well as any ports or paths at which the server is available. 301 +-----------+-------+---------------+-------------------------------+ 302 | Name | Query | Validity | Description | 303 +-----------+-------+---------------+-------------------------------+ 304 | CoAP | at | URI | Comma separated list of URIs | 305 | Transport | | | (scheme, address, port, and | 306 | URI List | | | path) available at the server | 307 +-----------+-------+---------------+-------------------------------+ 309 Table 2: The "at" RD parameter 311 The "at" parameter extends the Resource Directory's Registration and 312 Update interfaces. 314 The following example shows a type T1 endpoint registering its 315 resources and advertising its ability to use TCP as an alternative 316 transport: 318 Req: POST coap:/rd.example.com/rd 319 ?ep=node1&at=coap+tcp://server.example.com,coap+ws://server.example.com:5683/ws/ 320 Content-Format: 40 321 Payload: 322 ;ct=41;rt="temperature-f";if="sensor", 323 ;ct=41;rt="door";if="sensor" 325 Res: 2.01 Created 326 Location: /rd/4521 328 The next example shows the same endpoint updating its registration 329 with a new lifetime and the availability of a single alternative 330 transport for CoAP (in this case WebSockets): 332 Req: POST /rd/4521?lt=600&at=coap+ws://server.example.com:5683/ws/ 333 Content-Format: 40 334 Payload: 335 ;ct=41;rt="temperature-f";if="sensor", 336 ;ct=41;rt="door";if="sensor" 338 Res: 2.04 Changed 340 4.2. The 'tt' RD parameter 342 A CoAP client wishing to perform a look-up on the Resource Directory 343 for CoAP servers supporting multiple transports does so by using a 344 new "tt" parameter to query for CoAP alternative transport URIs. 346 +-----------+-------+---------------+-------------------------------+ 347 | Name | Query | Validity | Description | 348 +-----------+-------+---------------+-------------------------------+ 349 | CoAP | tt | | Transport type | 350 | Transport | | | requested by | 351 | Type | | | the client | 352 +-----------+-------+---------------+-------------------------------+ 354 Table 3: The "tt" RD parameter 356 The "tt" parameter extends the Resource Directory's rd-lookup 357 interface. 359 The following example shows a client performing a lookup for 360 endpoints supporting TCP: 362 Req: GET /rd-lookup/ep?tt=tcp 364 Res: 2.05 Content 365 ;ep="node5", 366 ;ep="node7" 368 The next example shows a client performing a lookup for all 369 transports supported by a specific endpoint: 371 Req: GET /rd-lookup/ep?ep=node5&tt=* 373 Res: 2.05 Content 374 ;ep="node5", 375 ;ep="node5" 377 5. IANA Considerations 379 This document requests the registration of new RD parameter types 380 "at" and "tt". 382 6. Security Considerations 384 When multiple transports, locations and representations are used, 385 some obvious risks are present both at the origin server as well as 386 by requesting clients. 388 When a client is presented with alternate URIs for retrieving 389 resources, it presents an opportunity for attackers to mount a series 390 of attacks, either by hijacking communication and masquerading as an 391 alternate location or by using a man-in-the-middle attack on TLS- 392 based communication to a server and redirecting traffic to an 393 alternate location. A malicious or compromised server could also be 394 used for reflective denial-of-service attacks on innocent third 395 parties. Moreover, clients may obtain web links to alternate URIs 396 containing weaker security properties than the existing session. 398 7. Acknowledgements 400 Thanks to Klaus Hartke for comments and reviewing this draft, and 401 Teemu Savolainen for initial discussions about protocol negotations 402 and lifetime values. Zach Shelby provided significant suggestions on 403 how the Resource Directory can be employed and extended in place of 404 link attributes and relation types. 406 8. References 408 8.1. Normative References 410 [I-D.ietf-core-resource-directory] 411 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 412 Resource Directory", draft-ietf-core-resource-directory-08 413 (work in progress), July 2016. 415 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 416 Constrained-Node Networks", RFC 7228, 417 DOI 10.17487/RFC7228, May 2014, 418 . 420 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 421 Application Protocol (CoAP)", RFC 7252, 422 DOI 10.17487/RFC7252, June 2014, 423 . 425 [RFC7641] Hartke, K., "Observing Resources in the Constrained 426 Application Protocol (CoAP)", RFC 7641, 427 DOI 10.17487/RFC7641, September 2015, 428 . 430 8.2. Informative References 432 [CoREWG96] 433 https://www.ietf.org/proceedings/96/minutes/minutes- 434 96-core, "IETF96 CoRE minutes", July 2016. 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [WWWArchv1] 442 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 443 of the World Wide Web, Volume One", December 2004. 445 Appendix A. Change Log 447 A.1. From -03 to -04 449 Removed previously introduced link attribute and relation types 451 Initial foray with Resource Directory support 453 A.2. From -02 to -03 455 Added new author 457 Rewrite of "Introduction" section 459 Added new Aims Section 461 Added new Section on Node Types 463 Introduced "al" Active Lifetime link attribute 465 Added new Section on Observing transports and resources 467 Security and IANA considerations sections populated 469 A.3. From -01 to -02 471 Freshness update. 473 A.4. From -00 to -01 475 Reworked "Introduction" section, added "Rationale", and "Goals" 476 sections. 478 Authors' Addresses 480 Bilhanan Silverajan 481 Tampere University of Technology 482 Korkeakoulunkatu 10 483 FI-33720 Tampere 484 Finland 486 Email: bilhanan.silverajan@tut.fi 488 Mert Ocak 489 Ericsson 490 Hirsalantie 11 491 02420 Jorvas 492 Finland 494 Email: mert.ocak@ericsson.com