idnits 2.17.1 draft-groves-coap-webrtcdc-00.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: WebRTC DCs allows the indication of whether a SCTP user message is empty through the use of PPIDs (WebRTC String Empty and WebRTC Binary Empty). CoAP defines the use of empty messages. However from the perspective of SCTP these CoAP messages would still contain header information thus PPIDs for empty data MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: CoAP uses an Empty Confirmable message to provoke a Reset message to check the liveness of an endpoint (so called "CoAP" ping). In WebRTC liveness and the ability to send data is determined through the usage of Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness [RFC7675]. Therefore endpoints utilising CoAP over WebRTC DC MUST not use CoAP "reset" messages. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: CoAP also uses Empty messages to acknowledge a request. This is not required due to the SCTP level acknowledgement. Therefore Empty messages MUST not be used with CoAP over WebRTC. -- The document date (July 4, 2016) is 2843 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 491 == Unused Reference: 'I-D.ietf-rtcweb-security' is defined on line 871, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-08 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-14 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-15 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-08 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-06 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-02 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-09 Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE C. Groves, Ed. 3 Internet-Draft W. Yang 4 Intended status: Informational Huawei 5 Expires: January 5, 2017 July 4, 2016 7 A WebRTC Data Channel Transport for the Constrained Application Protocol 8 (CoAP) 9 draft-groves-coap-webrtcdc-00 11 Abstract 13 The WebRTC framework defines a generic transport service allowing 14 WEB-browsers and other endpoints to exchange generic data from peer 15 to peer utilizing a Stream Control Transmission Protocol (SCTP) 16 transport. This service is known as Web Real Time Communication 17 WebRTC data channels (WebRTC DC). The use of WebRTC DCs for the 18 Constrained Application Protocol (CoAP) allows WebRTC enabled devices 19 to exchange CoAP data between peers in a secure reliable manner. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 5, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 57 3. Constrained Application Protocol . . . . . . . . . . . . . . 5 58 3.1. Message Model . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Request Response Model . . . . . . . . . . . . . . . . . 6 60 3.3. Intermediaries and Caching . . . . . . . . . . . . . . . 7 61 3.4. Resource Discovery . . . . . . . . . . . . . . . . . . . 7 62 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Option Format and Value . . . . . . . . . . . . . . . . . 9 64 5. Message Transmission . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Messages and Endpoints . . . . . . . . . . . . . . . . . 10 66 5.2. Messages Transmitted Reliably . . . . . . . . . . . . . . 10 67 5.3. Messages Transmitted without Reliability . . . . . . . . 11 68 5.4. Message Correlation . . . . . . . . . . . . . . . . . . . 11 69 5.5. Message Duplication . . . . . . . . . . . . . . . . . . . 11 70 5.6. Message Size . . . . . . . . . . . . . . . . . . . . . . 12 71 5.7. Congestion Control . . . . . . . . . . . . . . . . . . . 12 72 5.8. Transmission Parameters . . . . . . . . . . . . . . . . . 12 73 6. Request/Response Semantics . . . . . . . . . . . . . . . . . 12 74 7. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7.1. coaps+wr URI scheme . . . . . . . . . . . . . . . . . . . 13 76 8. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 13 78 8.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 14 79 9. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . . . 14 80 10. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 14 81 11. Interworking . . . . . . . . . . . . . . . . . . . . . . . . 14 82 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 13.1. New WebRTC DC Protocol Value . . . . . . . . . . . . . . 15 85 13.2. Secure Service Name and Port Number Registration . . . . 16 86 13.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 16 87 13.4. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 16 88 13.5. New SIP Media Feature Tag . . . . . . . . . . . . . . . 16 89 14. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 91 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 93 16.2. Informative References . . . . . . . . . . . . . . . . . 22 94 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 97 1. Introduction 99 Whilst the Constrained Application Protocol (CoAP) [RFC7252] was 100 designed for Internet of Things (IoT) deployments in constrained 101 network environments its ready adoption has seen the use of it in a 102 multitude of different network environments. 103 [I-D.silverajan-core-coap-alternative-transports] provides use cases 104 for alternate CoAP transports. 106 [I-D.ietf-core-coap-tcp-tls] highlights a number of issues using the 107 native User Datagram Transport (UDP) and envisages deployments more 108 closely integrated with a Web environment. In a similar manner 109 [I-D.savolainen-core-coap-websockets] proposes the use of the 110 WebSocket protocol [RFC6455]. The use of CoAP over WebRTC DCs has 111 not yet been discussed. 113 WebRTC is a framework [I-D.ietf-rtcweb-overview] that defines real 114 time protocols for browser-based applications. It allows 115 communications between peer WebRTC endpoints (e.g. browsers) without 116 the need to communicate through a web server. 118 In addition to protocols for the realtime transport of audio and 119 video, the transport of generic peer-to-peer non-media data has been 120 defined using WebRTC DCs. The non-media data is transported using 121 the Stream Control Transmission Protocol (SCTP) [RFC4960] 122 encapsulated in the Datagram Transport Layer Security (DTLS) 123 [RFC6347]. It allows both reliable and partially reliable transport 124 and provides confidentiality, source authenticated and integrity 125 protected transfers. The use of Interactive Connectivity 126 Establishment (ICE) [RFC5245] allows network address translator (NAT) 127 traversal. The SCTP/DTLS association may be shared with existing 128 audio and video streams enabling multiplexing of several data streams 129 over a single port further facilitating NAT traversal. 131 Use cases for WebRTC DCs (section 3.1/[I-D.ietf-rtcweb-data-channel] 132 envisage scenarios where the real-time gaming experience is enhanced 133 by additional object state information. Additional scenarios are 134 considered where information such as heart rate sensor or oxygen 135 saturation sensors could augment audio and video in remote medicine 136 scenarios. The transport of such sensor information is what CoAP has 137 been designed for. 139 This is illustrated in Figure 1 showing the WebRTC Trapeziod with 140 added sensor/CoAP information. The left hand side WebRTC endpoint 141 acts as a CoAP to CoAP proxy. 143 +-----------+ +-----------+ 144 | Web | | Web | 145 | | Signaling | | 146 | |-------------| | 147 | Server | path | Server | 148 | | | | 149 +-----------+ +-----------+ 150 / \ 151 / \ Application- 152 / \ defined over 153 / \ HTTP/Websockets 154 / Application-defined over \ 155 / HTTP/Websockets \ 156 / \ 157 +-----------+ +-----------+ 158 |JS/HTML/CSS| |JS/HTML/CSS| 159 +-----------+ +-----------+ 160 +-----------+ +-----------+ 161 SensorA | | | | 162 CoAP/UDP | | | | 163 +------+ Browser | ------------------------- | Browser + 164 | | Media path | | 165 | | (CoAP/WebRTC DC) | | 166 +-----------+ +-----------+ 168 Figure 1: CoAP and WebRTC Trapeziod 170 By utilizing the WebRTC DC (SCTP over DTLS over ICE/UDP (or ICE/TCP)) 171 transport for CoAP a number of important features are inherited 172 including: congestion control, order and unordered messages delivery, 173 large message transmission by providing segmentation and reassembly 174 and multiple unidirectional streams. A more detailed analysis of the 175 benefits of WebRTC DCs can be found in section 176 5/[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-tsvwg-sctp-dtls-encaps] 177 describes the usage of SCTP over DTLS. 179 WebRTC defines in-band and out-of-band methods for establishing a 180 data channel and indicating its characteristics. The Data Channel 181 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] 182 provides an in band means of establishing individual data channels. 183 [I-D.ietf-mmusic-data-channel-sdpneg] uses the Session Description 184 Protocol (SDP) [RFC4566] to provide an out-of-band means to establish 185 data channels. 187 By defining the use of CoAP over WebRTC DC it negates the need for 188 the WebRTC endpoint to interwork between any CoAP messages received 189 from local devices to a proprietary WebRTC DC format when signalling 190 a remote WebRTC endpoint. 192 The SCTP Payload Protocol Identifier (PPID) allows the identification 193 of whether a UTF-8 or Binary encoding is being used and thus 194 facilitates the use of text or binary CoAP protocol serializations. 196 Note: The draft does not yet consider [I-D.bormann-core-coap-sig]. 197 The intention has been to provide a draft that parallels the current 198 CoAP over TCP and CoAP over Web Sockets drafts. It is likely that 199 there will be impacts due to the [I-D.bormann-core-coap-sig]. 201 2. Requirements Language 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC 2119 [RFC2119]. 207 3. Constrained Application Protocol 209 This section describes the use of CoAP over WebRTC DC as a delta to 210 the information contained in section 2/[RFC7252]. 212 Figure 2 shows the CoAP abstract layering as applied to the WebRTC 213 framework. 215 +---------------------------+ 216 | Application | 217 +------+------+-------------+ \ 218 | DCEP | Requests/Responses | | 219 | +--------------------| | CoAP 220 | | Messages | | 221 +------+--------------------+ / 222 | SCTP | 223 +-----------------------------------------+ 224 | STUN | SRTP | DTLS | 225 +-----------------------------------------+ 226 | ICE | 227 +-----------------------------------------+ 228 | UDP1 | UDP2 | UDP3 | ... | 229 +-----------------------------------------+ 231 Figure 2: WebRTC protocol layers including CoAP 233 WebRTC DC mandates the use of SCTP over DTLS. Whilst the above 234 diagram indicates the use of ICE over UDP the use of TCP is also 235 possible in fall back scenarios. 237 3.1. Message Model 239 WebRTC DC allows application protocol messages to be exchanged by 240 peers. WebRTC supports both a reliable and partially reliable 241 methods of transmitting user messages. 243 CoAP [RFC7252] supports four message types "Confirmable, Non- 244 Confirmable, Acknowledge and Reset". As SCTP provides the 245 reliability mechanism the CoAP message types are not strictly needed 246 for CoAP over WebRTC DC. However the message type is still included 247 in the modified CoAP header for usage over WebRTC DC to facilitate 248 interworking. See section 5 for more information. 250 WebRTC DC does not support multicast usage. 252 3.2. Request Response Model 254 WebRTC DCs are realized as a pair of one incoming and one outgoing 255 SCTP stream (with the same identifier) allowing bi-directional 256 communication. Each channel has properties (see section 257 6.4/[I-D.ietf-rtcweb-data-channel] as discussed below: 259 o reliable or unreliable message transmission: WebRTC DCs support 260 the per message indication whether user messages are reliable or 261 partially reliable. Partial reliability indicates that message 262 retransmission is limited to a certain number of retransmissions 263 or lifetime. This loosely parallels to the CoAP usage of 264 Confirmable (CON) or Non-confirmable (NON) messages. 266 o in-order or out-of-order message delivery: WebRTC DCs support the 267 per message indication whether user messages are delivered in or 268 out of order. CoAP has been designed for unreliable transports 269 and therefore assumes that messages may arrive out-of-order. CoAP 270 implements a lightweight reliability mechanism to deal with this 271 issue. 273 o priority: WebRTC DCs allows a priority to specified for stream 274 scheduling. The usage of this is application specific. Usage of 275 CoAP has no impact on this parameter. It's up to the application 276 using CoAP to set this indication. 278 o an optional label: This is an application/implementation specific 279 label. Uniqueness is not guaranteed. Usage of CoAP has no impact 280 on this parameter. 282 o an optional protocol: This is used to indicate the application 283 protocol in use. A value is required to identify the usage of 284 CoAP. 286 As discussed above WebRTC DC supports an unreliable / un-ordered 287 delivery of messages. Implementations utilizing these data channel 288 characteristics may use CoAP messages and request/response model 289 largely unchanged. In this case the CoAP reliability mechanisms 290 would be used. However as WebRTC DC's usage of SCTP is reliable or 291 partially reliable there is some redundancy between the functionality 292 that WebRTC DCs and CoAP provides. 294 The redundancies are identified and discussed in section 295 3/[I-D.ietf-core-coap-tcp-tls]. Namely: 297 1 There is no need to carry acknowledgement semantics at a CoAP 298 level. 300 2 There is no need for duplicate delivery detection. This is part 301 of the SCTP layer. 303 3.3. Intermediaries and Caching 305 As discussed whilst the CoAP message type is not required for 306 reliability of CoAP over WebRTC DC the use of message type is to 307 facilitate interworking to other transports in intermediaries. No 308 other impacts are foreseen. 310 3.4. Resource Discovery 312 The usage of CoAP over WebRTC DC has no foreseeable impacts on 313 resource discovery. 315 4. Message Format 317 As discussed in [I-D.ietf-core-coap-tcp-tls] the use of a reliable 318 underlying transport allows the use of a modified CoAP header format. 319 The modified format removes the "Type (T)" and "Message ID" fields 320 and introduces a "length" as illustrated below in Figure 3. 322 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |Len=13 | TKL | Length (8-bit)| Code | TKL bytes ... 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Options (if any) ... 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |1 1 1 1 1 1 1 1| Payload (if any) ... 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 3: CoAP Header with TCP with 8-bit Length in Header 334 The length field was introduced to introduce message delimitation to 335 keep messages separate in TCP. WebRTC DC uses the message 336 orientation of SCTP to preserve message boundaries thus the use of 337 single application message per SCTP user message is mandated by the 338 WebRTC framework. Therefore a further simplified form of header is 339 defined for CoAP over WebRTC datachannel usage: 341 0 1 2 3 342 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 |Ver| T | TKL | Code | TKL bytes ... 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Options (if any) ... 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |1 1 1 1 1 1 1 1| Payload (if any)... 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 4: CoAP Header with SCTP with 8-bit Length in Header 353 The "Version (Ver)" and "Type (T)" fields are re-introduced as 354 compared to [I-D.ietf-core-coap-tcp-tls] to maintain compatibility 355 with CoAP [RFC7252]. Thus the above header is only different from 356 the CoAP header in that 2 bytes are saved due to the removal of the 357 "Message ID". 359 Version (Ver) is effectively redundant due to the negotiation of the 360 sub-protocol "coap.v1" at data channel establishment. This field 361 MUST match the version indicated in the protocol field. 363 The use of the message type (T) is used as an indication to the CoAP 364 receiver as to the characteristics of the message. The receiver MUST 365 NOT use this information to implement a CoAP level reliability 366 mechanism. Sections 5.2 and 5.3 detail the usage of message types. 368 Author's Note 1: The 4 bits required for "Version" and "Type" could 369 be removed however this would mean that octet aligned boundaries 370 would no longer be reserved. [I-D.savolainen-core-coap-websockets] 371 instead indicates that the four most significant bits (i.e. those for 372 Ver and T) be set to zero and are reserved. 374 Author's Note 2: A further alternative option is to use the CoAP 375 header as defined in [RFC7252] and to indicate that for CoAP over 376 WebRTC DC the "T" and "Message ID" are populated with "0-bits" when 377 sending and ignored when receiving messages. 379 CoAP [RFC7252] supports the use of different content-formats. WebRTC 380 DC defines the use of PPIDs per SCTP user message as follows: 382 o WebRTC String: to identify a non-empty JavaScript string encoded 383 in UTF-8. 385 o WebRTC Binary: to identify a non-empty JavaScript binary data 386 (ArrayBuffer, ArrayBufferView or Blob). 388 Depending on the content-format (see section 12.3/[RFC7252]) an 389 appropriate PPID to the encoding type SHOULD be used to minimise the 390 need for translating between encodings. For example content type of 391 "text/plain" would result in the use of PPID "WebRTC String". 393 Author's note: Specific mappings for each content-format could be 394 provided however given that the formats may change in the future it 395 may be sufficient to offer broad guidance instead. 397 4.1. Option Format and Value 399 There are no impacts to option formats or values due to the use of 400 CoAP over WebRTC DCs. 402 Author's note: Given that the host is determined by the usage of 403 WebRTC are the Uri-Host and Uri-Port relevant? It would seem that 404 this may be valuable to establish a resource tree independent of 405 WebRTC. 407 5. Message Transmission 409 In order to use a WebRTC DC, a SCTP over DTLS over ICE/UDP (or ICE/ 410 TCP) association must be established. A DTLS connection is 411 established followed by an SCTP association. The out-of-band 412 establishment method through the use of SDP-based Data Channel 413 Negotiation [I-D.ietf-mmusic-data-channel-sdpneg] allows the 414 negotiation of SCTP over DTLS over ICE/UDP as well as the negotiation 415 and establishment of the characteristics of an individual WebRTC DC. 417 The in-band establishment method through the use of the Data Channel 418 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] only 419 allows for the establishment of a WebRTC DC once the SCTP over DTLS 420 is established. It relies on DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK 421 messages on the relevant SCTP stream to negotiate the properties of 422 the channel. A separate SCTP PPID (50) indicates that the SCTP user 423 message is a WebRTC DCEP message to allow de-multiplexing by the 424 endpoint. 426 WebRTC DCs are realized as a pair of one incoming and one outgoing 427 SCTP stream (with the same identifier). Requests are sent on an 428 outgoing SCTP stream and received on the peer incoming stream. The 429 SCTP stream identifier is bound to the WebRTC DC instance at the 430 establishment of the data channel. The establishment protocol 431 provides rules for determining the SCTP stream IDs. 433 WebRTC DC closure (Stream Reset) is supported through the use of the 434 SCTP stream reconfiguration extension defined in [RFC6525]. The SCTP 435 Stream Reconfiguration reset has the effect of setting the numbering 436 sequence of the SCTP stream back to zero. This is separate function 437 to the CoAP "Reset" message. There is no mapping between the SCTP 438 Stream Reset and the CoAP "Reset" message. 440 5.1. Messages and Endpoints 442 As per section 5/[I-D.ietf-core-coap-tcp-tls] requests can be sent 443 from both the connecting host and the endpoint that accepted the 444 connection. Who initiated the SCTP/DTLS connection has no bearing on 445 the meaning of the CoAP terms client and server. 447 WebRTC DC mandates the use of DTLS thus the endpoint is identified 448 depending on the security mode. 450 WebRTC DCs allows the indication of whether a SCTP user message is 451 empty through the use of PPIDs (WebRTC String Empty and WebRTC Binary 452 Empty). CoAP defines the use of empty messages. However from the 453 perspective of SCTP these CoAP messages would still contain header 454 information thus PPIDs for empty data MUST not be used. 456 CoAP uses an Empty Confirmable message to provoke a Reset message to 457 check the liveness of an endpoint (so called "CoAP" ping). In WebRTC 458 liveness and the ability to send data is determined through the usage 459 of Session Traversal Utilities for NAT (STUN) Usage for Consent 460 Freshness [RFC7675]. Therefore endpoints utilising CoAP over WebRTC 461 DC MUST not use CoAP "reset" messages. 463 CoAP also uses Empty messages to acknowledge a request. This is not 464 required due to the SCTP level acknowledgement. Therefore Empty 465 messages MUST not be used with CoAP over WebRTC. 467 5.2. Messages Transmitted Reliably 469 For CoAP messages marked as confirmable the sender SHALL use a 470 reliable SCTP user message. 472 A CoAP endpoint MUST use the ordered delivery SCTP service, as 473 described in [RFC4960], for the CoAP protocol. 475 CoAP receivers MUST NOT generate CoAP "ACK" or "reset" messages. 476 SCTP level acknowledgement mechanisms are used. 478 5.3. Messages Transmitted without Reliability 480 WebRTC DC makes use of the SCTP Partial Reliability (SCTP-PR) 481 Extension [RFC3758]. This extension allows a user to indicate on a 482 per message basis how persistent the transport service should be in 483 attempting to send the message to the receiver. One of the benefits 484 of using this extension identified by [RFC3758] is: 486 1. Some application layer protocols may benefit from being able 487 to use a single SCTP association to carry both reliable content, 488 -- such as text pages, billing and accounting information, setup 489 signaling -- and unreliable content, e.g., state that is highly 490 sensitive to timeliness, where generating a new packet is more 491 advantageous than transmitting an old one [3]. 493 This benefit is also one of the reasons the CoAP "Non-Confirmable" 494 message was introduced. However the SCTP-PR and the CoAP "Non- 495 Confirmable" message mechanisms differs in their approach. The SCTP- 496 PR mechanism focuses on sender side behaviour (e.g. when to abandon 497 retransmission). The CoAP "Non-Confirmable" message focuses on 498 receiver side behaviour (e.g. must not send a CoAP ACK). Even with 499 the use of SCTP-PR an SCTP receiver will send an SCTP level ACK for a 500 successfully received SCTP CHUNK. The CoAP "Non-Confirmable" message 501 has no effect on the SCTP level function. 503 Therefore the use of a CoAP "Non-Confirmable" message type is 504 redundant as the CoAP receiver will never send a CoAP ACK message in 505 response. However to facilitate potential interworking at the 506 receiver the sender SHALL still indicate a "Non-confirmable" message 507 type in a CoAP request/response when required. 509 SCTP-PR provides a complimentary function and thus CoAP senders who 510 send Non-confirmable messages SHALL also use SCTP-PR for that 511 message. 513 5.4. Message Correlation 515 Due to reliability being handled at the SCTP layers the CoAP "Message 516 ID" is not required. 518 5.5. Message Duplication 520 The SCTP layer provides message duplication protection. The CoAP 521 application level procedure is not required. 523 5.6. Message Size 525 The considerations in section 4.1/[I-D.ietf-core-coap-tcp-tls] 526 regarding message size limitations also apply to the use of WebRTC 527 DCs. However [I-D.ietf-rtcweb-data-channel] indicates that senders 528 SHOULD limit the maximum message size to 16KB to avoid monopolization 529 of the SCTP association. Section 5/[I-D.ietf-tsvwg-sctp-dtls-encaps] 530 provides further details regarding segmentation and reassembly and 531 path maximum transmission unit (MTU) discovery. 533 Interleaving of large user messages is supported by an SCTP protocol 534 extension defined in [I-D.ietf-tsvwg-sctp-ndata]. 536 5.7. Congestion Control 538 SCTP provides congestion control on a per-association basis (see 539 section 5/[I-D.ietf-rtcweb-data-channel]. 541 5.8. Transmission Parameters 543 The application level parameters defined in section 4.8/[RFC7252] are 544 not relevant to SCTP. 546 6. Request/Response Semantics 548 Request and response semantics for CoAP over WebRTC DC is as per 549 section 5/[RFC7252] with the following exceptions: 551 o section 5.2/[RFC7252]: separate responses MUST be used. Given 552 that WebRTC DC provides an SCTP level acknowledgement it is not 553 possible to piggy back CoAP responses. 555 o section 5.3.1/[RFC7252]: due to the use of DTLS the advice 556 regarding token use without using TLS is invalid. 558 o section 5.3.2/[RFC7252]: In addition CoAP request/response 559 matching is unique to a particular WebRTC DC (SCTP StreamID pair). 561 o section 5.8/[RFC7252]: It is not possible to use a 4.05 562 piggybacked response. 564 7. CoAP URI 566 CoAP [RFC7252] defines the "coap" and "coaps" URI schemes for 567 identifying CoAP resources and providing a means of locating the 568 resource. [RFC7252] defines these resources for use with CoAP over 569 UDP. 571 Section 8/[RFC7252] (Multicast CoAP), does not apply to the URI 572 schemes defined in the present specification. 574 Resources made available via the "coaps+wr" schemes have no shared 575 identity with the other scheme or with the "coap" or "coaps" scheme, 576 even if their resource identifiers indicate the same authority (the 577 same host listening to the same port). The schemes constitute 578 distinct namespaces and, in combination with the authority, are 579 considered to be distinct origin servers. 581 7.1. coaps+wr URI scheme 583 coaps-wr-URI = "coaps+wr:" "//" host [ ":" port ] path-abempty 584 [ "?" query ] 586 The semantics defined in section 6.3/[RFC7252], apply to this URI 587 scheme, with the following changes: 589 o The port SHALL be omitted. The underlying UDP or TCP port and 590 SCTP port is negotiated prior to the establishment of the CoAP 591 over WebRTC DC. 593 8. Discovery 595 8.1. Service Discovery 597 WebRTC does not define peer discovery mechanisms. Peers discover 598 each other through the use of the ICE protocol. ICE candidates need 599 to be sent from peer to peer via signalling. The Javascript Session 600 Establishment Protocol (JSEP) [I-D.ietf-rtcweb-jsep] details the 601 generic SDP media descriptions for peer endpoints to determine the 602 characteristics of a session. The actual signalling protocol between 603 application servers is unspecified. WebRTC endpoints MUST implement 604 the network functions detailed by JSEP including ICE functionality. 606 Whilst the inter-application server signalling protocol is 607 unspecified, the Session Initiation Protocol (SIP) is able to carry 608 SDP for the purposes of establishing a CoAP over WebRTC DC session. 609 SIP allows the use of media feature tags to indicate user agent 610 capabilities [RFC3840]. In order to indicate that a SIP user agent 611 supports the use of CoAP a new "sip.coap" media feature tag is 612 proposed. A CoAP-capable endpoint SHOULD include this media feature 613 tag in its REGISTER requests and OPTION responses. It SHOULD also 614 include the media feature tag in INVITE and UPDATE [RFC3311] requests 615 and responses. Presence of the media feature tag in the contact 616 field of a requestor response can be used to determine that the far 617 end supports CLUE. 619 The exchange of SDP results in: the underlying transport address 620 (e.g. IPv4 or IPv6), the underlying transport port (e.g. UDP port) 621 the SCTP port and the SCTP StreamID used for the CoAP WebRTC DC being 622 exchanged between the peer endpoints. 624 8.2. Resource Discovery 626 On establishment of a CoAP WebRTC DC endpoints are able to use the 627 resource discovery mechanism defined in [RFC6690] for CoAP resources. 629 9. Multicast CoAP 631 WebRTC DCs do not support multicast. 633 10. Securing CoAP 635 This document defines how to convey CoAP over WebRTC DCs. The WebRTC 636 security architecture [I-D.ietf-rtcweb-security-arch] mandates the 637 use of DTLS for data channels. The use of DTLS 1.2 is compatible 638 with CoAP [RFC7252] which allows makes use of DTLS 1.2. 640 The use of DTLS for WebRTC is detailed in 641 [I-D.ietf-rtcweb-security-arch]. 643 11. Interworking 645 An WebRTC endpoint supporting CoAP may in affect act as a gateway 646 between local sensor devices and a remote peer endpoint. The local 647 sensors may utilise CoAP over an alternate signalling transport such 648 as UDP to the local WebRTC endpoint. The WebRTC endpoint may then 649 utilise CoAP over WebRTC to signal to the remote peer. 651 A CoAP gateway when converting to and from a WebRTC transport will in 652 general perform the following functions: 654 o Map received Empty CoAP message to SCTP level operations and 655 discard the empty message. 657 o Map received ACK message to SCTP level operations and discard the 658 ACK message. 660 o Separate piggy-backed messages. 662 o Provide a mapping between received and sent Tokens in order to 663 match requests and responses. 665 Other behaviour depends on the type of proxy behaviour the gateway is 666 performing. See section 5.7/[RFC7252] for more details. 668 12. Security Considerations 670 Security considerations for WebRTC are discussed in [ID. ietf-rtcweb- 671 security]. 673 The use of CoAP over WebRTC can potentially negate the risks 674 mentioned in: 676 o section 11.3/[RFC7252] on insecure UDP and multicast being used to 677 aid an amplification attack. 679 o section 11.4/[RFC7252] on IP address spoofing and section 680 11.5/[RFC7252] on Cross-Protocol attacks. 682 o section 11.6/[RFC7252] may also not be relevant as WebRTC 683 endpoints are not expected to be severely constrained. 685 Of particular relevance to the support of CoAP over WebRTC DC is 686 access to local devices. Devices generating CoAP data are 687 essentially the same as cameras and microphones in that they may 688 expose sensitive data about the user or the location of the device. 689 Thus the guidance of section 4.1/[I-D.ietf-rtcweb-security] applies 690 to devices generating CoAP data. Whilst CoAP has been designed for 691 constrained devices where there is no user interface to inform/ 692 request consent, it is assumed that device utilising WebRTC DC for 693 CoAP is more likely at minimum a Class 2 [RFC7228] device that could 694 facilitate consent. 696 The CoAP media feature tag defined by this document tag may be 697 present in sessions not utilising CoAP, which increases the metadata 698 available about the sending device, which can help an attacker 699 differentiate between multiple devices and help them identify 700 otherwise anonymised users via the fingerprint of features their 701 device supports. To prevent this, SIP signalling SHOULD always be 702 encrypted using TLS [RFC5630]. 704 13. IANA Considerations 706 13.1. New WebRTC DC Protocol Value 708 NOTE: This registration is exactly the same as the registration in 709 [I-D.savolainen-core-coap-websockets]. 711 This document requests the registration of the subprotocol name 712 "coap.v1" in the WebSocket Subprotocol Name Registry. 714 Subprotocol Identifier: coap.v1 715 Subprotocol Common Name: Constrained Application Protocol (CoAP) 717 Subprotocol Definition: [This document] 719 13.2. Secure Service Name and Port Number Registration 721 No need has been identified to register a new service name and port 722 number for CoAP over WebRTC. Port number allocation is dynamic. The 723 use of the SCTP over DTLS over UDP/TCP results in a layering of 724 services. 726 13.3. ALPN Protocol ID 728 [I-D.ietf-core-coap-tcp-tls] defines a new "coap" application 729 protocol negotiation protocol identity. However as the DTLS 730 connection is used to establish a WebRTC application the protocol 731 identifiers defined in [I-D.ietf-rtcweb-alpn] MUST be used. Note: 732 that confidentiality protection does not extend to WebRTC DCs. 734 13.4. URI Schemes 736 This document registers a new URI scheme "coaps+wr" for the use of 737 CoAP over WebRTC DCs. The "coaps+wr" URI schemes can be compared to 738 the "https" URI scheme. 740 The IANA is requested to add this new URI schemes to the registry 741 established with [RFC7595]. 743 13.5. New SIP Media Feature Tag 745 This specification registers a new media feature tag in the SIP 746 [RFC3264] tree per the procedures defined in [RFC2506] and [RFC3840]. 748 Media feature tag name: sip.coap 750 ASN.1 Identifier: 1.3.6.1.8.4.30 752 Summary of the media feature indicated by this tag: This feature tag 753 indicates that the device supports the Constrained Application 754 Protocol (CoAP). 756 Values appropriate for use with this feature tag: Boolean. 758 The feature tag is intended primarily for use in the following 759 applications, protocols, services, or negotiation mechanisms: This 760 feature tag is useful to indicate the support of CoAP. 762 Related standards or documents: [this draft] 763 Security Considerations: Security considerations for this media 764 feature tag are discussed in Section 12. 766 Name(s) and email address(es) of person(s) to contact for further 767 information: 769 CORE workgroup: core@ietf.org 771 CORE chairs: core-chairs@ietf.org 773 Intended usage: COMMON 775 14. Examples 777 The example SDP Offer shows a CoAP over WebRTC DC utilising out-of- 778 band negotiation [I-D.ietf-mmusic-data-channel-sdpneg]. It is based 779 on the example in section 7.2/[I-D.ietf-rtcweb-jsep]. Modified lines 780 are indicated with ">>>" at the start of the line. These indicators 781 are NOT part of the SDP syntax. Note: some lines have been broken 782 into two lines for formatting reasons. 784 v=0 785 o=- 4962303333179871723 1 IN IP4 0.0.0.0 786 s=- 787 t=0 0 788 a=group:BUNDLE a1 d1 789 a=ice-options:trickle 790 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 791 c=IN IP4 0.0.0.0 792 a=rtcp:9 IN IP4 0.0.0.0 793 a=mid:a1 794 a=msid:57017fee-b6c1-4162-929c-a25110252400 795 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 796 a=sendrecv 797 a=rtpmap:96 opus/48000/2 798 a=rtpmap:0 PCMU/8000 799 a=rtpmap:8 PCMA/8000 800 a=rtpmap:97 telephone-event/8000 801 a=rtpmap:98 telephone-event/48000 802 a=maxptime:120 803 a=ice-ufrag:ATEn1v9DoTMB9J4r 804 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 805 a=fingerprint:sha-256 806 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 807 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 808 a=setup:actpass 809 a=rtcp-mux 810 a=rtcp-rsize 811 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 812 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 813 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 815 m=application 0 UDP/DTLS/SCTP webrtc-datachannel 816 c=IN IP4 0.0.0.0 817 a=bundle-only 818 a=mid:d1 819 a=fmtp:webrtc-datachannel max-message-size=65536 820 a=sctp-port 5000 821 a=fingerprint:sha-256 822 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 823 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 824 a=setup:actpass 825 >>>a=dcmap:0 subprotocol="coap.v1";"label="coap" 827 15. Acknowledgements 829 We would like to thank the authors of [I-D.ietf-core-coap-tcp-tls] 830 and [I-D.savolainen-core-coap-websockets] for providing a framework 831 for this document. 833 This template was derived from an initial version written by Pekka 834 Savola and contributed by him to the xml2rfc project. 836 16. References 838 16.1. Normative References 840 [I-D.ietf-mmusic-data-channel-sdpneg] 841 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 842 and J. Marcon, "SDP-based Data Channel Negotiation", 843 draft-ietf-mmusic-data-channel-sdpneg-08 (work in 844 progress), February 2016. 846 [I-D.ietf-rtcweb-alpn] 847 Thomson, M., "Application Layer Protocol Negotiation for 848 Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- 849 alpn-04 (work in progress), May 2016. 851 [I-D.ietf-rtcweb-data-channel] 852 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 853 Channels", draft-ietf-rtcweb-data-channel-13 (work in 854 progress), January 2015. 856 [I-D.ietf-rtcweb-data-protocol] 857 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 858 Establishment Protocol", draft-ietf-rtcweb-data- 859 protocol-09 (work in progress), January 2015. 861 [I-D.ietf-rtcweb-jsep] 862 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 863 Session Establishment Protocol", draft-ietf-rtcweb-jsep-14 864 (work in progress), March 2016. 866 [I-D.ietf-rtcweb-overview] 867 Alvestrand, H., "Overview: Real Time Protocols for 868 Browser-based Applications", draft-ietf-rtcweb-overview-15 869 (work in progress), January 2016. 871 [I-D.ietf-rtcweb-security] 872 Rescorla, E., "Security Considerations for WebRTC", draft- 873 ietf-rtcweb-security-08 (work in progress), February 2015. 875 [I-D.ietf-rtcweb-security-arch] 876 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 877 rtcweb-security-arch-12 (work in progress), June 2016. 879 [I-D.ietf-tsvwg-sctp-dtls-encaps] 880 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 881 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 882 dtls-encaps-09 (work in progress), January 2015. 884 [I-D.ietf-tsvwg-sctp-ndata] 885 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 886 "Stream Schedulers and User Message Interleaving for the 887 Stream Control Transmission Protocol", draft-ietf-tsvwg- 888 sctp-ndata-06 (work in progress), July 2016. 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, 892 DOI 10.17487/RFC2119, March 1997, 893 . 895 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 896 Registration Procedure", BCP 31, RFC 2506, 897 DOI 10.17487/RFC2506, March 1999, 898 . 900 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 901 with Session Description Protocol (SDP)", RFC 3264, 902 DOI 10.17487/RFC3264, June 2002, 903 . 905 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 906 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 907 2002, . 909 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 910 Conrad, "Stream Control Transmission Protocol (SCTP) 911 Partial Reliability Extension", RFC 3758, 912 DOI 10.17487/RFC3758, May 2004, 913 . 915 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 916 "Indicating User Agent Capabilities in the Session 917 Initiation Protocol (SIP)", RFC 3840, 918 DOI 10.17487/RFC3840, August 2004, 919 . 921 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 922 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 923 July 2006, . 925 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 926 RFC 4960, DOI 10.17487/RFC4960, September 2007, 927 . 929 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 930 (ICE): A Protocol for Network Address Translator (NAT) 931 Traversal for Offer/Answer Protocols", RFC 5245, 932 DOI 10.17487/RFC5245, April 2010, 933 . 935 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 936 Initiation Protocol (SIP)", RFC 5630, 937 DOI 10.17487/RFC5630, October 2009, 938 . 940 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 941 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 942 January 2012, . 944 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 945 Transmission Protocol (SCTP) Stream Reconfiguration", 946 RFC 6525, DOI 10.17487/RFC6525, February 2012, 947 . 949 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 950 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 951 . 953 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 954 Constrained-Node Networks", RFC 7228, 955 DOI 10.17487/RFC7228, May 2014, 956 . 958 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 959 Application Protocol (CoAP)", RFC 7252, 960 DOI 10.17487/RFC7252, June 2014, 961 . 963 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 964 and Registration Procedures for URI Schemes", BCP 35, 965 RFC 7595, DOI 10.17487/RFC7595, June 2015, 966 . 968 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 969 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 970 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 971 October 2015, . 973 16.2. Informative References 975 [I-D.bormann-core-coap-sig] 976 Bormann, C., "CoAP Signaling Messages", draft-bormann- 977 core-coap-sig-02 (work in progress), June 2016. 979 [I-D.ietf-core-coap-tcp-tls] 980 Bormann, C., Lemay, S., Technologies, Z., and H. 981 Tschofenig, "A TCP and TLS Transport for the Constrained 982 Application Protocol (CoAP)", draft-ietf-core-coap-tcp- 983 tls-02 (work in progress), April 2016. 985 [I-D.savolainen-core-coap-websockets] 986 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 987 WebSockets", draft-savolainen-core-coap-websockets-07 988 (work in progress), June 2016. 990 [I-D.silverajan-core-coap-alternative-transports] 991 Silverajan, B. and T. Savolainen, "CoAP Communication with 992 Alternative Transports", draft-silverajan-core-coap- 993 alternative-transports-09 (work in progress), December 994 2015. 996 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 997 RFC 6455, DOI 10.17487/RFC6455, December 2011, 998 . 1000 Appendix A. Additional Stuff 1002 This becomes an Appendix. 1004 Authors' Addresses 1006 Christian Groves (editor) 1007 Huawei 1008 Melbourne 1009 Australia 1011 Email: Christian.Groves@nteczone.com 1013 Weiwei Yang 1014 Huawei 1015 P.R.China 1017 Email: tommy@huawei.com