idnits 2.17.1 draft-ietf-rtcweb-data-channel-04.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 25, 2013) is 4071 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 29, 2013 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 February 25, 2013 10 RTCWeb Data Channels 11 draft-ietf-rtcweb-data-channel-04.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 29, 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. It also MUST ensure that large data channel transfers 193 don't unduely delay traffic on other data channels. 195 Req. 7 The data channel transport protocol MUST NOT encode local IP 196 addresses inside its protocol fields; doing so reveals 197 potentially private information, and leads to failure if the 198 address is depended upon. 200 Req. 8 The data channel transport protocol SHOULD support 201 unbounded-length "messages" (i.e., a virtual socket stream) 202 at the application layer, for such things as image-file- 203 transfer; Implementations might enforce a reasonable message 204 size limit. 206 Req. 9 The data channel transport protocol SHOULD avoid IP 207 fragmentation. It MUST support PMTU discovery and MUST NOT 208 rely on ICMP or ICMPv6 being generated or being passed back, 209 especially for PMTU discovery. 211 Req. 10 It MUST be possible to implement the protocol stack in the 212 user application space. 214 5. SCTP over DTLS over UDP Considerations 216 The important features of SCTP in the RTCWeb context are: 218 o TCP-friendly congestion control. 220 o The congestion control is modifiable for integration with media 221 stream congestion control. 223 o Support for multiple channels with different characteristics. 225 o Support for out-of-order delivery. 227 o Support for large datagrams and PMTU-discovery and fragmentation. 229 o Reliable or partial reliability support. 231 o Support of multiple streams. 233 SCTP multihoming will not be used in RTCWeb. The SCTP layer will 234 simply act as if it were running on a single-homed host, since that 235 is the abstraction that the lower layer (a connection oriented, 236 unreliable datagram service) exposes. 238 The encapsulation of SCTP over DTLS defined in 239 [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source 240 authenticated, and integrity protected transfers. Using DTLS over 241 UDP in combination with ICE enables NAT traversal in IPv4 based 242 networks. SCTP as specified in [RFC4960] MUST be used in combination 243 with the extension defined in [RFC3758] and provides the following 244 interesting features for transporting non-media data between 245 browsers: 247 o Support of multiple unidirectional streams. 249 o Ordered and unordered delivery of user messages. 251 o Reliable and partial-reliable transport of user messages. 253 Each SCTP user message contains a so called Payload Protocol 254 Identifier (PPID) that is passed to SCTP by its upper layer and sent 255 to its peer. This value can be used to multiplex multiple protocols 256 over a single SCTP association. The sender provides for each 257 protocol a specific PPID and the receiver can demultiplex the 258 messages based on the received PPID. 260 The encapsulation of SCTP over DTLS, together with the SCTP features 261 listed above satisfies all the requirements listed in Section 4. 263 The layering of protocols for WebRTC is shown in the following 264 Figure 2. 266 +------+ 267 |RTCWEB| 268 | DATA | 269 +------+ 270 | SCTP | 271 +--------------------+ 272 | STUN | SRTP | DTLS | 273 +--------------------+ 274 | ICE | 275 +--------------------+ 276 | UDP1 | UDP2 | ... | 277 +--------------------+ 279 Figure 2: WebRTC protocol layers 281 This stack (especially in contrast to DTLS over SCTP [RFC6083] in 282 combination with SCTP over UDP [I-D.ietf-tsvwg-sctp-udp-encaps]) has 283 been chosen because it 285 o supports the transmission of arbitrary large user messages. 287 o shares the DTLS connection with the media channels. 289 o provides privacy for the SCTP control information. 291 Considering the protocol stack of Figure 2 the usage of DTLS over UDP 292 is specified in [RFC6347], while the usage of SCTP on top of DTLS is 293 specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. 295 Since DTLS is typically implemented in user-land, the SCTP stack also 296 needs to be a user-land stack. 298 When using DTLS as the lower layer, only single homed SCTP 299 associations MUST be used, since DTLS does not expose any address 300 management to its upper layer. The ICE/UDP layer can handle IP 301 address changes during a session without needing to notify the DTLS 302 and SCTP layers, though it would be advantageous to retest path MTU 303 on an IP address change. 305 DTLS implementations used for this stack SHOULD support controlling 306 fields of the IP layer like the Don't fragment (DF)-bit in case of 307 IPv4 and the Differentiated Services Code Point (DSCP) field required 308 for supporting [I-D.ietf-rtcweb-qos]. Being able to set the (DF)-bit 309 in case of IPv4 is required for performing path MTU discovery. The 310 DTLS implementation SHOULD also support sending user messages 311 exceeding the path MTU. 313 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP 314 layer, since there is no way to identify the corresponding 315 association. Therefore SCTP MUST support performing Path MTU 316 discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] 317 using probing messages specified in [RFC4820]. The initial Path MTU 318 MUST NOT exceed 1280 [ *** need justification ***] bytes until 319 measured otherwise. 321 In general, the lower layer interface of an SCTP implementation 322 SHOULD be adapted to address the differences between IPv4 or IPv6 323 (being connection-less) or DTLS (being connection-oriented). 325 When protocol stack of Figure 2 is used, DTLS protects the complete 326 SCTP packet, so it provides confidentiality, integrity and source 327 authentication of the complete SCTP packet. 329 This protocol stack MUST support the usage of multiple SCTP streams. 330 A user message can be sent ordered or unordered and with partial or 331 full reliability. The partial reliability extension MUST support 332 policies to limit 334 o the transmission and retransmission by time. 336 o the number of retransmissions. 338 Limiting the number of retransmissions to zero combined with 339 unordered delivery provides a UDP-like service where each user 340 message is sent exactly once and delivered in the order received. 342 SCTP provides congestion control on a per-association base. This 343 means that all SCTP streams within a single SCTP association share 344 the same congestion window. Traffic not being sent over SCTP is not 345 covered by the SCTP congestion control. Due to the typical parallel 346 SRTP media streams, a delay-sensitive congestion control algorithm 347 MUST be supported and the congestion control MAY be coordinated 348 between the data channels and the media streams to avoid a data 349 channel transfer ending up with most or all the channel bandwidth. 351 Since SCTP does not support the negotiation of a congestion control 352 algorithm, the algorithm either MUST be negotiated before 353 establishment of the SCTP association or MUST NOT require any 354 negotiation because it only requires sender side behavior using 355 existing information carried in the association. 357 6. The Usage of SCTP in the RTCWeb Context 359 6.1. Association Setup 361 The SCTP association will be set up when the two endpoints of the 362 WebRTC PeerConnection agree on opening it, as negotiated by JSEP 363 (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally, 364 the negotiation SHOULD include some type of congestion control 365 selection. It will use the DTLS connection selected via SDP; 366 typically this will be shared via BUNDLE or equivalent with DTLS 367 connections used to key the DTLS-SRTP media streams. 369 The application SHOULD indicate the initial number of streams 370 required when opening the association, and if no value is supplied, 371 the implementation SHOULD provide an appropriate default. If more 372 simultaneous streams are needed, [RFC6525] allows adding additional 373 (but not removing) streams to an existing association. Note there 374 can be up to 65536 SCTP streams per SCTP association in each 375 direction. 377 6.2. SCTP Streams 379 SCTP defines a stream as an unidirectional logical channel existing 380 within an SCTP association one to another SCTP endpoint. The streams 381 are used to provide the notion of in-sequence delivery and for 382 multiplexing. Each user message is sent on a particular stream, 383 either order or unordered. Ordering is preserved only for ordered 384 messages sent on the same stream. 386 6.3. Channel Definition 388 The W3C has consensus on defining the application API for WebRTC 389 dataChannels to be bidirectional. They also consider the notions of 390 in-sequence, out-of-sequence, reliable and un-reliable as properties 391 of Channels. One strong wish is for the application-level API to be 392 close to the API for WebSockets, which implies bidirectional streams 393 of data and waiting for onopen to fire before sending, a textual 394 label used to identify the meaning of the stream, among other things. 396 The realization of a bidirectional Data Channel is a pair of one 397 incoming stream and one outgoing SCTP stream. 399 The simple protocol specified in [I-D.jesup-rtcweb-data-protocol] 400 MUST be used to set up and manage the bidirectional data channels. 402 Note that there's no requirement for the SCTP streams used to create 403 a bidirectional channel have the same number in each direction. How 404 stream values are selected is protocol and implementation dependent. 406 Closing of a Data Channel MUST be signaled by resetting the 407 corresponding streams [RFC6525]. Resetting a stream set the Stream 408 Sequence Numbers (SSNs) of the stream back to 'zero' with a 409 corresponding notification to the application layer that the reset 410 has been performed. Streams are available to reuse after a reset has 411 been performed. 413 [RFC6525] also guarantees that all the messages are delivered (or 414 expired) before resetting the stream. 416 6.4. Usage of Payload Protocol Identifier 418 The SCTP Payload Protocol Identifiers (PPIDs) can be used to signal 419 the interpretation of the "Payload data", like the protocol specified 420 in [I-D.jesup-rtcweb-data-protocol] uses them to identify a 421 Javascript string, a Javascript binary data (ArrayBuffer or Blob) and 422 to provide fragmentation support for large messages that may cause 423 the message to monopolize the SCTP association. 425 7. Security Considerations 427 This document does not add any additional considerations to the ones 428 given in [I-D.ietf-rtcweb-security] and 429 [I-D.ietf-rtcweb-security-arch]. 431 8. IANA Considerations 433 This document does not require any actions by the IANA. 435 9. Acknowledgments 437 Many thanks for comments, ideas, and text from Harald Alvestrand, 438 Adam Bergkvist, Cullen Jennings, Eric Rescorla, Randall Stewart, 439 Justin Uberti, and Magnus Westerlund. 441 10. References 443 10.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 449 Conrad, "Stream Control Transmission Protocol (SCTP) 450 Partial Reliability Extension", RFC 3758, May 2004. 452 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 453 Parameter for the Stream Control Transmission Protocol 454 (SCTP)", RFC 4820, March 2007. 456 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 457 Discovery", RFC 4821, March 2007. 459 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 460 RFC 4960, September 2007. 462 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 463 (ICE): A Protocol for Network Address Translator (NAT) 464 Traversal for Offer/Answer Protocols", RFC 5245, 465 April 2010. 467 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 468 Security Version 1.2", RFC 6347, January 2012. 470 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 471 Transmission Protocol (SCTP) Stream Reconfiguration", 472 RFC 6525, February 2012. 474 [I-D.jesup-rtcweb-data-protocol] 475 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 476 Protocol", draft-jesup-rtcweb-data-protocol-03 (work in 477 progress), September 2012. 479 [I-D.ietf-tsvwg-sctp-dtls-encaps] 480 Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS 481 Encapsulation of SCTP Packets for RTCWEB", 482 draft-ietf-tsvwg-sctp-dtls-encaps-00 (work in progress), 483 February 2013. 485 [I-D.ietf-rtcweb-security] 486 Rescorla, E., "Security Considerations for RTC-Web", 487 draft-ietf-rtcweb-security-04 (work in progress), 488 January 2013. 490 [I-D.ietf-rtcweb-security-arch] 491 Rescorla, E., "RTCWEB Security Architecture", 492 draft-ietf-rtcweb-security-arch-06 (work in progress), 493 January 2013. 495 [I-D.ietf-rtcweb-jsep] 496 Uberti, J. and C. Jennings, "Javascript Session 497 Establishment Protocol", draft-ietf-rtcweb-jsep-02 (work 498 in progress), October 2012. 500 [I-D.ietf-rtcweb-qos] 501 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 502 other packet markings for RTCWeb QoS", 503 draft-ietf-rtcweb-qos-00 (work in progress), October 2012. 505 10.2. Informative References 507 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 508 Transport Layer Security (DTLS) for Stream Control 509 Transmission Protocol (SCTP)", RFC 6083, January 2011. 511 [I-D.ietf-rtcweb-use-cases-and-requirements] 512 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 513 Time Communication Use-cases and Requirements", 514 draft-ietf-rtcweb-use-cases-and-requirements-10 (work in 515 progress), December 2012. 517 [I-D.ietf-tsvwg-sctp-udp-encaps] 518 Tuexen, M. and R. Stewart, "UDP Encapsulation of SCTP 519 Packets for End-Host to End-Host Communication", 520 draft-ietf-tsvwg-sctp-udp-encaps-11 (work in progress), 521 February 2013. 523 Authors' Addresses 525 Randell Jesup 526 Mozilla 527 US 529 Email: randell-ietf@jesup.org 531 Salvatore Loreto 532 Ericsson 533 Hirsalantie 11 534 Jorvas 02420 535 FI 537 Email: salvatore.loreto@ericsson.com 538 Michael Tuexen 539 Muenster University of Applied Sciences 540 Stegerwaldstrasse 39 541 Steinfurt 48565 542 DE 544 Email: tuexen@fh-muenster.de