The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
RFC 8857
Victor Pascual
Nokia
Antón Román
Quobis
Stéphane Cazeaux
Orange
Gonzalo Salgueiro
Cisco Systems, Inc.
Ram Mohan Ravindranath
Cisco Systems, Inc.
2021-01
IETF
BFCPBIS Working Group
BFCP
WebSocket
The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies the use of Binary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on Internet Standards is available in 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/rfc8857.
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. Terminology
  - 2.1. Definitions
- 3. The WebSocket Protocol
- 4. The WebSocket BFCP Subprotocol
  - 4.1. Handshake
  - 4.2. BFCP Encoding
- 5. Transport Reliability
- 6. SDP Considerations
  - 6.1. Transport Negotiation
  - 6.2. SDP Media Attributes
- 7. SDP Offer/Answer Procedures
  - 7.1. General
  - 7.2. Example Usage of 'websocket-uri' SDP Attribute
- 8. Authentication
- 9. Security Considerations
- 10. IANA Considerations
  - 10.1. Registration of the WebSocket BFCP Subprotocol
  - 10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" Values
- 11. References
  - 11.1. Normative References
  - 11.2. Informative References
- Acknowledgements
- Authors' Addresses
Introduction
The WebSocket (WS) protocol [RFC6455] enables two-way message exchange between clients and servers on top of a persistent TCP connection, optionally secured with Transport Layer Security (TLS) [RFC8446]. The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.
The Binary Floor Control Protocol (BFCP) is a protocol to coordinate access to shared resources in a conference. It is defined in [RFC8855] and is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. This document extends the applicability of [RFC8855] and [RFC8856] to enable the usage of BFCP in these scenarios.
The transport over which BFCP entities exchange messages depends on how the clients obtain information to contact the floor control server (e.g., using a Session Description Protocol (SDP) offer/answer exchange per [RFC8856] or the procedure described in RFC 5018 [RFC5018]). [RFC8855] defines two transports for BFCP: TCP and UDP. This specification defines a new WebSocket subprotocol (as defined in Section 1.9 of [RFC6455]) for transporting BFCP messages between a WebSocket client and server. This subprotocol provides a reliable and boundary-preserving transport for BFCP when run on top of TCP. Since WebSocket provides a reliable transport, the extensions defined in [RFC8855] for sending BFCP over unreliable transports are not applicable.
Terminology
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.
Definitions
BFCP WebSocket Client:
Any BFCP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket BFCP subprotocol as defined by this document.
BFCP WebSocket Server:
Any BFCP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket BFCP subprotocol as defined by this document.
The WebSocket Protocol
The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC8446]) in which both client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket subprotocol and extensions negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes.
The WebSocket connection handshake is based on HTTP [RFC7230] and utilizes the HTTP GET method with an Upgrade header field. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed, the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, the client and server agree on the application protocol to use on top of the WebSocket transport. Such an application protocol (also known as a "WebSocket subprotocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as the WebSocket BFCP subprotocol defined in this document). Once the HTTP 101 response is processed, both the client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges.
The WebSocket protocol defines message units to be used by applications for the exchange of data, so it provides a message boundary-preserving transport layer.
The WebSocket BFCP Subprotocol
The term WebSocket subprotocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket BFCP subprotocol for carrying BFCP messages over a WebSocket connection.
Handshake
The BFCP WebSocket client and BFCP WebSocket server negotiate usage of the WebSocket BFCP subprotocol during the WebSocket handshake procedure as defined in Section 1.3 of [RFC6455]. The client MUST include the value "bfcp" in the Sec-WebSocket-Protocol header field in its handshake request. The 101 reply from the server MUST contain "bfcp" in its corresponding Sec-WebSocket-Protocol header field.
Below is an example of a WebSocket handshake in which the client requests the WebSocket BFCP subprotocol support from the server:

  GET / HTTP/1.1
  Host: bfcp-ws.example.com
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
  Origin: http://www.example.com
  Sec-WebSocket-Protocol: bfcp
  Sec-WebSocket-Version: 13

The handshake response from the server accepting the WebSocket BFCP subprotocol would look as follows:

  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
  Sec-WebSocket-Protocol: bfcp

Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of BFCP messages.
BFCP Encoding
BFCP messages use a TLV (Type-Length-Value) binary encoding, therefore BFCP WebSocket clients and BFCP WebSocket servers MUST be transported in unfragmented binary WebSocket frames (FIN: 1, opcode: %x2) to exchange BFCP messages. The WebSocket frame data MUST be a valid BFCP message, so the length of the payload of the WebSocket frame MUST be lower than the maximum size allowed (2^{16} +12 bytes) for a BFCP message as described in [RFC8855]. In addition, the encoding rules for reliable protocols defined in [RFC8855] MUST be followed.
While this specification assumes that BFCP encoding is only TLV binary, future documents may define other mechanisms, like JSON serialization. If encoding changes, a new subprotocol identifier would need to be selected.
Each BFCP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one BFCP message.
Transport Reliability
The WebSocket protocol [RFC6455] provides a reliable transport, and therefore the BFCP WebSocket subprotocol defined by this document also provides reliable BFCP transport. Thus, client and server transactions using the WebSocket protocol for transport MUST follow the procedures for reliable transports as defined in [RFC8855] and [RFC8856].
BFCP WebSocket clients cannot receive incoming WebSocket connections initiated by any other peer. This means that a BFCP WebSocket client MUST actively initiate a connection towards a BFCP WebSocket server. The BFCP server will have a globally routable address and thus does not require ICE, as clients always initiate connections to it.
SDP Considerations
Transport Negotiation
Rules to generate an "m=" line for a BFCP stream are described in [RFC8856], Section 4.
New values are defined for the SDP "proto" field: 'TCP/WS/BFCP' and 'TCP/WSS/BFCP'.
- 'TCP/WS/BFCP' is used when BFCP runs on top of WS, which in turn runs on top of TCP.
- 'TCP/WSS/BFCP' is used when BFCP runs on top of secure WebSocket (WSS), which in turn runs on top of TLS and TCP.
The "port" field is set following the rules in Section 4 and Section 7.1 of [RFC8856]. Depending on the value of the SDP 'setup' attribute defined in [RFC4145], the "port" field contains the port to which the remote endpoint will direct BFCP messages, or it is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of '9', which is the discard port. The 'connection' attribute and port MUST follow the rules of [RFC4145].
While this document recommends the use of secure WebSocket (i.e., TCP/WSS) for security reasons, TCP/WS is also permitted so as to achieve maximum compatibility among clients.
SDP Media Attributes
[RFC8124] defines a new SDP attribute to indicate the connection Uniform Resource Identifier (URI) for the WebSocket client. The SDP attribute 'websocket-uri' defined in Section 3 of [RFC8124] 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, the procedures mentioned in Section 4 of [RFC8124] MUST be followed.
SDP Offer/Answer Procedures
General
An endpoint (i.e., both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each BFCP-over-WebSocket media stream and MUST assign either a 'TCP/WSS/BFCP' 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. Furthermore, the server side, which could be either the offerer or answerer, MUST add a 'websocket-uri' attribute in the media section depending on whether it wishes to use WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in [RFC8124]. Additionally, the SDP offer/answer procedures defined in Section 4 of [RFC8124] MUST be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.
Example Usage of 'websocket-uri' SDP Attribute
The following is an example of an "m=" line for a BFCP connection. In this example, the offerer sends the SDP with the "proto" field having a value of 'TCP/WSS/BFCP', indicating that the offerer wishes to use secure WebSocket as a transport for the media stream, and the "fmt" field having a value of '*' (for details on the "fmt" field, see Section 4 of [RFC8856]).

Offer (browser):
m=application 9 TCP/WSS/BFCP *
a=setup:active
a=connection:new
a=floorctrl:c-only
m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31

Answer (server):
m=application 50000 TCP/WSS/BFCP *
a=setup:passive
a=connection:new
a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
a=floorctrl:s-only
a=confid:4321
a=userid:1234
a=floorid:1 m-stream:10
a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0
a=label:10
m=video 50004 RTP/AVP 31
a=label:11

It is possible that an endpoint (e.g., a browser) sends an offerless INVITE to the server. In such cases, the server will act as SDP offerer. The server MUST assign the SDP 'setup' attribute with a value of 'passive'. The server MUST have a 'websocket-uri' attribute with a 'ws-URI' or 'wss-URI' value depending on whether the server wishes to use WebSocket or secure WebSocket. This attribute MUST follow the syntax defined in Section 3 of [RFC8124]. For BFCP application, the "proto" value in the "m=" line MUST be 'TCP/WSS/BFCP' if WebSocket is over TLS, else it MUST be 'TCP/WS/BFCP'.
Authentication
Section 9 of [RFC8855] states that BFCP clients and floor control servers SHOULD authenticate each other prior to accepting messages, and RECOMMENDS that mutual TLS/DTLS authentication be used. However, browser-based WebSocket clients have no control over the use of TLS in the WebSocket API [WS-API], so it is RECOMMENDED that standard web-based methods for client and server authentication are used, as follows.
When a BFCP WebSocket client connects to a BFCP WebSocket server, it SHOULD use TCP/WSS as its transport. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, secure WebSocket (WSS) MUST be used, and the floor control server MUST authenticate the client. The WebSocket client MUST follow the procedures in [RFC7525] while setting up TLS connection with the WebSocket server. The BFCP client validates the server by means of verifying the server certificate. This means the 'websocket-uri' value MUST contain a hostname. The verification process does not use "a=fingerprint".
A floor control server that receives a message over TCP/WS can mandate the use of TCP/WSS by generating an Error message, as described in Section 13.8 of [RFC8855], with an error code with a value of 9 (Use TLS).
Prior to sending BFCP requests, a BFCP WebSocket client connects to a BFCP WebSocket server and performs the connection handshake. As described in Section 4.1, the handshake procedure involves an HTTP GET method request from the client and a response from the server including an HTTP 101 status code.
In order to authorize the WebSocket connection, the BFCP WebSocket server SHOULD inspect any cookie header fields [RFC6265] present in the HTTP GET request. 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, which could be done by many existing mechanisms. As an alternative method, the BFCP WebSocket server could request HTTP authentication by replying to the client's GET method request with an HTTP 401 status code. The WebSocket protocol [RFC6455] covers this usage in Section 4.1:
- If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP [RFC7230] procedures; in particular, the client might perform authentication if it receives an 401 status code. The WebSocket clients are vulnerable to the attacks of basic authentication (mentioned in Section 4 of [RFC7617]) and digest authentication (mentioned in Section 5 of [RFC7616]). To overcome some of these weaknesses, WebSocket clients can use the HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in [RFC7486], for example.
Security Considerations
Considerations from [RFC8855], [RFC8856], and [RFC5018] apply.
BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. It is RECOMMENDED that the BFCP traffic transported over WebSocket be protected by using a Secure WebSocket connection (using TLS [RFC8446] over TCP). The security considerations in [RFC6455] apply for BFCP over WebSocket as well. The security model here is a typical webserver-client model where the client validates the server certificate and then connects to the server. Section 8 describes the authentication procedures between client and server.
When using BFCP over WebSocket, the security mechanisms defined in [RFC8855] are not used. Instead, the application is required to build and rely on the security mechanisms in [RFC6455].
The rest of this section analyses the threats described in Section 14 of [RFC8855] when WebSocket is used as a transport protocol for BFCP.
An attacker attempting to impersonate a floor control server is avoided by having servers accept BFCP messages over WSS only. As with any other web connection, the clients will verify the server's certificate. The BFCP WebSocket client MUST follow the procedures in [RFC7525] (including hostname verification as per Section 6.1 of [RFC7525]) while setting up a TLS connection with floor control WebSocket server.
An attacker attempting to impersonate a floor control client is avoided by having servers accept BFCP messages over WSS only. As described in Section 10.5 of [RFC6455] the floor control server can use any client authentication mechanism and follow the steps in Section 8 of this document.
Attackers may attempt to modify messages exchanged by a client and a floor control server. This can be prevented by having WSS between client and server.
An attacker trying to replay the messages is prevented by having floor control servers check that messages arriving over a given WSS connection use an authorized user ID.
Attackers may eavesdrop on the network to get access to confidential information between the floor control server and a 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 directly, applications need to have a way to control the WebSocket libraries to use encryption algorithms specified in Section 7 of [RFC8855]. Since the WebSocket API [WS-API] does not have a way to allow an application to select the encryption algorithm to be used, the protection level provided when WSS is used is limited to the underlying TLS algorithm used by the WebSocket library.
IANA Considerations
Registration of the WebSocket BFCP Subprotocol
IANA has registered the WebSocket BFCP subprotocol under the "WebSocket Subprotocol Name Registry" as follows:
Subprotocol Identifier:
bfcp
Subprotocol Common Name:
WebSocket Transport for BFCP (Binary Floor Control Protocol)
Subprotocol Definition:
RFC 8857
Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" Values
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 Table 1:
Values for the SDP "proto" Field
Value | Reference
TCP/WS/BFCP | RFC 8857
TCP/WSS/BFCP | RFC 8857
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC4145]

TCP-Based Media Transport in the Session Description Protocol (SDP)
D. Yon
G. Camarillo
September 2005
RFC 4145
DOI 10.17487/RFC4145
[RFC5018]

Connection Establishment in the Binary Floor Control Protocol (BFCP)
G. Camarillo
September 2007
RFC 5018
DOI 10.17487/RFC5018
[RFC6455]

The WebSocket Protocol
I. Fette
A. Melnikov
December 2011
RFC 6455
DOI 10.17487/RFC6455
[RFC7525]

Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Y. Sheffer
R. Holz
P. Saint-Andre
May 2015
BCP 195
RFC 7525
DOI 10.17487/RFC7525
[RFC8124]

The Session Description Protocol (SDP) WebSocket Connection URI Attribute
R. Ravindranath
G. Salgueiro
March 2017
RFC 8124
DOI 10.17487/RFC8124
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC8855]

The Binary Floor Control Protocol (BFCP)
Gonzalo Camarillo
Keith Drage
Tom Kristensen
Jörg Ott
Charles Eckel
January 2021
RFC 8855
DOI 10.17487/RFC8855
[RFC8856]

Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
Gonzalo Camarillo
Tom Kristensen
Christer Holmberg
January 2021
RFC 8856
DOI 10.17487/RFC8856
Informative References
[RFC6265]

HTTP State Management Mechanism
A. Barth
April 2011
RFC 6265
DOI 10.17487/RFC6265
[RFC7230]

Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
R. Fielding, Ed.
J. Reschke, Ed.
June 2014
RFC 7230
DOI 10.17487/RFC7230
[RFC7486]

HTTP Origin-Bound Authentication (HOBA)
S. Farrell
P. Hoffman
M. Thomas
March 2015
RFC 7486
DOI 10.17487/RFC7486
[RFC7616]

HTTP Digest Access Authentication
R. Shekh-Yusef, Ed.
D. Ahrens
S. Bremer
September 2015
RFC 7616
DOI 10.17487/RFC7616
[RFC7617]

The 'Basic' HTTP Authentication Scheme
J. Reschke
September 2015
RFC 7617
DOI 10.17487/RFC7617
[RFC8446]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[WS-API]

The WebSocket API
Ian Hickson, Ed.
W3C Candidate Recommendation, September 2012
Acknowledgements
The authors want to thank Robert Welbourn from Acme Packet and Sergio Garcia Murillo, who made significant contributions to the first draft version of this document. This work benefited from the thorough review and constructive comments of Charles Eckel, Christer Holmberg, Paul Kyzivat, Dan Wing, and Alissa Cooper. Thanks to Bert Wijnen, Robert Sparks, and Mirja Kühlewind for their reviews and comments on this document.
Thanks to Spencer Dawkins, Ben Campbell, Kathleen Moriarty, Alexey Melnikov, Jari Arkko, and Stephen Farrell for their feedback and comments during IESG reviews.
Authors' Addresses
Victor Pascual
Nokia
Barcelona
Spain
victor.pascual_avila@nokia.com
Antón Román
Quobis
Pol. Ind. A Granxa, Casa de Pedra
O Porriño
36475
Spain
anton.roman@quobis.com
Stéphane Cazeaux
Orange
42 rue des Coutures
Caen
14000
France
stephane.cazeaux@orange.com
Gonzalo Salgueiro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park
NC
27709
US
gsalguei@cisco.com
Ram Mohan Ravindranath
Cisco Systems, Inc.
Cessna Business Park
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore
Karnataka
560103
India
rmohanr@cisco.com