idnits 2.17.1 draft-silverajan-core-coap-protocol-negotiation-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2846 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 527, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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: January 9, 2017 Ericsson 6 July 8, 2016 8 CoAP Protocol Negotiation 9 draft-silverajan-core-coap-protocol-negotiation-03 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. 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 January 9, 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 2.3. Interaction with Energy-constrained Servers . . . . . . . 5 59 3. Node Types based on Transport Availability . . . . . . . . . 6 60 4. New Link Attribute and Relation types . . . . . . . . . . . . 7 61 5. Observing Transport Types and Resource Representations . . . 8 62 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 10.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 70 A.1. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 13 71 A.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 13 72 A.3. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 using 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 A means for CoAP clients to interact with an origin server's CoRE 137 resource directory interface to discover alternative transports 138 and links describing alternate locations of CoAP resources. 140 o An ability for servers to convey the names of supported CoAP 141 transports to requesting clients, in order of preference, as well 142 as any optional lifetime values associated with them. 144 o A new link format attribute as well as a new link relation type 145 that together enable an origin server to serve a resource from 146 other protocol configurations or endpoints. 148 2. Aim 150 The following simple scenarios aim to better portray how CoAP 151 protocol negotiation benefits communicating nodes 153 2.1. Overcoming Middlebox Issues 155 Discovering which transports are available is important for a client 156 to determine the optimal alternative to perform CoAP messaging 157 according to its needs, particularly when separated from a CoAP 158 server via a NAT. It is well-known that some firewalls as well as 159 many NATs, particularly home gateways, hinder the proper operation of 160 UDP traffic. NAT bindings for UDP-based traffic do not have as long 161 timeouts as TCP-based traffic. 163 +-------------+-----+ +---+ +-----+-------------+ 164 | | |--1-->| |--1-->| | | 165 | | UDP | | N | | UDP | | 166 | | |<--2--| |<--2--| | | 167 | CoAP Client +-----+ | A | +-----+ CoAP Server | 168 | | |--3-->| |--3-->| | | 169 | | TCP | | T | | TCP | | 170 | | |<--4--| |<--4--| | | 171 +-------------+-----+ +---+ +-----+-------------+ 173 Figure 1: CoAP Client initially accesses CoAP Server over UDP and 174 then switching to TCP 176 Figure 1 depicts such a scenario, where a CoAP client uses UDP 177 initially for accessing a CoAP Server, and engages in discovering 178 alternative transports offered by the server. The client 179 subsequently decides to use TCP for CoAP messaging instead of UDP to 180 set up an Observe relationship for a resource at the CoAP Server, in 181 order to avoid incoming packets containing resource updates being 182 discarded by the NAT. 184 2.2. Better resource caching and serving in proxies 186 Figure 2 outlines a more complex example of intermediate nodes such 187 as CoAP-based proxies to intelligently cache and respond to CoAP or 188 HTTP clients with the same resource representation requested over 189 alternative transports or server endpoints. 191 In this example, a CoAP over WebSockets client successfully obtains a 192 response from a CoAP forward proxy to retrieve a resource 193 representation from an origin server using UDP, by supplying the CoAP 194 server's endpoint address and resource in a Proxy-URI option. Arrow 195 1 represents a GET request to "coap+ws://proxy.example.com" which 196 subsequently retrieves the resource from the CoAP server using the 197 URI "coap://example.org/sensors/temperature", shown as arrow 2. 199 +---------+ 200 | CoAP+WS | +--------+-------+---+ +-----+---------+ 201 | Client |<-1->| Web | | |<-2->| | | 202 +---------+ | Socket | CoAP | U |<-4->| UDP | CoAP | 203 +---------+ +--------+ Proxy | D | +-----+ Server | 204 | HTTP |<-3->| HTTP | | P | | TCP | | 205 | Client |<-5->| | | | | | | 206 +---------+ +--------+-------+---+ +-----+---------+ 208 Figure 2: Proxying and returning a resource's alternate cached 209 representations to multiple clients 211 Subsequently, assume an HTTP client requests the same resource, but 212 instead specifies a CoAP over TCP alternative URI instead. Arrow 3 213 represents this event, where the HTTP client performs a GET request 214 to "http://proxy.example.com/coap+tcp://example.org/sensors/ 215 temperature". When the proxy receives the request, instead of 216 immediately retrieving the temperature resource again over TCP, it 217 first verifies from the CoAP server whether the cached resource 218 retrieved over UDP is a valid equivalent representation of the 219 resource requested by the HTTP client over TCP (arrow 4). Upon 220 confirmation, the proxy is able to supply the same cached 221 representation to the HTTP client as well (arrow 5). 223 2.3. Interaction with Energy-constrained Servers 225 Figure 3 illustrates discovery and communication between a CoAP 226 client and an energy-constrained CoAP Server. Such a server aims at 227 conserving its energy unless a need arises otherwise. The figure 228 depicts the server maintaining its communication in a low-power state 229 by listening only for incoming SMS messages while disabling 230 communication on radio interfaces requiring greater energy. This is 231 depicted as the server's initial state in the figure, showing an 232 active SMS endpoint and a disabled or dormant UDP interface. 234 +-------------+-----+ +-----+-------------+ 235 | | |--1---->| | | 236 | | SMS | | SMS | | 237 | | |<---2---| | | 238 | CoAP Client +-----+ +-----+ CoAP Server | 239 | | |--3---->| | | 240 | | UDP | |(UDP)| | 241 | | |<---4---| | | 242 +-------------+-----+ +-----+-------------+ 244 Figure 3: CoAP client interacting over SMS to discover a server's IP- 245 based endpoint 247 A CoAP client wishing to perform CoAP operations can query a CoAP 248 server for available transports via SMS, as shown in arrow 1. Upon 249 reception of the message, should the server have its radio and IP 250 interface up, it can send an SMS response containing the location of 251 the CoAP IP endpoint and supported transports. Alternatively, the 252 incoming SMS can be also used by the server as a triggering event to 253 temporarily power up its radio interface so that UDP or other 254 transport-based CoAP communication can instead be employed, and 255 likewise provide this information in its response. This is depicted 256 as arrow 2. Subsequently, low latency IP-based CoAP communication 257 can occur between the endpoints as shown by arrows 3 and 4. 259 3. Node Types based on Transport Availability 261 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 262 devices, in terms of their resource constraints, energy limitations 263 and communication power. For this document, in addition to these 264 capabilities, it seems useful to additionally identify devices based 265 on their transport capabilities. 267 +-------+----------------------------+ 268 | Name | Transport Availability | 269 +-------+----------------------------+ 270 | T0 | Single transport | 271 | | | 272 | T1 | Multiple transports, with | 273 | | one or more active at any | 274 | | point in time | 275 | | | 276 | T2 | Multiple active and | 277 | | persistent transports | 278 | | at all times | 279 +-------+----------------------------+ 281 Table 1: Classes of Available Transports 283 Type T0 nodes possess the capability of exactly 1 type of transport 284 channel for CoAP, at all times. These include both active and sleepy 285 nodes, which may choose to perform duty cycling for power saving. 287 Type T1 nodes possess multiple different transports, and can retrieve 288 or expose CoAP resources over any or all of these transports. 289 However, not all transports are constantly active and certain 290 transport channels and interfaces could be kept in a mostly-off state 291 for energy-efficiency, such as when using CoAP over SMS (refer to 292 section 2.1) 294 Type T2 nodes possess more than 1 transport, and multiple transports 295 are simultaneously active at all times in a persistent manner. CoAP 296 proxy nodes which allow CoAP endpoints from disparate transports to 297 communicate with each other, are a good example of this. 299 4. New Link Attribute and Relation types 301 A CoAP server wishing to allow interactions with resources from 302 multiple locations or transports can do so by specifying the 303 Transport Type "tt" link attribute, which is an opaque string. 304 Multiple transport types can be included in the value of this 305 parameter, each separated by a space. In such cases, transport types 306 appear in a prioritised list, with the most preferred transport type 307 by the CoAP server specified first and the lowest priority transport 308 type last. 310 At the same time, each transport type supported by the server is also 311 described with an "altloc" link relation type. The "altloc" relation 312 type specifices a URI (containing the URI scheme, authority and 313 optionally path) providing an alternate endpoint location up to but 314 not including the resource path of a representation. 316 Each URI specified by "altloc" link relation type can also have an 317 active lifetime value described with "al" link extension, which is an 318 integer showing the active lifetime in seconds. The "al" link 319 extension specifies how long the CoAP server will respond to the 320 specified URI in "altloc" relation type. 322 Both "tt" and "altloc" are optional CoAP features. If supported, 323 they occur at the granularity level of an origin server, ie. they 324 cannot be applied selectively on some resources only. Therefore 325 "altloc" is always anchored at the root resource ("/"). The "al" 326 link attribute, while also being optional, exists at the granularity 327 of each transport protocol used. When it is absent, it is assumed 328 that the transport protocol is persistent. 330 Additionally, the "tt" and "al" link attributes as well as the 331 "altloc" relation type can be ignored by unsupported CoAP clients. 333 5. Observing Transport Types and Resource Representations 335 A CoAP client interested in being notified of changes in an origin 336 server's transport protocols for CoAP, can choose to do so with an 337 Observe relationship [RFC7641]. The client registers its interest on 338 the available active transports by setting the Observe option with a 339 GET to ".well-known/core" on a CoAP server, with a client-specified 340 parameter value for "tt" as depicted in Figure 4. Updates on the 341 active transports will be sent to the CoAP client as CoAP 342 notifications. 344 Client Server 345 | | 346 | GET /.well-known/core?tt=* | 347 | Token: 0x7a | Registration 348 | Observe: 0 | 349 +----------------------------->| 350 | | 351 | 2.05 Content | 352 | Token: 0x7a | Notification of 353 | Observe: 18 | transport type 354 | Payload: "udp sms" | 355 |<-----------------------------+ 356 | | 357 | 2.05 Content | 358 | Token: 0x7a | Notification of new 359 | Observe: 32 | transport 360 | Payload: "udp sms tcp" | 361 |<-----------------------------+ 362 | | 363 | 2.05 Content | 364 | Token: 0x7a | Notification of 365 | Observe: 56 | transport type 366 | Payload: "udp sms" | 367 |<-----------------------------+ 369 Figure 4: CoAP client observing .well-known/core for all transport 370 types 372 Observe relationships between a CoAP client and a CoAP server must 373 conform to established norms specified in [RFC7641]. Subsequent 374 notifications are considered to simply be additional responses to the 375 original client GET request. Therefore, should a client subsequently 376 switch to a different transport protocol (such as from UDP to TCP), 377 it is the responsibility of the client to deregister its interest 378 beforehand or cancel its interest as specified in section 3.6 of 379 [RFC7641]. No assumptions of session continuation should be made and 380 the client should instead re-register its interest using the new 381 transport, either actively, or upon the Max-Age of a stored 382 representation being exceeded at the client. 384 A server can also prevent notifications to be perpetually sent to a 385 client on a previous transport, by using confirmable CoAP messages 386 for responses. This allows the server to remove an unresponsive 387 client from its list of interested observers. 389 6. Examples 391 Figure 5 shows a CoAP server returning all transport types and the 392 alternate resource locations to a CoAP client performing a CoAP 393 Request to ./well-known/core 395 In this case, the server supplies two different locations to interact 396 with resources using CoAP over TCP i.e. the resources given in the 397 CoAP response are available from multiple hosts with different entry 398 points and transport layer security. 400 At the same time, the path to the WebSocket endpoint is provided in 401 addition to the FQDN of the server, for using CoAP over WebSockets, 402 exemplifying the ability to separate a CoAP resource path from a web- 403 based CoAP endpoint path in a URI. 405 REQ: GET /.well-known/core 407 RES: 2.05 Content 408 ;ct=40;title="Sensor Index", tt="tcp ws sms", 409 ;rt="temperature-c";if="sensor", 410 ;rt="light-lux";if="sensor", 411 ;rel="altloc", 412 ;rel="altloc", 413 ;rel="altloc", 414 ;rel="altloc" 416 Figure 5: Example of Server response 418 Figure 6 shows a CoAP client actively soliciting a CoAP server for 419 all supported transport types and protocol configurations. 421 REQ: GET /.well-known/core?tt=* 423 RES: 2.05 Content 424 ;tt="tcp sms ws" 425 ;rel="altloc", 426 ;rel="altloc", 427 ;rel="altloc", 428 ;rel="altloc" 430 Figure 6: CoAP client discovering transports supported by a CoAP 431 server. 433 Figure 7 shows a CoAP client explicitly soliciting support for a 434 specific transport type using a query filter parameter. 436 REQ: GET /.well-known/core?tt=sms 438 RES: 2.05 Content 439 ;tt="tcp sms ws" 440 ;rel="altloc" 442 Figure 7: CoAP client looking for a specific transport to use with a 443 CoAP server. 445 Figure 8 shows a CoAP client making a CoAP over SMS request to an 446 energy-constrained CoAP server, explicitly soliciting support for 447 UDP-based communication by using a query filter parameter. The 448 server temporarily activates its UDP interface, responds with the 449 location of the UDP endpoint and also provides the expected lifetime 450 of the transport, which in this case is 120 seconds. 452 REQ: GET /.well-known/core?tt=udp 454 RES: 2.05 Content 455 ;tt="udp sms" 456 ;rel="altloc";al=120 458 Figure 8: CoAP client using CoAP over SMS to discover UDP-based 459 address and transport lifetime. 461 7. IANA Considerations 463 This document requests the registration of a new link relation type 464 "altloc". 466 Relation name: 467 altloc 469 Description: 470 Identifies an alternate CoAP endpoint location for a resource. 472 Reference: 473 This document. 475 8. Security Considerations 477 When multiple transports, locations and representations are used, 478 some obvious risks are present both at the origin server as well as 479 by requesting clients. 481 An energy-constrained node exposing its resource representations 482 using CoAP over SMS, but subsequently enabling its IP interface on- 483 demand, can be subjected to denial-of-sleep as well as battery 484 draining attacks by attackers. The risk can be somewhat mitigated at 485 the server by strict requirements on the active lifetime of IP-based 486 communication as well as restricting which clients are allowed to 487 request for IP-based communication and referring other incoming 488 requests to a caching proxy instead. 490 When a client is presented with alternate URIs for retrieving 491 resources, it presents an opportunity for attackers to mount a series 492 of attacks, either by hijacking communication and masquerading as an 493 alternate location or by using a man-in-the-middle attack on TLS- 494 based communication to a server and redirecting traffic to an 495 alternate location. A malicious or compromised server could also be 496 used for reflective denial-of-service attacks on innocent third 497 parties. Moreover, clients may obtain web links to alternate URIs 498 containing weaker security properties than the existing session. 500 9. Acknowledgements 502 Thanks to Klaus Hartke for comments and reviewing this draft, and 503 Teemu Savolainen for initial discussions about protocol negotations 504 and lifetime values. 506 10. References 508 10.1. Normative References 510 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 511 Constrained-Node Networks", RFC 7228, 512 DOI 10.17487/RFC7228, May 2014, 513 . 515 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 516 Application Protocol (CoAP)", RFC 7252, 517 DOI 10.17487/RFC7252, June 2014, 518 . 520 [RFC7641] Hartke, K., "Observing Resources in the Constrained 521 Application Protocol (CoAP)", RFC 7641, 522 DOI 10.17487/RFC7641, September 2015, 523 . 525 10.2. Informative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [WWWArchv1] 533 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 534 of the World Wide Web, Volume One", December 2004. 536 Appendix A. Change Log 538 A.1. From -02 to -03 540 Added new author 542 Rewrite of "Introduction" section 544 Added new Aims Section 546 Added new Section on Node Types 548 Introduced "al" Active Lifetime link attribute 550 Added new Section on Observing transports and resources 552 Security and IANA considerations sections populated 554 A.2. From -01 to -02 556 Freshness update. 558 A.3. From -00 to -01 560 Reworked "Introduction" section, added "Rationale", and "Goals" 561 sections. 563 Authors' Addresses 564 Bilhanan Silverajan 565 Tampere University of Technology 566 Korkeakoulunkatu 10 567 FI-33720 Tampere 568 Finland 570 Email: bilhanan.silverajan@tut.fi 572 Mert Ocak 573 Ericsson 574 Hirsilantie 11 575 02420 Jorvase 576 Finland 578 Email: mert.ocak@ericsson.com