idnits 2.17.1 draft-ietf-rtcweb-data-protocol-09.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 (January 4, 2015) is 3399 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 486, but not defined ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-sctp-dtls-encaps-07 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-12 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-07 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-10 Summary: 4 errors (**), 0 flaws (~~), 6 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: July 8, 2015 Ericsson 6 M. Tuexen 7 Muenster Univ. of Appl. Sciences 8 January 4, 2015 10 WebRTC Data Channel Establishment Protocol 11 draft-ietf-rtcweb-data-protocol-09.txt 13 Abstract 15 The WebRTC framework specifies protocol support for direct 16 interactive rich communication using audio, video, and data between 17 two peers' web-browsers. This document specifies a simple protocol 18 for establishing symmetric Data Channels between the peers. It uses 19 a two way handshake and allows sending of user data without waiting 20 for the handshake to complete. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 8, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. DATA_CHANNEL_OPEN Message . . . . . . . . . . . . . . . . 4 62 5.2. DATA_CHANNEL_ACK Message . . . . . . . . . . . . . . . . 7 63 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8.1. SCTP Payload Protocol Identifier . . . . . . . . . . . . 9 67 8.2. New Standalone Registry for the DCEP . . . . . . . . . . 9 68 8.2.1. New Message Type Registry . . . . . . . . . . . . . . 9 69 8.2.2. New Channel Type Registry . . . . . . . . . . . . . . 10 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 10.2. Informational References . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The Data Channel Establishment Protocol (DCEP) is designed to 79 provide, in the WebRTC Data Channel context 80 [I-D.ietf-rtcweb-data-channel], a simple in-band method to open 81 symmetric Data Channels. As discussed in 82 [I-D.ietf-rtcweb-data-channel], the protocol uses the Stream Control 83 Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram 84 Transport Layer Security (DTLS) as described in 85 [I-D.ietf-tsvwg-sctp-dtls-encaps] to benefit from their already 86 standardized transport and security features. DTLS 1.0 is defined in 87 [RFC4347] and the present latest version, DTLS 1.2, is defined in 88 [RFC6347]. 90 2. Conventions 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Terminology 98 This document uses the following terms: 100 Association: An SCTP association. 102 Stream: A unidirectional stream of an SCTP association. It is 103 uniquely identified by an SCTP stream identifier (0-65534). Note: 104 the SCTP stream identifier 65535 is reserved due to SCTP INIT and 105 INIT-ACK chunks only allowing a maximum of 65535 Streams to be 106 negotiated (0-65534). 108 Stream Identifier: The SCTP stream identifier uniquely identifying a 109 Stream. 111 Data Channel: Two Streams with the same Stream Identifier, one in 112 each direction, which are managed together. 114 4. Protocol Overview 116 The Data Channel Establishment Protocol is a simple, low-overhead way 117 to establish bidirectional Data Channels over an SCTP association 118 with a consistent set of properties. 120 The set of consistent properties includes: 122 o reliable or unreliable message transmission. In case of 123 unreliable transmissions, the same level of unreliability is used. 125 o in-order or out-of-order message delivery. 127 o the priority of the Data Channel. 129 o an optional label for the Data Channel. 131 o an optional protocol for the Data Channel. 133 o the Streams. 135 This protocol uses a two way handshake to open a Data Channel. The 136 handshake pairs one incoming and one outgoing Stream, both having the 137 same Stream Identifier, into a single bidirectional Data Channel. 138 The peer that initiates opening a Data Channel selects a Stream 139 Identifier for which the corresponding incoming and outgoing Streams 140 are unused and sends a DATA_CHANNEL_OPEN message on the outgoing 141 Stream. The peer responds with a DATA_CHANNEL_ACK message on its 142 corresponding outgoing Stream. Then the Data Channel is open. Data 143 Channel Establishment Protocol messages are sent on the same Stream 144 as the user messages belonging to the Data Channel. The 145 demultiplexing is based on the SCTP payload protocol identifier 146 (PPID), since the Data Channel Establishment Protocol uses a specific 147 PPID. 149 Note: The opening side MAY send user messages before the 150 DATA_CHANNEL_ACK is received. 152 To avoid collisions where both sides try to open a Data Channel with 153 the same Stream Identifiers, each side MUST use Streams with either 154 even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN 155 message. When using SCTP over DTLS 156 [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which 157 side uses odd or even is based on the underlying DTLS connection 158 role: the side acting as the DTLS client MUST use Streams with even 159 Stream Identifiers, the side acting as the DTLS server MUST use 160 Streams with odd Stream Identifiers. 162 Note: There is no attempt to ensure uniqueness for the label; if both 163 sides open a Data Channel labeled "x" at the same time, there will be 164 two Data Channels labeled "x" - one on an even Stream pair, one on an 165 odd pair. 167 The protocol field is to ease cross-application interoperation 168 ("federation") by identifying the user data being passed with an 169 IANA-registered string ('WebSocket Subprotocol Name Registry' defined 170 in [RFC6455]), and may be useful for homogeneous applications which 171 may create more than one type of Data Channel. Please note that 172 there is also no attempt to ensure uniqueness for the protocol field. 174 5. Message Formats 176 Every Data Channel Establishment Protocol message starts with a one 177 byte field called "Message Type" which indicates the type of the 178 message. The corresponding values are managed by IANA (see 179 Section 8.2.1). 181 5.1. DATA_CHANNEL_OPEN Message 183 This message is sent initially on the Stream used for user messages 184 using the Data Channel. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Message Type | Channel Type | Priority | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Reliability Parameter | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Label Length | Protocol Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 \ / 196 | Label | 197 / \ 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 \ / 200 | Protocol | 201 / \ 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Message Type: 1 byte (unsigned integer) 205 This field holds the IANA defined message type for the 206 DATA_CHANNEL_OPEN message. The value of this field is 0x03 as 207 specified in Section 8.2.1. 209 Channel Type: 1 byte (unsigned integer) 210 This field specifies the type of the Data Channel to be opened and 211 the values are managed by IANA (see Section 8.2.2): 213 DATA_CHANNEL_RELIABLE (0x00): The Data Channel provides a 214 reliable in-order bi-directional communication. 216 DATA_CHANNEL_RELIABLE_UNORDERED (0x80): The Data Channel provides 217 a reliable unordered bi-directional communication. 219 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01): The Data Channel 220 provides a partially-reliable in-order bi-directional 221 communication. User messages will not be retransmitted more 222 times than specified in the Reliability Parameter. 224 DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED (0x81): The Data 225 Channel provides a partial reliable unordered bi-directional 226 communication. User messages will not be retransmitted more 227 times than specified in the Reliability Parameter. 229 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02): The Data Channel 230 provides a partial reliable in-order bi-directional 231 communication. User messages might not be transmitted or 232 retransmitted after a specified life-time given in milli- 233 seconds in the Reliability Parameter. This life-time starts 234 when providing the user message to the protocol stack. 236 DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED (0x82): The Data 237 Channel provides a partial reliable unordered bi-directional 238 communication. User messages might not be transmitted or 239 retransmitted after a specified life-time given in milli- 240 seconds in the Reliability Parameter. This life-time starts 241 when providing the user message to the protocol stack. 243 Priority: 2 bytes (unsigned integer) 244 The priority of the Data Channel as described in 245 [I-D.ietf-rtcweb-data-channel]. 247 Reliability Parameter: 4 bytes (unsigned integer) 248 For reliable Data Channels this field MUST be set to 0 on the 249 sending side and MUST be ignored on the receiving side. If a 250 partial reliable Data Channel with limited number of 251 retransmissions is used, this field specifies the number of 252 retransmissions. If a partial reliable Data Channel with limited 253 lifetime is used, this field specifies the maximum lifetime in 254 milliseconds. The following table summarizes this: 256 +------------------------------------------------+------------------+ 257 | Channel Type | Reliability | 258 | | Parameter | 259 +------------------------------------------------+------------------+ 260 | DATA_CHANNEL_RELIABLE | Ignored | 261 | DATA_CHANNEL_RELIABLE_UNORDERED | Ignored | 262 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | Number of RTX | 263 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | Number of RTX | 264 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | Lifetime in ms | 265 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | Lifetime in ms | 266 +------------------------------------------------+------------------+ 268 Label Length: 2 bytes (unsigned integer) 269 The length of the label field in bytes. 271 Protocol Length: 2 bytes (unsigned integer) 272 The length of the protocol field in bytes. 274 Label: Variable Length (sequence of characters) 275 The name of the Data Channel as a UTF-8 encoded string as 276 specified in [RFC3629]. This may be an empty string. 278 Protocol: Variable Length (sequence of characters) 279 If this is an empty string the protocol is unspecified. If it is 280 a non-empty string, it specifies a protocol registered in the 281 'WebSocket Subprotocol Name Registry' created in [RFC6455]. This 282 string is UTF-8 encoded as specified in [RFC3629]. 284 5.2. DATA_CHANNEL_ACK Message 286 This message is sent in response to a DATA_CHANNEL_OPEN_RESPONSE 287 message on the stream used for user messages using the Data Channel. 288 Reception of this message tells the opener that the Data Channel 289 setup handshake is complete. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Message Type | 295 +-+-+-+-+-+-+-+-+ 297 Message Type: 1 byte (unsigned integer) 298 This field holds the IANA defined message type for the 299 DATA_CHANNEL_ACK message. The value of this field is 0x02 as 300 specified in Section 8.2.1. 302 6. Procedures 304 All Data Channel Establishment Protocol messages MUST be sent using 305 ordered delivery and reliable transmission. They MUST be sent on the 306 same outgoing Stream as the user messages belonging to the 307 corresponding Data Channel. Multiplexing and demultiplexing is done 308 by using the SCTP payload protocol identifier (PPID). Therefore Data 309 Channel Establishment Protocol message MUST be sent with the assigned 310 PPID for the Data Channel Establishment Protocol (see Section 8.1). 311 Other messages MUST NOT be sent using this PPID. 313 The peer that initiates opening a Data Channel selects a Stream 314 Identifier for which the corresponding incoming and outgoing Streams 315 are unused. If the side is the DTLS client, it MUST choose an even 316 Stream Identifier, if the side is the DTLS server, it MUST choose an 317 odd one. It fills in the parameters of the DATA_CHANNEL_OPEN message 318 and sends it on the chosen Stream. 320 If a DATA_CHANNEL_OPEN message is received on an unused Stream, the 321 Stream Identifier corresponds to the role of the peer and all 322 parameters in the DATA_CHANNEL_OPEN message are valid, then a 323 corresponding DATA_CHANNEL_ACK message is sent on the Stream with the 324 same Stream Identifier as the one the DATA_CHANNEL_OPEN message was 325 received on. 327 If the DATA_CHANNEL_OPEN message doesn't satisfy the conditions 328 above, for instance if a DATA_CHANNEL_OPEN message is received on an 329 already used Stream or there are any problems with parameters within 330 the DATA_CHANNEL_OPEN message, the odd/even rule is violated or the 331 DATA_CHANNEL_OPEN message itself is not well-formed, the receiver 332 MUST close the corresponding Data Channel using the procedure 333 described in [I-D.ietf-rtcweb-data-channel] and MUST NOT send a 334 DATA_CHANNEL_ACK message in response to the received message. 335 Therefore, receiving an SCTP stream reset request for a Stream on 336 which no DATA_CHANNEL_ACK message has been received indicates to the 337 sender of the corresponding DATA_CHANNEL_OPEN message the failure of 338 the Data Channel setup procedure. After also successfully resetting 339 the corresponding outgoing Stream, which concludes the Data Channel 340 closing initiated by the peer, a new DATA_CHANNEL_OPEN message can be 341 sent on the Stream. 343 After the DATA_CHANNEL_OPEN message has been sent, the sender of the 344 DATA_CHANNEL_OPEN MAY start sending messages containing user data 345 without waiting for the reception of the corresponding 346 DATA_CHANNEL_ACK message. However, before the DATA_CHANNEL_ACK 347 message or any other message has been received on a Data Channel, all 348 other messages containing user data and belonging to this Data 349 Channel MUST be sent ordered, no matter whether the Data Channel is 350 ordered or not. After the DATA_CHANNEL_ACK or any other message has 351 been received on the Data Channel, messages containing user data MUST 352 be sent ordered on ordered Data Channels and MUST be sent unordered 353 on unordered Data Channels. Therefore receiving a message containing 354 user data on an unused Stream indicates an error. The corresponding 355 Data Channel MUST be closed as described in 356 [I-D.ietf-rtcweb-data-channel]. 358 7. Security Considerations 360 The DATA_CHANNEL_OPEN messages contains two variable length fields: 361 the protocol and the label. A receiver must be prepared to receive 362 DATA_CHANNEL_OPEN messages where these field have the maximum length 363 of 65535 bytes. Error cases like the use of inconsistent lengths 364 fields, unknown parameter values or violation the odd/even rule must 365 also be handled by closing the corresponding Data Channel. An end- 366 point must also be prepared that the peer open the maximum number of 367 Data Channels. 369 This protocol does not provide privacy, integrity or authentication. 370 It needs to be used as part of a protocol suite that contains all 371 these things. Such a protocol suite is specified in 372 [I-D.ietf-tsvwg-sctp-dtls-encaps]. 374 For general considerations see [I-D.ietf-rtcweb-security] and 375 [I-D.ietf-rtcweb-security-arch]. 377 8. IANA Considerations 379 [NOTE to RFC-Editor: 381 "RFCXXXX" is to be replaced by the RFC number you assign this 382 document. 384 ] 386 IANA is asked to update the reference of an already existing SCTP 387 PPID assignment (Section 8.1) and to create a new standalone registry 388 with its own URL for the DCEP (Section 8.2) containing two new 389 registration tables (Section 8.2.1 and Section 8.2.2). 391 8.1. SCTP Payload Protocol Identifier 393 This document uses one already registered SCTP Payload Protocol 394 Identifier (PPID) named "WebRTC Control". [RFC4960] creates the 395 registry "SCTP Payload Protocol Identifiers" from which this 396 identifier was assigned. IANA is requested to update the reference 397 of this assignment to point to this document and to update the name. 398 The corresponding date should be kept. 400 Therefore this assignment should be updated to read: 402 +-------------+-----------+-----------+------------+ 403 | Value | SCTP PPID | Reference | Date | 404 +-------------+-----------+-----------+------------+ 405 | WebRTC DCEP | 50 | [RFCXXXX] | 2013-09-20 | 406 +-------------+-----------+-----------+------------+ 408 8.2. New Standalone Registry for the DCEP 410 IANA is requested to create a new standalone registry (aka a webpage) 411 with its own URL for the Data Channel Establishment Protocol (DCEP). 412 The title should be "Data Channel Establishment Protocol (DCEP) 413 Parameters". It will contain the two tables as described in 414 Section 8.2.1 and Section 8.2.2. 416 8.2.1. New Message Type Registry 418 IANA is requested to create a new registration table "Message Type 419 Registry" for the Data Channel Establishment Protocol (DCEP) to 420 manage the one byte "Message Type" field in DCEP messages (see 421 Section 5). This registration table should be part of the registry 422 described in Section 8.2. 424 The assignment of new message types is done through an RFC required 425 action, as defined in [RFC5226]. Documentation of the new message 426 type MUST contain the following information: 428 1. A name for the new message type; 430 2. A detailed procedural description of the use of messages with the 431 new type within the operation of the Data Channel Establishment 432 Protocol. 434 Initially the following values need to be registered: 436 +-------------------+-----------+-----------+ 437 | Name | Type | Reference | 438 +-------------------+-----------+-----------+ 439 | Reserved | 0x00 | [RFCXXXX] | 440 | Reserved | 0x01 | [RFCXXXX] | 441 | DATA_CHANNEL_ACK | 0x02 | [RFCXXXX] | 442 | DATA_CHANNEL_OPEN | 0x03 | [RFCXXXX] | 443 | Unassigned | 0x04-0xfe | | 444 | Reserved | 0xff | [RFCXXXX] | 445 +-------------------+-----------+-----------+ 447 Please note that the values 0x00 and 0x01 are reserved to avoid 448 interoperability problems, since they have been used in earlier 449 versions of the document. The value 0xff has been reserved for 450 future extensibility. The range of possible values is from 0x00 to 451 0xff. 453 8.2.2. New Channel Type Registry 455 IANA is requested to create a new registration table "Channel Type 456 Registry" for the Data Channel Establishment Protocol to manage the 457 one byte "Channel Type" field in DATA_CHANNEL_OPEN messages (see 458 Section 5.1). This registration table should be part of the registry 459 described in Section 8.2. 461 The assignment of new message types is done through an RFC required 462 action, as defined in [RFC5226]. Documentation of the new Channel 463 Type MUST contain the following information: 465 1. A name for the new Channel Type; 467 2. A detailed procedural description of the user message handling 468 for Data Channels using this new Channel Type. 470 Please note that if new Channel Types support ordered and unordered 471 message delivery, the high order bit MUST be used to indicate whether 472 the message delivery is unordered or not. 474 Initially the following values need to be registered: 476 +------------------------------------------------+------+-----------+ 477 | Name | Type | Reference | 478 +------------------------------------------------+------+-----------+ 479 | DATA_CHANNEL_RELIABLE | 0x00 | [RFCXXXX] | 480 | DATA_CHANNEL_RELIABLE_UNORDERED | 0x80 | [RFCXXXX] | 481 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT | 0x01 | [RFCXXXX] | 482 | DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED | 0x81 | [RFCXXXX] | 483 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED | 0x02 | [RFCXXXX] | 484 | DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED | 0x82 | [RFCXXXX] | 485 | Reserved | 0x7f | [RFCXXXX] | 486 | Reserved | 0xff | [RFCXXXX] | 487 | Unassigned | rest | | 488 +------------------------------------------------+------+-----------+ 490 Please note that the values 0x7f and 0xff have been reserved for 491 future extensibility. The range of possible values is from 0x00 to 492 0xff. 494 9. Acknowledgments 496 The authors wish to thank Harald Alvestrand, Richard Barnes, Adam 497 Bergkvist, Spencer Dawkins, Barry Dingle, Stefan Haekansson, Cullen 498 Jennings, Paul Kyzivat, Doug Leonard, Alexey Melnikov, Pete Resnick, 499 Irene Ruengeler, Randall Stewart, Peter Thatcher, Martin Thompson, 500 Justin Uberti, and many others for their invaluable comments. 502 10. References 504 10.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 510 10646", STD 63, RFC 3629, November 2003. 512 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 513 Security", RFC 4347, April 2006. 515 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 516 4960, September 2007. 518 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 519 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 520 May 2008. 522 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 523 Security Version 1.2", RFC 6347, January 2012. 525 [I-D.ietf-tsvwg-sctp-dtls-encaps] 526 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 527 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 528 dtls-encaps-07 (work in progress), December 2014. 530 [I-D.ietf-rtcweb-data-channel] 531 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 532 Channels", draft-ietf-rtcweb-data-channel-12 (work in 533 progress), September 2014. 535 10.2. Informational References 537 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 538 6455, December 2011. 540 [I-D.ietf-rtcweb-security] 541 Rescorla, E., "Security Considerations for WebRTC", draft- 542 ietf-rtcweb-security-07 (work in progress), July 2014. 544 [I-D.ietf-rtcweb-security-arch] 545 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 546 rtcweb-security-arch-10 (work in progress), July 2014. 548 Authors' Addresses 550 Randell Jesup 551 Mozilla 552 US 554 Email: randell-ietf@jesup.org 556 Salvatore Loreto 557 Ericsson 558 Hirsalantie 11 559 Jorvas 02420 560 FI 562 Email: salvatore.loreto@ericsson.com 563 Michael Tuexen 564 Muenster University of Applied Sciences 565 Stegerwaldstrasse 39 566 Steinfurt 48565 567 DE 569 Email: tuexen@fh-muenster.de