BFCPBIS Working Group Ram. Ravindranath
Internet-Draft G. Salgueiro
Intended status: Standards Track Cisco
Expires: April 22, 2017 October 19, 2016

Session Description Protocol (SDP) WebSocket Connection URI Attribute
draft-ietf-bfcpbis-sdp-ws-uri-06

Abstract

The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.

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 of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents 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 April 22, 2017.

Copyright Notice

Copyright (c) 2016 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 (http://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

The WebSocket protocol [RFC6455] enables bidirectional message exchange between clients and servers on top of a persistent TCP connection (optionally secured with Transport Layer Security (TLS) [RFC5246]). The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.

Modern web browsers include a WebSocket client stack compliant with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (e.g., those running on personal computers, mobile devices, etc.) will also make a WebSocket client stack available. Several specifications have been written that define how different applications can use a WebSocket subprotocol as a reliable transport mechanism.

For example, [RFC7118] defines WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP)[RFC3261] entities to enable use of SIP in web-oriented deployments. Additionally, [I-D.pd-dispatch-msrp-websocket] defines a new WebSocket sub-protocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays. [RFC7395] defines a WebSocket subprotocol for the Extensible Messaging and Presence Protocol (XMPP). Similarly, [I-D.ietf-bfcpbis-bfcp-websocket] defines a WebSocket sub-protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP in new scenarios.

As defined in Section 3 of [RFC2818], when using Secure WebSockets the Canonical Name (CNAME) of the Secure Sockets Layer (SSL) [RFC6101] certificate MUST match the WebSocket connection URI host. In most cases it is not viable for certificates signed by well known authorities. Thus, there is a need to indicate the connection URI for the WebSocket Client. For applications that use Session Description Protocol (SDP) [RFC4566] to negotiate, the connection URI can be indicated by means of an SDP attribute. This specification defines new SDP attributes to indicate the connection URI for the WebSocket client. Applications that use SDP for negotiation and WebSocket as a transport protocol can use this specification to advertise the WebSocket client connection URI.

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

3. SDP Considerations

3.1. General

Applications that use the SDP Offer/Answer mechanism [RFC3264] for negotiating media and also use WebSocket as a transport protocol MAY indicate the connection URI for the WebSocket Client via a new SDP a= media-level attribute defined in Section 3.2.

Applications that use SDP for negotiation and also use secure WebSocket as a transport protocol TLS MAY indicate the connection URI for the WebSocket Client via a new SDP a= media-level attribute defined in Section 3.3.

3.2. ws-uri SDP Attribute

This section defines a new SDP media-level attribute, 'ws-uri' which can appear in any of the media sections.

Example:

   a=ws-uri:ws://example.com/chat
   

Where "ws://example.com/chat" is the ws-URI defined in Section 3 of [RFC6455].

When the 'ws-uri' attribute is present in the media section of the SDP, the IP address in 'c= ' line SHALL be ignored and the full URI SHALL be used instead to open the WebSocket connection. The clients MUST ensure that they use the URI to open the webSocket connection and ignore the IP address in 'c=' line and port in m= line.

3.3. wss-uri SDP Attribute

This section defines a new SDP media-level attribute, 'wss-uri' which can appear in any of the media sections.

Example:

   a=wss-uri:wss://example.com/chat
   

Here "wss://example.com/chat" is the wss-URI defined in Section 3 of [RFC6455].

When the 'wss-uri' attribute is present in the media section of the SDP, the IP address in 'c= ' line SHALL be ignored and the full URI SHALL be used instead to open the WebSocket connection. The clients MUST ensure that they use the URI to open the webSocket connection and ignore the IP address in 'c=' line and port in m= line.

3.4. ws-uri and wss-uri Multiplexing Considerations

Multiplexing characteristics of SDP attributes are described in [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute multiplexing categories are introduced there.

There are no multiplexing rules specified for the ws-uri and wss-uri SDP media-level attributes. Additionally, the specification of multiplexing rules for the ws-uri and wss-uri attributes is outside the scope of this document.

While it is technically possible to bundle WebSocket, there are a variety of reasons that make it impractical and it is thus considered unlikely to be used in practice. Therefore, the ws-uri and wss-uri SDP media-level attributes defined in Section 3.2 and Section 3.3 for using WebSocket as a transport protocol are not likely to be used with SDP bundle and are consequently categorized as CAUTION for multiplexing.

If future extensions define how to bundle WebSocket then multiplexing rules for the "a=ws-uri:" and "a=wss-uri:" attributes need to be defined as well, for instance in an extension of this SDP based WebSocket negotiation specification.

4. SDP Offer/Answer Procedures

4.1. General

An endpoint (i.e., both the offerer and the answerer) that wishes to negotiate WebSocket as transport protocol MUST indicate that it wishes to use WebSocket or secure WebSocket in the "proto" field of the "m=" line. Furthermore, the server side, which could be either the offerer or answerer, MUST add an "a=ws-uri" or "a=wss-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 Section 3. The procedures in this section apply to an "m=" line associated with any media stream that uses WebSocket or secure WebSocket as transport.

4.2. Generating the Initial Offer

An SDP offerer in order to negotiate WebSocket as a transport MUST indicate the same in the "proto" field of the "m=" line. For example, to negotiate BFCP-over-WebSocket the "proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST be TCP/WS/BFCP.

The offerer SHOULD assign the SDP "setup" attribute with a value of "active" (the offerer will be the initiator of the outgoing TCP connection), unless the offerer insists on being a receiver of an incoming connection, in which case the offerer SHOULD use a value of "passive". The offerer MUST NOT assign an SDP "setup" attribute with a "holdconn" value.

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

The following is an example of an "m=" line for a BFCP connection:

In the above example, the client is intending to setup the TLS /TCP connection and hence the port is set to a value of 9, which is the discard port.

4.3. Generating the Answer

If the answerer accepts the offered WebSocket transport connection, in the associated SDP answer, the answerer MUST assign an SDP "setup" attribute with a value of either "active" or "passive", according to the procedures in [RFC4145]. The answerer MUST NOT assign an SDP "setup" attribute with a value of "holdconn".

If the answerer assigns an SDP "setup" attribute with a value of "active", the answerer MUST initiate the WebSocket connection handshake by acting as client on the negotiated media stream, towards the IP address and port of the offerer using the procedures described in [RFC6455]. The answer MUST have an "a=ws-uri" or "a=wss-uri" attribute depending on whether the application uses WebSocket or secureWebSocket. This attribute MUST follow the syntax defined in Section 3. For BFCP application, the "proto" value in the "m=" line MUST be TCP/WSS/BFCP if WebSocket is run on TLS, else it MUST be TCP/WS/BFCP.

Answer (server):
m=application 50000 TCP/WSS/BFCP *
a=setup:passive
a=connection:new
a=wss-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
      

The following example shows a case where the server responds with a BFCP media stream over a WebSocket connection running TLS. It shows an answer "m=" line for the BFCP connection. In this example since WebSockets is running over TLS, the server answers back with "a=wss-uri" attribute in the media section of SDP indicating the connection URI:

4.4. Offerer Processing of the Answer

When the offerer receives an SDP answer, if the offerer ends up being active it MUST follow the procedures in Section 5.

4.5. Modifying the Session

Once an offer/answer exchange has been completed, either endpoint MAY send a new offer in order to modify the session. The endpoints can reuse the existing WebSocket connection by adding "a=connection:existing" attribute in the media section of SDP following the rules mentioned in [RFC4145] if the ws-uri values and the transport parameters indicated by each endpoint are unchanged. Otherwise, following the rules for the initial offer/answer exchange, the endpoints can negotiate and create a new WebSocket connection on top of TLS/TCP or TCP.

4.6. Offerless INVITE Scenarios

In some scenarios an endpoint (e.g., a browser) originating the call (UAC) can send an offerless INVITE to the server. The server will generate an offer in response to the INVITE. In such cases the server MUST send an offer with setup attribute as "passive" so as to accept incoming connection and MUST include "a=wss-uri" or "a=ws-uri" attribute in the media section depending on whether the server wishes to use WebSocket or secure WebSocket. The SDP offer sent by the server will look like the example in Section 4.3.

5. Procedures at WebSocket Client

The webSocket client MUST always initiate the outgoing TCP connection and hence the SDP a=setup attribute MUST be always "active" for the WebSocket client in its SDP offer/answer. In the below example, the WebSocket client is the offerer and hence assigns "setup" attribute with a value of "active".

The WebSocket server is a server on Internet and hence MUST always assign SDP "setup" attribute with a value of "passive". This also avoids the need to use ICE between WebSocket Client and WebSocket Server as the connection model here would be a typical client to server web connection.

Once the offer/answer is complete the client MUST initiate the WebSocket connection handshake by sending a GET message on the negotiated media stream, towards the IP address and port of the answerer, as per the procedures described in [RFC6455]. If there are multiple records returned for the connection URI in the "a=wss-uri" or "a=ws-uri" then the clients MAY use procedures in Section 4 of [RFC6555] to attempt the connection towards the server. When no port is passed in the "a=wss-uri" or "a=ws-uri" attribute, the default ports (80 or 443) is used.

6. Security Considerations

An attacker may attempt to add, modify, or remove 'a=ws-uri' or 'a=wss-uri' attribute from a session description. This could result in an application behaving undesirably. Consequently, it is strongly RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [RFC3261], S/MIME is the natural choice to provide such end-to-end integrity protection.

It is also RECOMMENDED that the application signaling traffic being transported over a WebSocket communication session be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP).

The WebSocket clients have to initiate the TCP connection to the WebSocket server identified by the FQDN in a=ws/a=wss-uri. Further as with any other web connection, the clients will verify the servers certificate. The WebSocket client MUST follow the procedures in [RFC7525] while setting up TLS connection with webSocket server.

7. IANA Considerations

7.1. Registration of the 'ws-uri' SDP Media Attribute

NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.

This document defines a new SDP media-level attribute "ws-uri" in Section 3.2 and requests that IANA to register the following SDP att-field under the Session Description Protocol (SDP) Parameters registry as follows:

Attribute name: ws-uri
Long-form attribute name: Websocket Connection URI
Type of attribute: media
Mux category: CAUTION
Charset Dependent: No
Purpose: The 'ws-uri' attribute is intended to be used as a connection URI for opening the WebSocket connection.
Appropriate values: A ws-URI as defined in [RFC6455]
Contact name: Gonzalo Salgueiro
Contact e-mail: gsalguei@cisco.com
Reference: RFCXXXX

7.2. Registration of the 'wss-uri' SDP Media Attribute

NOTE to RFC Editor: Please replace "XXXX" with the number of this RFC.

This document defines a new SDP media-level attribute "wss-uri" in Section 3.3 and requests that IANA to register the following SDP att-field under the Session Description Protocol (SDP) Parameters registry as follows:

Attribute name: wss-uri
Long-form attribute name: Websocket Connection URI over Secure Transport
Type of attribute: media
Mux category: CAUTION
Charset Dependent: No
Purpose: The 'wss-uri' attribute is intended to be used as a connection URI for opening the WebSocket connection over a secure transport.
Appropriate values: A wss-URI as defined in [RFC6455]
Contact name: Gonzalo Salgueiro
Contact e-mail: gsalguei@cisco.com
Reference: RFCXXXX

8. Acknowledgements

Thanks to Christer Holmberg for raising the need for a BFCP-independent SDP attribute for WebSocket Connection URI.

The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, Christer Holmberg, Charles Eckel and Dan Wing for their invaluable suggestions and review comments.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011.

9.2. Informative References

[I-D.ietf-bfcpbis-bfcp-websocket] Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R. and S. Murillo, "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Internet-Draft draft-ietf-bfcpbis-bfcp-websocket-10, June 2016.
[I-D.ietf-bfcpbis-rfc4582bis] Camarillo, G., Drage, K., Kristensen, T., Ott, J. and C. Eckel, "The Binary Floor Control Protocol (BFCP)", Internet-Draft draft-ietf-bfcpbis-rfc4582bis-16, November 2015.
[I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", Internet-Draft draft-ietf-mmusic-sdp-mux-attributes-14, September 2016.
[I-D.pd-dispatch-msrp-websocket] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G. and R. R, "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", Internet-Draft draft-pd-dispatch-msrp-websocket-15, August 2016.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002.
[RFC4566] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008.
[RFC6101] Freier, A., Karlton, P. and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012.
[RFC7118] Baz Castillo, I., Millan Villegas, J. and V. Pascual, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", RFC 7118, DOI 10.17487/RFC7118, January 2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014.
[RFC7395] Stout, L., Moffitt, J. and E. Cestari, "An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket", RFC 7395, DOI 10.17487/RFC7395, October 2014.
[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.
[WS-API] W3C and I. Hickson, "The WebSocket API", May 2012.

Authors' Addresses

Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India EMail: rmohanr@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US EMail: gsalguei@cisco.com