The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)NokiaBarcelonaSpainvictor.pascual_avila@nokia.comQuobisPol. Ind. A Granxa, Casa de PedraO Porriño36475Spainanton.roman@quobis.comOrange42 rue des CouturesCaen14000Francestephane.cazeaux@orange.comCisco Systems, Inc.7200-12 Kit Creek RoadResearch Triangle ParkNC27709USgsalguei@cisco.comCisco Systems, Inc.Cessna Business ParkKadabeesanahalli Village, Varthur Hobli,Sarjapur-Marathahalli Outer Ring RoadBangaloreKarnataka560103Indiarmohanr@cisco.com
IETF
BFCPBIS Working GroupBFCPWebSocket 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
.
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
() 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
. Introduction
. Terminology
. Definitions
. The WebSocket Protocol
. The WebSocket BFCP Subprotocol
. Handshake
. BFCP Encoding
. Transport Reliability
. SDP Considerations
. Transport Negotiation
. SDP Media Attributes
. SDP Offer/Answer Procedures
. General
. Example Usage of 'websocket-uri' SDP Attribute
. Authentication
. Security Considerations
. IANA Considerations
. Registration of the WebSocket BFCP Subprotocol
. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" Values
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionThe WebSocket (WS) protocol enables
two-way message exchange between clients and servers on top of a
persistent TCP connection, optionally secured with Transport Layer Security (TLS)
. The initial protocol handshake makes use of
Hypertext Transfer Protocol (HTTP) 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 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 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
and
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 or the
procedure described in RFC 5018 ).
defines two transports
for BFCP: TCP and UDP. This specification defines a new
WebSocket subprotocol (as defined in
) 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 for sending BFCP over unreliable
transports are not applicable. TerminologyThe 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
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 ProtocolThe WebSocket protocol is a
transport layer on top of TCP (optionally secured with
TLS ) 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 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 SubprotocolThe 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.HandshakeThe BFCP WebSocket client and BFCP WebSocket server
negotiate usage of the WebSocket BFCP subprotocol during the
WebSocket handshake procedure as defined in
.
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 EncodingBFCP 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 (216 +12 bytes) for a BFCP
message as described in . In addition, the
encoding rules for reliable protocols defined in 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 ReliabilityThe WebSocket protocol 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
and .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 ConsiderationsTransport NegotiationRules to generate an "m=" line for a BFCP stream are described
in .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
and Section
of . Depending on the value
of the SDP 'setup' attribute defined in ,
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 .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 defines a new SDP attribute
to indicate the connection Uniform Resource Identifier (URI) for the WebSocket client.
The SDP attribute 'websocket-uri' defined in 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 MUST be followed.SDP Offer/Answer ProceduresGeneral 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 . Additionally,
the SDP offer/answer procedures defined in MUST
be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.Example Usage of 'websocket-uri' SDP AttributeThe 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
).
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
.
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
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 , 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 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 ,
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 , 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
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
covers this usage in Section :
If the status code received from the server is not 101,
the WebSocket client stack handles the response per HTTP
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 ) and
digest authentication (mentioned in ). To overcome
some of these weaknesses, WebSocket clients can use the
HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in
, for example.
Security ConsiderationsConsiderations from ,
, and 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 over TCP). The security
considerations in 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.
describes the authentication procedures between client
and server.When using BFCP over WebSocket, the security mechanisms defined in
are not used. Instead, the
application is required to build and rely on the security mechanisms in .The rest of this section analyses the threats described in
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 (including hostname verification as per
) 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
the floor control server can use
any client authentication mechanism and follow the steps in
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
. Since the
WebSocket 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 ConsiderationsRegistration of the WebSocket BFCP SubprotocolIANA 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" ValuesThis document defines two new values for the SDP "proto"
subregistry within the "Session Description Protocol (SDP) Parameters"
registry. The resulting entries are shown in :
Values for the SDP "proto" Field
Value
Reference
TCP/WS/BFCP
RFC 8857
TCP/WSS/BFCP
RFC 8857
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.TCP-Based Media Transport in the Session Description Protocol (SDP)This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]Connection Establishment in the Binary Floor Control Protocol (BFCP)This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]The WebSocket ProtocolThe WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.The Session Description Protocol (SDP) WebSocket Connection URI AttributeThe WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Binary Floor Control Protocol (BFCP)Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) StreamsInformative ReferencesHTTP State Management MechanismThis document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.HTTP Origin-Bound Authentication (HOBA)HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.HTTP Digest Access AuthenticationThe Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.The 'Basic' HTTP Authentication SchemeThis document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.The WebSocket APIW3C Candidate Recommendation, September 2012AcknowledgementsThe authors want to thank from Acme Packet and
,
who made significant contributions to the first draft version of
this document. This work benefited from the thorough review
and constructive comments of , ,
, , and .
Thanks to , , and
for their reviews and comments on this document.
Thanks to , ,
, , ,
and for
their feedback and comments during IESG reviews. Authors' AddressesNokiaBarcelonaSpainvictor.pascual_avila@nokia.comQuobisPol. Ind. A Granxa, Casa de PedraO Porriño36475Spainanton.roman@quobis.comOrange42 rue des CouturesCaen14000Francestephane.cazeaux@orange.comCisco Systems, Inc.7200-12 Kit Creek RoadResearch Triangle ParkNC27709USgsalguei@cisco.comCisco Systems, Inc.Cessna Business ParkKadabeesanahalli Village, Varthur Hobli,Sarjapur-Marathahalli Outer Ring RoadBangaloreKarnataka560103Indiarmohanr@cisco.com