idnits 2.17.1 draft-ietf-bfcpbis-bfcp-websocket-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.draft-ietf-bfcpbis-RFC4583bis], [I-D.draft-ietf-bfcpbis-RFC4582bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 422 has weird spacing: '...te name ws-ur...' -- The document date (June 26, 2014) is 3592 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-ietf-bfcpbis-rfc4583bis' is mentioned on line 24, but not defined ** Obsolete undefined reference: RFC 4583 (Obsoleted by RFC 8856) == Outdated reference: A later version (-16) exists of draft-ietf-bfcpbis-rfc4582bis-11 == Outdated reference: A later version (-27) exists of draft-ietf-bfcpbis-rfc4583bis-09 ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPBIS Working Group V. Pascual 3 Internet-Draft A. Roman 4 Updates: rfc4582bis, rfc4583bis (if Quobis 5 approved) S. Cazeaux 6 Intended status: Standards Track France Telecom Orange 7 Expires: December 28, 2014 G. Salgueiro 8 Cisco 9 S. Garcia Murillo 10 Medooze 11 June 26, 2014 13 The WebSocket Protocol as a Transport for the Binary Floor Control 14 Protocol (BFCP) 15 draft-ietf-bfcpbis-bfcp-websocket-01 17 Abstract 19 The WebSocket protocol enables two-way realtime communication between 20 clients and servers. This document specifies a new WebSocket sub- 21 protocol as a reliable transport mechanism between Binary Floor 22 Control Protocol (BFCP) entities to enable usage of BFCP in new 23 scenarios. This document normatively updates [I-D.draft-ietf- 24 bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 28, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 4 64 4. The WebSocket BFCP Sub-Protocol . . . . . . . . . . . . . . . 4 65 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. BFCP encoding . . . . . . . . . . . . . . . . . . . . . . 5 67 5. BFCP WebSocket Transport . . . . . . . . . . . . . . . . . . 6 68 6. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . 6 69 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. Registration of the WebSocket BFCP Sub-Protocol . . . . . 9 73 9.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 74 'proto' Values . . . . . . . . . . . . . . . . . . . . . 9 75 9.3. Registration of the 'ws-uri' SDP media attribute . . . . 9 76 9.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The WebSocket [RFC6455] protocol enables two-way message exchange 85 between clients and servers on top of a persistent TCP connection 86 (optionally secured with TLS [RFC5246]). The initial protocol 87 handshake makes use of HTTP [RFC2616] semantics, allowing the 88 WebSocket protocol to reuse existing HTTP infrastructure. 90 The Binary Floor Control Protocol (BFCP) is a protocol to coordinate 91 access to shared resources in a conference. It is defined in 92 [I-D.ietf-bfcpbis-rfc4582bis] and is used between floor participants 93 and floor control servers, and between floor chairs (i.e., 94 moderators) and floor control servers. 96 Modern web browsers include a WebSocket client stack complying with 97 the WebSocket API [WS-API] as specified by the W3C. It is expected 98 that other client applications (those running in personal computers 99 and devices such as smartphones) will also make a WebSocket client 100 stack available. This document updates [I-D.ietf-bfcpbis-rfc4582bis] 101 and [I-D.ietf-bfcpbis-rfc4583bis] in order to enable the usage of 102 BFCP in these scenarios. 104 The transport over which BFCP entities exchange messages depends on 105 how the clients obtain information to contact the floor control 106 server (e.g. using an SDP offer/answer exchange per 107 [I-D.ietf-bfcpbis-rfc4583bis] or the procedure described in RFC5018 108 [RFC5018]). [I-D.ietf-bfcpbis-rfc4582bis] defines two transports for 109 BFCP: TCP and UDP. This specification defines a new WebSocket sub- 110 protocol (as defined in section 1.9 in [RFC6455]) for transporting 111 BFCP messages between a WebSocket client and server. This sub- 112 protocol provides a reliable and boundary preserving transport for 113 BFCP when run on top of TCP. Since WebSocket is a reliable 114 transport, the extensions defined in [I-D.ietf-bfcpbis-rfc4582bis] 115 for sending BFCP over unreliable transports are not applicable. 117 This document does not restrict the selection nor prevent the usage 118 of other transport mechanisms for the BFCP protocol. Transport 119 selection is entirely at the discretion of the application. As an 120 example, an RTCWeb applications may choose to use either DataChannel 121 or WebSocket transport for BFCP, while non-RTCWeb applications could 122 still benefit from the ubiquity of the WebSocket protocol and make 123 use of the transport for BFCP defined in this document. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2.1. Definitions 133 BFCP WebSocket Client: Any BFCP entity capable of opening outbound 134 connections to WebSocket servers and communicating using the 135 WebSocket BFCP sub-protocol as defined by this document. 137 BFCP WebSocket Server: Any BFCP entity capable of listening for 138 inbound connections from WebSocket clients and communicating 139 using the WebSocket BFCP sub-protocol as defined by this 140 document. 142 3. The WebSocket Protocol 144 The WebSocket protocol [RFC6455] is a transport layer on top of TCP 145 (optionally secured with TLS [RFC5246]) in which both client and 146 server exchange message units in both directions. The protocol 147 defines a connection handshake, WebSocket sub-protocol and extensions 148 negotiation, a frame format for sending application and control data, 149 a masking mechanism, and status codes for indicating disconnection 150 causes. 152 The WebSocket connection handshake is based on HTTP [RFC2616] and 153 utilizes the HTTP GET method with an "Upgrade" request. This is sent 154 by the client and then answered by the server (if the negotiation 155 succeeded) with an HTTP 101 status code. Once the handshake is 156 completed the connection upgrades from HTTP to the WebSocket 157 protocol. This handshake procedure is designed to reuse the existing 158 HTTP infrastructure. During the connection handshake, client and 159 server agree on the application protocol to use on top of the 160 WebSocket transport. Such an application protocol (also known as a 161 "WebSocket sub-protocol") defines the format and semantics of the 162 messages exchanged by the endpoints. This could be a custom protocol 163 or a standardized one (as the WebSocket BFCP sub-protocol defined in 164 this document). Once the HTTP 101 response is processed both client 165 and server reuse the underlying TCP connection for sending WebSocket 166 messages and control frames to each other. Unlike plain HTTP, this 167 connection is persistent and can be used for multiple message 168 exchanges. 170 The WebSocket protocol defines message units to be used by 171 applications for the exchange of data, so it provides a message 172 boundary-preserving transport layer. These message units can contain 173 either UTF-8 text or binary data, and can be split into multiple 174 WebSocket text/binary transport frames as needed by the WebSocket 175 stack. 177 The WebSocket API [WS-API] for web browsers only defines callbacks 178 to be invoked upon receipt of an entire message unit, regardless 179 of whether it was received in a single Websocket frame or split 180 across multiple frames. 182 4. The WebSocket BFCP Sub-Protocol 184 The term WebSocket sub-protocol refers to an application-level 185 protocol layered on top of a WebSocket connection. This document 186 specifies the WebSocket BFCP sub-protocol for carrying BFCP messages 187 through a WebSocket connection. 189 4.1. Handshake 191 The BFCP WebSocket Client and BFCP WebSocket Server negotiate usage 192 of the WebSocket BFCP sub-protocol during the WebSocket handshake 193 procedure as defined in section 1.3 of [RFC6455]. The Client MUST 194 include the value "bfcp" in the Sec-WebSocket-Protocol header in its 195 handshake request. The 101 reply from the Server MUST contain "bfcp" 196 in its corresponding Sec-WebSocket-Protocol header. 198 Below is an example of a WebSocket handshake in which the Client 199 requests the WebSocket BFCP sub-protocol support from the Server: 201 GET / HTTP/1.1 202 Host: bfcp-ws.example.com 203 Upgrade: websocket 204 Connection: Upgrade 205 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 206 Origin: http://www.example.com 207 Sec-WebSocket-Protocol: bfcp 208 Sec-WebSocket-Version: 13 210 The handshake response from the Server accepting the WebSocket BFCP 211 sub-protocol would look as follows: 213 HTTP/1.1 101 Switching Protocols 214 Upgrade: websocket 215 Connection: Upgrade 216 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 217 Sec-WebSocket-Protocol: bfcp 219 Once the negotiation has been completed, the WebSocket connection is 220 established and can be used for the transport of BFCP messages. The 221 WebSocket messages transmitted over this connection MUST conform to 222 the negotiated WebSocket sub-protocol. 224 4.2. BFCP encoding 226 BFCP messages use a TLV (Type-Length-Value) binary encoding, 227 therefore BFCP WebSocket Clients and BFCP WebSocket Servers MUST be 228 transported in unfragmented binary WebSocket frames 229 (FIN:1,opcode:%x2) to exchange BFCP messages. The WebSocket frame 230 data MUST be a valid BCFP message, so the length of the payload of 231 the WebSocket frame MUST be lower than the maximum size allowed (2^16 232 +12 bytes) for a BCFP message as described in 233 [I-D.ietf-bfcpbis-rfc4582bis]. In addition, the encoding rules for 234 reliable protocols defined in [I-D.ietf-bfcpbis-rfc4582bis] MUST be 235 followed. 237 While this specification assumes that BFCP enconding is only TLV 238 binary, future documents may define other mechanisms like JSON 239 serialization. 241 5. BFCP WebSocket Transport 243 WebSocket [RFC6455] is a reliable protocol and therefore the BFCP 244 WebSocket sub-protocol defined by this document is a reliable BFCP 245 transport. Thus, client and server transactions using WebSocket for 246 transport MUST follow the procedures for reliable transports as 247 defined in [I-D.ietf-bfcpbis-rfc4582bis] and 248 [I-D.ietf-bfcpbis-rfc4583bis] 250 BFCP WebSocket clients cannot receive incoming WebSocket connections 251 initiated by any other peer. This means that a BFCP Websocket client 252 MUST actively initiate a connection towards a BFCP Websocket server 254 Each BFCP message MUST be carried within a single WebSocket message, 255 and a WebSocket message MUST NOT contain more than one BFCP message. 257 6. Fields in the 'm' Line 259 Rules to generate an 'm' line for a BFCP stream are described in 260 [I-D.ietf-bfcpbis-rfc4583bis], Section 3 262 New values are defined for the transport field: TCP/WS/BFCP and 263 TCP/WSS/BFCP. 265 TCP/WS/BFCP is used when BFCP runs on top of WS, which in turn 266 runs on top of TCP. 268 TCP/WSS/BFCP is used when BFCP runs on top of WSS, which in turn 269 runs on top of TLS and TCP. 271 When TCP is used as the transport, the port field is set following 272 the rules in Section 7 of [I-D.ietf-bfcpbis-rfc4582bis]. Depending 273 on the value of the 'setup' attribute, the port field contains the 274 port to which the remote endpoint will direct BFCP messages or is 275 irrelevant (i.e., the endpoint will initiate the connection towards 276 the remote endpoint) and should be set to a value of 9, which is the 277 discard port. Connection attribute and port MUST follow the rules of 278 [RFC4145] 280 Some web browsers do not allow non-secure Websocket connections to be 281 made. So, while the recommendation to use Secure WebSockets (i.e. 282 TCP/WSS) is for security reasons, it is also to achieve maximum 283 compatiblity among clients. 285 When using Secure Websockets the CNAME of the SSL certificate must 286 match the WebSocket connection URI host, and while it is possible to 287 generate self signed certificates with IPs as CNAME, it will not be 288 viable in most cases for certificates signed by well known 289 authorities. So, a new attribute 'ws-uri' is defined in this 290 specification to indicate the connection uri for the WebSocket 291 Client. The Augmented BNF syntax as described in [RFC4234] is: 293 ws-uri = "a=ws-uri:" ws-URI 295 Where ws-URI is defined in [RFC6455] 297 When the 'ws-uri' attribute is present in the BFCP media section of 298 the SDP, the IP and port provided in the 'c' lines SHALL be ignored 299 and the full uri SHALL be used instead to open the WebSocket 300 connection. The port provided in the 'm' line SHALL be ignored too, 301 as the a=ws-uri will provide port number when needed. 303 The following are examples of 'm' lines for BFCP connections: 305 Offer (browser): 306 m=application 9 TCP/WSS/BFCP * 307 a=setup:active 308 a=connection:new 309 a=floorctrl:c-only 310 m=audio 55000 RTP/AVP 0 311 m=video 55002 RTP/AVP 31 313 Answer (server): 314 m=application 50000 TCP/WSS/BFCP * 315 a=setup:passive 316 a=connection:new 317 a=ws-uri:wss://bfcp-ws.example.com?token=3170449312 318 a=floorctrl:s-only 319 a=confid:4321 320 a=userid:1234 321 a=floorid:1 m-stream:10 322 a=floorid:2 m-stream:11 323 m=audio 50002 RTP/AVP 0 324 a=label:10 325 m=video 50004 RTP/AVP 31 326 a=label:11 328 7. Authentication 330 Section 9 of [I-D.ietf-bfcpbis-rfc4582bis] states that BFCP clients 331 and floor control servers SHOULD authenticate each other prior to 332 accepting messages, and RECOMMENDS that mutual TLS/DTLS 333 authentication be used. However, browser-based WebSocket clients 334 have no control over the use of TLS in the WebSocket API [WS-API], so 335 it is RECOMMENDED that standard Web-based methods for client and 336 server authentication are used, as follows. 338 When a BFCP WebSocket client connects to a BFCP WebSocket server, it 339 SHOULD use TCP/WSS as its transport. The WebSocket client SHOULD 340 inspect the TLS certificate offered by the server and verify that it 341 is valid. 343 Since the WebSocket API does not distinguish between certificate 344 errors and other kinds of failure to establish a connection, it is 345 expected that browser vendors will warn end users directly of any 346 kind of problem with the server certificate. 348 A floor control server that receives a message over TCP/WS can 349 request the use of TCP/WSS by generating an Error message, as 350 described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an 351 Error code with a value of 9 (use TLS). 353 Prior to sending BFCP requests, a BFCP WebSocket client connects to a 354 BFCP WebSocket server and performs the connection handshake. As 355 described in Section 3 the handshake procedure involves a HTTP GET 356 method request from the client and a response from the server 357 including an HTTP 101 status code. 359 In order to authorize the WebSocket connection, the BFCP WebSocket 360 server MAY inspect any cookie [RFC6265] headers present in the HTTP 361 GET request. For many web applications the value of such a cookie is 362 provided by the web server once the user has authenticated themselves 363 to the web server, which could be done by many existing mechanisms. 364 As an alternative method, the BFCP WebSocket Server could request 365 HTTP authentication by replying to the Client's GET method request 366 with a HTTP 401 status code. The WebSocket protocol [RFC6455] covers 367 this usage in section 4.1: 369 If the status code received from the server is not 101, the 370 WebSocket client stack handles the response per HTTP [RFC2616] 371 procedures, in particular the client might perform authentication 372 if it receives 401 status code. 374 8. Security Considerations 376 Considerations from [I-D.ietf-bfcpbis-rfc4582bis], 377 [I-D.ietf-bfcpbis-rfc4583bis] and RFC5018 [RFC5018] apply. 379 BFCP relies on lower-layer security mechanisms to provide replay and 380 integrity protection and confidentiality. It is RECOMMENDED that the 381 BFCP traffic transported over a WebSocket communication be protected 382 by using a secure WebSocket connection (using TLS [RFC5246] over 383 TCP). 385 9. IANA Considerations 387 9.1. Registration of the WebSocket BFCP Sub-Protocol 389 This specification requests IANA to register the WebSocket BFCP sub- 390 protocol under the "WebSocket Subprotocol Name" Registry with the 391 following data: 393 Subprotocol Identifier: bfcp 395 Subprotocol Common Name: WebSocket Transport for BFCP (Binary Floor 396 Control Protocol) 398 Subprotocol Definition: TBD: this document 400 9.2. Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' 401 Values 403 This document defines two new values for the SDP 'proto' field under 404 the Session Description Protocol (SDP) Parameters registry. The 405 resulting entries are shown in Figure 1 below: 407 Value Reference 408 -------------- --------- 409 TCP/WS/BFCP [TBD: this document] 410 TCP/WSS/BFCP [TBD: this document] 412 Figure 1: Values for the SDP 'proto' field 414 9.3. Registration of the 'ws-uri' SDP media attribute 416 This section instructs the IANA to register the following SDP att- 417 field under the Session Description Protocol (SDP) Parameters 418 registry: 420 Contact name TBD 422 Attribute name ws-uri 424 Long-form attribute name Websocket Connection URI 426 Type of attribute Media level 428 Subject to charset No 429 Purpose of attribute The 'ws-uri' attribute is intended to be used 430 as connection URI for opening the WebSocket. 432 Allowed attribute values A ws-URI as defined in [RFC6455] 434 9.4. Acknowledgements 436 The authors want to thank Robert Welboun, from Acme Packet, who made 437 significant contributions to the first version of this document. 439 10. References 441 10.1. Normative References 443 [I-D.ietf-bfcpbis-rfc4582bis] 444 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 445 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 446 ietf-bfcpbis-rfc4582bis-11 (work in progress), February 447 2014. 449 [I-D.ietf-bfcpbis-rfc4583bis] 450 Camarillo, G. and T. Kristensen, "Session Description 451 Protocol (SDP) Format for Binary Floor Control Protocol 452 (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-09 (work in 453 progress), February 2014. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, March 1997. 458 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 459 the Session Description Protocol (SDP)", RFC 4145, 460 September 2005. 462 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 463 Specifications: ABNF", RFC 4234, October 2005. 465 [RFC5018] Camarillo, G., "Connection Establishment in the Binary 466 Floor Control Protocol (BFCP)", RFC 5018, September 2007. 468 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 469 6455, December 2011. 471 10.2. Informative References 473 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 474 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 475 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 477 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 478 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 480 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 481 April 2011. 483 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 485 Authors' Addresses 487 Victor Pascual 488 Quobis 490 Email: victor.pascual@quobis.com 492 Anton Roman 493 Quobis 495 Email: anton.roman@quobis.com 497 Stephane Cazeaux 498 France Telecom Orange 500 Email: stephane.cazeaux@orange.com 502 Gonzalo Salgueiro 503 Cisco Systems, Inc. 504 7200-12 Kit Creek Road 505 Research Triangle Park, NC 27709 506 US 508 Email: gsalguei@cisco.com 510 Sergio Garcia Murillo 511 Medooze 513 Email: sergio.garcia.murillo@gmail.com