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