RFC 8857

The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)

📅 published January 2021, from ietf

The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) 🎀

Okay bestie, this is RFC 8857 💅 It was written by V. Pascual (Nokia), A. Román (Quobis), S. Cazeaux (Orange), G. Salgueiro (Cisco), and R. Ravindranath (Cisco). It's a Standards Track document, published in January 2021, and its ISSN is 2070-1721 ✨ The header doesn't list anything it obsoletes or updates, so it's just doing its own thing 🦋

Abstract 💖

WebSockets let clients and servers chat back and forth in real time 🫶 This doc says BFCP can ride on top of WebSocket as a brand-new subprotocol, so BFCP gets a reliable transport in brand-new scenarios. It's giving main character energy 👑

Status of This Memo 📜

This is an Internet Standards Track document 🔥

This doc comes from the IETF, and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more about Internet Standards, check out Section 2 of RFC 7841 💜

For the current status, any errata, or how to send feedback on this doc, go to https://www.rfc-editor.org/info/rfc8857 🌸

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) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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

1. Introduction ✨

Okay so the WebSocket (WS) protocol [RFC6455] lets clients and servers swap messages both ways over a persistent TCP connection. You can optionally wrap it in Transport Layer Security (TLS) [RFC8446] 🔐 The initial handshake uses Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, which is so smart because WebSocket can reuse all the existing HTTP infrastructure 🧚

The Binary Floor Control Protocol (BFCP) is the protocol for coordinating access to shared resources in a conference 🎤 It's defined in [RFC8855], and it gets used between floor participants and floor control servers, and also between floor chairs (aka moderators) and floor control servers 👑

Modern web browsers include a WebSocket client stack that follows the WebSocket API [WS-API] from the W3C 💻 Other client apps, like the ones on personal computers and devices such as smartphones, are expected to offer a WebSocket client stack too. This document extends where [RFC8855] and [RFC8856] apply, so BFCP can be used in these scenarios 🌈

Which transport BFCP entities use to swap messages depends on how the clients find the floor control server. For example, they might do a Session Description Protocol (SDP) offer/answer exchange per [RFC8856], or follow the procedure described in RFC 5018 [RFC5018] 🦋 [RFC8855] defines two transports for BFCP, which are TCP and UDP. This spec defines a new WebSocket subprotocol (as defined in Section 1.9 of [RFC6455]) for carrying BFCP messages between a WebSocket client and server. The subprotocol gives BFCP a reliable and boundary-preserving transport when it runs on top of TCP 🫶 Since WebSocket is already reliable, the extensions in [RFC8855] for sending BFCP over unreliable transports don't apply here 🙅‍♀️

2. 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like they do right here 💜

2.1. Definitions 💜

BFCP WebSocket Client: Any BFCP entity that can open outbound connections to WebSocket servers and talk using the WebSocket BFCP subprotocol defined by this document 💖

BFCP WebSocket Server: Any BFCP entity that can listen for inbound connections from WebSocket clients and talk using the WebSocket BFCP subprotocol defined by this document 🌸

3. The WebSocket Protocol 🌈

WebSocket is a transport layer sitting on top of TCP (optionally secured with TLS [RFC8446]), and both the client and the server can send message units in both directions 🔁 The protocol covers a connection handshake, negotiation of WebSocket subprotocols and extensions, a frame format for application and control data, a masking mechanism, and status codes that say why a connection ended ✨

The WebSocket connection handshake is based on HTTP [RFC7230]. It uses the HTTP GET method with an Upgrade header field 🤝 The client sends that, and if negotiation works, the server answers with an HTTP 101 status code. Once the handshake is done, the connection upgrades from HTTP to WebSocket 🦋 The whole handshake is designed to reuse the existing HTTP infrastructure. During it, the client and server agree on the application protocol to run on top of the WebSocket transport. That application protocol, also known as a "WebSocket subprotocol," defines the format and meaning of the messages the endpoints swap. It could be a custom protocol or a standardized one, like the WebSocket BFCP subprotocol in this document 💅 After the HTTP 101 response is processed, both sides reuse the underlying TCP connection to send WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can handle multiple message exchanges 🌊

WebSocket defines message units that applications use to exchange data, so it gives you a transport layer that preserves message boundaries 🎀

4. The WebSocket BFCP Subprotocol 🍓

The term WebSocket subprotocol means 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 💖

4.1. Handshake 🤝

The BFCP WebSocket client and BFCP WebSocket server negotiate the WebSocket BFCP subprotocol during the WebSocket handshake, following Section 1.3 of [RFC6455]. The client MUST include the value "bfcp" in the Sec-WebSocket-Protocol header field of its handshake request. The 101 reply from the server MUST contain "bfcp" in its matching Sec-WebSocket-Protocol header field 🔥

Here's an example of a WebSocket handshake where the client asks the server for WebSocket BFCP subprotocol support 👀

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

If the server accepts the WebSocket BFCP subprotocol, the handshake response looks like this 🦋

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

Once the negotiation is complete, the WebSocket connection is established and ready to carry BFCP messages ✨

4.2. BFCP Encoding 🫶

BFCP messages use a TLV (Type-Length-Value) binary encoding. So 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 WebSocket frame payload MUST be lower than the maximum size allowed for a BFCP message as described in [RFC8855], which is (2^(16) +12 bytes) 📏 On top of that, the encoding rules for reliable protocols defined in [RFC8855] MUST be followed 💅

This spec only assumes BFCP encoding is TLV binary, but future documents might define other mechanisms, like JSON serialization 🧩 If the 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 🍓

5. Transport Reliability 🔥

The WebSocket protocol [RFC6455] provides a reliable transport, so the BFCP WebSocket subprotocol in this document also gives you reliable BFCP transport ✨ That means client and server transactions that use WebSocket for transport MUST follow the procedures for reliable transports defined in [RFC8855] and [RFC8856] 💖

BFCP WebSocket clients can't receive incoming WebSocket connections started by any other peer 🙈 This means a BFCP WebSocket client MUST actively initiate a connection toward a BFCP WebSocket server. The BFCP server will have a globally routable address, so it doesn't need ICE, because clients always initiate connections to it 🌈

6. SDP Considerations 💀

6.1. Transport Negotiation

okay so the rules for making an "m=" line for a BFCP stream live over in [RFC8856], Section 4 💖 go read those first bestie

two brand new values get added to the SDP "proto" field: 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' ✨

  • 'TCP/WS/BFCP' is for BFCP running on WS, which runs on TCP 🦋
  • 'TCP/WSS/BFCP' is for BFCP running on secure WebSocket (WSS), which runs on TLS and TCP 🔐

The "port" field follows the rules in Section 4 and Section 7.1 of [RFC8856]. Depending on the SDP 'setup' attribute from [RFC4145], the port is either where the remote endpoint will send BFCP messages, or it doesn't matter at all because the endpoint is the one starting the connection. In that second case it should be set to '9', which is the discard port 🙈 The 'connection' attribute and port MUST follow the rules of [RFC4145].

While this document recommends secure WebSocket (TCP/WSS) for security reasons, plain TCP/WS is also allowed so clients get the maximum compatibility 🌈

6.2. SDP Media Attributes

[RFC8124] defines a new SDP attribute that carries the connection Uniform Resource Identifier (URI) for the WebSocket client 🎀 The 'websocket-uri' attribute defined in Section 3 of [RFC8124] MUST be used when BFCP runs on top of WS or WSS. When the 'websocket-uri' attribute shows up in the media section of the SDP, the procedures in Section 4 of [RFC8124] MUST be followed.

7. SDP Offer/Answer Procedures

7.1. General

An endpoint (that means both the offerer and the answerer) MUST create an SDP media description ("m=" line) for each BFCP-over-WebSocket media stream 💅 It MUST also assign either 'TCP/WSS/BFCP' or 'TCP/WS/BFCP' to the "proto" field of that "m=" line, depending on whether it wants secure WebSocket or plain WebSocket. The server side, which could be either the offerer or the answerer, MUST add a 'websocket-uri' attribute in the media section, depending on whether it wants WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in [RFC8124]. On top of all that, the SDP offer/answer procedures defined in Section 4 of [RFC8124] MUST be followed for the "m=" line of a BFCP-over-WebSocket media stream 🔥

7.2. Example Usage of 'websocket-uri' SDP Attribute

Here's an example "m=" line for a BFCP connection 👑 The offerer sends an SDP where the "proto" field is 'TCP/WSS/BFCP', which means the offerer wants secure WebSocket as the transport for the media stream. The "fmt" field is '*' (for the lowdown on "fmt", check 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's possible for an endpoint (like a browser) to send an offerless INVITE to the server 🧚 When that happens, the server acts as the SDP offerer. The server MUST assign the SDP 'setup' attribute a value of 'passive'. The server MUST also have a 'websocket-uri' attribute with a 'ws-URI' or 'wss-URI' value, depending on whether it wants WebSocket or secure WebSocket. This attribute MUST follow the syntax defined in Section 3 of [RFC8124]. For the 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' 🌸

8. Authentication

Section 9 of [RFC8855] says that BFCP clients and floor control servers SHOULD authenticate each other before accepting messages, and it recommends that mutual TLS/DTLS authentication be used. BUT browser-based WebSocket clients have no say over whether TLS gets used in the WebSocket API [WS-API], so standard web-based methods for client and server authentication are RECOMMENDED instead, 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 has confidentiality and integrity protection, then 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 the TLS connection with the WebSocket server. The BFCP client validates the server by 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 gets a message over TCP/WS can require the use of TCP/WSS by sending an Error message, described in Section 13.8 of [RFC8855], with an error code of 9 (Use TLS) 🚫

Before sending BFCP requests, a BFCP WebSocket client connects to a BFCP WebSocket server and does the connection handshake. As described in Section 4.1, the handshake involves an HTTP GET method request from the client and a response from the server that includes an HTTP 101 status code ✨

To authorize the WebSocket connection, the BFCP WebSocket server SHOULD inspect any cookie header fields [RFC6265] in the HTTP GET request. For lots of web apps, the cookie value is given by the web server once the user has logged in to the web server, and many existing mechanisms can do that 🍓 As an alternative, the BFCP WebSocket server could ask for HTTP authentication by replying to the client's GET method request with an HTTP 401 status code. The WebSocket protocol [RFC6455] covers this 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.

9. Security Considerations

Considerations from [RFC8855], [RFC8856], and [RFC5018] apply here 🛡️

BFCP depends on lower-layer security mechanisms for replay and integrity protection, and for confidentiality. It is RECOMMENDED that BFCP traffic carried over WebSocket be protected by using a Secure WebSocket connection (using TLS [RFC8446] over TCP). The security considerations in [RFC6455] apply to BFCP over WebSocket too. 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 you use 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 looks at the threats described in Section 14 of [RFC8855] when WebSocket is the transport protocol for BFCP 👀

An attacker trying to impersonate a floor control server gets blocked by having servers accept BFCP messages over WSS only. Like with any other web connection, the clients 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 the floor control WebSocket server 🔒

An attacker trying to impersonate a floor control client gets blocked the same way, 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 try to modify messages exchanged between a client and a floor control server. This can be prevented by having WSS between client and server 😭

An attacker trying to replay messages is stopped 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 confidential info between the floor control server and a client (for example, why a floor request was denied). To make sure BFCP users get the same level of protection they'd get using BFCP directly, applications need a way to control the WebSocket libraries so they use the encryption algorithms specified in Section 7 of [RFC8855]. The WebSocket API [WS-API] has no way for an application to pick the encryption algorithm, so the protection level you get with WSS is limited to whatever TLS algorithm the WebSocket library uses. Iykyk 🙈

10. IANA Considerations

10.1. Registration of the WebSocket BFCP Subprotocol

IANA has registered the WebSocket BFCP subprotocol in the "WebSocket Subprotocol Name Registry" 🎉 Here's the entry:

Subprotocol Identifier:  bfcp

Subprotocol Common Name:  WebSocket Transport for BFCP (Binary Floor
   Control Protocol)

Subprotocol Definition:  RFC 8857

10.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" Values

This document defines two new values for the SDP "proto" subregistry inside the "Session Description Protocol (SDP) Parameters" registry 🦋 The entries end up looking like Table 1:

                   +==============+===========+
                   | Value        | Reference |
                   +==============+===========+
                   | TCP/WS/BFCP  | RFC 8857  |
                   +--------------+-----------+
                   | TCP/WSS/BFCP | RFC 8857  |
                   +--------------+-----------+

                     Table 1: Values for the
                        SDP "proto" Field

11. References

Reference entries pick up in the next part 📚

11. References ✨

11.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>.

[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <https://www.rfc-editor.org/info/rfc4145>.

[RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, DOI 10.17487/RFC5018, September 2007, <https://www.rfc-editor.org/info/rfc5018>.

[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC8124] Ravindranath, R. and G. Salgueiro, "The Session Description Protocol (SDP) WebSocket Connection URI Attribute", RFC 8124, DOI 10.17487/RFC8124, March 2017, <https://www.rfc-editor.org/info/rfc8124>.

[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>.

[RFC8855] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", RFC 8855, DOI 10.17487/RFC8855, January 2021, <https://www.rfc-editor.org/info/rfc8855>.

[RFC8856] Camarillo, G., Kristensen, T., and C. Holmberg, "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 8856, DOI 10.17487/RFC8856, January 2021, <https://www.rfc-editor.org/info/rfc8856>.

11.2. Informative References 🧚

[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- Bound Authentication (HOBA)", RFC 7486, DOI 10.17487/RFC7486, March 2015, <https://www.rfc-editor.org/info/rfc7486>.

[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>.

[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[WS-API] Hickson, I., Ed., "The WebSocket API", W3C Candidate Recommendation, September 2012, <https://www.w3.org/TR/2012/CR-websockets-20120920/>.

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

Email: victor.pascual_avila@nokia.com

Antón Román Quobis Pol. Ind. A Granxa, Casa de Pedra 36475 O Porriño Spain

Email: anton.roman@quobis.com

Stéphane Cazeaux Orange 42 rue des Coutures 14000 Caen France

Email: stephane.cazeaux@orange.com

Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America

Email: gsalguei@cisco.com

Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore 560103 Karnataka India

Email: rmohanr@cisco.com

📦 where this page comes from