rfc8857xml2.original.xml   rfc8857.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
which is available here: http://xml.resource.org. --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ docName="draft-ietf-bfcpbis-bfcp-websocket-15" number="8857" ipr="trust200902" o
<!-- One method to get references from the online citation libraries. bsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" toc
There has to be one entity for each item to be referenced. Depth="4" symRefs="true" sortRefs="true" version="3">
An alternate method (rfc include) is described in the references. -->
<!-- Normative References -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!-- MUST, SHOULD, MAY -->
<!ENTITY RFC7235 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7235.xml">
<!-- HTTP Over TLS -->
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3261.xml">
<!-- SIP -->
<!ENTITY RFC3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3263.xml">
<!-- Locating SIP Servers -->
<!ENTITY RFC3403 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3403.xml">
<!-- NAPTR -->
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5234.xml">
<!-- ABNF -->
<!ENTITY RFC6455 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6455.xml">
<!-- WebSocket -->
<!ENTITY RFC7525 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7525.xml">
<!-- Recommendations for TLS -->
<!ENTITY RFC5018 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5018.xml">
<!-- TCP -->
<!ENTITY RFC4582 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4582.xml">
<!-- BFCP -->
<!ENTITY RFC4583 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4583.xml">
<!-- BFCP SDP -->
<!ENTITY BFCPbis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-
D.ietf-bfcpbis-rfc4582bis.xml">
<!-- rfc4582bis -->
<!ENTITY SDPBFCPbis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference
.I-D.ietf-bfcpbis-rfc4583bis.xml">
<!-- rfc4583bis -->
<!-- Informative References -->
<!ENTITY RFC2606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2606.xml">
<!-- Reserved Top Level DNS Names -->
<!ENTITY RFC7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7230.xml">
<!ENTITY RFC7616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7616.xml">
<!ENTITY RFC7617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7617.xml">
<!ENTITY RFC7486 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7486.xml">
<!-- HTTP -->
<!ENTITY RFC3327 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3327.xml">
<!-- Path -->
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3986.xml">
<!-- URI -->
<!ENTITY RFC4168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4168.xml">
<!-- SIP STCP -->
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5246.xml">
<!-- TLS -->
<!ENTITY RFC5626 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5626.xml">
<!-- Outbound -->
<!ENTITY RFC5627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5627.xml">
<!-- GRUU -->
<!ENTITY RFC6223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6223.xml">
<!-- SUpport for Keep-Alive -->
<!ENTITY RFC6265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6265.xml">
<!-- HTTP State Management Mechanism -->
<!ENTITY RFC4145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4145.xml">
<!-- TCP-Based Media Transport in SDP -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc tocappendix="yes" ?>
<rfc category="std" docName="draft-ietf-bfcpbis-bfcp-websocket-15"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<!-- xml2rfc v2v3 conversion 2.35.0 -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="WebSocket as a Transport for BFCP">The WebSocket <title abbrev="WebSocket as a Transport for BFCP">The WebSocket
Protocol as a Transport for the Binary Floor Control Protocol Protocol as a Transport for the Binary Floor Control Protocol
(BFCP)</title> (BFCP)</title>
<seriesInfo name="RFC" value="8857"/>
<!-- add 'role="editor"' below for the editors if appropriate --> <author fullname="Victor Pascual" initials="V." surname="Pascual">
<organization>Nokia</organization>
<!-- Another author who claims to be an editor -->
<author fullname="Victor Pascual" initials="V.P."
surname="Pascual">
<organization>Genaker</organization>
<address> <address>
<postal> <postal>
<street/> <city>Barcelona</city>
<code/> <country>Spain</country>
<city>Barcelona</city> </postal>
<region/> <email>victor.pascual_avila@nokia.com</email>
<country>Spain</country>
</postal>
<email>victor.pascual@genaker.net</email>
</address> </address>
</author> </author>
<author fullname="Antón Román" initials="A." surname="Román">
<author fullname="Ant&oacute;n Rom&aacute;n" initials="A.R."
surname="Rom&aacute;n">
<organization>Quobis</organization> <organization>Quobis</organization>
<address> <address>
<postal>
<extaddr>Pol. Ind. A Granxa, Casa de Pedra</extaddr>
<city>O Porriño</city>
<code>36475</code>
<country>Spain</country>
</postal>
<email>anton.roman@quobis.com</email> <email>anton.roman@quobis.com</email>
</address> </address>
</author> </author>
<author fullname="Stéphane Cazeaux" initials="S." surname="Cazeaux">
<author fullname="St&eacute;phane Cazeaux" initials="S.C." <organization>Orange</organization>
surname="Cazeaux">
<organization>France Telecom Orange</organization>
<address> <address>
<postal>
<street>42 rue des Coutures</street>
<city>Caen</city>
<code>14000</code>
<country>France</country>
</postal>
<email>stephane.cazeaux@orange.com</email> <email>stephane.cazeaux@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro">
<author fullname="Gonzalo Salgueiro" initials="G.S."
surname="Salgueiro">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>7200-12 Kit Creek Road</street> <street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city> <city>Research Triangle Park</city>
<region>NC</region> <region>NC</region>
<code>27709</code> <code>27709</code>
<country>US</country> <country>US</country>
</postal> </postal>
<email>gsalguei@cisco.com</email> <email>gsalguei@cisco.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Ravindranath" fullname="Ram Mohan Ravindranat
<author initials="R" surname="Ravindranath" fullname="Ram Mohan Ravindranat h">
h"> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<organization abbrev="Cisco">Cisco Systems, Inc.</organiz <address>
ation> <postal>
<address> <extaddr>Cessna Business Park</extaddr>
<postal> <extaddr>Kadabeesanahalli Village, Varthur Hobli,</extaddr>
<street>Cessna Business Park,</street> <street>Sarjapur-Marathahalli Outer Ring Road</street>
<street>Kadabeesanahalli Village, Varthur <city>Bangalore</city>
Hobli,</street> <region>Karnataka</region>
<street>Sarjapur-Marathahalli Outer Ring <code>560103</code>
Road</street> <country>India</country>
<city>Bangalore</city> </postal>
<region>Karnataka</region> <email>rmohanr@cisco.com</email>
<code>560103</code> </address>
<country>India</country> </author>
</postal> <date month="May" year="2020"/>
<email>rmohanr@cisco.com</email>
</address>
</author>
<date year="2017"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current on
e, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not s
pecified for the
purpose of calculating the expiry date). With drafts it is normally su
fficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>IETF</area> <area>IETF</area>
<workgroup>BFCPBIS Working Group</workgroup> <workgroup>BFCPBIS Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>BFCP</keyword> <keyword>BFCP</keyword>
<keyword>WebSocket</keyword> <keyword>WebSocket</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t> The WebSocket protocol enables two-way realtime communication <t> The WebSocket protocol enables two-way real-time communication
between clients and servers. This document specifies the use of Binary Flo or between clients and servers. This document specifies the use of Binary Flo or
Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliabl e Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliabl e
transport mechanism between BFCP entities in new scenarios. </t> transport mechanism between BFCP entities in new scenarios. </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<t>The WebSocket(WS) <xref target="RFC6455"/> protocol enables <name>Introduction</name>
<t>The WebSocket (WS) protocol <xref target="RFC6455" format="default"/> e
nables
two-way message exchange between clients and servers on top of a two-way message exchange between clients and servers on top of a
persistent TCP connection, optionally secured with Transport Layer Securit y (TLS) persistent TCP connection, optionally secured with Transport Layer Securit y (TLS)
<xref target="RFC5246"/>. The initial protocol handshake makes use of <xref target="RFC8446" format="default"/>. The initial protocol handshake
Hypertext Transfer Protocol (HTTP) <xref target="RFC7230"/> semantics, all makes use of
owing the WebSocket Hypertext Transfer Protocol (HTTP) <xref target="RFC7230" format="default"
/> semantics, allowing the WebSocket
protocol to reuse existing HTTP infrastructure.</t> protocol to reuse existing HTTP infrastructure.</t>
<t>The Binary Floor Control Protocol (BFCP) is a protocol to <t>The Binary Floor Control Protocol (BFCP) is a protocol to
coordinate access to shared resources in a conference. It is coordinate access to shared resources in a conference. It is
defined in <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> and is defined in <xref target="RFC8855" format="default"/> and is
used between floor participants and floor control servers, and used between floor participants and floor control servers, and
between floor chairs (i.e., moderators) and floor control between floor chairs (i.e., moderators) and floor control
servers.</t> servers.</t>
<t>Modern web browsers include a WebSocket client stack <t>Modern web browsers include a WebSocket client stack
complying with the WebSocket API <xref target="WS-API"/> as complying with the WebSocket API <xref target="WS-API" format="default"/> as
specified by the W3C. It is expected that other client specified by the W3C. It is expected that other client
applications (those running in personal computers and devices applications (those running in personal computers and devices
such as smartphones) will also make a WebSocket client stack such as smartphones) will also make a WebSocket client stack
available. This document extends the applicability of available. This document extends the applicability of
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> and <xref target="RFC8855" format="default"/> and
<xref target="I-D.ietf-bfcpbis-rfc4583bis"/> to enable the <xref target="RFC8856" format="default"/> to enable the
usage of BFCP in these scenarios.</t> usage of BFCP in these scenarios.</t>
<t>The transport over which BFCP entities exchange messages <t>The transport over which BFCP entities exchange messages
depends on how the clients obtain information to contact the depends on how the clients obtain information to contact the
floor control server (e.g. using an Session Description Protocol (SDP) floor control server (e.g., using a Session Description Protocol (SDP)
offer/answer exchange per <xref target="I-D.ietf-bfcpbis-rfc4583bis"/> or offer/answer exchange per <xref target="RFC8856" format="default"/> or the
the procedure described in RFC 5018 <xref target="RFC5018" format="default"/>)
procedure described in RFC5018 <xref target="RFC5018"/>). .
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> defines two transports <xref target="RFC8855" format="default"/> defines two transports
for BFCP: TCP and UDP. This specification defines a new for BFCP: TCP and UDP. This specification defines a new
WebSocket sub-protocol (as defined in Section 1.9 in <xref WebSocket subprotocol (as defined in
target="RFC6455"/>) for transporting BFCP messages between a <xref target="RFC6455" section="1.9" sectionFormat="of" format="default"/>
WebSocket client and server. This sub-protocol provides a reliable and bou ) for transporting BFCP messages between a
ndary WebSocket client and server. This subprotocol provides a reliable and
preserving transport for BFCP when run on top of TCP. Since WebSocket prov boundary-preserving transport for BFCP when run on top of TCP. Since WebSo
ides cket provides
a reliable transport, the extensions defined in <xref a reliable transport, the extensions defined in <xref target="RFC8855" for
target="I-D.ietf-bfcpbis-rfc4582bis"/> for sending BFCP over unreliabl mat="default"/> for sending BFCP over unreliable
e
transports are not applicable. </t> transports are not applicable. </t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp1
"OPTIONAL" in this document are to be interpreted as described 4>",
in <xref target="RFC2119"/>.</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
/bcp14>",
<section anchor="definitions" title="Definitions"> "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTION
<t><list hangIndent="6" style="hanging"> AL</bcp14>"
<t hangText="BFCP WebSocket Client:">Any BFCP entity capable in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
<section anchor="definitions" numbered="true" toc="default">
<name>Definitions</name>
<dl newline="false" spacing="normal" indent="6">
<dt>BFCP WebSocket Client:</dt>
<dd>Any BFCP entity capable
of opening outbound connections to WebSocket servers and of opening outbound connections to WebSocket servers and
communicating using the WebSocket BFCP sub-protocol as communicating using the WebSocket BFCP subprotocol as
defined by this document.</t> defined by this document.</dd>
<dt>BFCP WebSocket Server:</dt>
<t hangText="BFCP WebSocket Server:">Any BFCP entity capable <dd>Any BFCP entity capable
of listening for inbound connections from WebSocket of listening for inbound connections from WebSocket
clients and communicating using the WebSocket BFCP clients and communicating using the WebSocket BFCP
sub-protocol as defined by this document.</t> subprotocol as defined by this document.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="the_websocket_protocol" numbered="true" toc="default">
<section anchor="the_websocket_protocol" <name>The WebSocket Protocol</name>
title="The WebSocket Protocol"> <t>The WebSocket protocol <xref target="RFC6455" format="default"/> is a
<t>The WebSocket protocol <xref target="RFC6455"/> is a transport layer on top of TCP (optionally secured with
transport layer on top of TCP (optionally secured with TLS <xref TLS <xref target="RFC8446" format="default"/>) in which both client and se
target="RFC5246"/>) in which both client and server exchange rver exchange
message units in both directions. The protocol defines a message units in both directions. The protocol defines a
connection handshake, WebSocket sub-protocol and extensions connection handshake, WebSocket subprotocol and extensions
negotiation, a frame format for sending application and control negotiation, a frame format for sending application and control
data, a masking mechanism, and status codes for indicating data, a masking mechanism, and status codes for indicating
disconnection causes.</t> disconnection causes.</t>
<t>The WebSocket connection handshake is based on
<t>The WebSocket connection handshake is based on HTTP <xref HTTP <xref target="RFC7230" format="default"/> and utilizes the HTTP GET m
target="RFC7230"/> and utilizes the HTTP GET method with an ethod with an
"Upgrade" request. This is sent by the client and then answered Upgrade header field. This is sent by the client and then answered
by the server (if the negotiation succeeded) with an HTTP 101 by the server (if the negotiation succeeded) with an HTTP 101
status code. Once the handshake is completed the connection status code. Once the handshake is completed, the connection
upgrades from HTTP to the WebSocket protocol. This handshake upgrades from HTTP to the WebSocket protocol. This handshake
procedure is designed to reuse the existing HTTP infrastructure. procedure is designed to reuse the existing HTTP infrastructure.
During the connection handshake, client and server agree on the During the connection handshake, the client and server agree on the
application protocol to use on top of the WebSocket transport. application protocol to use on top of the WebSocket transport.
Such an application protocol (also known as a "WebSocket Such an application protocol (also known as a "WebSocket
sub-protocol") defines the format and semantics of the messages subprotocol") defines the format and semantics of the messages
exchanged by the endpoints. This could be a custom protocol or a exchanged by the endpoints. This could be a custom protocol or a
standardized one (as the WebSocket BFCP sub-protocol defined in standardized one (as the WebSocket BFCP subprotocol defined in
this document). Once the HTTP 101 response is processed both this document). Once the HTTP 101 response is processed, both
client and server reuse the underlying TCP connection for the client and server reuse the underlying TCP connection for
sending WebSocket messages and control frames to each other. sending WebSocket messages and control frames to each other.
Unlike plain HTTP, this connection is persistent and can be used Unlike plain HTTP, this connection is persistent and can be used
for multiple message exchanges.</t> for multiple message exchanges.</t>
<t>The WebSocket protocol defines message units to be used by <t>The WebSocket protocol defines message units to be used by
applications for the exchange of data, so it provides a message applications for the exchange of data, so it provides a message
boundary-preserving transport layer.</t> boundary-preserving transport layer.</t>
</section> </section>
<section anchor="the_websocket_bfcp_subprotocol" numbered="true" toc="defaul
<section anchor="the_websocket_bfcp_subprotocol" t">
title="The WebSocket BFCP Sub-Protocol"> <name>The WebSocket BFCP Subprotocol</name>
<t>The term WebSocket sub-protocol refers to an <t>The term WebSocket subprotocol refers to an
application-level protocol layered on top of a WebSocket application-level protocol layered on top of a WebSocket
connection. This document specifies the WebSocket BFCP connection. This document specifies the WebSocket BFCP
sub-protocol for carrying BFCP messages over a WebSocket subprotocol for carrying BFCP messages over a WebSocket
connection.</t> connection.</t>
<section anchor="handshake" numbered="true" toc="default">
<section anchor="handshake" title="Handshake"> <name>Handshake</name>
<t>The BFCP WebSocket Client and BFCP WebSocket Server <t>The BFCP WebSocket client and BFCP WebSocket server
negotiate usage of the WebSocket BFCP sub-protocol during the negotiate usage of the WebSocket BFCP subprotocol during the
WebSocket handshake procedure as defined in Section 1.3 of WebSocket handshake procedure as defined in
<xref target="RFC6455"/>. The Client MUST include the value <xref target="RFC6455" section="1.3" sectionFormat="of" format="default"
"BFCP" in the Sec-WebSocket-Protocol header in its handshake />.
request. The 101 reply from the Server MUST contain "BFCP" in The client <bcp14>MUST</bcp14> include the value
its corresponding Sec-WebSocket-Protocol header.</t> "bfcp" in the Sec-WebSocket-Protocol header field in its handshake
request. The 101 reply from the server <bcp14>MUST</bcp14> contain "bfcp
" in
its corresponding Sec-WebSocket-Protocol header field.</t>
<t>Below is an example of a WebSocket handshake in which the <t>Below is an example of a WebSocket handshake in which the
Client requests the WebSocket BFCP sub-protocol support from client requests the WebSocket BFCP subprotocol support from
the Server:<figure> the server:</t>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
GET / HTTP/1.1 GET / HTTP/1.1
Host: bfcp-ws.example.com Host: bfcp-ws.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com Origin: http://www.example.com
Sec-WebSocket-Protocol: BFCP Sec-WebSocket-Protocol: bfcp
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
]]></artwork> ]]></artwork>
</figure></t> <t>The handshake response from the server accepting the
WebSocket BFCP subprotocol would look as follows:</t>
<t>The handshake response from the Server accepting the <artwork name="" type="" align="left" alt=""><![CDATA[
WebSocket BFCP sub-protocol would look as follows:<figure>
<artwork><![CDATA[
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: BFCP Sec-WebSocket-Protocol: bfcp
]]></artwork> ]]></artwork>
</figure></t>
<t>Once the negotiation has been completed, the WebSocket <t>Once the negotiation has been completed, the WebSocket
connection is established and can be used for the transport of connection is established and can be used for the transport of
BFCP messages. </t> BFCP messages. </t>
</section> </section>
<section anchor="bfcp_encoding" numbered="true" toc="default">
<section anchor="bfcp_encoding" title="BFCP Encoding"> <name>BFCP Encoding</name>
<t>BFCP messages use a TLV (Type-Length-Value) binary <t>BFCP messages use a TLV (Type-Length-Value) binary
encoding, therefore BFCP WebSocket Clients and BFCP WebSocket encoding, therefore BFCP WebSocket clients and BFCP WebSocket
Servers MUST be transported in unfragmented binary WebSocket servers <bcp14>MUST</bcp14> be transported in unfragmented binary WebSoc
frames (FIN:1,opcode:%x2) to exchange BFCP messages. The ket
WebSocket frame data MUST be a valid BCFP message, so the frames (FIN: 1, opcode: %x2) to exchange BFCP messages. The
length of the payload of the WebSocket frame MUST be lower WebSocket frame data <bcp14>MUST</bcp14> be a valid BFCP message, so the
than the maximum size allowed (2^16 +12 bytes) for a BCFP length of the payload of the WebSocket frame <bcp14>MUST</bcp14> be lowe
message as described in <xref r
target="I-D.ietf-bfcpbis-rfc4582bis"/>. In addition, the than the maximum size allowed (2<sup>16</sup> +12 bytes) for a BFCP
encoding rules for reliable protocols defined in <xref message as described in <xref target="RFC8855" format="default"/>. In ad
target="I-D.ietf-bfcpbis-rfc4582bis"/> MUST be followed.</t> dition, the
encoding rules for reliable protocols defined in <xref target="RFC8855"
format="default"/>
<bcp14>MUST</bcp14> be followed.</t>
<t>While this specification assumes that BFCP encoding is only TLV binar y, <t>While this specification assumes that BFCP encoding is only TLV binar y,
future documents may define other mechanisms like JSON serialization. future documents may define other mechanisms, like JSON serialization.
if encoding changes a new subprotocol identifier would need to be selec If encoding changes, a new subprotocol identifier would need to be sele
ted.</t> cted.</t>
<t>Each BFCP message MUST be carried within a single WebSocket <t>Each BFCP message <bcp14>MUST</bcp14> be carried within a single WebS
message, and a WebSocket message MUST NOT contain more than one ocket
message, and a WebSocket message <bcp14>MUST NOT</bcp14> contain more than
one
BFCP message.</t> BFCP message.</t>
</section> </section>
</section> </section>
<section anchor="bfcp_websocket_transport" numbered="true" toc="default">
<section anchor="bfcp_websocket_transport" <name>Transport Reliability</name>
title="Transport Reliability"> <t>The WebSocket protocol <xref target="RFC6455" format="default"/> provid
<t>WebSocket <xref target="RFC6455"/> provides a reliable transport and es a reliable transport, and
therefore the BFCP WebSocket sub-protocol defined by this therefore the BFCP WebSocket subprotocol defined by this
document also provides reliable BFCP transport. Thus, client and server document also provides reliable BFCP transport. Thus, client and server
transactions using WebSocket for transport MUST follow the transactions using the WebSocket protocol for transport <bcp14>MUST</bcp14
procedures for reliable transports as defined in <xref > follow the
target="I-D.ietf-bfcpbis-rfc4582bis"/> and <xref procedures for reliable transports as defined in <xref target="RFC8855" fo
target="I-D.ietf-bfcpbis-rfc4583bis"/>.</t> rmat="default"/>
and <xref target="RFC8856" format="default"/>.</t>
<t>BFCP WebSocket clients cannot receive incoming WebSocket <t>BFCP WebSocket clients cannot receive incoming WebSocket
connections initiated by any other peer. This means that a BFCP connections initiated by any other peer. This means that a BFCP
WebSocket client MUST actively initiate a connection towards a WebSocket client <bcp14>MUST</bcp14> actively initiate a connection toward
BFCP WebSocket server. The BFCP server is a will have a globally routable s a
address BFCP WebSocket server. The BFCP server will have a globally routable addre
and thus does not require ICE as clients always initiate connections to it ss
. </t> and thus does not require ICE, as clients always initiate connections to i
t. </t>
</section> </section>
<section anchor="sdp_con" numbered="true" toc="default">
<name>SDP Considerations</name>
<section anchor="updates_to_rfc_4583bis" numbered="true" toc="default">
<name>Transport Negotiation</name>
<t>Rules to generate an "m=" line for a BFCP stream are described
in <xref target="RFC8856" section="4" sectionFormat="comma" format="defaul
t"/>.</t>
<section anchor="sdp_con" <t>New values are defined for the SDP "proto" field: 'TCP/WS/BFCP'
title="SDP Considerations"> and 'TCP/WSS/BFCP'. </t>
<ul empty="true" spacing="normal">
<section anchor="updates_to_rfc_4583bis" <li>'TCP/WS/BFCP' is used when BFCP runs on top of WS, which in
title="Transport Negotiation"> turn runs on top of TCP.</li>
<t>Rules to generate an 'm' line for a BFCP stream are described <li>'TCP/WSS/BFCP' is used when BFCP runs on top of secure WebSocket (
in <xref target="I-D.ietf-bfcpbis-rfc4583bis"/>, Section 3</t> WSS), which
in turn runs on top of TLS and TCP.</li>
<t>New values are defined for the transport field: TCP/WS/BFCP </ul>
and TCP/WSS/BFCP. <list style="empty"> <t>The "port" field is set following the rules in Section
<t>TCP/WS/BFCP is used when BFCP runs on top of WS, which in <xref target="RFC8856" section="4" sectionFormat="bare" format="default"/>
turn runs on top of TCP.</t> and Section
<xref target="RFC8856" section="7.1" sectionFormat="bare" format="default"
<t>TCP/WSS/BFCP is used when BFCP runs on top of WSS, which />
in turn runs on top of TLS and TCP.</t> of <xref target="RFC8856" format="default"/>. Depending on the value
</list></t> of the SDP 'setup' attribute defined in <xref target="RFC4145" format="def
ault"/>,
<t>The port field is set following the rules in Section 3 and Section 8.1 the "port" field contains the port to which the remote endpoint will
of <xref direct BFCP messages, or it is irrelevant (i.e., the endpoint will initiat
target="I-D.ietf-bfcpbis-rfc4583bis"/>. Depending on the value e the connection
of the SDP 'setup' attribute defined in <xref target="RFC4145"/>, towards the remote endpoint) and should be set to a value of '9',
the port field contains the port to which the remote endpoint will which is the discard port. The 'connection' attribute and port <bcp14>MUST
direct BFCP messages or is irrelevant (i.e., the endpoint will initiate th </bcp14>
e connection follow the rules of <xref target="RFC4145" format="default"/>.</t>
towards the remote endpoint) and should be set to a value of 9, <t>While this document recommends the use of secure WebSocket (i.e., TC
which is the discard port. Connection attribute and port MUST P/WSS)
follow the rules of <xref target="RFC4145"/></t>
<t>While this document recommends the use of secure WebSockets (i.e.TCP/WS
S)
for security reasons, TCP/WS is also permitted so as to achieve maximum for security reasons, TCP/WS is also permitted so as to achieve maximum
compatibility among clients.</t> compatibility among clients.</t>
</section> </section>
<section anchor="attribute" numbered="true" toc="default">
<section anchor="attribute" <name>SDP Media Attributes</name>
title="SDP Media Attributes"> <t><xref target="RFC8124" format="default"/> defines a new SDP attribute
<t><xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/> defines a new SDP attribu to indicate the connection Uniform Resource Identifier (URI) for the WebSo
te cket client.
to indicate the connection Uniform Resource Identifier (URI) for the WebSo The SDP attribute 'websocket-uri' defined in <xref target="RFC8124" sectio
cket Client. n="3" sectionFormat="of" format="default"/>
The SDP attribute 'websocket-uri' defined in Section 3 of <xref target="I- <bcp14>MUST</bcp14> be used when BFCP runs on top of WS or WSS.
D.ietf-bfcpbis-sdp-ws-uri"/>
MUST be used when BFCP runs on top of WS or WSS.
When the 'websocket-uri' attribute is present in the media section of the SDP, When the 'websocket-uri' attribute is present in the media section of the SDP,
the procedures mentioned in Section 4 of <xref target="I-D.ietf-bfcpbis-sd the procedures mentioned in <xref target="RFC8124" section="4" sectionForm
p-ws-uri"/> at="of" format="default"/>
MUST be followed.</t> <bcp14>MUST</bcp14> be followed.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<name>SDP Offer/Answer Procedures</name>
<section anchor="general" numbered="true" toc="default">
<name>General</name>
</section> <t> An endpoint (i.e., both the offerer and the answerer) <bcp14>MUST</b
cp14> create an SDP media description ("m=" line)
<section title="SDP Offer/Answer Procedures"> for each BFCP-over-WebSocket media stream and <bcp14>MUST</bcp14> assign e
<section anchor="general" title="General"> ither a 'TCP/WSS/BFCP' or 'TCP/WS/BFCP' value to the
<t> An endpoint (i.e., both the offerer and the answerer) MUST create an SD
P media description ("m=" line)
for each BFCP-over-WebSocket media stream and MUST assign either TCP/WSS/B
FCP or TCP/WS/BFCP value to the
"proto" field of the "m=" line depending on whether the endpoint wishes to use secure WebSocket or WebSocket. "proto" field of the "m=" line depending on whether the endpoint wishes to use secure WebSocket or WebSocket.
Furthermore, the server side, which could be either the offerer or answere r, MUST add an "a=websocket-uri" Furthermore, the server side, which could be either the offerer or answere r, <bcp14>MUST</bcp14> add a 'websocket-uri'
attribute in the media section depending on whether it wishes to use WebSo cket or secure WebSocket. This new attribute in the media section depending on whether it wishes to use WebSo cket or secure WebSocket. This new
attribute MUST follow the syntax defined in <xref target="I-D.ietf-bfcpbis attribute <bcp14>MUST</bcp14> follow the syntax defined in <xref target="R
-sdp-ws-uri"/>. Additionally, FC8124" format="default"/>. Additionally,
the SDP Offer/Answer procedures defined in Section 4 of <xref target="I- the SDP offer/answer procedures defined in <xref target="RFC8124" section=
D.ietf-bfcpbis-sdp-ws-uri"/> MUST "4" sectionFormat="of" format="default"/> <bcp14>MUST</bcp14>
be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.</t> be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.</t>
</section> </section>
<section anchor="example" title="Example Usage of 'websocket-uri' SDP Attri <section anchor="example" numbered="true" toc="default">
bute"> <name>Example Usage of 'websocket-uri' SDP Attribute</name>
<t>The following is an example of an "m=" line for a BFCP connection. In <t>The following is an example of an "m=" line for a BFCP connection.
this example, the offerer sends the SDP with the "proto" field having a value o In this example, the offerer sends the SDP with the "proto" field having a
f TCP/WSS/BFCP * indicating that the offerer wishes to use secure WebSocket as a value of 'TCP/WSS/BFCP', indicating that the offerer wishes to use secure
transport for the media stream.</t> WebSocket as a transport for the media stream, and the "fmt" field having
<t> a value of '*' (for details on the "fmt" field, see
<figure> <xref target="RFC8856" section="4" sectionFormat="of" format="default"/>).</t>
<artwork><![CDATA[
<sourcecode type="sdp"><![CDATA[
Offer (browser): Offer (browser):
m=application 9 TCP/WSS/BFCP * m=application 9 TCP/WSS/BFCP *
a=setup:active a=setup:active
a=connection:new a=connection:new
a=floorctrl:c-only a=floorctrl:c-only
m=audio 55000 RTP/AVP 0 m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31 m=video 55002 RTP/AVP 31
Answer (server): Answer (server):
m=application 50000 TCP/WSS/BFCP * m=application 50000 TCP/WSS/BFCP *
skipping to change at line 488 skipping to change at line 344
a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312 a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
a=floorctrl:s-only a=floorctrl:s-only
a=confid:4321 a=confid:4321
a=userid:1234 a=userid:1234
a=floorid:1 m-stream:10 a=floorid:1 m-stream:10
a=floorid:2 m-stream:11 a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0 m=audio 50002 RTP/AVP 0
a=label:10 a=label:10
m=video 50004 RTP/AVP 31 m=video 50004 RTP/AVP 31
a=label:11 a=label:11
]]></artwork> ]]></sourcecode>
</figure></t>
<t> <t>
It is possible that an endpoint (e.g., a browser) sends an offerless I NVITE to the server. It is possible that an endpoint (e.g., a browser) sends an offerless I NVITE to the server.
In such cases the server will act as SDP offerer. The server MUST assi In such cases, the server will act as SDP offerer. The server <bcp14>M
gn the SDP "setup" UST</bcp14> assign the SDP 'setup'
attribute with a value of "passive". The server MUST have an "a=websoc attribute with a value of 'passive'. The server <bcp14>MUST</bcp14> ha
ket-uri" attribute ve a 'websocket-uri' attribute
with a "ws-URI" or "wss-URI" value depending on whether the server wis with a 'ws-URI' or 'wss-URI' value depending on whether the server wis
hes to use WebSocket or secure WebSocket. hes to use WebSocket or secure WebSocket.
This attribute MUST follow the syntax defined in Section 3 of <xref t This attribute <bcp14>MUST</bcp14> follow the syntax defined in
arget="I-D.ietf-bfcpbis-sdp-ws-uri"/> . <xref target="RFC8124" section="3" sectionFormat="of" format="default"
For BFCP application, the "proto" value in the "m=" line MUST be TCP/ />.
WSS/BFCP if WebSocket is over TLS, For BFCP application, the "proto" value in the "m=" line <bcp14>MUST<
else it MUST be TCP/WS/BFCP. /bcp14> be 'TCP/WSS/BFCP' if WebSocket is over TLS,
else it <bcp14>MUST</bcp14> be 'TCP/WS/BFCP'.
</t> </t>
</section>
</section> </section>
</section> <section anchor="authentication" numbered="true" toc="default">
<name>Authentication</name>
<section anchor="authentication" title="Authentication"> <t><xref target="RFC8855" section="9" sectionFormat="of" format="default"/
<t>Section 9 of <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> >
states that BFCP clients and floor control servers SHOULD states that BFCP clients and floor control servers <bcp14>SHOULD</bcp14>
authenticate each other prior to accepting messages, and authenticate each other prior to accepting messages, and
RECOMMENDS that mutual TLS/DTLS authentication be used. However, RECOMMENDS that mutual TLS/DTLS authentication be used. However,
browser-based WebSocket clients have no control over the use of browser-based WebSocket clients have no control over the use of
TLS in the WebSocket API <xref target="WS-API"/>, so it is TLS in the WebSocket API <xref target="WS-API" format="default"/>, so it i
RECOMMENDED that standard Web-based methods for client and s
<bcp14>RECOMMENDED</bcp14> that standard web-based methods for client and
server authentication are used, as follows.</t> server authentication are used, as follows.</t>
<t>When a BFCP WebSocket client connects to a BFCP WebSocket <t>When a BFCP WebSocket client connects to a BFCP WebSocket
server, it SHOULD use TCP/WSS as its transport. If the signaling server, it <bcp14>SHOULD</bcp14> use TCP/WSS as its transport. If the sign aling
or control protocol traffic used to set up the conference is authenticated or control protocol traffic used to set up the conference is authenticated
and confidentiality and integrity protected, Secure WebSocket (WSS) MUST b and confidentiality and integrity protected, secure WebSocket (WSS) <bcp14
e used, >MUST</bcp14> be used,
and the floor control server MUST authenticate the client. The WebSocket c and the floor control server <bcp14>MUST</bcp14> authenticate the client.
lient The WebSocket client
MUST follow the procedures in <xref target="RFC7525"/> while setting up TL <bcp14>MUST</bcp14> follow the procedures in <xref target="RFC7525" format
S ="default"/> while setting up TLS
connection with the WebSocket server. connection with the WebSocket server.
The BFCP client validates the server by means of verifying the server cert ificate. The BFCP client validates the server by means of verifying the server cert ificate.
This means the "websocket-uri" value MUST contain a hostname. This means the 'websocket-uri' value <bcp14>MUST</bcp14> contain a hostnam
The verification process does not use a=fingerprint.</t> e.
The verification process does not use "a=fingerprint".</t>
<t>A floor control server that receives a message over TCP/WS <t>A floor control server that receives a message over TCP/WS
can mandate the use of TCP/WSS by generating an Error message, can mandate the use of TCP/WSS by generating an Error message,
as described in Section 13.8 of <xref as described in <xref target="RFC8855" section="13.8" sectionFormat="of" f
target="I-D.ietf-bfcpbis-rfc4582bis"/>, with an Error code with ormat="default"/>,
a value of 9 (use TLS).</t> with an error code with a value of 9 (Use TLS).</t>
<t>Prior to sending BFCP requests, a BFCP WebSocket client <t>Prior to sending BFCP requests, a BFCP WebSocket client
connects to a BFCP WebSocket server and performs the connection connects to a BFCP WebSocket server and performs the connection
handshake. As described in <xref handshake. As described in <xref target="handshake" format="default"/>, th
target="the_websocket_protocol"/> the handshake procedure e handshake procedure
involves a HTTP GET method request from the client and a involves an HTTP GET method request from the client and a
response from the server including an HTTP 101 status code.</t> response from the server including an HTTP 101 status code.</t>
<t>In order to authorize the WebSocket connection, the BFCP <t>In order to authorize the WebSocket connection, the BFCP
WebSocket server SHOULD inspect any cookie <xref target="RFC6265"/> WebSocket server <bcp14>SHOULD</bcp14> inspect any cookie header fields
headers present in the HTTP GET request. For many web <xref target="RFC6265" format="default"/> present in the HTTP GET request.
applications the value of such a cookie is provided by the web For many web
applications, the value of such a cookie is provided by the web
server once the user has authenticated themselves to the web server once the user has authenticated themselves to the web
server, which could be done by many existing mechanisms. As an server, which could be done by many existing mechanisms. As an
alternative method, the BFCP WebSocket Server could request HTTP alternative method, the BFCP WebSocket server could request HTTP
authentication by replying to the Client's GET method request authentication by replying to the client's GET method request
with a HTTP 401 status code. The WebSocket protocol <xref with an HTTP 401 status code. The WebSocket protocol <xref target="RFC6455
target="RFC6455"/> covers this usage in Section 4.1: " format="default"/>
<list style="empty"> covers this usage in Section <xref target="RFC6455" section="4.1" sectionF
<t>If the status code received from the server is not 101, ormat="bare" format="default"/>:
the WebSocket client stack handles the response per HTTP </t>
<xref target="RFC7230"/> procedures, in particular the <ul empty="true" spacing="normal">
client might perform authentication if it receives 401 <li>If the status code received from the server is not 101,
status code.</t>
<t>If the status code received from the server is not 101,
the WebSocket client stack handles the response per HTTP the WebSocket client stack handles the response per HTTP
<xref target="RFC7230"/> procedures, in particular the <xref target="RFC7230" format="default"/> procedures; in particular, t
client might perform authentication if it receives 401 he
client might perform authentication if it receives an 401
status code. The WebSocket clients are vulnerable to the attacks status code. The WebSocket clients are vulnerable to the attacks
of basic authentication (mentioned in Section 4 of <xref target="RFC761 of basic authentication (mentioned in <xref target="RFC7617" section="4
7"/>) and " sectionFormat="of" format="default"/>) and
digest authentication (mentioned in Section 5 of <xref target="RFC7616"/ digest authentication (mentioned in <xref target="RFC7616" section="5" s
>]). To overcome ectionFormat="of" format="default"/>). To overcome
some of these weakness, the WebSocket clients for example can use some of these weaknesses, WebSocket clients can use the
HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in <xref tar HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in
get="RFC7486"/>.</t> <xref target="RFC7486" format="default"/>, for example.</li>
</list></t> </ul>
</section> </section>
<section anchor="security_considerations" numbered="true" toc="default">
<section anchor="security_considerations" <name>Security Considerations</name>
title="Security Considerations"> <t>Considerations from <xref target="RFC8855" format="default"/>,
<t>Considerations from <xref <xref target="RFC8856" format="default"/>, and <xref target="RFC5018" form
target="I-D.ietf-bfcpbis-rfc4582bis"/>, <xref at="default"/> apply.</t>
target="I-D.ietf-bfcpbis-rfc4583bis"/> and RFC5018 <xref
target="RFC5018"/> apply.</t>
<t>BFCP relies on lower-layer security mechanisms to provide <t>BFCP relies on lower-layer security mechanisms to provide
replay and integrity protection and confidentiality. It is replay and integrity protection and confidentiality. It is
RECOMMENDED that the BFCP traffic transported over a WebSocket <bcp14>RECOMMENDED</bcp14> that the BFCP traffic transported over WebSocke
communication be protected by using a secure WebSocket t
connection (using TLS <xref target="RFC5246"/> over TCP). The security be protected by using a Secure WebSocket
considerations in <xref target="RFC6455"/> apply for BFCP over WebSocket a connection (using TLS <xref target="RFC8446" format="default"/> over TCP).
s well. The security
considerations in <xref target="RFC6455" format="default"/> apply for BFCP
over WebSocket as well.
The security model here is a typical webserver-client model The security model here is a typical webserver-client model
where the client validates the server certificate and then connects to the server. where the client validates the server certificate and then connects to the server.
<xref target="authentication"/> describes the authentication procedures be tween client <xref target="authentication" format="default"/> describes the authenticat ion procedures between client
and server.</t> and server.</t>
<t>When using BFCP over WebSocket, the security mechanisms defined in
<t>When using BFCP over websockets, the security mechanisms defined in <xref target="RFC8855" format="default"/> are not used. Instead, the
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> are not used. Instead, the application is required to build and rely on the security mechanisms in <xre
application is required to build and rely on the security mechanisms in <xre f target="RFC6455" format="default"/>.</t>
f target="RFC6455"/>.</t> <t>The rest of this section analyses the threats described in
<xref target="RFC8855" section="14" sectionFormat="of" format="default"/>
<t>The rest of this section analyses the threats described in Section 14 of when WebSocket is used as a transport
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> when WebSocket is used as tra
nsport
protocol for BFCP.</t> protocol for BFCP.</t>
<t>An attacker attempting to impersonate a floor control server is avoided <t>An attacker attempting to impersonate a floor control server is
by having avoided by having servers accept BFCP messages over WSS
servers accept BFCP messages over WSS only. As with any other web connecti only. As with any other web connection, the clients will verify the server
on, the clients 's
will verify the servers certificate. The floor control WebSocket client M certificate. The BFCP WebSocket client <bcp14>MUST</bcp14> follow the
UST follow the procedures in <xref target="RFC7525" format="default"/> (including hostnam
procedures in <xref target="RFC7525"/> (including hostname verification as e verification as per
per <xref target="RFC7525" section="6.1" sectionFormat="of" format="default"/>
Section 6.1 in <xref target="RFC7525"/>) while setting up TLS connection w ) while setting up a TLS connection with floor
ith floor control WebSocket server.</t>
control webSocket server.</t>
<t>An attacker attempting to impersonate a floor control client is avoided by <t>An attacker attempting to impersonate a floor control client is avoided by
having servers accept BFCP messages over WSS only. As described in having servers accept BFCP messages over WSS only. As described in
Section 10.5 of <xref target="RFC6455"/> the floor control server can us <xref target="RFC6455" section="10.5" sectionFormat="of" format="default
e "/> the floor control server can use
any client authentication mechanism and follow the steps in <xref target any client authentication mechanism and follow the steps in <xref target
="authentication"/> ="authentication" format="default"/>
of this document.</t> of this document.</t>
<t>Attackers may attempt to modify messages exchanged by a client and a <t>Attackers may attempt to modify messages exchanged by a client and a
floor control server. This can be prevented by having WSS between client a nd server.</t> floor control server. This can be prevented by having WSS between client a nd server.</t>
<t>An attacker trying to replay the messages is prevented by
<t>An attacker trying to replay the messages is prevented by
having floor control servers check that messages arriving over a having floor control servers check that messages arriving over a
given WSS connection use an authorized user ID. </t> given WSS connection use an authorized user ID. </t>
<t>Attackers may eavesdrop on the network to get access
<t>Attackers may may eavesdrop on the network to get access
to confidential information between the floor control server and a to confidential information between the floor control server and a
client (e.g., why a floor request was denied). In order to ensure that client (e.g., why a floor request was denied). In order to ensure that
BFCP users are getting the level of protection that they would get using BFCP users are getting the level of protection that they would get using
the BFCP protocol directly, applications need to have a way to BFCP directly, applications need to have a way to
control the websocket libraries to use encryption algorithms specified in control the WebSocket libraries to use encryption algorithms specified in
Section 7 of <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> . Since the <xref target="RFC8855" section="7" sectionFormat="of" format="default"/>. Sin
WebSocket API <xref target="WS-API"/> does not have a way to allow an ce the
WebSocket API <xref target="WS-API" format="default"/> does not have a way to
allow an
application to select the encryption algorithm to be used, the protection lev el application to select the encryption algorithm to be used, the protection lev el
provided when WSS is used is limited to the underlying TLS algorithm used by provided when WSS is used is limited to the underlying TLS algorithm used by
WebSocket library.</t> the WebSocket library.</t>
</section> </section>
<section anchor="iana_considerations" numbered="true" toc="default">
<section anchor="iana_considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<section title="Registration of the WebSocket BFCP Sub-Protocol"> <section numbered="true" toc="default">
<t>This specification requests IANA to register the WebSocket <name>Registration of the WebSocket BFCP Subprotocol</name>
BFCP sub-protocol under the "WebSocket Subprotocol Name" <t>IANA has registered the WebSocket
Registry with the following data:</t> BFCP subprotocol under the "WebSocket Subprotocol Name Registry"
as follows:</t>
<t><list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Subprotocol Identifier:">BFCP</t> <dt>Subprotocol Identifier:</dt>
<dd>bfcp</dd>
<t hangText="Subprotocol Common Name:">WebSocket Transport <dt>Subprotocol Common Name:</dt>
for BFCP (Binary Floor Control Protocol)</t> <dd>WebSocket Transport
for BFCP (Binary Floor Control Protocol)</dd>
<t hangText="Subprotocol Definition:">RFC&rfc.number;</t> <dt>Subprotocol Definition:</dt>
</list></t> <dd>RFC 8857</dd>
<t>[[NOTE TO RFC EDITOR: Please change &rfc.number; to the number as </dl>
signed to this specification, and remove this paragraph on publication.]]</t>
</section> </section>
<section numbered="true" toc="default">
<name>Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" V
alues</name>
<t>This document defines two new values for the SDP "proto"
subregistry within the "Session Description Protocol (SDP) Parameters"
registry. The resulting entries are shown in <xref target="IANA_SDP_prot
o" format="default"/>:</t>
<section title="Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP ' <table anchor="IANA_SDP_proto">
proto' Values"> <name>Values for the SDP "proto" Field</name>
<t>This document defines two new values for the SDP 'proto' <thead>
field under the Session Description Protocol (SDP) Parameters <tr>
registry. The resulting entries are shown in <xref <th>Value</th>
target="IANA_SDP_proto"/> below:<figure <th>Reference</th>
anchor="IANA_SDP_proto" align="center" </tr>
title="Values for the SDP 'proto' Field"> </thead>
<artwork><![CDATA[ <tbody>
Value Reference <tr>
---------- ----------- <td>TCP/WS/BFCP</td>
TCP/WS/BFCP RFCXXXX; <td>RFC 8857</td>
TCP/WSS/BFCP RFCXXXX; </tr>
]]></artwork> <tr>
</figure></t> <td>TCP/WSS/BFCP</td>
<td>RFC 8857</td>
<t>[[NOTE TO RFC EDITOR: Please change &rfc.number; to the number assi </tr>
gned to this specification, and remove this paragraph on publication.]]</t> </tbody>
</section> </table>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors want to thank Robert Welbourn, from Acme Packet and Sergi
o Garcia Murillo
who made significant contributions to the first version of
this document. This work benefited from the thorough review
and constructive comments of Charles Eckel, Christer Holmberg, Paul Kyzi
vat, Dan Wing and Alissa Cooper.
Thanks to Bert Wijnen, Robert Sparks and Mirja Kuehlewind for their revi
ews and comments on this document.
</t>
<t> Thanks for Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey
Melnikov, Jari Arkko and Stephen Farrell for
their feedback and comments during IESG reviews. </t>
</section> </section>
</section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative --> <references>
<name>References</name>
<!-- There are 2 ways to insert reference entries from the citation librarie <references>
s: <name>Normative References</name>
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
(as shown) FC.2119.xml"/>
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
l"?> here FC.8174.xml"/>
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
xml") FC.4145.xml"/>
Both are cited textually in the same manner: by using xref elements. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
If you use the PI option, xml2rfc will, by default, try to find included fi FC.6455.xml"/>
les in the same <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
directory as the including file. You can also define the XML_LIBRARY enviro FC.5018.xml"/>
nment variable
with a value containing a set of directories to search. These can be eithe
r in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2119;
&RFC4145; <reference anchor="RFC8855" target="https://www.rfc-editor.org/info/rfc8855">;
&RFC6455; <front>
<title>The Binary Floor Control Protocol (BFCP)</title>
&RFC5018; <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization />
</author>
&BFCPbis; <author initials="K." surname="Drage" fullname="Keith Drage">
<organization />
</author>
&RFC7525; <author initials="T." surname="Kristensen" fullname="Tom Kristensen">
<organization />
</author>
&SDPBFCPbis; <author initials="J." surname="Ott" fullname="Jörg Ott">
<organization />
</author>
<?rfc include="reference.I-D.ietf-bfcpbis-sdp-ws-uri"?> <author initials="C." surname="Eckel" fullname="Charles Eckel">
<organization />
</author>
</references> <date month="May" year="2020" />
</front>
<seriesInfo name="RFC" value="8855" />
<seriesInfo name="DOI" value="10.17487/RFC8855"/>
<references title="Informative References"> </reference>
&RFC7230;
&RFC5246; <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer ence.RFC.7525.xml"/>;
&RFC6265; <reference anchor='RFC8856' target="https://www.rfc-editor.org/info/rfc8856">
<front>
<title>Session Description Protocol (SDP) Format for Binary Floor Control
Protocol (BFCP) Streams</title>
&RFC7616; <author initials='G' surname='Camarillo' fullname='Gonzalo Camarillo'>
<organization />
</author>
&RFC7617; <author initials='T' surname='Kristensen' fullname='Tom Kristensen'>
<organization />
</author>
&RFC7486; <author initials='C.' surname='Holmberg' fullname='Christer Holmberg'>
<organization />
</author>
<reference anchor="WS-API"> <date month='May' year='2020' />
<front> </front>
<title>The WebSocket API</title> <seriesInfo name="RFC" value="8856"/>
<seriesInfo name="DOI" value="10.17487/RFC8856"/>
</reference>
<author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<organization>W3C</organization> FC.8124.xml"/>
</author> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6265.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7616.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7617.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7486.xml"/>
<author fullname="Ian Hickson" initials="I." role="editor" <reference anchor="WS-API" target="https://www.w3.org/TR/2012/CR-websock
surname="Hickson"> ets-20120920/">
<organization>Google, Inc.</organization> <front>
</author> <title>The WebSocket API</title>
<author fullname="Ian Hickson" initials="I." role="editor" surname="
Hickson">
</author>
</front>
<refcontent>W3C Candidate Recommendation, September 2012</refcontent>
</reference>
</references>
</references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<date month="May" year="2012"/> <t>The authors want to thank <contact fullname="Robert Welbourn"/> from Ac
</front> me Packet and
</reference> <contact fullname="Sergio Garcia Murillo"/>,
</references> who made significant contributions to the first draft version of
this document. This work benefited from the thorough review
and constructive comments of <contact fullname="Charles Eckel"/>, <conta
ct fullname="Christer Holmberg"/>,
<contact fullname="Paul Kyzivat"/>, <contact fullname="Dan Wing"/>, and
<contact fullname="Alissa Cooper"/>.
Thanks to <contact fullname="Bert Wijnen"/>, <contact fullname="Robert S
parks"/>, and <contact fullname="Mirja Kühlewind"/>
for their reviews and comments on this document.
</t>
<t> Thanks to <contact fullname="Spencer Dawkins"/>, <contact fullname="Be
n Campbell"/>,
<contact fullname="Kathleen Moriarty"/>, <contact fullname="Alexey Melni
kov"/>, <contact fullname="Jari Arkko"/>,
and <contact fullname="Stephen Farrell"/> for
their feedback and comments during IESG reviews. </t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 124 change blocks. 
623 lines changed or deleted 503 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/