diff options
Diffstat (limited to 'doc/rfc/rfc8850.txt')
| -rw-r--r-- | doc/rfc/rfc8850.txt | 465 |
1 files changed, 465 insertions, 0 deletions
diff --git a/doc/rfc/rfc8850.txt b/doc/rfc/rfc8850.txt new file mode 100644 index 0000000..e5a1e11 --- /dev/null +++ b/doc/rfc/rfc8850.txt @@ -0,0 +1,465 @@ + + + + +Internet Engineering Task Force (IETF) C. Holmberg +Request for Comments: 8850 Ericsson +Category: Experimental January 2021 +ISSN: 2070-1721 + + + Controlling Multiple Streams for Telepresence (CLUE) Protocol + Data Channel + +Abstract + + This document defines how to use the WebRTC data channel mechanism to + realize a data channel, referred to as a Controlling Multiple Streams + for Telepresence (CLUE) data channel, for transporting CLUE protocol + messages between two CLUE entities. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8850. + +Copyright Notice + + Copyright (c) 2021 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions + 3. CLUE Data Channel + 3.1. General + 3.2. SCTP Considerations + 3.2.1. General + 3.2.2. SCTP Payload Protocol Identifier (PPID) + 3.2.3. Reliability + 3.2.4. Order + 3.2.5. Stream Reset + 3.2.6. SCTP Multihoming + 3.2.7. Closing the CLUE Data Channel + 3.3. SDP Considerations + 3.3.1. General + 3.3.2. SDP dcmap Attribute + 3.3.3. SDP dcsa Attribute + 3.3.4. Example + 4. Security Considerations + 5. IANA Considerations + 5.1. Subprotocol Identifier "clue" + 6. References + 6.1. Normative References + 6.2. Informative References + Acknowledgements + Author's Address + +1. Introduction + + This document defines how to use the WebRTC data channel mechanism + [RFC8831] to realize a data channel, referred to as a Controlling + Multiple Streams for Telepresence (CLUE) data channel, for + transporting CLUE protocol messages [RFC8847] between two CLUE + entities. + + This document also defines how to describe the SCTPoDTLS association + [RFC8261] (also referred to as "SCTP over DTLS" in this document) + used to realize the CLUE data channel using the Session Description + Protocol (SDP) [RFC4566] and defines usage of the SDP-based "SCTP + over DTLS" data channel negotiation mechanism [RFC8864]. ("SCTP" + stands for "Stream Control Transmission Protocol".) This includes + SCTP considerations specific to a CLUE data channel, the SDP media + description ("m=" line) values, and usage of SDP attributes specific + to a CLUE data channel. + + Details and procedures associated with the CLUE protocol, and the SDP + Offer/Answer procedures [RFC3264] for negotiating usage of a CLUE + data channel, are outside the scope of this document. + + | NOTE: The usage of the Data Channel Establishment Protocol + | (DCEP) [RFC8832] for establishing a CLUE data channel is + | outside the scope of this document. + +2. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + SCTPoDTLS association + Refers to an SCTP association carried over a DTLS connection + [RFC8261]. + + WebRTC data channel + Refers to a pair of SCTP streams over an SCTPoDTLS association + that is used to transport non-media data between two entities, as + defined in [RFC8831]. + + CLUE data channel + Refers to a WebRTC data channel realization [RFC8831], with a + specific set of SCTP characteristics, with the purpose of + transporting CLUE protocol messages [RFC8847] between two CLUE + entities. + + CLUE entity + Refers to a SIP User Agent (UA) [RFC3261] that supports the CLUE + data channel and the CLUE protocol. + + CLUE session + Refers to a SIP session [RFC3261] between two SIP UAs, where a + CLUE data channel, associated with the SIP session, has been + established between the SIP UAs. + + SCTP stream + Defined in [RFC4960] as a unidirectional logical channel + established from one to another associated SCTP endpoint, within + which all user messages are delivered in sequence except for those + submitted to the unordered delivery service. + + SCTP stream identifier + Defined in [RFC4960] as an unsigned integer. Identifies an SCTP + stream. + +3. CLUE Data Channel + +3.1. General + + This section describes the realization of a CLUE data channel, using + the WebRTC data channel mechanism. This includes a set of SCTP + characteristics specific to a CLUE data channel, the values of the + "m=" line describing the SCTPoDTLS association associated with the + WebRTC data channel, and the usage of the SDP-based "SCTP over DTLS" + data channel negotiation mechanism for creating the CLUE data + channel. + + As described in [RFC8831], the SCTP streams realizing a WebRTC data + channel must be associated with the same SCTP association. In + addition, both SCTP streams realizing the WebRTC data channel must + use the same SCTP stream identifier value. These rules also apply to + a CLUE data channel. + + Within a given CLUE session, a CLUE entity MUST use a single CLUE + data channel for transport of all CLUE messages towards its peer. + +3.2. SCTP Considerations + +3.2.1. General + + As described in [RFC8831], different SCTP options (e.g., regarding + ordered delivery) can be used for a data channel. This section + describes the SCTP options used for a CLUE data channel. Section 3.3 + describes how SCTP options are signaled using SDP. + +3.2.2. SCTP Payload Protocol Identifier (PPID) + + A CLUE entity MUST use the PPID value 51 when sending a CLUE message + on a CLUE data channel. + + | NOTE: As described in [RFC8831], the PPID value 51 indicates + | that the SCTP message contains data encoded in UTF-8 format. + | The PPID value 51 does not indicate which application protocol + | the SCTP message is associated with -- only the format in which + | the data is encoded. + +3.2.3. Reliability + + The usage of SCTP for the CLUE data channel ensures reliable + transport of CLUE protocol messages [RFC8847]. + + [RFC8831] requires the support of the partial reliability extension + defined in [RFC3758] and the limited retransmission policy defined in + [RFC7496]. A CLUE entity MUST NOT use these extensions, as messages + are required to always be sent reliably. A CLUE entity MUST + terminate the session if it detects that the peer entity uses any of + the extensions. + +3.2.4. Order + + A CLUE entity MUST use the ordered delivery SCTP service, as + described in [RFC4960], for the CLUE data channel. + +3.2.5. Stream Reset + + A CLUE entity MUST support the stream reset extension defined in + [RFC6525]. + + Per [RFC8831], the dynamic address reconfiguration extension + parameter ('Supported Extensions Parameter') defined in [RFC5061] + must be used to signal the support of the stream reset extension + defined in [RFC6525]. Other features defined in [RFC5061] MUST NOT + be used for CLUE data channels. + +3.2.6. SCTP Multihoming + + SCTP multihoming is not supported for SCTPoDTLS associations and + therefore cannot be used for a CLUE data channel. + +3.2.7. Closing the CLUE Data Channel + + As described in [RFC8831], to close a data channel, an entity sends + an SCTP reset message [RFC6525] on its outgoing SCTP stream + associated with the data channel. When the remote peer receives the + reset message, it also sends (unless already sent) a reset message on + its outgoing SCTP stream associated with the data channel. The + SCTPoDTLS association, and other data channels established on the + same association, are not affected by the SCTP reset messages. + +3.3. SDP Considerations + +3.3.1. General + + This section defines how to (1) construct the SDP media description + ("m=" line) for describing the SCTPoDTLS association used to realize + a CLUE data channel and (2) use the SDP-based "SCTP over DTLS" data + channel negotiation mechanism [RFC8864] for establishing a CLUE data + channel on the SCTPoDTLS association. + + | NOTE: Protocols other than SDP for negotiating usage of an + | SCTPoDTLS association for realizing a CLUE data channel are + | outside the scope of this specification. + + [RFC8848] describes the SDP Offer/Answer procedures for negotiating a + CLUE session, including the CLUE-controlled media streams and the + CLUE data channel. + +3.3.1.1. SDP Media Description Fields + + [RFC8841] defines how to set the values of an "m=" line describing an + SCTPoDTLS association. As defined in [RFC8841], for a CLUE data + channel the values are set as follows: + + +===============+==========+============+======================+ + | media | port | proto | fmt | + +===============+==========+============+======================+ + | "application" | UDP port | "UDP/DTLS/ | "webrtc-datachannel" | + | | value | SCTP" | | + +---------------+----------+------------+----------------------+ + | "application" | TCP port | "TCP/DTLS/ | "webrtc-datachannel" | + | | value | SCTP" | | + +---------------+----------+------------+----------------------+ + + Table 1: SDP "proto" Field Values + + CLUE entities SHOULD NOT transport the SCTPoDTLS association used to + realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" + proto value), unless it is known that UDP/DTLS/SCTP will not work + (for instance, when the Interactive Connectivity Establishment (ICE) + mechanism [RFC8445] is used and the ICE procedures determine that TCP + transport is required). + +3.3.1.2. SDP sctp-port Attribute + + As defined in [RFC8841], the SDP sctp-port attribute value is set to + the SCTP port of the SCTPoDTLS association. A CLUE entity can choose + any valid SCTP port value [RFC8841]. + +3.3.2. SDP dcmap Attribute + + The values of the SDP dcmap attribute [RFC8864], associated with the + "m=" line describing the SCTPoDTLS association used to realize the + WebRTC data channel, are set as follows: + + +===========+=============+=============+=======+========+==========+ + | stream-id | subprotocol | label |ordered|max-retr| max-time | + +===========+=============+=============+=======+========+==========+ + | Value of | "CLUE" | Application | "true"| N/A | N/A | + | the SCTP | | specific | | | | + |stream used| | | | | | + | to realize| | | | | | + | the CLUE | | | | | | + | data | | | | | | + | channel | | | | | | + +-----------+-------------+-------------+-------+--------+----------+ + + Table 2: SDP dcmap Attribute Values + + | NOTE: As CLUE entities are required to use ordered SCTP message + | delivery, with full reliability, according to the procedures in + | [RFC8864] the max-retr and max-time attribute parameters are + | not used when negotiating CLUE data channels. + +3.3.3. SDP dcsa Attribute + + The SDP dcsa attribute [RFC8864] is not used when establishing a CLUE + data channel. + +3.3.4. Example + + The example in Figure 1 shows an SDP media description for a CLUE + data channel. Complete SDP examples can be found in [RFC8848]. + + m=application 54111 UDP/DTLS/SCTP webrtc-datachannel + a=sctp-port: 5000 + a=dcmap:2 subprotocol="CLUE";ordered=true + + Figure 1: SDP Media Description for a CLUE Data Channel + +4. Security Considerations + + This specification relies on the security properties of the WebRTC + data channel described in [RFC8831], including reliance on DTLS. + Since CLUE sessions are established using SIP/SDP, protecting the + data channel against message modification and recovery requires the + use of SIP authentication and authorization mechanisms described in + [RFC3261] for session establishment prior to establishing the data + channel. + +5. IANA Considerations + +5.1. Subprotocol Identifier "clue" + + This document adds the subprotocol identifier "clue" to the + "WebSocket Subprotocol Name Registry" as follows: + + +-------------------------+----------+ + | Subprotocol Identifier | clue | + +-------------------------+----------+ + | Subprotocol Common Name | CLUE | + +-------------------------+----------+ + | Subprotocol Definition | RFC 8850 | + +-------------------------+----------+ + | Reference | RFC 8850 | + +-------------------------+----------+ + + Table 3: Registration of 'clue' Value + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + DOI 10.17487/RFC3261, June 2002, + <https://www.rfc-editor.org/info/rfc3261>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. + Kozuka, "Stream Control Transmission Protocol (SCTP) + Dynamic Address Reconfiguration", RFC 5061, + DOI 10.17487/RFC5061, September 2007, + <https://www.rfc-editor.org/info/rfc5061>. + + [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control + Transmission Protocol (SCTP) Stream Reconfiguration", + RFC 6525, DOI 10.17487/RFC6525, February 2012, + <https://www.rfc-editor.org/info/rfc6525>. + + [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, + "Additional Policies for the Partially Reliable Stream + Control Transmission Protocol Extension", RFC 7496, + DOI 10.17487/RFC7496, April 2015, + <https://www.rfc-editor.org/info/rfc7496>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, + "Datagram Transport Layer Security (DTLS) Encapsulation of + SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November + 2017, <https://www.rfc-editor.org/info/rfc8261>. + + [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data + Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, + <https://www.rfc-editor.org/info/rfc8831>. + + [RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, + "Session Description Protocol (SDP) Offer/Answer + Procedures for Stream Control Transmission Protocol (SCTP) + over Datagram Transport Layer Security (DTLS) Transport", + RFC 8841, DOI 10.17487/RFC8841, January 2021, + <https://www.rfc-editor.org/info/rfc8841>. + + [RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. + Even, Ed., "Negotiation Data Channels Using the Session + Description Protocol (SDP)", RFC 8864, + DOI 10.17487/RFC8864, January 2021, + <https://www.rfc-editor.org/info/rfc8864>. + +6.2. Informative References + + [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. + Conrad, "Stream Control Transmission Protocol (SCTP) + Partial Reliability Extension", RFC 3758, + DOI 10.17487/RFC3758, May 2004, + <https://www.rfc-editor.org/info/rfc3758>. + + [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive + Connectivity Establishment (ICE): A Protocol for Network + Address Translator (NAT) Traversal", RFC 8445, + DOI 10.17487/RFC8445, July 2018, + <https://www.rfc-editor.org/info/rfc8445>. + + [RFC8832] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel + Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832, + January 2021, <https://www.rfc-editor.org/info/rfc8832>. + + [RFC8847] Presta, R. and S P. Romano, "Protocol for Controlling + Multiple Streams for Telepresence (CLUE)", RFC 8847, + DOI 10.17487/RFC8847, January 2021, + <https://www.rfc-editor.org/info/rfc8847>. + + [RFC8848] Hanton, R., Kyzivat, P., Xiao, L., and C. Groves, "Session + Signaling for Controlling Multiple Streams for + Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848, + January 2021, <https://www.rfc-editor.org/info/rfc8848>. + +Acknowledgements + + Thanks to Paul Kyzivat, Christian Groves, and Mark Duckworth for + comments on this document. + +Author's Address + + Christer Holmberg + Ericsson + Hirsalantie 11 + FI-02420 Jorvas + Finland + + Email: christer.holmberg@ericsson.com |