idnits 2.17.1 draft-ietf-bfcpbis-sdp-ws-uri-02.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 2, 2016) is 2915 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-06 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-12 == Outdated reference: A later version (-15) exists of draft-pd-dispatch-msrp-websocket-11 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- 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 7235 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 5 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: November 3, 2016 May 2, 2016 7 Session Description Protocol (SDP) WebSocket Connection URI Attribute 8 draft-ietf-bfcpbis-sdp-ws-uri-02 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 November 3, 2016. 34 Copyright Notice 36 Copyright (c) 2016 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. ws-uri SDP Attribute . . . . . . . . . . . . . . . . . . 3 56 3.3. wss-uri SDP Attribute . . . . . . . . . . . . . . . . . . 4 57 3.4. ws-uri and wss-uri Multiplexing Considerations . . . . . 4 58 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 59 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Generating the Initial Offer . . . . . . . . . . . . . . 5 61 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6 62 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7 63 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7 64 4.6. Offerless INVITE Scenarios . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 The WebSocket protocol [RFC6455] enables bidirectional message 76 exchange between clients and servers on top of a persistent TCP 77 connection (optionally secured with Transport Layer Security (TLS) 78 [RFC5246]). The initial protocol handshake makes use of Hypertext 79 Transfer Protocol (HTTP) [RFC7235] semantics, allowing the WebSocket 80 protocol to reuse existing HTTP infrastructure. 82 Modern web browsers include a WebSocket client stack compliant with 83 the WebSocket API [WS-API] as specified by the W3C. It is expected 84 that other client applications (e.g., those running on personal 85 computers, mobile devices, etc.) will also make a WebSocket client 86 stack available. Several specifications have been written that 87 define how different applications can use a WebSocket subprotocol as 88 a reliable transport mechanism. 90 For example, [RFC7118] defines WebSocket subprotocol as a reliable 91 transport mechanism between Session Initiation Protocol 92 (SIP)[RFC3261] entities to enable use of SIP in web-oriented 93 deployments. Additionally, [I-D.pd-dispatch-msrp-websocket] defines 94 a new WebSocket sub-protocol as a reliable transport mechanism 95 between Message Session Relay Protocol (MSRP) clients and relays. 96 [RFC7395] defines a WebSocket subprotocol for the Extensible 97 Messaging and Presence Protocol (XMPP). Similarly, 98 [I-D.ietf-bfcpbis-bfcp-websocket] defines a WebSocket sub-protocol as 99 a reliable transport mechanism between Binary Floor Control Protocol 100 (BFCP) [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP 101 in new scenarios. 103 As defined in Section 3 of [RFC2818], when using Secure WebSockets 104 the Canonical Name (CNAME) of the Secure Sockets Layer (SSL) 105 [RFC6101] certificate MUST match the WebSocket connection URI host. 106 While it is possible to generate self-signed certificates with 107 Internet Providers (IPs) as CNAME, in most cases it is not viable for 108 certificates signed by well known authorities. Thus, there is a need 109 to indicate the connection URI for the WebSocket Client. For 110 applications that use Session Description Protocol (SDP) [RFC4566] to 111 negotiate, the connection URI can be indicated by means of an SDP 112 attribute. This specification defines new SDP attributes to indicate 113 the connection URI for the WebSocket client. Applications that use 114 SDP for negotiation and WebSocket as a transport protocol can use 115 this specification to advertise the WebSocket client connection URI. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. SDP Considerations 125 3.1. General 127 Applications that use the SDP Offer/Answer mechanism [RFC3264] for 128 negotiating media and also use WebSocket as a transport protocol MAY 129 indicate the connection URI for the WebSocket Client via a new SDP a= 130 media-level attribute defined in Section 3.2. 132 Applications that use SDP for negotiation and also use secure 133 WebSocket as a transport protocol TLS MAY indicate the connection URI 134 for the WebSocket Client via a new SDP a= media-level attribute 135 defined in Section 3.3. 137 3.2. ws-uri SDP Attribute 139 This section defines a new SDP media-level attribute, 'ws-uri' which 140 can appear in any of the media sections. 142 Name : ws-uri 144 Value: ws-uri (defined in Section 3 of [RFC6455]) 145 Usage Level: media 147 Mux Category: NOT RECOMMENDED 149 Charset Dependent: no 151 Example: 153 a=ws-uri:ws://example.com/chat 155 When the 'ws-uri' attribute is present in the media section of the 156 SDP, the IP address in 'c= ' line SHALL be ignored and the full URI 157 SHALL be used instead to open the WebSocket connection. The port 158 provided in the 'm= ' line SHALL be ignored too, as the 'a=ws-uri' 159 SHALL provide port number when needed. 161 3.3. wss-uri SDP Attribute 163 This section defines a new SDP media-level attribute, 'wss-uri' which 164 can appear in any of the media sections. 166 Name : wss-uri 168 Value: wss-uri (defined in Section 3 of [RFC6455]) 170 Usage Level: media 172 Mux Category: NOT RECOMMENDED 174 Charset Dependent: no 176 Example: 178 a=wss-uri:ws://example.com/chat 180 When the 'wss-uri' attribute is present in the media section of the 181 SDP, the IP address in 'c= ' line SHALL be ignored and the full URI 182 SHALL be used instead to open the secure WebSocket connection. The 183 port provided in the 'm= ' line SHALL be ignored too, as the 'a=wss- 184 uri' SHALL provide port number when needed. 186 3.4. ws-uri and wss-uri Multiplexing Considerations 188 Multiplexing characteristics of SDP attributes are described in 189 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 190 multiplexing categories are introduced there. 192 Section 3.2 and Section 3.3 describes the multiplex category for the 193 new attributes in this document. 195 There are no multiplexing rules specified for the ws-uri and wss-uri 196 SDP media-level attributes. Additionally, the specification of 197 multiplexing rules for the ws-uri and wss-uri attributes is outside 198 the scope of this document. 200 While it is technically possible to bundle WebSocket, there are a 201 variety of reasons that make it impractical and it is thus considered 202 unlikely to be used in practice. Therefore, the ws-uri and wss-uri 203 SDP media-level attributes defined in Section 3.2 and Section 3.3 for 204 using WebSocket as a transport protocol are not likely to be used 205 with SDP bundle and are consequently categorized as NOT RECOMMENDED 206 for multiplexing. 208 If future extensions define how to bundle WebSocket then multiplexing 209 rules for the "a=ws-uri:" and "a=wss-uri:" attributes need to be 210 defined as well, for instance in an extension of this SDP based 211 WebSocket negotiation specification. 213 4. SDP Offer/Answer Procedures 215 4.1. General 217 An endpoint (i.e., both the offerer and the answerer) that wishes to 218 negotiate WebSocket as transport protocol MUST indicate that it 219 wishes to use WebSocket or secure WebSocket in the "proto" field of 220 the "m=" line. Furthermore, the server side, which could be either 221 the offerer or answerer, MUST add an "a=ws-uri" or "a=wss-uri" 222 attribute in the media section depending on whether it wishes to use 223 WebSocket or secure WebSocket. This new attribute MUST follow the 224 syntax defined in Section 3. The procedures in this section apply to 225 an "m=" line associated with any media stream that uses WebSocket or 226 secure WebSocket as transport. 228 4.2. Generating the Initial Offer 230 An SDP offerer in order to negotiate WebSocket as a transport MUST 231 indicate the same in the "proto" field of the "m=" line. For 232 example, to negotiate BFCP-over-WebSocket the "proto" value in the 233 "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST 234 be TCP/WS/BFCP. 236 The offerer SHOULD assign the SDP "setup" attribute with a value of 237 "active" (the offerer will be the initiator of the outgoing TCP 238 connection), unless the offerer insists on being a receiver of an 239 incoming connection, in which case the offerer SHOULD use a value of 240 "passive". The offerer MUST NOT assign an SDP "setup" attribute with 241 a "holdconn" value. If the offerer assigns the SDP "setup" attribute 242 with a value of "passive", the offerer MUST be prepared to receive an 243 incoming TCP connection on the IP and port tuple advertised in the 244 "c=" line and audio/video ports of the BFCP media stream before it 245 receives the SDP answer. 247 The following is an example of an "m=" line for a BFCP connection: 249 Offer (browser): 250 m=application 9 TCP/WSS/BFCP * 251 a=setup:active 252 a=connection:new 253 a=floorctrl:c-only 254 m=audio 55000 RTP/AVP 0 255 m=video 55002 RTP/AVP 31 257 In the above example, the client is intending to setup the TLS /TCP 258 connection and hence the port is set to a value of 9, which is the 259 discard port. 261 4.3. Generating the Answer 263 If the answerer accepts the offered WebSocket transport connection, 264 in the associated SDP answer, the answerer MUST assign an SDP "setup" 265 attribute with a value of either "active" or "passive", according to 266 the procedures in [RFC4145]. The answerer MUST NOT assign an SDP 267 "setup" attribute with a value of "holdconn". 269 If the answerer assigns an SDP "setup" attribute with a value of 270 "active", the answerer MUST initiate the WebSocket connection 271 handshake by acting as client on the negotiated media stream, towards 272 the IP address and port of the offerer using the procedures described 273 in [RFC6455]. The answer MUST have an "a=ws-uri" or "a=wss-uri" 274 attribute depending on whether the application is run of WS or WSS. 275 This attribute MUST follow the syntax defined in Section 3. For BFCP 276 application, the "proto" value in the "m=" line MUST be TCP/WSS/BFCP 277 if WebSocket is run on TLS, else it MUST be TCP/WS/BFCP. 279 The following example shows a case where the server responds with a 280 BFCP media stream over a WebSocket connection running TLS. It shows 281 an answer "m=" line for the BFCP connection. In this example since 282 WebSockets is running over TLS, the server answers back with "a=wss- 283 uri" attribute in the media section of SDP indicating the connection 284 URI: 286 Answer (server): 287 m=application 50000 TCP/WSS/BFCP * 288 a=setup:passive 289 a=connection:new 290 a=wss-uri:wss://bfcp-ws.example.com?token=3170449312 291 a=floorctrl:s-only 292 a=confid:4321 293 a=userid:1234 294 a=floorid:1 m-stream:10 295 a=floorid:2 m-stream:11 296 m=audio 50002 RTP/AVP 0 297 a=label:10 298 m=video 50004 RTP/AVP 31 299 a=label:11 301 4.4. Offerer Processing of the Answer 303 When the offerer receives an SDP answer, if the offerer ends up being 304 active it MUST initiate the WebSocket connection handshake by sending 305 a GET message on the negotiated media stream, towards the IP address 306 and port of the answerer, as per the procedures described in 307 [RFC6455]. 309 4.5. Modifying the Session 311 Once an offer/answer exchange has been completed, either endpoint MAY 312 send a new offer in order to modify the session. The endpoints can 313 reuse the existing WebSocket connection by adding 314 "a=connection:existing" attribute in the media section of SDP 315 following the rules mentioned in [RFC4145] if the ws-uri values and 316 the transport parameters indicated by each endpoint are unchanged. 317 Otherwise, following the rules for the initial offer/answer exchange, 318 the endpoints can negotiate and create a new WebSocket connection on 319 top of TLS/TCP or TCP. 321 4.6. Offerless INVITE Scenarios 323 In some scenarios an endpoint (e.g., a browser) originating the call 324 (UAC) can send an offerless INVITE to the server. The server will 325 generate an offer in response to the INVITE. In such cases the 326 server MUST send an offer with setup attribute as "passive" so as to 327 accept incoming connection and MUST include "a=wss-uri" or "a=ws-uri" 328 attribute in the media section depending on whether the server wishes 329 to use WebSocket or secure WebSocket. The SDP offer sent by the 330 server will look like the example in Section 4.3. 332 5. Security Considerations 334 An attacker may attempt to add, modify, or remove 'a=ws-uri' or 335 'a=wss-uri' attribute from a session description. This could result 336 in an application behaving undesirably. Consequently, it is strongly 337 RECOMMENDED that integrity protection be applied to the SDP session 338 descriptions. For session descriptions carried in SIP [RFC3261], S/ 339 MIME is the natural choice to provide such end-to-end integrity 340 protection. 342 It is also RECOMMENDED that the application signaling traffic being 343 transported over a WebSocket communication session be protected by 344 using a secure WebSocket connection (using TLS [RFC5246] over TCP). 346 6. IANA Considerations 348 NOTE to RFC Editor: Please replace "XXXX" with the number of this 349 RFC. 351 This document requests that IANA to register the attributes defined 352 in Section 3.2 and Section 3.3 as new values for the SDP att-field 353 under the Session Description Protocol (SDP) Parameters registry, 354 with RFCXXXX as the reference. 356 7. Acknowledgements 358 Thanks to Christer Holmberg for raising the need for a BFCP- 359 independent SDP attribute for WebSocket Connection URI. 361 The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar and 362 Christer Holmberg for their invaluable suggestions and review 363 comments. 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 375 the Session Description Protocol (SDP)", RFC 4145, 376 DOI 10.17487/RFC4145, September 2005, 377 . 379 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 380 RFC 6455, DOI 10.17487/RFC6455, December 2011, 381 . 383 8.2. Informative References 385 [I-D.ietf-bfcpbis-bfcp-websocket] 386 Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R., 387 and S. Murillo, "The WebSocket Protocol as a Transport for 388 the Binary Floor Control Protocol (BFCP)", draft-ietf- 389 bfcpbis-bfcp-websocket-06 (work in progress), February 390 2016. 392 [I-D.ietf-bfcpbis-rfc4582bis] 393 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 394 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 395 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 396 2015. 398 [I-D.ietf-mmusic-sdp-mux-attributes] 399 Nandakumar, S., "A Framework for SDP Attributes when 400 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 401 (work in progress), January 2016. 403 [I-D.pd-dispatch-msrp-websocket] 404 Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 405 and R. R, "The WebSocket Protocol as a Transport for the 406 Message Session Relay Protocol (MSRP)", draft-pd-dispatch- 407 msrp-websocket-11 (work in progress), May 2016. 409 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 410 DOI 10.17487/RFC2818, May 2000, 411 . 413 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 414 A., Peterson, J., Sparks, R., Handley, M., and E. 415 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 416 DOI 10.17487/RFC3261, June 2002, 417 . 419 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 420 with Session Description Protocol (SDP)", RFC 3264, 421 DOI 10.17487/RFC3264, June 2002, 422 . 424 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 425 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 426 July 2006, . 428 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 429 (TLS) Protocol Version 1.2", RFC 5246, 430 DOI 10.17487/RFC5246, August 2008, 431 . 433 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 434 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 435 DOI 10.17487/RFC6101, August 2011, 436 . 438 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 439 "The WebSocket Protocol as a Transport for the Session 440 Initiation Protocol (SIP)", RFC 7118, 441 DOI 10.17487/RFC7118, January 2014, 442 . 444 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 445 Protocol (HTTP/1.1): Authentication", RFC 7235, 446 DOI 10.17487/RFC7235, June 2014, 447 . 449 [RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An 450 Extensible Messaging and Presence Protocol (XMPP) 451 Subprotocol for WebSocket", RFC 7395, 452 DOI 10.17487/RFC7395, October 2014, 453 . 455 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 457 Authors' Addresses 459 Ram Mohan Ravindranath 460 Cisco Systems, Inc. 461 Cessna Business Park, 462 Kadabeesanahalli Village, Varthur Hobli, 463 Sarjapur-Marathahalli Outer Ring Road 464 Bangalore, Karnataka 560103 465 India 467 Email: rmohanr@cisco.com 468 Gonzalo Salgueiro 469 Cisco Systems, Inc. 470 7200-12 Kit Creek Road 471 Research Triangle Park, NC 27709 472 US 474 Email: gsalguei@cisco.com