BFCPBIS Working Group

Internet Engineering Task Force (IETF)                        V. Pascual
Internet-Draft                                                   Genaker
Intended status:
Request for Comments: 8857                                         Nokia
Category: Standards Track                                       A. Roman
Expires: July 1, 2018 Román
ISSN: 2070-1721                                                   Quobis
                                                              S. Cazeaux
                                                   France Telecom
                                                                  Orange
                                                            G. Salgueiro
                                                         R. Ravindranath
                                                                   Cisco
                                                       December 28, 2017
                                                            January 2021

   The WebSocket Protocol as a Transport for the Binary Floor Control
                            Protocol (BFCP)
                  draft-ietf-bfcpbis-bfcp-websocket-15

Abstract

   The WebSocket protocol enables two-way realtime real-time communication
   between clients and servers.  This document specifies the use of
   Binary Floor Control Protocol(BFCP) Protocol (BFCP) as a new WebSocket sub-protocol subprotocol
   enabling a reliable transport mechanism between BFCP entities in new
   scenarios.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 1, 2018.
   https://www.rfc-editor.org/info/rfc8857.

Copyright Notice

   Copyright (c) 2017 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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The WebSocket Protocol  . . . . . . . . . . . . . . . . . . .   3
   4.  The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . .   4 Subprotocol
     4.1.  Handshake . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  BFCP Encoding . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Transport Reliability . . . . . . . . . . . . . . . . . . . .   5
   6.  SDP Considerations  . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Transport Negotiation . . . . . . . . . . . . . . . . . .   6
     6.2.  SDP Media Attributes  . . . . . . . . . . . . . . . . . .   6
   7.  SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . .   7
     7.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   7
     7.2.  Example Usage of 'websocket-uri' SDP Attribute  . . . . .   7
   8.  Authentication  . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Registration of the WebSocket BFCP Sub-Protocol  . . . .  10 Subprotocol
     10.2.  Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP
            'proto'
            "proto" Values . . . . . . . . . . . . . . . . . . . . .  11
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     12.1.
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     12.2.
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Acknowledgements
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The WebSocket(WS) [RFC6455] 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) [RFC5246].
   [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
   [I-D.ietf-bfcpbis-rfc4582bis]
   [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
   [I-D.ietf-bfcpbis-rfc4582bis]
   [RFC8855] and [I-D.ietf-bfcpbis-rfc4583bis] [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. (e.g., using an a Session Description Protocol (SDP) offer/answer
   exchange per [I-D.ietf-bfcpbis-rfc4583bis] [RFC8856] or the procedure described in RFC5018 RFC 5018
   [RFC5018]).  [I-D.ietf-bfcpbis-rfc4582bis]  [RFC8855] defines two transports for BFCP: TCP and UDP.
   This specification defines a new WebSocket sub-protocol subprotocol (as defined in
   Section 1.9 in of [RFC6455]) for transporting BFCP messages between a
   WebSocket client and server.  This sub-protocol subprotocol provides a reliable
   and boundary preserving boundary-preserving transport for BFCP when run on top of TCP.
   Since WebSocket provides a reliable transport, the extensions defined
   in
   [I-D.ietf-bfcpbis-rfc4582bis] [RFC8855] for sending BFCP over unreliable transports are not
   applicable.

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 interpreted as described in [RFC2119]. BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.1.  Definitions

   BFCP WebSocket Client:  Any BFCP entity capable of opening outbound
         connections to WebSocket servers and communicating using the
         WebSocket BFCP sub-protocol 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 sub-protocol subprotocol as defined by this
         document.

3.  The WebSocket Protocol

   The WebSocket protocol [RFC6455] is a transport layer on top of TCP
   (optionally secured with TLS [RFC5246]) [RFC8446]) in which both client and
   server exchange message units in both directions.  The protocol
   defines a connection handshake, WebSocket sub-protocol 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" request. 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 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 sub-protocol") 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 sub-protocol subprotocol defined in
   this document).  Once the HTTP 101 response is processed 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.

4.  The WebSocket BFCP Sub-Protocol Subprotocol

   The term WebSocket sub-protocol subprotocol refers to an application-level
   protocol layered on top of a WebSocket connection.  This document
   specifies the WebSocket BFCP sub-protocol subprotocol for carrying BFCP messages
   over a WebSocket connection.

4.1.  Handshake

   The BFCP WebSocket Client client and BFCP WebSocket Server server negotiate usage
   of the WebSocket BFCP sub-protocol subprotocol during the WebSocket handshake
   procedure as defined in Section 1.3 of [RFC6455].  The Client client MUST
   include the value "BFCP" "bfcp" in the Sec-WebSocket-Protocol header field
   in its handshake request.  The 101 reply from the Server server MUST contain "BFCP"
   "bfcp" in its corresponding Sec-WebSocket-Protocol header. header field.

   Below is an example of a WebSocket handshake in which the Client client
   requests the WebSocket BFCP sub-protocol subprotocol support from the Server: 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 bfcp
     Sec-WebSocket-Version: 13

   The handshake response from the Server server accepting the WebSocket BFCP
   sub-protocol
   subprotocol would look as follows:

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

   Once the negotiation has been completed, the WebSocket connection is
   established and can be used for the transport of BFCP messages.

4.2.  BFCP Encoding

   BFCP messages use a TLV (Type-Length-Value) binary encoding,
   therefore BFCP WebSocket Clients clients and BFCP WebSocket Servers servers MUST be
   transported in unfragmented binary WebSocket frames
   (FIN:1,opcode:%x2) (FIN: 1, opcode:
   %x2) to exchange BFCP messages.  The WebSocket frame data MUST be a
   valid BCFP BFCP message, so the length of the payload of the WebSocket
   frame MUST be lower than the maximum size allowed (2^16 (2^(16) +12 bytes)
   for a BCFP BFCP message as described in
   [I-D.ietf-bfcpbis-rfc4582bis]. [RFC8855].  In addition, the
   encoding rules for reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] [RFC8855] MUST be
   followed.

   While this specification assumes that BFCP encoding is only TLV
   binary, future documents may define other mechanisms mechanisms, like JSON
   serialization.  if  If encoding changes 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 transport, and
   therefore the BFCP WebSocket sub-protocol 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 [I-D.ietf-bfcpbis-rfc4582bis] [RFC8855] and
   [I-D.ietf-bfcpbis-rfc4583bis].
   [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 is a will have a globally routable address and thus does
   not require ICE ICE, as clients always initiate connections to it.

6.  SDP Considerations

6.1.  Transport Negotiation

   Rules to generate an 'm' "m=" line for a BFCP stream are described in
   [I-D.ietf-bfcpbis-rfc4583bis],
   [RFC8856], Section 3 4.

   New values are defined for the transport SDP "proto" field: TCP/WS/BFCP 'TCP/WS/BFCP' and
   TCP/WSS/BFCP.

      TCP/WS/BFCP
   '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

      'TCP/WSS/BFCP' is used when BFCP runs on top of WSS, secure WebSocket
      (WSS), which in turn runs on top of TLS and TCP.

   The port "port" field is set following the rules in Section 3 4 and
   Section 8.1 7.1 of [I-D.ietf-bfcpbis-rfc4583bis]. [RFC8856].  Depending on the value of the SDP 'setup'
   attribute defined in [RFC4145], the port "port" field contains the port to
   which the remote endpoint will direct BFCP
   messages 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, '9', which is
   the discard port.  Connection  The 'connection' attribute and port MUST follow
   the rules of [RFC4145] [RFC4145].

   While this document recommends the use of secure WebSockets (i.e.TCP/
   WSS) WebSocket (i.e.,
   TCP/WSS) for security reasons, TCP/WS is also permitted so as to
   achieve maximum compatibility among clients.

6.2.  SDP Media Attributes

   [I-D.ietf-bfcpbis-sdp-ws-uri]

   [RFC8124] defines a new SDP attribute to indicate the connection
   Uniform Resource Identifier (URI) for the WebSocket
   Client. client.  The SDP
   attribute 'websocket-uri' defined in Section 3 of
   [I-D.ietf-bfcpbis-sdp-ws-uri] [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
   [I-D.ietf-bfcpbis-sdp-ws-uri] [RFC8124] MUST be followed.

7.  SDP Offer/Answer Procedures

7.1.  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 TCP/WSS/BFCP a 'TCP/WSS/BFCP' or TCP/WS/BFCP '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 an
   "a=websocket-uri" 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 [I-D.ietf-bfcpbis-sdp-ws-uri]. [RFC8124].  Additionally,
   the SDP Offer/Answer offer/answer procedures defined in Section 4 of
   [I-D.ietf-bfcpbis-sdp-ws-uri] [RFC8124]
   MUST be followed for the "m=" line associated with a BFCP-over-WebSocket BFCP-over-
   WebSocket media stream.

7.2.  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 * 'TCP/WSS/BFCP', indicating that the offerer wishes
   to use secure WebSocket as a transport for the media stream. 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 cases, the server will act as SDP
   offerer.  The server MUST assign the SDP "setup" 'setup' attribute with a
   value of "passive". 'passive'.  The server MUST have an "a=websocket-uri" a 'websocket-uri' attribute
   with a "ws-URI" 'ws-URI' or "wss-URI" '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
   [I-D.ietf-bfcpbis-sdp-ws-uri] . [RFC8124].  For BFCP
   application, the "proto" value in the "m=" line MUST be TCP/WSS/BFCP 'TCP/WSS/
   BFCP' if WebSocket is over TLS, else it MUST be TCP/WS/BFCP. 'TCP/WS/BFCP'.

8.  Authentication

   Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] [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
   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 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" 'websocket-uri' value MUST contain a hostname.  The
   verification process does not use a=fingerprint. "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 [I-D.ietf-bfcpbis-rfc4582bis], [RFC8855], with an
   Error error code with a
   value of 9 (use (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 3 4.1, the handshake procedure involves a 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] headers present in
   the HTTP GET request.  For many web applications 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 server
   could request HTTP authentication by replying to the Client's client's GET
   method request with a 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 401 status code.

      If the status code received from the server is not 101, the
      WebSocket client stack handles the response per HTTP [RFC7230]
      procedures,
      procedures; in particular 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]]). [RFC7616]).  To overcome some of these weakness, the weaknesses,
      WebSocket clients for example can use the HTTP Origin-Bound Authentication
      (HOBA) mechanism mentioned in [RFC7486]. [RFC7486], for example.

9.  Security Considerations

   Considerations from [I-D.ietf-bfcpbis-rfc4582bis],
   [I-D.ietf-bfcpbis-rfc4583bis] [RFC8855], [RFC8856], and RFC5018 [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 a WebSocket communication be protected by using a secure
   Secure WebSocket connection (using TLS [RFC5246] [RFC8446] over TCP).  The
   security considerations in [RFC6455] apply for BFCP over WebSocket as
   well.  The security model here is a typical webserver-
   client 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 websockets, WebSocket, the security mechanisms defined in
   [I-D.ietf-bfcpbis-rfc4582bis]
   [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 [I-D.ietf-bfcpbis-rfc4582bis] [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 servers server's
   certificate.  The floor control BFCP WebSocket client MUST follow the procedures in
   [RFC7525] (including hostname verification as per Section 6.1 in of
   [RFC7525]) while setting up a TLS connection with floor control webSocket
   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 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 the BFCP protocol
   directly, applications need to have a way to control the websocket WebSocket
   libraries to use encryption algorithms specified in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis] .
   [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.

10.  IANA Considerations

10.1.  Registration of the WebSocket BFCP Sub-Protocol

   This specification requests Subprotocol

   IANA to register has registered the WebSocket BFCP sub-
   protocol subprotocol under the
   "WebSocket Subprotocol Name" Registry with the
   following data: Name Registry" as follows:

   Subprotocol Identifier:  BFCP  bfcp

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

   Subprotocol Definition:  RFCXXXX

   [[NOTE TO  RFC EDITOR: Please change XXXX to the number assigned to
   this specification, and remove this paragraph on publication.]] 8857

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

   This document defines two new values for the SDP 'proto' field under "proto" subregistry
   within the Session "Session Description Protocol (SDP) Parameters Parameters" registry.
   The resulting entries are shown in Figure 1 below: Table 1:

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

                Figure | RFC 8857  |
                       +--------------+-----------+

                         Table 1: Values for the
                            SDP 'proto' "proto" Field

   [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to
   this specification, and remove this paragraph on publication.]]

11.  Acknowledgements

   The authors want to thank Robert Welbourn, from Acme Packet and
   Sergio 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 Kyzivat, Dan Wing and Alissa Cooper.  Thanks to Bert Wijnen,
   Robert Sparks and Mirja Kuehlewind for their reviews and comments on
   this document.

   Thanks for Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey
   Melnikov, Jari Arkko and Stephen Farrell for their feedback and
   comments during IESG reviews.

12.  References

12.1.

11.1.  Normative References

   [I-D.ietf-bfcpbis-rfc4582bis]
              Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.
              Eckel, "The Binary Floor Control Protocol (BFCP)", draft-
              ietf-bfcpbis-rfc4582bis-16 (work in progress), November
              2015.

   [I-D.ietf-bfcpbis-rfc4583bis]
              Camarillo, G., Kristensen, T., and P. Jones, "Session
              Description Protocol (SDP) Format for Binary Floor Control
              Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-18
              (work in progress), October 2017.

   [I-D.ietf-bfcpbis-sdp-ws-uri]
              R, R. and G. Salgueiro, "Session Description Protocol
              (SDP) WebSocket Connection URI Attribute", draft-ietf-
              bfcpbis-sdp-ws-uri-09 (work in progress), February 2017.

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

12.2.  Informative References

   [RFC5246]  Dierks, T.

   [RFC8124]  Ravindranath, R. and E. Rescorla, G. Salgueiro, "The Transport Layer Security
              (TLS) Session
              Description Protocol Version 1.2", (SDP) WebSocket Connection URI
              Attribute", RFC 5246, 8124, DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>. 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]   W3C and I.   Hickson, I., Ed., "The WebSocket API", May 2012. 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
   Genaker
   Nokia
   Barcelona
   Spain

   Email: victor.pascual@genaker.net

   Anton Roman 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

   Stephane

   Stéphane Cazeaux
   France Telecom
   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
   US
   United States of America

   Email: gsalguei@cisco.com

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

   Email: rmohanr@cisco.com