idnits 2.17.1 draft-ietf-bfcpbis-sdp-ws-uri-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 6, 2017) is 2629 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) == Outdated reference: A later version (-15) exists of draft-ietf-bfcpbis-bfcp-websocket-14 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BFCPBIS Working Group Ram. Ravindranath 3 Internet-Draft G. Salgueiro 4 Intended status: Standards Track Cisco 5 Expires: August 10, 2017 February 6, 2017 7 Session Description Protocol (SDP) WebSocket Connection URI Attribute 8 draft-ietf-bfcpbis-sdp-ws-uri-09 10 Abstract 12 The WebSocket protocol enables bidirectional real-time communication 13 between clients and servers in web-based applications. This document 14 specifies extensions to Session Description Protocol (SDP) for 15 application protocols using WebSocket as a transport. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 10, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. SDP Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. websocket-uri SDP Attribute . . . . . . . . . . . . . . . 3 56 3.3. websocket-uri Multiplexing Considerations . . . . . . . . 4 57 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 4 58 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Generating the Initial Offer . . . . . . . . . . . . . . 5 60 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 5 61 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 6 62 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 6 63 4.6. Offerless INVITE Scenarios . . . . . . . . . . . . . . . 7 64 5. Procedures at WebSocket Client . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Registration of the 'websocket-uri' SDP Media Attribute . 8 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 The WebSocket protocol [RFC6455] enables bidirectional message 77 exchange between clients and servers on top of a persistent TCP 78 connection (optionally secured with Transport Layer Security (TLS) 79 [RFC5246]). The initial protocol handshake makes use of Hypertext 80 Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket 81 protocol to reuse existing HTTP infrastructure. 83 Modern web browsers include a WebSocket client stack compliant with 84 the WebSocket API [WS-API] as specified by the W3C. It is expected 85 that other client applications (e.g., those running on personal 86 computers, mobile devices, etc.) will also make a WebSocket client 87 stack available. Several specifications have been written that 88 define how different applications can use a WebSocket subprotocol as 89 a reliable transport mechanism. 91 For example, [RFC7118] defines WebSocket subprotocol as a reliable 92 transport mechanism between Session Initiation Protocol 93 (SIP)[RFC3261] entities to enable use of SIP in web-oriented 94 deployments. Additionally, [RFC7977] defines a new WebSocket sub- 95 protocol as a reliable transport mechanism between Message Session 96 Relay Protocol (MSRP) clients and relays. [RFC7395] defines a 97 WebSocket subprotocol for the Extensible Messaging and Presence 98 Protocol (XMPP). Similarly, [I-D.ietf-bfcpbis-bfcp-websocket] 99 defines a WebSocket sub-protocol as a reliable transport mechanism 100 between Binary Floor Control Protocol (BFCP) 101 [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP in new 102 scenarios. 104 When WebSocket sub-protocol is used as a transport mechanism between 105 a server and client, there needs to be a way to indicate the 106 connection URI from the Server to the WebSocket Client. For 107 applications that use Session Description Protocol (SDP) [RFC4566] to 108 negotiate, the connection URI can be indicated by means of an SDP 109 attribute. This specification defines new SDP attributes to indicate 110 the connection URI for the WebSocket client. Applications that use 111 SDP for negotiation and WebSocket as a transport protocol can use 112 this specification to advertise the WebSocket client connection URI. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 [RFC2119]. 121 3. SDP Considerations 123 3.1. General 125 Applications that use the SDP Offer/Answer mechanism [RFC3264] for 126 negotiating media and also use WebSocket or secure WebSocket as a 127 transport protocol MAY indicate the connection URI for the WebSocket 128 Client via a new SDP a= media-level attribute defined in Section 3.2. 130 3.2. websocket-uri SDP Attribute 132 This section defines a new SDP media-level attribute, "websocket-uri" 133 which can appear in any of the media sections. 135 Example: 137 a=websocket-uri:wss://example.com/chat 139 Where "wss://example.com/chat" is the ws-URI defined in Section 3 of 140 [RFC6455]. 142 When the "websocket-uri" attribute is present in the media section of 143 the SDP, the IP address in 'c= ' line SHALL be ignored and the full 144 URI SHALL be used instead to open the WebSocket connection. The 145 clients MUST ensure that they use the URI to open the webSocket 146 connection and ignore the IP address in 'c=' line and port in m= 147 line. 149 3.3. websocket-uri Multiplexing Considerations 151 Multiplexing characteristics of SDP attributes are described in 152 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 153 multiplexing categories are introduced there. 155 o The multiplexing category of the "a=websocket-uri:" attribute is 156 CAUTION. 158 There are no multiplexing rules specified for the "websocket-uri" SDP 159 media-level attribute. Additionally, the specification of 160 multiplexing rules for the 'websocket-uri'attribute is outside the 161 scope of this document. 163 While it is technically possible to bundle WebSocket, there are a 164 variety of reasons that make it impractical and it is thus considered 165 unlikely to be used in practice. Therefore, the "websocket-uri" SDP 166 media-level attribute defined in Section 3.2 for using WebSocket as a 167 transport protocol is not likely to be used with SDP bundle and is 168 consequently categorized as CAUTION for multiplexing. 170 If future extensions define how to bundle WebSocket then multiplexing 171 rules for the "a=websocket-uri:" attribute need to be defined as 172 well, for instance in an extension of this SDP based WebSocket 173 negotiation specification. 175 4. SDP Offer/Answer Procedures 177 4.1. General 179 An endpoint (i.e., both the offerer and the answerer) that wishes to 180 negotiate WebSocket as transport protocol MUST indicate that it 181 wishes to use WebSocket or secure WebSocket in the "proto" field of 182 the "m=" line. Furthermore, the server side, which could be either 183 the offerer or answerer, MUST add an "a=websocket-uri" attribute in 184 the media section whose value can be either "ws-URI" or "wss-URI" 185 defined in Section 3 [RFC6455] depending on whether it wishes to use 186 WebSocket or secure WebSocket. This new attribute MUST follow the 187 syntax defined in Section 3. The procedures in this section apply to 188 an "m=" line associated with any media stream that uses WebSocket or 189 secure WebSocket as transport. 191 Both offerer or answerer can initiate a webSocket connection. It is 192 expected that based on the topology (for example, if the client is 193 behind NAT and server is on global IP address) the offerer and 194 answers applications decides on who will initiate the webSocket 195 connection and appropriately set the "setup" attribute in SDP 196 following the procedures of [RFC4145]. 198 4.2. Generating the Initial Offer 200 An SDP offerer in order to negotiate WebSocket as a transport MUST 201 indicate the same in the "proto" field of the "m=" line. For 202 example, to negotiate BFCP-over-WebSocket the "proto" value in the 203 "m=" line is TCP/WSS/BFCP if WebSocket is over TLS, else it is 204 TCP/WS/BFCP as specified in [I-D.ietf-bfcpbis-bfcp-websocket]. 206 The offerer SHOULD assign the SDP "setup" attribute with a value of 207 "active" (the offerer will be the initiator of the outgoing TCP 208 connection) or "passive" if the offerer wishes to be a receiver of an 209 incoming connection. The offerer MUST NOT assign an SDP "setup" 210 attribute with a "holdconn" value. The offerer MUST follow the 211 procedures described in [RFC4145] while using the "setup" attribute. 212 If the "setup" attribute has a value "passive" it MUST have a URI in 213 the "a=websocket-uri" attribute. 215 The following is an example of an "m=" line for a BFCP connection: 217 Offer (browser): 218 m=application 9 TCP/WSS/BFCP * 219 a=setup:active 220 a=connection:new 221 a=floorctrl:c-only 222 m=audio 55000 RTP/AVP 0 223 m=video 55002 RTP/AVP 31 225 In the above example, the client is intending to setup the TLS /TCP 226 connection and hence the port is set to a value of 9, which is the 227 discard port. 229 4.3. Generating the Answer 231 If the answerer accepts the offered WebSocket transport connection, 232 in the associated SDP answer, the answerer MUST assign an SDP "setup" 233 attribute with a value of either "active" or "passive", according to 234 the procedures in [RFC4145]. The answerer MUST NOT assign an SDP 235 "setup" attribute with a value of "holdconn". 237 If the answerer assigns an SDP "setup" attribute with a value of 238 "active", the answerer MUST initiate the WebSocket connection 239 handshake by acting as client on the negotiated media stream, towards 240 the URI specified in "a=websocket-uri" SDP attribute using the 241 procedures described in Section 4 of [RFC6455]. 243 If the answers assigns SDP "setup" attribute with "passive", then it 244 MUST have a "ws-URI" or "wss-URI" defined in Section 3 of [RFC6455] 245 in "a=websocket-uri" SDP attribute depending on whether the 246 application uses WebSocket or secureWebSocket. This attribute MUST 247 follow the syntax defined in Section 3. 249 The following example shows a case where the server responds with a 250 BFCP media stream over a WebSocket connection running TLS. It shows 251 an answer "m=" line for the BFCP connection. In this example since 252 WebSockets is running over TLS, the server answers back with 253 "a=websocket-uri" attribute in the media section of SDP having a 254 "wss-URI" connection URI: 256 Answer (server): 257 m=application 50000 TCP/WSS/BFCP * 258 a=setup:passive 259 a=connection:new 260 a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312 261 a=floorctrl:s-only 262 a=confid:4321 263 a=userid:1234 264 a=floorid:1 m-stream:10 265 a=floorid:2 m-stream:11 266 m=audio 50002 RTP/AVP 0 267 a=label:10 268 m=video 50004 RTP/AVP 31 269 a=label:11 271 4.4. Offerer Processing of the Answer 273 When the offerer receives an SDP answer, if the offerer ends up being 274 active it MUST follow the procedures in Section 5. 276 4.5. Modifying the Session 278 Once an offer/answer exchange has been completed, either endpoint MAY 279 send a new offer in order to modify the session. The endpoints can 280 reuse the existing WebSocket connection by adding 281 "a=connection:existing" attribute in the media section of SDP 282 following the rules mentioned in [RFC4145] if the "websocket-uri" SDP 283 value and the transport parameters indicated by each endpoint are 284 unchanged. Otherwise, following the rules for the initial offer/ 285 answer exchange, the endpoints can negotiate and create a new 286 WebSocket connection on top of TLS/TCP or TCP. 288 4.6. Offerless INVITE Scenarios 290 In some scenarios an endpoint (e.g., a browser) originating the call 291 (UAC) can send an offerless INVITE to the server. The server will 292 generate an offer in response to the INVITE. In such cases the 293 server MUST send an offer with setup attribute as "passive" so as to 294 accept incoming connection and MUST include "a=websocket-uri" 295 attribute in the media section whose value MUST be either "ws-URI" or 296 "wss-URI" depending on whether the server wishes to use WebSocket or 297 secure WebSocket. The SDP offer sent by the server will look like 298 the example in Section 4.3. 300 5. Procedures at WebSocket Client 302 The webSocket client MUST always initiate the outgoing TCP connection 303 and hence the SDP a=setup attribute MUST be always "active" for the 304 WebSocket client in its SDP offer/answer. In the below example, the 305 WebSocket client is the offerer and hence assigns "setup" attribute 306 with a value of "active". 308 The WebSocket server is a server on the Internet and hence MUST 309 always assign SDP "setup" attribute with a value of "passive". This 310 also avoids the need to use ICE between WebSocket Client and 311 WebSocket Server as the connection model here would be a typical 312 client to server web connection. 314 Once the offer/answer is complete the client MUST initiate the 315 WebSocket connection handshake by sending a GET message on the 316 negotiated media stream, towards the URI specified in "a=websocket- 317 uri" as per the procedures described in [RFC6455]. When no port is 318 passed in the "a=websocket-uri" attribute, the default port (80 or 319 443) is used depending on whether the value has "ws-URI" or "wss- 320 URI". 322 6. Security Considerations 324 An attacker may attempt to add, modify, or remove "a=websocket-uri" 325 attribute from a session description. This could result in an 326 application behaving undesirably. Consequently, it is RECOMMENDED 327 that integrity protection be applied to the SDP session descriptions. 328 For session descriptions carried in SIP [RFC3261], S/MIME is 329 available to provide such end-to-end integrity protection. 331 As described in Section 10 of [RFC6455], application signalling 332 traffic being transported over WebSocket MUST support secure 333 WebSocket and SHOULD employ it when communicating with their peers. 335 The WebSocket clients have to initiate the TCP connection to the 336 WebSocket server identified by the FQDN in a=websocket-uri. Further 337 as with any other web connection, the clients will verify the servers 338 certificate. The WebSocket client MUST follow the procedures in 339 [RFC7525] (including hostname verification as per section 6.1 in 340 [RFC7525]) while setting up TLS connection with webSocket server. 342 7. IANA Considerations 344 7.1. Registration of the 'websocket-uri' SDP Media Attribute 346 NOTE to RFC Editor: Please replace "XXXX" with the number of this 347 RFC. 349 This document defines a new SDP media-level attribute "websocket-uri" 350 in Section 3.2 and requests that IANA to register the following SDP 351 att-field under the Session Description Protocol (SDP) Parameters 352 registry as follows: 354 +---------------------+---------------------------------------------+ 355 | Attribute name: | websocket-uri | 356 | Long-form attribute | Websocket Connection URI | 357 | name: | | 358 | Type of attribute: | media | 359 | Mux category: | CAUTION | 360 | Charset Dependent: | No | 361 | Purpose: | The 'websocket-uri' attribute is intended | 362 | | to be used as a connection URI for opening | 363 | | the WebSocket connection. | 364 | Appropriate values: | A ws-URI or wss-URI as defined in Section | 365 | | 3 of [RFC6455] | 366 | Contact name: | Gonzalo Salgueiro | 367 | Contact e-mail: | gsalguei@cisco.com | 368 | Reference: | RFCXXXX | 369 +---------------------+---------------------------------------------+ 371 8. Acknowledgements 373 Thanks to Christer Holmberg for raising the need for a BFCP- 374 independent SDP attribute for WebSocket Connection URI. 376 The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, 377 Christer Holmberg, Charles Eckel, Dan Wing, Alissa Cooper and Joel 378 Halpern for their invaluable suggestions and review comments. 380 Thanks to Mirja Kuehlewind, Alexey Melnikov, Ben Campbell and 381 Kathleen Moriarty for their comments and feedback during IESG 382 reviews. 384 9. References 386 9.1. Normative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, 391 . 393 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 394 the Session Description Protocol (SDP)", RFC 4145, 395 DOI 10.17487/RFC4145, September 2005, 396 . 398 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 399 RFC 6455, DOI 10.17487/RFC6455, December 2011, 400 . 402 9.2. Informative References 404 [I-D.ietf-bfcpbis-bfcp-websocket] 405 Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R., 406 and S. Murillo, "The WebSocket Protocol as a Transport for 407 the Binary Floor Control Protocol (BFCP)", draft-ietf- 408 bfcpbis-bfcp-websocket-14 (work in progress), January 409 2017. 411 [I-D.ietf-bfcpbis-rfc4582bis] 412 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 413 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 414 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 415 2015. 417 [I-D.ietf-mmusic-sdp-mux-attributes] 418 Nandakumar, S., "A Framework for SDP Attributes when 419 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 420 (work in progress), December 2016. 422 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 423 A., Peterson, J., Sparks, R., Handley, M., and E. 424 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 425 DOI 10.17487/RFC3261, June 2002, 426 . 428 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 429 with Session Description Protocol (SDP)", RFC 3264, 430 DOI 10.17487/RFC3264, June 2002, 431 . 433 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 434 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 435 July 2006, . 437 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 438 (TLS) Protocol Version 1.2", RFC 5246, 439 DOI 10.17487/RFC5246, August 2008, 440 . 442 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 443 "The WebSocket Protocol as a Transport for the Session 444 Initiation Protocol (SIP)", RFC 7118, 445 DOI 10.17487/RFC7118, January 2014, 446 . 448 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 449 Protocol (HTTP/1.1): Message Syntax and Routing", 450 RFC 7230, DOI 10.17487/RFC7230, June 2014, 451 . 453 [RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An 454 Extensible Messaging and Presence Protocol (XMPP) 455 Subprotocol for WebSocket", RFC 7395, 456 DOI 10.17487/RFC7395, October 2014, 457 . 459 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 460 "Recommendations for Secure Use of Transport Layer 461 Security (TLS) and Datagram Transport Layer Security 462 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 463 2015, . 465 [RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 466 and R. Ravindranath, "The WebSocket Protocol as a 467 Transport for the Message Session Relay Protocol (MSRP)", 468 RFC 7977, DOI 10.17487/RFC7977, September 2016, 469 . 471 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 473 Authors' Addresses 474 Ram Mohan Ravindranath 475 Cisco Systems, Inc. 476 Cessna Business Park, 477 Kadabeesanahalli Village, Varthur Hobli, 478 Sarjapur-Marathahalli Outer Ring Road 479 Bangalore, Karnataka 560103 480 India 482 Email: rmohanr@cisco.com 484 Gonzalo Salgueiro 485 Cisco Systems, Inc. 486 7200-12 Kit Creek Road 487 Research Triangle Park, NC 27709 488 US 490 Email: gsalguei@cisco.com