idnits 2.17.1 draft-silverajan-core-coap-protocol-negotiation-08.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 are 7 instances of too long lines in the document, the longest one being 15 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 (March 5, 2018) is 2237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 674, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-12 Summary: 1 error (**), 0 flaws (~~), 3 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: September 6, 2018 Ericsson 6 March 5, 2018 8 CoAP Protocol Negotiation 9 draft-silverajan-core-coap-protocol-negotiation-08 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. Several mechanisms are proposed: Extending the CoRE 19 Resource Directory with new parameter types, introducing a new CoAP 20 Option with which clients can interact directly with servers without 21 needing the Resource Directory, and finally a new CoRE Link Attribute 22 allowing exposing alternate locations on a per-resource basis. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 6, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Overcoming Middlebox Issues . . . . . . . . . . . . . . . 4 61 2.2. Better resource caching and serving in proxies . . . . . 5 62 2.3. Interaction with Energy-constrained Servers . . . . . . . 6 63 3. Node Types based on Transport Availability . . . . . . . . . 7 64 4. New Resource Directory Parameters . . . . . . . . . . . . . . 8 65 4.1. The 'at' RD parameter . . . . . . . . . . . . . . . . . . 8 66 4.2. The 'tt' RD parameter . . . . . . . . . . . . . . . . . . 9 67 5. CoAP Alternative-Transport Option . . . . . . . . . . . . . . 11 68 6. The 'ol' CoRE Link Attribute . . . . . . . . . . . . . . . . 14 69 6.1. Using /.well-known/core . . . . . . . . . . . . . . . . . 14 70 6.2. Using CoRE Resource Directory . . . . . . . . . . . . . . 15 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 10.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 17 78 A.1. From -07 to -08 . . . . . . . . . . . . . . . . . . . . . 17 79 A.2. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 17 80 A.3. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 17 81 A.4. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 17 82 A.5. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 17 83 A.6. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 17 84 A.7. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 18 85 A.8. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 The Constrained Application Protocol (CoAP) [RFC7252] allows clients, 91 origin servers and proxies, to exchange and manipulate resource 92 representations using REST-based methods over UDP or DTLS. CoAP 93 messaging however can use other alternative underlying transports 94 [I-D.silverajan-core-coap-alternative-transports]. 96 When CoAP-based endpoints and proxies possess the ability to perform 97 CoAP messaging over multiple transports, significant benefits can be 98 obtained if communicating client endpoints can discover that multiple 99 transport bindings may exist on an origin server over which CoAP 100 resources can be retrieved. This allows a client to understand and 101 possibly substitute a different transport protocol configuration for 102 the same CoAP resources on the origin server, based on the 103 preferences of the communicating peers. Inevitably, if two CoAP 104 endpoints reside in distinctly separate networks with orthogonal 105 transports, a CoAP proxy node is needed between the two networks so 106 that CoAP Requests and Responses can be exchanged properly. 108 A URI in CoAP, however, serves two purposes simultaneously. It 109 firstly functions as a locator, by specifying the network location of 110 the endpoint hosting the resource, and the underlying transport used 111 by CoAP for accessing the resource representation. It secondly 112 identifies the name of the specific resource found at that endpoint 113 together with its namespace, or resource path. A single CoAP URI 114 cannot be used to express the identity of the resource independently 115 of alternate underlying transports or protocol configuration. 116 Multiple URIs can result for a single CoAP resource representations 117 if: 119 o the authority components of the URI differ, owing to the same 120 physical host exposing several network endpoints. For example, 121 "coap://example.org/sensors/temperature" and 122 "coap://example.net/sensors/temperature" 124 o the scheme components of the URI differ, owing to the origin 125 server exposing several underlying transport alternatives. For 126 example, "coap://example.org/sensors/temperature" and 127 "coap+tcp://example.org/sensors/temperature" 129 Without a priori knowledge, clients would be unable to ascertain if 130 two or more URIs provided by an origin server are associated to the 131 same representation or not. Consequently, a communication mechanism 132 needs to be conceived to allow an origin server to properly capture 133 the relationship between these alternate representations or locations 134 and then subsequently supply this information to clients. This also 135 goes some way in limiting URI aliasing [WWWArchv1]. 137 In order to support CoAP clients, proxies and servers wishing to use 138 CoAP over multiple transports, this draft proposes the following: 140 o An ability for servers to register supported CoAP transports to a 141 CoRE Resource Directory [I-D.ietf-core-resource-directory] with 142 optional registration lifetime values 144 o A means for CoAP clients to interact with a CoRE resource 145 directory interface for requesting and discovering alternative 146 transports and locations of CoAP resources 148 o New Resource Directory parameter types enabling the above- 149 mentioned features. 151 o A new CoAP Option called Alternative-Transport that can be used by 152 CoAP clients to discover and retrieve the types of alternative 153 transports available at the origin server, as well as the links 154 describing the transport-specific endpoint address at which CoAP 155 resources are exposed from. 157 o A new CoRE Link attribute for exposing transports and endpoint 158 locations on an origin server on a per-resource basis. 160 2. Aim 162 The following simple scenarios aim to better portray how CoAP 163 protocol negotiation benefits communicating nodes 165 2.1. Overcoming Middlebox Issues 167 Discovering which transports are available is important for a client 168 to determine the optimal alternative to perform CoAP messaging 169 according to its needs, particularly when separated from a CoAP 170 server via a NAT. It is well-known that some firewalls as well as 171 many NATs, particularly home gateways, hinder the proper operation of 172 UDP traffic. NAT bindings for UDP-based traffic do not have as long 173 timeouts as TCP-based traffic. 175 +-------------+-----+ +---+ +-------------------+ 176 | | |--1-->| |--1-->| | | 177 | | UDP | | N | | UDP | | 178 | | |<--2--| |<--2--| | | 179 | CoAP Client +-----+ | A | +-----+ CoAP Server | 180 | | |--3-->| |--3-->| | | 181 | | TCP | | T | | TCP | | 182 | | |<--4--| |<--4--| | | 183 +-------------+-----+ +---+ +-----+-------------+ 185 Figure 1: CoAP Client initially accesses CoAP Server over UDP and 186 then switching to TCP 188 Figure 1 depicts such a scenario, where a CoAP client residing behind 189 a NAT uses UDP initially for accessing a CoAP Server, and engages in 190 discovering alternative transports offered by the server. The client 191 subsequently decides to use TCP for CoAP messaging instead of UDP to 192 set up an Observe relationship for a resource at the CoAP Server, in 193 order to avoid incoming packets containing resource updates being 194 discarded by the NAT. 196 2.2. Better resource caching and serving in proxies 198 Figure 2 outlines a more complex example of intermediate nodes such 199 as CoAP-based proxies to intelligently cache and respond to CoAP or 200 HTTP clients with the same resource representation requested over 201 alternative transports or server endpoints. As with the earlier 202 example, the CoAP Server registers its transports to a Resource 203 Directory (This is assumed to be performed beforehand and not 204 depicted in the figure, for brevity) 206 In this example, a CoAP over WebSockets client successfully obtains a 207 response from a CoAP forward proxy to retrieve a resource 208 representation from an origin server using UDP, by supplying the CoAP 209 server's endpoint address and resource in a Proxy-URI option. Arrow 210 1 represents a GET request to "coap+ws://proxy.example.com" which 211 subsequently retrieves the resource from the CoAP server using the 212 URI "coap://example.org/sensors/temperature", shown as arrow 2. 214 +---------+ 215 | CoAP+WS | +--------+-------+---+ +-----+---------+ 216 | Client |<-1->| Web | | |<-2->| | | 217 +---------+ | Socket | CoAP | U | | UDP | CoAP | 218 +---------+ +--------+ Proxy | D | +-----+ Server | 219 | HTTP |<-3->| HTTP | | P | | TCP | | 220 | Client |<-4->| | | | | | | 221 +---------+ +--------+-------+---+ +-----+---------+ 223 Figure 2: Proxying and returning a resource's alternate cached 224 representations to multiple clients 226 Subsequently, assume an HTTP client requests the same resource, but 227 instead specifies a CoAP over TCP alternative URI instead. Arrow 3 228 represents this event, where the HTTP client performs a GET request 229 to "http://proxy.example.com/coap+tcp://example.org/sensors/ 230 temperature". When the proxy receives the request, instead of 231 immediately retrieving the temperature resource again over TCP, it 232 first verifies either from the Resource Directory or directly from 233 the server, whether the cached resource retrieved over UDP is a valid 234 equivalent representation of the resource requested by the HTTP 235 client over TCP. Upon confirmation, the proxy is able to supply the 236 same cached representation to the HTTP client as well (arrow 4). 238 2.3. Interaction with Energy-constrained Servers 240 Figure 3 illustrates discovery and communication between a CoAP 241 client and an energy-constrained CoAP Server. Such a server aims at 242 conserving its energy unless a need arises otherwise. The figure 243 first depicts the server registering itself to a Resource Directory 244 over IP, and also supplies its alternative CoAP transport endpoints 245 (in this case, SMS), in steps 1 and 2. The server can subsequently 246 disable communication radio interfaces requiring greater energy (such 247 as for IP-based comunication), powering it up sporadically for 248 maintenance activities like registration renewals. At other times, 249 it maintains communication in a low-power state by listening only for 250 incoming SMS messages. 252 +---------+ 253 | CoRE | 254 +-->| RD |<--+ 255 | +-+---------+-+ | 256 3| | | |1 257 | |4 2| | 258 | v v | 259 +---------------+ +---------------+ 260 | | | | | | 261 | CoAP | UDP | | UDP | CoAP | 262 | Client +-----+ 5 +-----+ Server | 263 | | SMS +------>| SMS | | 264 | | +<------+ | | 265 +---------------+ 6 +---------------+ 267 Figure 3: CoAP client interacting with RD to discover a server's SMS- 268 based endpoint 270 A CoAP client wishing to perform CoAP operations with an energy- 271 constrained CoAP server may query a resource directory for the SMS- 272 based endpoint of the server (steps 3 and 4). Subsequently, SMS- 273 based CoAP communication can occur between the endpoints as shown by 274 arrows 5 and 6. Alternatively, the incoming SMS can be also used by 275 the server as a triggering event to temporarily power up its radio 276 interface so that UDP or other transport-based CoAP communication can 277 instead be employed for low latency communication with the client. 279 3. Node Types based on Transport Availability 281 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 282 devices, in terms of their resource constraints, energy limitations 283 and communication power. For this document, in addition to these 284 capabilities, it seems useful to also identify devices based on their 285 transport capabilities. 287 +-------+----------------------------+ 288 | Name | Transport Availability | 289 +-------+----------------------------+ 290 | T0 | Single transport | 291 | | | 292 | T1 | Multiple transports, with | 293 | | one or more active at any | 294 | | point in time | 295 | | | 296 | T2 | Multiple active and | 297 | | persistent transports | 298 | | at all times | 299 +-------+----------------------------+ 301 Table 1: Classes of Available Transports 303 Type T0 nodes possess the capability of exactly 1 type of transport 304 channel for CoAP, at all times. These include both active and sleepy 305 nodes, which may choose to perform duty cycling for power saving. 307 Type T1 nodes possess multiple different transports, and can retrieve 308 or expose CoAP resources over any or all of these transports. 309 However, not all transports are constantly active and certain 310 transport channels and interfaces could be kept in a mostly-off state 311 for energy-efficiency, such as when using CoAP over SMS. 313 Type T2 nodes possess more than 1 transport, and multiple transports 314 are simultaneously active at all times in a persistent manner. CoAP 315 proxy nodes which allow CoAP endpoints from disparate transports to 316 communicate with each other, are a good example of this. 318 4. New Resource Directory Parameters 320 In order to allow resource interactions between clients and servers 321 with multiple locations or transports, the registration, update and 322 lookup interfaces of the CoRE Resource Directory need to be extended. 323 In this section two new RD parameters, "at" and "tt" are introduced. 324 Both are optional CoAP features. If supported, they occur at the 325 granularity level of an origin server, ie. they cannot be applied 326 selectively on some resources only. When absent, it is assumed that 327 the server does not support multiple transports or locations. 329 4.1. The 'at' RD parameter 331 A CoAP server wishing to advertise its resources over multiple 332 transports does so by using one or more "at" parameters to register 333 CoAP alternative transport URIs with a Resource Directory. Such a 334 URI would contain the scheme, address as well as any port or paths at 335 which the server is available. 337 +-----------+-------+---------------+-------------------------------+ 338 | Name | Query | Validity | Description | 339 +-----------+-------+---------------+-------------------------------+ 340 | CoAP | at | URI | URI (scheme, address, port | 341 | Transport | | | and path) available | 342 | URI List | | | at the server | 343 +-----------+-------+---------------+-------------------------------+ 345 Table 2: The "at" RD parameter 347 The "at" parameter extends the Resource Directory's Registration and 348 Update interfaces. 350 The following example shows a type T1 endpoint registering its 351 resources and advertising its ability to use TCP and WebSockets as 352 alternative transports: 354 Req: POST coap://rd.example.com/rd?ep=node1 355 &at=coap+tcp://[2001:db8:f1::2]&at=coap+ws://server.example.com 356 Content-Format: 40 357 Payload: 358 ;ct=0;rt="temperature";if="core.s" 360 Res: 2.01 Created 361 Location: /rd/1234 363 An endpoint lookup would just reflect the registered attributes: 365 Req: GET /rd-lookup/ep 367 Res: 2.05 Content 368 ;ep="node1";con="coap://[2001:db8:f1::2]:5683"; 369 at="coap+tcp://[2001:db8:f1::2]";at="coap+ws://server.example.com" 371 The next example shows the same endpoint updating its registration 372 with a new lifetime and the availability of a single alternative 373 transport for CoAP (in this case TCP): 375 Req: POST /rd/1234?lt=600 376 &at=coap+tcp://[2001:db8:f1::2] 377 Content-Format: 40 378 Payload: 379 ;ct=0;rt="temperature";if="core.s" 381 Res: 2.04 Changed 383 If a lookup is performed on the same endpoint only 1 alternative 384 transport is indicated: 386 Req: GET /rd-lookup/ep 388 Res: 2.05 Content 389 ;ep="node1";con="coap://[2001:db8:f1::2]:5683"; 390 at="coap+tcp://[2001:db8:f1::2]" 392 A UDP client would then see the following in a resource lookup: 394 Req: GET /rd-lookup/res?rt=temperature 396 Res: 2.05 Content 397 ;ct=0;rt="temperature";if="core.s"; 398 anchor="coap://[2001:db8:f1::2]" 400 4.2. The 'tt' RD parameter 402 A CoAP client wishing to perform a look-up on the Resource Directory 403 for CoAP servers supporting multiple transports does so by using a 404 new "tt" parameter to query for CoAP alternative transport URIs. 406 +-----------+-------+---------------+-------------------------------+ 407 | Name | Query | Validity | Description | 408 +-----------+-------+---------------+-------------------------------+ 409 | CoAP | tt | | Transport type | 410 | Transport | | | requested by | 411 | Type | | | the client | 412 +-----------+-------+---------------+-------------------------------+ 414 Table 3: The "tt" RD parameter 416 The "tt" parameter extends the Resource Directory's rd-lookup 417 interface. 419 The following example shows a client performing a lookup for 420 endpoints supporting TCP: 422 Req: GET /rd-lookup/ep?tt=tcp 424 Res: 2.05 Content 425 ;con="coap+tcp://[2001:db8:f1::2]";ep="node1";ct="40" 427 The following example shows a client performing a resource lookup for 428 endpoints supporting TCP: 430 Req: GET /rd-lookup/res?rt=temperature&tt=tcp 432 Res: 2.05 Content 433 ;ct=0;rt="temperature"; 434 if="core.s";anchor="coap+tcp://[2001:db8:f1::2]" 436 The following example shows a client performing a lookup for 437 endpoints supporting SMS i.e. discovering SMS transports for sleepy 438 nodes and using SMS to communicate with the endpoint: 440 Req: GET /rd-lookup/ep?et=oic.d.switch&tt=sms 442 Res: 2.05 Content 443 ;con="coap+sms://0015105550101/";ep="node5"; 444 et="oic.d.switch";ct="40", 445 ;con="coap+sms://0015105550202/";ep="node8"; 446 et="oic.d.switch";ct="40" 448 5. CoAP Alternative-Transport Option 450 The CoAP Alternative-Transport Option can be used by CoAP clients and 451 CoAP servers in both Request and Response messages in constrained 452 environments where a CoRE Resource Directory is not present. 454 Figure 4 depicts the properties of the Alternative-Transport Option. 456 +-----+---+---+---+---+------------------------+--------+--------+----------+ 457 | No. | C | U | N | R | Name | Format | Length | Default | 458 +-----+---+---+---+---+------------------------+--------+--------+----------+ 459 | 66 | | x | - | x | Alternative-Transport | string | 0-1034 | (none) | 460 +-----+---+---+---+---+------------------------+--------+--------+----------+ 462 C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable 464 Figure 4: The Alternative-Transport Option 466 When included in a Request message, this option is used by the client 467 in 2 possible ways. In the first case, a CoAP client can include the 468 Option with Length 0 to retrieve all alternative transports from a 469 CoAP server. In response to the client, the server includes base URI 470 for each transport in its own Option. In the second case, a CoAP 471 client can include the Option with a specific value in a CoAP 472 Request, and the CoAP server returns the base URI(s) for the 473 specified transport. If the specified transport by a CoAP client 474 returns multiple results on a CoAP server, the server returns all 475 base URIs of the transport in the response, each base URI in its own 476 Option. 478 A CoAP client can also use this Option to retrieve several transports 479 at once by including multiple Options in the request to a CoAP 480 server. If any of the specified transports is supported by the 481 server, the server returns all base URIs in its own option. There 482 can be more than 1 result for any of the transports so that each 483 transport base URI is still included in the response in its own 484 option. 486 Figure 5 describes a simple interaction between a client and a 487 server, in which the client uses an Alternative-Transports Option 488 with a null value to discover and retrieve all the available 489 transports from the server, as part of a GET operation to retrieve a 490 resource representation. The server responds with a CoAP Response 491 message which contains the resource representation as a payload. In 492 addition, the server also supplies multiple Alternative-Transport 493 Options in the message, with each Option containing the base URI for 494 an available transport. In this case the base URIs returned for TCP- 495 based and WebSocket transports indicate their availability over a 496 non-standard port. 498 Client Server 499 + | 500 | GET /temperature | 501 | Token: 0x64 | 502 | Alternative-Transport: (null) | 503 +-------------------------------------->| 504 | | 505 | 2.05 Content | 506 | Token: 0x64 | 507 | Payload: 21.0 Cel | 508 | Alternative-Transport: | 509 | coap+tcp://example.org:5555/ | 510 | Alternative-Transport: | 511 | coaps+tcp://example.org:6666/ | 512 | Alternative-Transport: | 513 | coap+sms://0015105550101/ | 514 | Alternative-Transport: | 515 | coap+ws://example.org:8080/ | 516 | | 517 |<--------------------------------------+ 518 | | 520 Figure 5: Requesting all available alternative transports on the 521 server, and their locations 523 Alternatively, a client can also request for the availability of a 524 specific transport on the server, as shown in Figure 6. Here, the 525 CoAP Request contains an Alternative-Transport Option with the value 526 set to request the Base URIs for TCP-based endpoints. 528 Client Server 529 + | 530 | GET /temperature | 531 | Token: 0x64 | 532 | Alternative-Transport: tcp | 533 +-------------------------------------->| 534 | | 535 | 2.05 Content | 536 | Token: 0x64 | 537 | Payload: 21.0 Cel | 538 | Alternative-Transport: | 539 | coap+tcp://example.org:5555/ | 540 | Alternative-Transport: | 541 | coaps+tcp://example.org:6666/ | 542 | | 543 |<--------------------------------------+ 544 | | 546 Figure 6: Requesting TCP-based alternative transports on the server, 547 and their locations 549 A client may also request a subset of available transports on the 550 server, by providing multiple Options, each having a single transport 551 identifier. The server likewise responds to the client request by 552 supplying the requested transport information. This is shown in 553 Figure 7. 555 Client Server 556 + | 557 | GET /temperature | 558 | Token: 0x64 | 559 | Alternative-Transport: ws | 560 | Alternative-Transport: sms | 561 +-------------------------------------->| 562 | | 563 | 2.05 Content | 564 | Token: 0x64 | 565 | Payload: 21.0 Cel | 566 | Alternative-Transport: | 567 | coap+sms://0015105550101/ | 568 | Alternative-Transport: | 569 | coap+ws://example.org:8080/ | 570 | | 571 |<--------------------------------------+ 572 | | 574 Figure 7: Requesting WebSocket- and SMS-based alternative transports 575 on the server, and their locations 577 6. The 'ol' CoRE Link Attribute 579 In the majority of cases, it is expected that an origin server would 580 expose all its resources uniformly on its available transports or 581 endpoint addresses. Exceptions can exist however, where alternate 582 locations are made available on a per-resource basis. For such 583 cases, a new 'ol' ("other locations") attribute is provided. One or 584 more 'ol' attributes are used to provide base URIs from which a 585 specific resource can be reached. Allowing per-resource endpoint or 586 transport availability enables specific functions such as firmware 587 updates or hardware-specific operations. It also facilities mapping 588 to and from OCF-based resource-specific endpoint descriptions. 590 6.1. Using /.well-known/core 592 REQ: GET /.well-known/core 594 RES: 2.05 Content 595 ;ct=41;rt="temperature-f";if="sensor", 596 ;ct=41;rt="door";if="sensor", 597 ;if="sensor"; ol="http://[FDFD::123]:61616"; 598 ol="coap://server2.example.com" 600 6.2. Using CoRE Resource Directory 602 Req: POST coap:/rd.example.com/rd 603 ?ep=node1&at=coap+tcp://server.example.com&at=coap+ws://server.example.com:5683/ws/ 604 Content-Format: 40 605 Payload: 606 ;ct=41;rt="temperature-f";if="sensor", 607 ;ct=41;rt="door";if="sensor", 608 ;if="sensor"; ol="http://[FDFD::123]:61616"; 609 ol="coap://server2.example.com" 611 Res: 2.01 Created 612 Location: /rd/4521 614 7. IANA Considerations 616 This document requests the registration of new RD parameter types 617 "at" and "tt". 619 The following entry needs to be added to the CoAP Option Numbers 620 Registry: 622 +--------+------------------------+------------------+ 623 | Number | Name | Reference | 624 +--------+------------------------+------------------+ 625 | 66 | Alternative-Transports | (this document) | 626 +--------+------------------------+------------------+ 628 8. Security Considerations 630 When multiple transports, locations and representations are used, 631 some obvious risks are present both at the origin server as well as 632 by requesting clients. 634 When a client is presented with alternate URIs for retrieving 635 resources, it presents an opportunity for attackers to mount a series 636 of attacks, either by hijacking communication and masquerading as an 637 alternate location or by using a man-in-the-middle attack on TLS- 638 based communication to a server and redirecting traffic to an 639 alternate location. A malicious or compromised server could also be 640 used for reflective denial-of-service attacks on innocent third 641 parties. Moreover, clients may obtain web links to alternate URIs 642 containing weaker security properties than the existing session. 644 9. Acknowledgements 646 Thanks to Jaime Jimenez, Christian Amsuess and Klaus Hartke for 647 comments and reviewing this draft. Teemu Savolainen was involved in 648 initial discussions about protocol negotations and lifetime values. 649 Zach Shelby provided significant suggestions on how the Resource 650 Directory can be employed and extended in place of link attributes 651 and relation types. 653 10. References 655 10.1. Normative References 657 [I-D.ietf-core-resource-directory] 658 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 659 Amsuess, "CoRE Resource Directory", draft-ietf-core- 660 resource-directory-12 (work in progress), October 2017. 662 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 663 Application Protocol (CoAP)", RFC 7252, 664 DOI 10.17487/RFC7252, June 2014, 665 . 667 10.2. Informative References 669 [I-D.silverajan-core-coap-alternative-transports] 670 Silverajan, B. and T. Savolainen, "CoAP Communication with 671 Alternative Transports", draft-silverajan-core-coap- 672 alternative-transports-11 (work in progress), March 2018. 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, 676 DOI 10.17487/RFC2119, March 1997, 677 . 679 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 680 Constrained-Node Networks", RFC 7228, 681 DOI 10.17487/RFC7228, May 2014, 682 . 684 [WWWArchv1] 685 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 686 of the World Wide Web, Volume One", December 2004. 688 Appendix A. Change Log 690 A.1. From -07 to -08 692 Added example of energy constrained CoAP server 694 Updated examples of using "at" and "tt" 696 "at" and "ol" are no longer comma-separated URI lists. 698 A.2. From -06 to -07 700 Added support for 'ol' Link attribute 702 A.3. From -05 to -06 704 Added support for CoAP Alternative-Transports Option 706 A.4. From -04 to -05 708 Freshness update 710 A.5. From -03 to -04 712 Removed previously introduced link attribute and relation types 714 Initial foray with Resource Directory support 716 A.6. From -02 to -03 718 Added new author 720 Rewrite of "Introduction" section 722 Added new Aims Section 724 Added new Section on Node Types 726 Introduced "al" Active Lifetime link attribute 728 Added new Section on Observing transports and resources 730 Security and IANA considerations sections populated 732 A.7. From -01 to -02 734 Freshness update. 736 A.8. From -00 to -01 738 Reworked "Introduction" section, added "Rationale", and "Goals" 739 sections. 741 Authors' Addresses 743 Bilhanan Silverajan 744 Tampere University of Technology 745 Korkeakoulunkatu 10 746 FI-33720 Tampere 747 Finland 749 Email: bilhanan.silverajan@tut.fi 751 Mert Ocak 752 Ericsson 753 Hirsalantie 11 754 02420 Jorvas 755 Finland 757 Email: mert.ocak@ericsson.com