idnits 2.17.1 draft-ram-bfcpbis-sdp-ws-uri-03.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 (February 16, 2016) is 2992 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-10 -- 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 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) 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: August 19, 2016 February 16, 2016 7 Session Description Protocol (SDP) WebSocket Connection URI Attribute 8 draft-ram-bfcpbis-sdp-ws-uri-03 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 19, 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 Category . . . . . . . . 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 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6.1. Registration of the 'ws-uri' SDP Media Attribute . . . . 8 67 6.2. Registration of the 'wss-uri' SDP Media Attribute . . . . 8 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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) [RFC2616] 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, [I-D.pd-dispatch-msrp-websocket] defines 95 a new WebSocket sub-protocol as a reliable transport mechanism 96 between Message Session Relay Protocol (MSRP) clients and relays. 98 [RFC7395] defines a WebSocket subprotocol for the Extensible 99 Messaging and Presence Protocol (XMPP). Similarly, 100 [I-D.ietf-bfcpbis-bfcp-websocket] defines a WebSocket sub-protocol as 101 a reliable transport mechanism between Binary Floor Control Protocol 102 (BFCP) [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP 103 in new scenarios. 105 As defined in Section 3 of [RFC2818], when using Secure WebSockets 106 the Canonical Name (CNAME) of the Secure Sockets Layer (SSL) 107 [RFC6101] certificate MUST match the WebSocket connection URI host. 108 While it is possible to generate self-signed certificates with 109 Internet Providers (IPs) as CNAME, in most cases it is not viable for 110 certificates signed by well known authorities. Thus, there is a need 111 to indicate the connection URI for the WebSocket Client. For 112 applications that use Session Description Protocol (SDP) [RFC4566] to 113 negotiate, the connection URI can be indicated by means of an SDP 114 attribute. This specification defines new SDP attributes to indicate 115 the connection URI for the WebSocket client. Applications that use 116 SDP for negotiation and WebSocket as a transport protocol can use 117 this specification to advertise the WebSocket client connection URI. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. SDP Considerations 127 3.1. General 129 Applications that use the SDP Offer/Answer mechanism [RFC3264] for 130 negotiating media and also use WebSocket as a transport protocol MAY 131 indicate the connection URI for the WebSocket Client via a new SDP a= 132 media-level attribute defined in Section 3.2. 134 Applications that use SDP for negotiation and also use secure 135 WebSocket as a transport protocol TLS MAY indicate the connection URI 136 for the WebSocket Client via a new SDP a= media-level attribute 137 defined in Section 3.3. 139 3.2. ws-uri SDP Attribute 141 This section defines a new SDP media-level attribute, 'ws-uri' which 142 can appear in any of the media lines. When the 'ws-uri' attribute is 143 present in the media section of the SDP, the IP address in 'c= ' line 144 SHALL be ignored and the full URI SHALL be used instead to open the 145 WebSocket connection. The port provided in the 'm= ' line SHALL be 146 ignored too, as the 'a=ws-uri' SHALL provide port number when needed. 148 The Augmented Backus-Naur Form (ABNF) syntax (as described in 149 [RFC5234]) of this new attribute is defined as follows: 151 ws-uri = "a=ws-uri:" ws-URI 153 Where ws-URI is defined in Section 3 of [RFC6455]. 155 3.3. wss-uri SDP Attribute 157 This section defines a new SDP media-level attribute, 'wss-uri' which 158 can appear in any of the media lines. When the 'wss-uri' attribute 159 is present in the media section of the SDP, the IP address in 'c= ' 160 line SHALL be ignored and the full URI SHALL be used instead to open 161 the secure WebSocket connection. The port provided in the 'm= ' line 162 SHALL be ignored too, as the 'a=wss-uri' SHALL provide port number 163 when needed. 165 The Augmented Backus-Naur Form (ABNF) syntax (as described in 166 [RFC5234]) of this new attribute is defined as follows: 168 wss-uri = "a=wss-uri:" wss-URI 170 Where wss-URI is defined in Section 3 of [RFC6455]. 172 3.4. ws-uri and wss-uri Multiplexing Category 174 Multiplexing characteristics of SDP attributes are described in 175 [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute 176 multiplexing categories are introduced there. 178 o The multiplexing category of the "a=ws-uri:" attribute is NOT 179 RECOMMENDED. 181 o The multiplexing category of the "a=ws-uri:" attribute is NOT 182 RECOMMENDED. 184 There are no multiplexing rules specified for the ws-uri and wss-uri 185 SDP media-level attributes. Additionally, the specification of 186 multiplexing rules for the ws-uri and wss-uri attributes is outside 187 the scope of this document. 189 While it is technically possible to bundle WebSocket, there are a 190 variety of reasons that make it impractical and it is thus considered 191 unlikely to be used in practice. Therefore, the ws-uri and wss-uri 192 SDP media-level attributes defined in Section 3.2 and Section 3.3 for 193 using WebSocket as a transport protocol are not likely to be used 194 with SDP bundle and are consequently categorized as NOT RECOMMENDED 195 for multiplexing. 197 If future extensions define how to bundle WebSocket then multiplexing 198 rules for the "a=ws-uri:" and "a=wss-uri:" attributes need to be 199 defined as well, for instance in an extension of this SDP based 200 WebSocket negotiation specification. 202 4. SDP Offer/Answer Procedures 204 4.1. General 206 An endpoint (i.e., both the offerer and the answerer) that wishes to 207 negotiate WebSocket as transport protocol MUST indicate that it 208 wishes to use WebSocket or secureWebSocket in the "proto" field of 209 the "m=" line. Furthermore, the SDP answerer MUST add an "a=ws-uri" 210 or "a=wss-uri" attribute in the "m=" line of each media-line 211 depending on whether the "proto" field has WebSocket or 212 secureWebSocket. This new attribute MUST follow the syntax defined 213 in Section 3. The procedures in this section apply to an "m=" line 214 associated with any media stream that uses WebSocket or 215 secureWebSocket as transport. 217 4.2. Generating the Initial Offer 219 An SDP offerer in order to negotiate WebSocket as a transport MUST 220 indicate the same in the "proto" field of the "m=" line. For 221 example, to negotiate BFCP-over-WebSocket the "proto" value in the 222 "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST 223 be TCP/WS/BFCP. 225 The offerer SHOULD assign the SDP "setup" attribute with a value of 226 "active" (the offerer will be the initiator of the outgoing TCP 227 connection), unless the offerer insists on being a receiver of an 228 incoming connection, in which case the offerer SHOULD use a value of 229 "passive". The offerer MUST NOT assign an SDP "setup" attribute with 230 a "holdconn" value. If the offerer assigns the SDP "setup" attribute 231 with a value of "passive", the offerer MUST be prepared to receive an 232 incoming TCP connection on the IP and port tuple advertised in the 233 "c=" line and audio/video ports of the BFCP media stream before it 234 receives the SDP answer. 236 The following is an example of an "m=" line for a BFCP connection: 238 Offer (browser): 239 m=application 9 TCP/WSS/BFCP * 240 a=setup:active 241 a=connection:new 242 a=floorctrl:c-only 243 m=audio 55000 RTP/AVP 0 244 m=video 55002 RTP/AVP 31 246 In the above example, the client is intending to setup the TLS /TCP 247 connection and hence the port is set to a value of 9, which is the 248 discard port. 250 4.3. Generating the Answer 252 If the answerer accepts the offered WebSocket transport connection, 253 in the associated SDP answer, the answerer MUST assign an SDP "setup" 254 attribute with a value of either "active" or "passive", according to 255 the procedures in [RFC4145]. The answerer MUST NOT assign an SDP 256 "setup" attribute with a value of "holdconn". 258 If the answerer assigns an SDP "setup" attribute with a value of 259 "active", the answerer MUST initiate the WebSocket connection 260 handshake by acting as client on the negotiated media stream, towards 261 the IP address and port of the offerer using the procedures described 262 in [RFC6455]. The answer MUST have an "a=ws-uri" or "a=wss-uri" 263 attribute depending on whether the application is run of WS or WSS. 264 This attribute MUST follow the syntax defined in Section 3. For BFCP 265 application, the "proto" value in the "m=" line MUST be TCP/WSS/BFCP 266 if WebSocket is run on TLS, else it MUST be TCP/WS/BFCP. 268 The following example shows a case where the server responds with a 269 BFCP media stream over a WebSocket connection running TLS. It shows 270 an answer "m=" line for the BFCP connection. In this example since 271 WebSockets is running over TLS, the server answers back with "a=wss- 272 uri" attribute in SDP indicating the connection URI: 274 Answer (server): 275 m=application 50000 TCP/WSS/BFCP * 276 a=setup:passive 277 a=connection:new 278 a=wss-uri:wss://bfcp-ws.example.com?token=3170449312 279 a=floorctrl:s-only 280 a=confid:4321 281 a=userid:1234 282 a=floorid:1 m-stream:10 283 a=floorid:2 m-stream:11 284 m=audio 50002 RTP/AVP 0 285 a=label:10 286 m=video 50004 RTP/AVP 31 287 a=label:11 289 4.4. Offerer Processing of the Answer 291 When the offerer receives an SDP answer, if the offerer ends up being 292 active it MUST initiate the WebSocket connection handshake by sending 293 a GET message on the negotiated media stream, towards the IP address 294 and port of the answerer, as per the procedures described in 295 [RFC6455]. 297 4.5. Modifying the Session 299 Once an offer/answer exchange has been completed, either endpoint MAY 300 send a new offer in order to modify the session. The endpoints can 301 reuse the existing WebSocket connection if the ws-uri values and the 302 transport parameters indicated by each endpoint are unchanged. 303 Otherwise, following the rules for the initial offer/answer exchange, 304 the endpoints can negotiate and create a new WebSocket connection on 305 top of TLS/TCP or TCP. 307 5. Security Considerations 309 An attacker may attempt to add, modify, or remove 'a=ws-uri' or 310 'a=wss-uri' attribute from a session description. This could result 311 in an application behaving undesirably. Consequently, it is strongly 312 RECOMMENDED that integrity protection be applied to the SDP session 313 descriptions. For session descriptions carried in SIP [RFC3261], S/ 314 MIME is the natural choice to provide such end-to-end integrity 315 protection. 317 It is also RECOMMENDED that the application signaling traffic being 318 transported over a WebSocket communication session be protected by 319 using a secure WebSocket connection (using TLS [RFC5246] over TCP). 321 6. IANA Considerations 323 6.1. Registration of the 'ws-uri' SDP Media Attribute 325 NOTE to RFC Editor: Please replace "XXXX" with the number of this 326 RFC. 328 This document defines a new SDP media-level attribute "a=ws-uri:" and 329 requests that IANA to register the following SDP att-field under the 330 Session Description Protocol (SDP) Parameters registry as follows: 332 +---------------------+---------------------------------------------+ 333 | Attribute name: | ws-uri | 334 | Long-form attribute | Websocket Connection URI | 335 | name: | | 336 | Type of attribute: | media | 337 | Mux category: | NOT RECOMMENDED | 338 | Charset Dependent: | No | 339 | Purpose: | The 'ws-uri' attribute is intended to be | 340 | | used as a connection URI for opening the | 341 | | WebSocket connection. | 342 | Appropriate values: | A ws-URI as defined in [RFC6455] | 343 | Contact name: | Gonzalo Salgueiro | 344 | Contact e-mail: | gsalguei@cisco.com | 345 | Reference: | RFCXXXX | 346 +---------------------+---------------------------------------------+ 348 6.2. Registration of the 'wss-uri' SDP Media Attribute 350 NOTE to RFC Editor: Please replace "XXXX" with the number of this 351 RFC. 353 This document defines a new SDP media-level attribute "a=wss-uri:" 354 and requests that IANA to register the following SDP att-field under 355 the Session Description Protocol (SDP) Parameters registry as 356 follows: 358 +---------------------+---------------------------------------------+ 359 | Attribute name: | wss-uri | 360 | Long-form attribute | Websocket Connection URI over Secure | 361 | name: | Transport | 362 | Type of attribute: | media | 363 | Mux category: | NOT RECOMMENDED | 364 | Charset Dependent: | No | 365 | Purpose: | The 'wss-uri' attribute is intended to be | 366 | | used as a connection URI for opening the | 367 | | WebSocket connection over a secure | 368 | | transport. | 369 | Appropriate values: | A wss-URI as defined in [RFC6455] | 370 | Contact name: | Gonzalo Salgueiro | 371 | Contact e-mail: | gsalguei@cisco.com | 372 | Reference: | RFCXXXX | 373 +---------------------+---------------------------------------------+ 375 7. Acknowledgements 377 Thanks to Christer Holmberg for raising the need for a BFCP- 378 independent SDP attribute for WebSocket Connection URI. 380 The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, and 381 Christer Holmberg for their invaluable suggestions and review 382 comments. 384 8. References 386 8.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 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 399 Specifications: ABNF", STD 68, RFC 5234, 400 DOI 10.17487/RFC5234, January 2008, 401 . 403 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 404 RFC 6455, DOI 10.17487/RFC6455, December 2011, 405 . 407 8.2. Informative References 409 [I-D.ietf-bfcpbis-bfcp-websocket] 410 Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R., 411 and S. Murillo, "The WebSocket Protocol as a Transport for 412 the Binary Floor Control Protocol (BFCP)", draft-ietf- 413 bfcpbis-bfcp-websocket-06 (work in progress), February 414 2016. 416 [I-D.ietf-bfcpbis-rfc4582bis] 417 Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. 418 Eckel, "The Binary Floor Control Protocol (BFCP)", draft- 419 ietf-bfcpbis-rfc4582bis-16 (work in progress), November 420 2015. 422 [I-D.ietf-mmusic-sdp-mux-attributes] 423 Nandakumar, S., "A Framework for SDP Attributes when 424 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 425 (work in progress), January 2016. 427 [I-D.pd-dispatch-msrp-websocket] 428 Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., 429 and R. R, "The WebSocket Protocol as a Transport for the 430 Message Session Relay Protocol (MSRP)", draft-pd-dispatch- 431 msrp-websocket-10 (work in progress), February 2016. 433 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 434 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 435 Transfer Protocol -- HTTP/1.1", RFC 2616, 436 DOI 10.17487/RFC2616, June 1999, 437 . 439 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 440 DOI 10.17487/RFC2818, May 2000, 441 . 443 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 444 A., Peterson, J., Sparks, R., Handley, M., and E. 445 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 446 DOI 10.17487/RFC3261, June 2002, 447 . 449 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 450 with Session Description Protocol (SDP)", RFC 3264, 451 DOI 10.17487/RFC3264, June 2002, 452 . 454 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 455 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 456 July 2006, . 458 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 459 (TLS) Protocol Version 1.2", RFC 5246, 460 DOI 10.17487/RFC5246, August 2008, 461 . 463 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 464 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 465 DOI 10.17487/RFC6101, August 2011, 466 . 468 [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, 469 "The WebSocket Protocol as a Transport for the Session 470 Initiation Protocol (SIP)", RFC 7118, 471 DOI 10.17487/RFC7118, January 2014, 472 . 474 [RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An 475 Extensible Messaging and Presence Protocol (XMPP) 476 Subprotocol for WebSocket", RFC 7395, 477 DOI 10.17487/RFC7395, October 2014, 478 . 480 [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. 482 Authors' Addresses 484 Ram Mohan Ravindranath 485 Cisco Systems, Inc. 486 Cessna Business Park, 487 Kadabeesanahalli Village, Varthur Hobli, 488 Sarjapur-Marathahalli Outer Ring Road 489 Bangalore, Karnataka 560103 490 India 492 Email: rmohanr@cisco.com 494 Gonzalo Salgueiro 495 Cisco Systems, Inc. 496 7200-12 Kit Creek Road 497 Research Triangle Park, NC 27709 498 US 500 Email: gsalguei@cisco.com