idnits 2.17.1 draft-ietf-rtcweb-data-channel-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 (February 24, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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 (-04) exists of draft-jesup-rtcweb-data-protocol-03 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-00 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-04 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-06 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-02 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-10 == Outdated reference: A later version (-14) exists of draft-ietf-tsvwg-sctp-udp-encaps-11 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Jesup 3 Internet-Draft Mozilla 4 Intended status: Standards Track S. Loreto 5 Expires: August 28, 2013 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 February 24, 2013 10 RTCWeb Data Channels 11 draft-ietf-rtcweb-data-channel-03.txt 13 Abstract 15 The Web Real-Time Communication (WebRTC) working group is charged to 16 provide protocol support for direct interactive rich communication 17 using audio, video, and data between two peers' web-browsers. This 18 document specifies the non-media data transport aspects of the WebRTC 19 framework. It provides an architectural overview of how the Stream 20 Control Transmission Protocol (SCTP) is used in the WebRTC context as 21 a generic transport service allowing Web Browser to exchange generic 22 data from peer to peer. 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 http://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 August 28, 2013. 41 Copyright Notice 43 Copyright (c) 2013 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Use Cases for Unreliable Data Channels . . . . . . . . . . 4 62 3.2. Use Cases for Reliable Data Channels . . . . . . . . . . . 4 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . . 6 65 6. The Usage of SCTP in the RTCWeb Context . . . . . . . . . . . 9 66 6.1. Association Setup . . . . . . . . . . . . . . . . . . . . 9 67 6.2. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.3. Channel Definition . . . . . . . . . . . . . . . . . . . . 9 69 6.4. Usage of Payload Protocol Identifier . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 Non-media data types in the context of RTCWeb are handled by using 81 SCTP [RFC4960] encapsulated in DTLS [RFC6347]. 83 +----------+ 84 | SCTP | 85 +----------+ 86 | DTLS | 87 +----------+ 88 | ICE/UDP | 89 +----------+ 91 Figure 1: Basic stack diagram 93 The encapsulation of SCTP over DTLS (see 94 [I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245]) 95 provides a NAT traversal solution together with confidentiality, 96 source authentication, and integrity protected transfers. This data 97 transport service operates in parallel to the media transports, and 98 all of them can eventually share a single transport-layer port 99 number. 101 SCTP as specified in [RFC4960] with the partial reliability extension 102 defined in [RFC3758] provides multiple streams natively with 103 reliable, and partially-reliable delivery modes. 105 The remainder of this document is organized as follows: Section 4 and 106 Section 3 provide requirements and use cases for both unreliable and 107 reliable peer to peer datagram base channel; Section 5 arguments SCTP 108 over DTLS over UDP; Section 6 provides an specification of how SCTP 109 should be used by the RTCWeb protocol framework for transporting non- 110 media data between browsers. 112 2. Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Use Cases 120 This section defined use cases specific to data channels. For 121 general use cases see [I-D.ietf-rtcweb-use-cases-and-requirements]. 123 3.1. Use Cases for Unreliable Data Channels 125 U-C 1 A real-time game where position and object state information 126 is sent via one or more unreliable data channels. Note that 127 at any time there may be no media channels, or all media 128 channels may be inactive, and that there may also be reliable 129 data channels in use. 131 U-C 2 Providing non-critical information to a user about the reason 132 for a state update in a video chat or conference, such as Mute 133 state. 135 3.2. Use Cases for Reliable Data Channels 137 U-C 3 A real-time game where critical state information needs to be 138 transferred, such as control information. Such a game may 139 have no media channels, or they may be inactive at any given 140 time, or may only be added due to in-game actions. 142 U-C 4 Non-realtime file transfers between people chatting. Note 143 that this may involve a large number of files to transfer 144 sequentially or in parallel, such as when sharing a folder of 145 images or a directory of files. 147 U-C 5 Realtime text chat while talking with an individual or with 148 multiple people in a conference. 150 U-C 6 Renegotiation of the set of media streams in the 151 PeerConnection. 153 U-C 7 Proxy browsing, where a browser uses data channels of a 154 PeerConnection to send and receive HTTP/HTTPS requests and 155 data, for example to avoid local internet filtering or 156 monitoring. 158 4. Requirements 160 This section lists the requirements for P2P data channels between two 161 browsers. 163 Req. 1 Multiple simultaneous data channels MUST be supported. Note 164 that there may 0 or more media streams in parallel with the 165 data channels, and the number and state (active/inactive) of 166 the media streams may change at any time. 168 Req. 2 Both reliable and unreliable data channels MUST be 169 supported. 171 Req. 3 Data channels MUST be congestion controlled; either 172 individually, as a class, or in conjunction with the media 173 streams, to ensure that data channels don't cause congestion 174 problems for the media streams, and that the RTCWeb 175 PeerConnection as a whole is fair with competing traffic 176 such as TCP. 178 Req. 4 The application SHOULD be able to provide guidance as to the 179 relative priority of each data channel relative to each 180 other, and relative to the media streams. [ TBD: how this is 181 encoded and what the impact of this is. ] This will interact 182 with the congestion control algorithms. 184 Req. 5 Data channels MUST be secured; allowing for confidentiality, 185 integrity and source authentication. See 186 [I-D.ietf-rtcweb-security] and 187 [I-D.ietf-rtcweb-security-arch] for detailed info. 189 Req. 6 Data channels MUST provide message fragmentation support 190 such that IP-layer fragmentation can be avoided no matter 191 how large a message the Javascript application passes to be 192 sent. 194 Req. 7 The data channel transport protocol MUST NOT encode local IP 195 addresses inside its protocol fields; doing so reveals 196 potentially private information, and leads to failure if the 197 address is depended upon. 199 Req. 8 The data channel transport protocol SHOULD support 200 unbounded-length "messages" (i.e., a virtual socket stream) 201 at the application layer, for such things as image-file- 202 transfer; Implementations might enforce a reasonable message 203 size limit. 205 Req. 9 The data channel packet format/encoding MUST be such that it 206 is impossible for a malicious Javascript to generate an 207 application message crafted such that it could be 208 interpreted as a native protocol over UDP - such as UPnP, 209 RTP, SNMP, STUN, etc. 211 Req. 10 The data channel transport protocol SHOULD avoid IP 212 fragmentation. It MUST support PMTU discovery and MUST NOT 213 rely on ICMP or ICMPv6 being generated or being passed back, 214 especially for PMTU discovery. 216 Req. 11 It MUST be possible to implement the protocol stack in the 217 user application space. 219 5. SCTP over DTLS over UDP Considerations 221 The important features of SCTP in the RTCWeb context are: 223 o TCP-friendly congestion control. 225 o The congestion control is modifiable for integration with media 226 stream congestion control. 228 o Support for multiple channels with different characteristics. 230 o Support for out-of-order delivery. 232 o Support for large datagrams and PMTU-discovery and fragmentation. 234 o Reliable or partial reliability support. 236 o Support of multiple streams. 238 SCTP multihoming will not be used in RTCWeb. The SCTP layer will 239 simply act as if it were running on a single-homed host, since that 240 is the abstraction that the lower layer (a connection oriented, 241 unreliable datagram service) exposes. 243 The encapsulation of SCTP over DTLS defined in 244 [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source 245 authenticated, and integrity protected transfers. Using DTLS over 246 UDP in combination with ICE enables NAT traversal in IPv4 based 247 networks. SCTP as specified in [RFC4960] MUST be used in combination 248 with the extension defined in [RFC3758] and provides the following 249 interesting features for transporting non-media data between 250 browsers: 252 o Support of multiple unidirectional streams. 254 o Ordered and unordered delivery of user messages. 256 o Reliable and partial-reliable transport of user messages. 258 Each SCTP user message contains a so called Payload Protocol 259 Identifier (PPID) that is passed to SCTP by its upper layer and sent 260 to its peer. This value can be used to multiplex multiple protocols 261 over a single SCTP association. The sender provides for each 262 protocol a specific PPID and the receiver can demultiplex the 263 messages based on the received PPID. 265 The encapsulation of SCTP over DTLS, together with the SCTP features 266 listed above satisfies all the requirements listed in Section 4. 268 The layering of protocols for WebRTC is shown in the following 269 Figure 2. 271 +------+ 272 |RTCWEB| 273 | DATA | 274 +------+ 275 | SCTP | 276 +--------------------+ 277 | STUN | SRTP | DTLS | 278 +--------------------+ 279 | ICE | 280 +--------------------+ 281 | UDP1 | UDP2 | ... | 282 +--------------------+ 284 Figure 2: WebRTC protocol layers 286 This stack (especially in contrast to DTLS over SCTP [RFC6083] in 287 combination with SCTP over UDP [I-D.ietf-tsvwg-sctp-udp-encaps]) has 288 been chosen because it 290 o supports the transmission of arbitrary large user messages. 292 o shares the DTLS connection with the media channels. 294 o provides privacy for the SCTP control information. 296 Considering the protocol stack of Figure 2 the usage of DTLS over UDP 297 is specified in [RFC6347], while the usage of SCTP on top of DTLS is 298 specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. 300 Since DTLS is typically implemented in user-land, the SCTP stack also 301 needs to be a user-land stack. 303 When using DTLS as the lower layer, only single homed SCTP 304 associations MUST be used, since DTLS does not expose any address 305 management to its upper layer. The ICE/UDP layer can handle IP 306 address changes during a session without needing to notify the DTLS 307 and SCTP layers, though it would be advantageous to retest path MTU 308 on an IP address change. 310 DTLS implementations used for this stack SHOULD support controlling 311 fields of the IP layer like the Don't fragment (DF)-bit in case of 312 IPv4 and the Differentiated Services Code Point (DSCP) field required 313 for supporting [I-D.ietf-rtcweb-qos]. Being able to set the (DF)-bit 314 in case of IPv4 is required for performing path MTU discovery. The 315 DTLS implementation SHOULD also support sending user messages 316 exceeding the path MTU. 318 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP 319 layer, since there is no way to identify the corresponding 320 association. Therefore SCTP MUST support performing Path MTU 321 discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] 322 using probing messages specified in [RFC4820]. The initial Path MTU 323 MUST NOT exceed 1280 [ *** need justification ***] bytes until 324 measured otherwise. 326 In general, the lower layer interface of an SCTP implementation 327 SHOULD be adapted to address the differences between IPv4 or IPv6 328 (being connection-less) or DTLS (being connection-oriented). 330 When protocol stack of Figure 2 is used, DTLS protects the complete 331 SCTP packet, so it provides confidentiality, integrity and source 332 authentication of the complete SCTP packet. 334 This protocol stack MUST support the usage of multiple SCTP streams. 335 A user message can be sent ordered or unordered and with partial or 336 full reliability. The partial reliability extension MUST support 337 policies to limit 339 o the transmission and retransmission by time. 341 o the number of retransmissions. 343 Limiting the number of retransmissions to zero combined with 344 unordered delivery provides a UDP-like service where each user 345 message is sent exactly once and delivered in the order received. 347 SCTP provides congestion control on a per-association base. This 348 means that all SCTP streams within a single SCTP association share 349 the same congestion window. Traffic not being sent over SCTP is not 350 covered by the SCTP congestion control. Due to the typical parallel 351 SRTP media streams, a delay-sensitive congestion control algorithm 352 MUST be supported and the congestion control MAY be coordinated 353 between the data channels and the media streams to avoid a data 354 channel transfer ending up with most or all the channel bandwidth. 356 Since SCTP does not support the negotiation of a congestion control 357 algorithm, the algorithm either MUST be negotiated before 358 establishment of the SCTP association or MUST NOT require any 359 negotiation because it only requires sender side behavior using 360 existing information carried in the association. 362 6. The Usage of SCTP in the RTCWeb Context 364 6.1. Association Setup 366 The SCTP association will be set up when the two endpoints of the 367 WebRTC PeerConnection agree on opening it, as negotiated by JSEP 368 (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally, 369 the negotiation SHOULD include some type of congestion control 370 selection. It will use the DTLS connection selected via SDP; 371 typically this will be shared via BUNDLE with DTLS connections used 372 to key the DTLS-SRTP media streams. 374 The application SHOULD indicate the initial number of streams 375 required when opening the association, and if no value is supplied, 376 the implementation SHOULD provide an appropriate default. If more 377 simultaneous streams are needed, [RFC6525] allows adding additional 378 (but not removing) streams to an existing association. Note there 379 can be up to 65536 SCTP streams per SCTP association in each 380 direction. 382 6.2. SCTP Streams 384 SCTP defines a stream as an unidirectional logical channel existing 385 within an SCTP association one to another SCTP endpoint. The streams 386 are used to provide the notion of in-sequence delivery and for 387 multiplexing. Each user message is sent on a particular stream, 388 either order or unordered. Ordering is preserved only for all 389 ordered messages sent on the same stream. 391 6.3. Channel Definition 393 The W3C has consensus on defining the application API for WebRTC 394 dataChannels to be bidirectional. They also consider the notions of 395 in-sequence, out-of-sequence, reliable and un-reliable as properties 396 of Channels. One strong wish is for the application-level API to be 397 close to the API for WebSockets, which implies bidirectional streams 398 of data and waiting for onopen to fire before sending, a textual 399 label used to identify the meaning of the stream, among other things. 401 The realization of a bidirectional Data Channel is a pair of one 402 incoming stream and one outgoing SCTP stream. 404 The simple protocol specified in [I-D.jesup-rtcweb-data-protocol] 405 MUST be used to set up and manage the bidirectional data channels. 407 Note that there's no requirement for the SCTP streams used to create 408 a bidirectional channel have the same number in each direction. How 409 stream values are selected is protocol and implementation dependent. 411 Closing of a Data Channel MUST be signaled by resetting the 412 corresponding streams [RFC6525]. Resetting a stream set the Stream 413 Sequence Numbers (SSNs) of the stream back to 'zero' with a 414 corresponding notification to the application layer that the reset 415 has been performed. Streams are available to reuse after a reset has 416 been performed. 418 [RFC6525] also guarantees that all the messages are delivered (or 419 expired) before resetting the stream. 421 6.4. Usage of Payload Protocol Identifier 423 The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal 424 the interpretation of the "Payload data", like the protocol specified 425 in [I-D.jesup-rtcweb-data-protocol] uses them to identify a 426 Javascript string, a Javascript array or a Javascript blob. 428 7. Security Considerations 430 This document does not add any additional considerations to the ones 431 given in [I-D.ietf-rtcweb-security] and 432 [I-D.ietf-rtcweb-security-arch]. 434 8. IANA Considerations 436 This document does not require any actions by the IANA. 438 9. Acknowledgments 440 Many thanks for comments, ideas, and text from Harald Alvestrand, 441 Adam Bergkvist, Cullen Jennings, Eric Rescorla, Randall Stewart, 442 Justin Uberti, and Magnus Westerlund. 444 10. References 446 10.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 452 Conrad, "Stream Control Transmission Protocol (SCTP) 453 Partial Reliability Extension", RFC 3758, May 2004. 455 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 456 Parameter for the Stream Control Transmission Protocol 457 (SCTP)", RFC 4820, March 2007. 459 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 460 Discovery", RFC 4821, March 2007. 462 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 463 RFC 4960, September 2007. 465 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 466 (ICE): A Protocol for Network Address Translator (NAT) 467 Traversal for Offer/Answer Protocols", RFC 5245, 468 April 2010. 470 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 471 Security Version 1.2", RFC 6347, January 2012. 473 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 474 Transmission Protocol (SCTP) Stream Reconfiguration", 475 RFC 6525, February 2012. 477 [I-D.jesup-rtcweb-data-protocol] 478 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 479 Protocol", draft-jesup-rtcweb-data-protocol-03 (work in 480 progress), September 2012. 482 [I-D.ietf-tsvwg-sctp-dtls-encaps] 483 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 484 Encapsulation of SCTP Packets for RTCWEB", 485 draft-ietf-tsvwg-sctp-dtls-encaps-00 (work in progress), 486 February 2013. 488 [I-D.ietf-rtcweb-security] 489 Rescorla, E., "Security Considerations for RTC-Web", 490 draft-ietf-rtcweb-security-04 (work in progress), 491 January 2013. 493 [I-D.ietf-rtcweb-security-arch] 494 Rescorla, E., "RTCWEB Security Architecture", 495 draft-ietf-rtcweb-security-arch-06 (work in progress), 496 January 2013. 498 [I-D.ietf-rtcweb-jsep] 499 Uberti, J. and C. Jennings, "Javascript Session 500 Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work 501 in progress), October 2012. 503 [I-D.ietf-rtcweb-qos] 504 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 505 other packet markings for RTCWeb QoS", 506 draft-ietf-rtcweb-qos-00 (work in progress), October 2012. 508 10.2. Informative References 510 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 511 Transport Layer Security (DTLS) for Stream Control 512 Transmission Protocol (SCTP)", RFC 6083, January 2011. 514 [I-D.ietf-rtcweb-use-cases-and-requirements] 515 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 516 Time Communication Use-cases and Requirements", 517 draft-ietf-rtcweb-use-cases-and-requirements-10 (work in 518 progress), December 2012. 520 [I-D.ietf-tsvwg-sctp-udp-encaps] 521 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 522 Packets for End-Host to End-Host Communication", 523 draft-ietf-tsvwg-sctp-udp-encaps-11 (work in progress), 524 February 2013. 526 Authors' Addresses 528 Randell Jesup 529 Mozilla 530 US 532 Email: randell-ietf@jesup.org 534 Salvatore Loreto 535 Ericsson 536 Hirsalantie 11 537 Jorvas 02420 538 FI 540 Email: salvatore.loreto@ericsson.com 541 Michael Tuexen 542 Muenster University of Applied Sciences 543 Stegerwaldstrasse 39 544 Steinfurt 48565 545 DE 547 Email: tuexen@fh-muenster.de