idnits 2.17.1 draft-ietf-rtcweb-data-channel-07.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 11, 2014) is 3725 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) == Missing Reference: 'RFCXXXX' is mentioned on line 533, but not defined ** 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 (-13) exists of draft-ietf-tsvwg-sctp-ndata-00 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-02 == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-03 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-06 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-08 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-05 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-sctp-prpolicies-01 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-05 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-13 Summary: 3 errors (**), 0 flaws (~~), 11 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 15, 2014 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 February 11, 2014 10 WebRTC Data Channels 11 draft-ietf-rtcweb-data-channel-07.txt 13 Abstract 15 The Real-Time Communication in WEB-browsers working group is charged 16 to 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-browsers 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 15, 2014. 41 Copyright Notice 43 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Use Cases for Unreliable Data Channels . . . . . . . . . 3 62 3.2. Use Cases for Reliable Data Channels . . . . . . . . . . 4 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. SCTP over DTLS over UDP Considerations . . . . . . . . . . . 5 65 6. The Usage of SCTP in the WebRTC Context . . . . . . . . . . . 8 66 6.1. SCTP Protocol Considerations . . . . . . . . . . . . . . 8 67 6.2. Association Setup . . . . . . . . . . . . . . . . . . . . 9 68 6.3. SCTP Streams . . . . . . . . . . . . . . . . . . . . . . 9 69 6.4. Channel Definition . . . . . . . . . . . . . . . . . . . 9 70 6.5. Opening a Channel . . . . . . . . . . . . . . . . . . . . 10 71 6.6. Transferring User Data on a Channel . . . . . . . . . . . 10 72 6.7. Closing a Channel . . . . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Non-media data types in the context of WebRTC are handled by using 84 SCTP [RFC4960] encapsulated in DTLS [RFC6347]. 86 +----------+ 87 | SCTP | 88 +----------+ 89 | DTLS | 90 +----------+ 91 | ICE/UDP | 92 +----------+ 94 Figure 1: Basic stack diagram 96 The encapsulation of SCTP over DTLS (see 97 [I-D.ietf-tsvwg-sctp-dtls-encaps]) over ICE/UDP (see [RFC5245]) 98 provides a NAT traversal solution together with confidentiality, 99 source authentication, and integrity protected transfers. This data 100 transport service operates in parallel to the media transports, and 101 all of them can eventually share a single transport-layer port 102 number. 104 SCTP as specified in [RFC4960] with the partial reliability extension 105 defined in [RFC3758] provides multiple streams natively with 106 reliable, and partially-reliable delivery modes for user messages. 107 Using the reconfiguration extension defined in [RFC6525] allows to 108 increase the number of streams during the lifetime of an SCTP 109 association and to reset individual SCTP streams. 111 The remainder of this document is organized as follows: Section 3 and 112 Section 4 provide use cases and requirements for both unreliable and 113 reliable peer to peer data channels; Section 5 arguments SCTP over 114 DTLS over UDP; Section 6 provides the specification of how SCTP 115 should be used by the WebRTC protocol framework for transporting non- 116 media data between WEB-browsers. 118 2. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Use Cases 126 This section defined use cases specific to data channels. For 127 general use cases see [I-D.ietf-rtcweb-use-cases-and-requirements]. 129 3.1. Use Cases for Unreliable Data Channels 131 U-C 1: A real-time game where position and object state information 132 is sent via one or more unreliable data channels. Note that 133 at any time there may be no media channels, or all media 134 channels may be inactive, and that there may also be reliable 135 data channels in use. 137 U-C 2: Providing non-critical information to a user about the reason 138 for a state update in a video chat or conference, such as 139 mute state. 141 3.2. Use Cases for Reliable Data Channels 143 U-C 3: A real-time game where critical state information needs to be 144 transferred, such as control information. Such a game may 145 have no media channels, or they may be inactive at any given 146 time, or may only be added due to in-game actions. 148 U-C 4: Non-realtime file transfers between people chatting. Note 149 that this may involve a large number of files to transfer 150 sequentially or in parallel, such as when sharing a folder of 151 images or a directory of files. 153 U-C 5: Realtime text chat during an audio and/or video call with an 154 individual or with multiple people in a conference. 156 U-C 6: Renegotiation of the configuration of the PeerConnection. 158 U-C 7: Proxy browsing, where a browser uses data channels of a 159 PeerConnection to send and receive HTTP/HTTPS requests and 160 data, for example to avoid local Internet filtering or 161 monitoring. 163 4. Requirements 165 This section lists the requirements for P2P data channels between two 166 browsers. 168 Req. 1: Multiple simultaneous data channels MUST be supported. 169 Note that there may 0 or more media streams in parallel 170 with the data channels in the same PeerConnection, and the 171 number and state (active/inactive) of these media streams 172 may change at any time. 174 Req. 2: Both reliable and unreliable data channels MUST be 175 supported. 177 Req. 3: Data channels of a PeerConnection MUST be congestion 178 controlled; either individually, as a class, or in 179 conjunction with the media streams of the PeerConnection, 180 to ensure that data channels don't cause congestion 181 problems for these media streams, and that the WebRTC 182 PeerConnection as a whole is fair with competing traffic 183 such as TCP. 185 Req. 4: The application SHOULD be able to provide guidance as to 186 the relative priority of each data channel relative to each 187 other, and relative to the media streams. This will 188 interact with the congestion control algorithms. 190 Req. 5: Data channels MUST be secured; allowing for 191 confidentiality, integrity and source authentication. See 192 [I-D.ietf-rtcweb-security] and 193 [I-D.ietf-rtcweb-security-arch] for detailed info. 195 Req. 6: Data channels MUST provide message fragmentation support 196 such that IP-layer fragmentation can be avoided no matter 197 how large a message the JavaScript application passes to be 198 sent. It also MUST ensure that large data channel 199 transfers don't unduly delay traffic on other data 200 channels. 202 Req. 7: The data channel transport protocol MUST NOT encode local 203 IP addresses inside its protocol fields; doing so reveals 204 potentially private information, and leads to failure if 205 the address is depended upon. 207 Req. 8: The data channel transport protocol SHOULD support 208 unbounded-length "messages" (i.e., a virtual socket stream) 209 at the application layer, for such things as image-file- 210 transfer; Implementations might enforce a reasonable 211 message size limit. 213 Req. 9: The data channel transport protocol SHOULD avoid IP 214 fragmentation. It MUST support PMTU (Path MTU) discovery 215 and MUST NOT rely on ICMP or ICMPv6 being generated or 216 being passed back, especially for PMTU discovery. 218 Req. 10: It MUST be possible to implement the protocol stack in the 219 user application space. 221 5. SCTP over DTLS over UDP Considerations 223 The important features of SCTP in the WebRTC context are: 225 o Usage of a TCP-friendly congestion control. 227 o The congestion control is modifiable for integration with media 228 stream congestion control. 230 o Support of multiple unidirectional streams, each providing its own 231 notion of ordered message delivery. 233 o Support of ordered and out-of-order message delivery. 235 o Supporting arbitrary large user message by providing fragmentation 236 and reassembly. 238 o Support of PMTU-discovery. 240 o Support of reliable or partially reliable message transport. 242 SCTP multihoming will not be used in WebRTC. The SCTP layer will 243 simply act as if it were running on a single-homed host, since that 244 is the abstraction that the lower layer (a connection oriented, 245 unreliable datagram service) exposes. 247 The encapsulation of SCTP over DTLS defined in 248 [I-D.ietf-tsvwg-sctp-dtls-encaps] provides confidentiality, source 249 authenticated, and integrity protected transfers. Using DTLS over 250 UDP in combination with ICE enables middlebox traversal in IPv4 and 251 IPv6 based networks. SCTP as specified in [RFC4960] MUST be used in 252 combination with the extension defined in [RFC3758] and provides the 253 following interesting features for transporting non-media data 254 between browsers: 256 o Support of multiple unidirectional streams. 258 o Ordered and unordered delivery of user messages. 260 o Reliable and partial-reliable transport of user messages. 262 Each SCTP user message contains a so called Payload Protocol 263 Identifier (PPID) that is passed to SCTP by its upper layer and sent 264 to its peer. This value can be used to multiplex multiple protocols 265 over a single SCTP association. The sender provides for each 266 protocol a specific PPID and the receiver can demultiplex the 267 messages based on the received PPID. The PPID is used to distinguish 268 UTF-8 encoded user data and binary encoded userdata. The Data 269 Channel Establishment Protocol defined in 270 [I-D.ietf-rtcweb-data-protocol] uses also a specific PPID to be 271 distinguished from user data. 273 The encapsulation of SCTP over DTLS, together with the SCTP features 274 listed above satisfies all the requirements listed in Section 4. 276 The layering of protocols for WebRTC is shown in the following 277 Figure 2. 279 +------+ 280 |WEBRTC| 281 | DATA | 282 +------+ 283 | SCTP | 284 +--------------------+ 285 | STUN | SRTP | DTLS | 286 +--------------------+ 287 | ICE | 288 +--------------------+ 289 | UDP1 | UDP2 | ... | 290 +--------------------+ 292 Figure 2: WebRTC protocol layers 294 This stack (especially in contrast to DTLS over SCTP [RFC6083] in 295 combination with SCTP over UDP [RFC6951]) has been chosen because it 297 o supports the transmission of arbitrary large user messages. 299 o shares the DTLS connection with the media channels of the 300 PeerConnection. 302 o provides privacy for the SCTP control information. 304 Considering the protocol stack of Figure 2 the usage of DTLS over UDP 305 is specified in [RFC6347], while the usage of SCTP on top of DTLS is 306 specified in [I-D.ietf-tsvwg-sctp-dtls-encaps]. Please note that the 307 demultiplexing STUN vs. SRTP vs. DTLS is done as described in 308 Section 5.1.2 of [RFC5764] and SCTP is the only payload of DTLS. 310 Since DTLS is typically implemented in user-land, the SCTP stack also 311 needs to be a user-land stack. 313 When using DTLS as the lower layer, only single homed SCTP 314 associations MUST be used, since DTLS does not expose any address 315 management to its upper layer. The ICE/UDP layer can handle IP 316 address changes during a session without needing to notify the DTLS 317 and SCTP layers, though it would be advantageous to retest Path MTU 318 on an IP address change. 320 DTLS implementations used for this stack SHOULD support controlling 321 fields of the IP layer like the Don't Fragment (DF)-bit in case of 322 IPv4 and the Differentiated Services Code Point (DSCP) field required 323 for supporting [I-D.ietf-rtcweb-qos]. Being able to set the (DF)-bit 324 in case of IPv4 is required for performing path MTU discovery. The 325 DTLS implementation SHOULD also support sending user messages 326 exceeding the Path MTU. 328 Incoming ICMP or ICMPv6 messages can't be processed by the SCTP 329 layer, since there is no way to identify the corresponding 330 association. Therefore SCTP MUST support performing Path MTU 331 discovery without relying on ICMP or ICMPv6 as specified in [RFC4821] 332 using probing messages specified in [RFC4820]. The initial Path MTU 333 at the IP layer MUST NOT exceed 1200 bytes for IPv4 and 1280 for 334 IPv6. 336 In general, the lower layer interface of an SCTP implementation 337 SHOULD be adapted to address the differences between IPv4 and IPv6 338 (being connection-less) or DTLS (being connection-oriented). 340 When protocol stack of Figure 2 is used, DTLS protects the complete 341 SCTP packet, so it provides confidentiality, integrity and source 342 authentication of the complete SCTP packet. 344 This SCTP stack and its upper layer MUST support the usage of 345 multiple SCTP streams. A user message can be sent ordered or 346 unordered and with partial or full reliability. The partial 347 reliability extension MUST support policies to limit 349 o the transmission and retransmission by time. 351 o the number of retransmissions. 353 Limiting the number of retransmissions to zero combined with 354 unordered delivery provides a UDP-like service where each user 355 message is sent exactly once and delivered in the order received. 357 SCTP provides congestion control on a per-association base. This 358 means that all SCTP streams within a single SCTP association share 359 the same congestion window. Traffic not being sent over SCTP is not 360 covered by the SCTP congestion control. Using a congestion control 361 different from the standard one might improve the impact on the 362 parallel SRTP media streams. Since SCTP does not support the 363 negotiation of a congestion control algorithm yet, alternate 364 congestion controls SHOULD either only require a different sender 365 side behavior using existing information carried in the association 366 or need also specify a negotiation of of a congestion control 367 algorithm. 369 6. The Usage of SCTP in the WebRTC Context 371 6.1. SCTP Protocol Considerations 373 The DTLS encapsulation of SCTP packets as described in 374 [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. 376 The following SCTP protocol extensions are required: 378 o The stream reset extension defined in [RFC6525] MUST be supported. 379 It is used for closing channels. 381 o The dynamic address reconfiguration extension defined in [RFC5061] 382 MUST be used to signal the support of the stream reset extension 383 defined in [RFC6525], other features of [RFC5061] are not REQUIRED 384 to be implemented. 386 o The partial reliability extension defined in [RFC3758] MUST be 387 supported. In addition to the timed reliability PR-SCTP policy 388 defined in [RFC3758], the limited retransmission policy defined in 389 [I-D.ietf-tsvwg-sctp-prpolicies] MUST be supported. 391 Once support for message interleaving as currently being discussed in 392 [I-D.ietf-tsvwg-sctp-ndata] is available, it SHOULD be supported. 394 6.2. Association Setup 396 The SCTP association will be set up when the two endpoints of the 397 WebRTC PeerConnection agree on opening it, as negotiated by JSEP 398 (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]. Additionally, 399 the negotiation SHOULD include some type of congestion control 400 selection. It will use the DTLS connection selected via ICE; 401 typically this will be shared via BUNDLE or equivalent with DTLS 402 connections used to key the DTLS-SRTP media streams. 404 The number of streams negotiated during SCTP association setup SHOULD 405 be 65535, which is the maximum number of streams that can negotiated 406 during the association setup. 408 6.3. SCTP Streams 410 SCTP defines a stream as a unidirectional logical channel existing 411 within an SCTP association one to another SCTP endpoint. The streams 412 are used to provide the notion of in-sequence delivery and for 413 multiplexing. Each user message is sent on a particular stream, 414 either order or unordered. Ordering is preserved only for ordered 415 messages sent on the same stream. 417 6.4. Channel Definition 419 The W3C has consensus on defining the application API for WebRTC 420 DataChannels to be bidirectional. They also consider the notions of 421 in-sequence, out-of-sequence, reliable and unreliable as properties 422 of Channels. One strong wish is for the application-level API to be 423 close to the API for WebSockets, which implies bidirectional streams 424 of data and waiting for onopen to fire before sending, a textual 425 label used to identify the meaning of the stream, among other things. 426 Each data channel also has a priority. These priorities MUST NOT be 427 strict priorities. 429 The realization of a bidirectional Data Channel is a pair of one 430 incoming stream and one outgoing SCTP stream having the same stream 431 SCTP identifier. 433 How stream values are selected is protocol and implementation 434 dependent. 436 6.5. Opening a Channel 438 Data channels can be opened by using internal or external 439 negotiation. The details are out of scope of this document. 441 A simple protocol for internal negotiation is specified in 442 [I-D.ietf-rtcweb-data-protocol] and MUST be supported. 444 When one side wants to open a channel using external negotiation, it 445 picks a stream. This can be based on the DTLS role (the client picks 446 even stream identifiers, the server odd stream identifiers) or done 447 in a different way. However, the application is responsible for 448 avoiding collisions with existing streams. If it attempts to re-use 449 a stream which is part of an existing Channel, the addition SHOULD 450 fail. In addition to choosing a stream, the application SHOULD also 451 inform the protocol of the options to use for sending messages. The 452 application MUST ensure in an application-specific manner that the 453 other side will also inform the protocol that the selected stream is 454 to be used, and the parameters for sending data from that side. 456 6.6. Transferring User Data on a Channel 458 All data sent on a Channel in both directions MUST be sent over the 459 underlying stream using the reliability defined when the Channel was 460 opened unless the options are changed, or per-message options are 461 specified by a higher level. 463 No more than one message should be put into an SCTP user message. 465 The SCTP Payload Protocol Identifiers (PPIDs) are used to signal the 466 interpretation of the "Payload data". For identifying a JavaScript 467 string encoded in UTF-8 the PPID "WebRTC String" MUST be used, for 468 JavaScript binary data (ArrayBuffer or Blob) the PPID "WebRTC Binary" 469 MUST be used (see Section 8). 471 The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary 472 Partial" is deprecated. They were used for a PPID based 473 fragmentation and reassembly of user messages belonging to reliable 474 and ordered data channels. 476 The SCTP base protocol specified in [RFC4960] does not support the 477 interleaving of user messages. Therefore sending a large user 478 message can monopolize the SCTP association. To overcome this 479 limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to 480 support message interleaving. Once this extension is available, it 481 MUST be used. As long as message interleaving is not supported, the 482 sender SHOULD limit the maximum message size to 16 KB to avoid 483 monopolization. 485 It is recommended that message size be kept within certain size 486 bounds as applications will not be able to support arbitrarily-large 487 single messages. This limit has to be negotiated, for example by 488 using [I-D.ietf-mmusic-sctp-sdp]. 490 The sender SHOULD disable the Nagle algorithm to minimize the 491 latency. 493 6.7. Closing a Channel 495 Closing of a Data Channel MUST be signaled by resetting the 496 corresponding outgoing streams [RFC6525]. Resetting a stream set the 497 Stream Sequence Numbers (SSNs) of the stream back to 'zero' with a 498 corresponding notification to the application layer that the reset 499 has been performed. Streams are available to reuse after a reset has 500 been performed. 502 [RFC6525] also guarantees that all the messages are delivered (or 503 abandoned) before resetting the stream. 505 7. Security Considerations 507 This document does not add any additional considerations to the ones 508 given in [I-D.ietf-rtcweb-security] and 509 [I-D.ietf-rtcweb-security-arch]. 511 8. IANA Considerations 513 [NOTE to RFC-Editor: 515 "RFCXXXX" is to be replaced by the RFC number you assign this 516 document. 518 ] 519 This document uses four already registered SCTP Payload Protocol 520 Identifiers (PPIDs): "DOMString Last", "Binary Data Partial", "Binary 521 Data Last", and "DOMString Partial". [RFC4960] creates the registry 522 "SCTP Payload Protocol Identifiers" from which these identifiers were 523 assigned. IANA is requested to update the reference of these four 524 assignments to point to this document and change the names of the 525 PPIDs. Therefore these four assignments should be updated to read: 527 +------------------------------------+-----------+-----------+ 528 | Value | SCTP PPID | Reference | 529 +------------------------------------+-----------+-----------+ 530 | WebRTC String | 51 | [RFCXXXX] | 531 | WebRTC Binary Partial (Deprecated) | 52 | [RFCXXXX] | 532 | WebRTC Binary | 53 | [RFCXXXX] | 533 | WebRTC String Partial (Deprecated) | 54 | [RFCXXXX] | 534 +------------------------------------+-----------+-----------+ 536 9. Acknowledgments 538 Many thanks for comments, ideas, and text from Harald Alvestrand, 539 Adam Bergkvist, Cullen Jennings, Eric Rescorla, Randall Stewart, 540 Justin Uberti, and Magnus Westerlund. 542 10. References 544 10.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 550 Conrad, "Stream Control Transmission Protocol (SCTP) 551 Partial Reliability Extension", RFC 3758, May 2004. 553 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 554 Parameter for the Stream Control Transmission Protocol 555 (SCTP)", RFC 4820, March 2007. 557 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 558 Discovery", RFC 4821, March 2007. 560 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 561 4960, September 2007. 563 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 564 Kozuka, "Stream Control Transmission Protocol (SCTP) 565 Dynamic Address Reconfiguration", RFC 5061, September 566 2007. 568 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 569 (ICE): A Protocol for Network Address Translator (NAT) 570 Traversal for Offer/Answer Protocols", RFC 5245, April 571 2010. 573 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 574 Security Version 1.2", RFC 6347, January 2012. 576 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 577 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 578 6525, February 2012. 580 [I-D.ietf-tsvwg-sctp-ndata] 581 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A 582 New Data Chunk for Stream Control Transmission Protocol", 583 draft-ietf-tsvwg-sctp-ndata-00 (work in progress), 584 February 2014. 586 [I-D.ietf-rtcweb-data-protocol] 587 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 588 Protocol", draft-ietf-rtcweb-data-protocol-02 (work in 589 progress), February 2014. 591 [I-D.ietf-tsvwg-sctp-dtls-encaps] 592 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 593 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 594 dtls-encaps-03 (work in progress), February 2014. 596 [I-D.ietf-rtcweb-security] 597 Rescorla, E., "Security Considerations for WebRTC", draft- 598 ietf-rtcweb-security-06 (work in progress), January 2014. 600 [I-D.ietf-rtcweb-security-arch] 601 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 602 rtcweb-security-arch-08 (work in progress), January 2014. 604 [I-D.ietf-rtcweb-jsep] 605 Uberti, J. and C. Jennings, "Javascript Session 606 Establishment Protocol", draft-ietf-rtcweb-jsep-05 (work 607 in progress), October 2013. 609 [I-D.ietf-rtcweb-qos] 610 Dhesikan, S., Druta, D., Jones, P., and J. Polk, "DSCP and 611 other packet markings for RTCWeb QoS", draft-ietf-rtcweb- 612 qos-00 (work in progress), October 2012. 614 [I-D.ietf-tsvwg-sctp-prpolicies] 615 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 616 "Additional Policies for the Partial Reliability Extension 617 of the Stream Control Transmission Protocol", draft-ietf- 618 tsvwg-sctp-prpolicies-01 (work in progress), January 2014. 620 [I-D.ietf-mmusic-sctp-sdp] 621 Loreto, S. and G. Camarillo, "Stream Control Transmission 622 Protocol (SCTP)-Based Media Transport in the Session 623 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-05 624 (work in progress), October 2013. 626 10.2. Informative References 628 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 629 Security (DTLS) Extension to Establish Keys for the Secure 630 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 632 [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 633 Transport Layer Security (DTLS) for Stream Control 634 Transmission Protocol (SCTP)", RFC 6083, January 2011. 636 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 637 Control Transmission Protocol (SCTP) Packets for End-Host 638 to End-Host Communication", RFC 6951, May 2013. 640 [I-D.ietf-rtcweb-use-cases-and-requirements] 641 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 642 Time Communication Use-cases and Requirements", draft- 643 ietf-rtcweb-use-cases-and-requirements-13 (work in 644 progress), February 2014. 646 Authors' Addresses 648 Randell Jesup 649 Mozilla 650 US 652 Email: randell-ietf@jesup.org 654 Salvatore Loreto 655 Ericsson 656 Hirsalantie 11 657 Jorvas 02420 658 FI 660 Email: salvatore.loreto@ericsson.com 661 Michael Tuexen 662 Muenster University of Applied Sciences 663 Stegerwaldstrasse 39 664 Steinfurt 48565 665 DE 667 Email: tuexen@fh-muenster.de