Network Working Group P. Dunkley Internet-Draft G. Llewellyn Updates: 4975 (if approved) Crocodile RCS Ltd Intended status: Standards Track May 10, 2013 Expires: November 11, 2013 The WebRTC Data Channel as a Transport for the Message Session Relay Protocol (MSRP) draft-pd-msrp-webrtc-00 Abstract The WebRTC Data Channel enables two-way real-time communication between browsers. This document updates normatively updates RFC 4975 to add support for WebRTC Data Channel as a transport for MSRP (Message Session Relay Protocol). This will enable secure, low- latency, structured peer-to-peer messaging between WebRTC end-points. 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 November 11, 2013. Copyright Notice Copyright (c) 2013 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 Dunkley & Llewellyn Expires November 11, 2013 [Page 1] Internet-Draft MSRP over WebRTC Data Channel May 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The WebRTC Data Channel . . . . . . . . . . . . . . . . . . . . 3 4. MSRP WebRTC Data Channel Transport . . . . . . . . . . . . . . 4 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Updates to RFC 4975 . . . . . . . . . . . . . . . . . . . . 4 4.2.1. MSRP URI Transport Parameter . . . . . . . . . . . . . 4 4.2.2. SDP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.3. Opening Data Channels for MSRP . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. SDP exchange . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 9 A.1. MSRP WebRTC Client Considerations . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Dunkley & Llewellyn Expires November 11, 2013 [Page 2] Internet-Draft MSRP over WebRTC Data Channel May 2013 1. Introduction The WebRTC Data Channel [I-D.ietf-rtcweb-data-channel] enables secure, reliable, low-latency message exchange between browsers. Network Address Translation (NAT) issues between browsers are handled through the use of ICE [RFC5245]. Modern web browsers include a WebRTC client stack complying with the WebRTC API [WEBRTC-API] as specified by the W3C. The specification in this document enables usage of MSRP in these scenarios. This specification updates MSRP [RFC4975] to support WebRTC Data Channel as a transport for the exchange of MSRP messages between browsers. MSRP over WebRTC is well suited for MSRP interactions between clients that require security, reliability, low-latency, and where there are no local policies requiring authorisation and/or logging of interactions. For client-to-server messaging or where local policy requires authentication and/or logging MSRP over WebSocket [I-D.pd-dispatch-msrp-websocket] should be considered. 2. Terminology All diagrams, examples, and notes in this specification are non- normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.1. Definitions MSRP WebRTC Client: An MSRP entity capable of opening WebRTC Data Channel connections to other MSRP entities. 3. The WebRTC Data Channel _This section is non-normative._ The WebRTC Data Channel [I-D.ietf-rtcweb-data-channel] is a transport layer on top of SCTP over DTLS over UDP in which clients exchange message units in both directions. WebRTC Data Channel defines message units to be used by applications Dunkley & Llewellyn Expires November 11, 2013 [Page 3] Internet-Draft MSRP over WebRTC Data Channel May 2013 for the exchange of data, so it provides a message boundary- preserving transport layer. These message units contain binary data. 4. MSRP WebRTC Data Channel Transport 4.1. General Each MSRP chunk MUST be carried within a single Data Channel message, and a Data Channel message MUST NOT contain more than one MSRP chunk. This simplifies parsing of MSRP messages for clients. When large messages are sent MSRP chunking (as defined in section 5.1 of [RFC4975]) MUST be used to split the message into several smaller MSRP chunks. 4.2. Updates to RFC 4975 4.2.1. MSRP URI Transport Parameter This document defines the value "dc" as the transport parameter value for an MSRP URI [RFC3986] to be contacted using WebRTC Data Channel as transport. The updated augmented BNF (Backus-Naur Form) [RFC5234] for this parameter is the following (the original BNF for this parameter can be found in [RFC4975]): transport = "tcp" / "dc" / 1*ALPHANUM 4.2.2. SDP When using MSRP over WebRTC the SDP connection and media-lines will be generated by browser when the "createOffer" method [I-D.ietf-rtcweb-jsep] is called. MSRP WebRTC Clients MUST NOT create connection and media-lines as described in section 8.1 of [RFC4975]. Other MSRP related SDP fields are contained within attribute-lines which MUST be added to browser generated SDP. As all MSRP over WebRTC messages are routed directly between MSRP WebRTC Clients there are no backwards compatibility issues with non- WebRTC MSRP clients. The "dc" transport parameter will appear in the endpoint URI in SDP "path" attribute ([RFC4975] section 8.2). Dunkley & Llewellyn Expires November 11, 2013 [Page 4] Internet-Draft MSRP over WebRTC Data Channel May 2013 4.3. Opening Data Channels for MSRP Section 5.4 of [I-D.ietf-mmusic-sctp-sdp] defines the "subprotocol Attribute" enabling the client to indicate which protocol it would like to speak on a channel. This document defines a new subprotocol of "MSRP" which MUST be used on channels carrying MSRP over WebRTC. When establishing MSRP sessions clients often include a lot of meta- data [RFC5547] about the intended use of the session in attribute- lines within the SDP (for example, when performing file-transfer filename, type, and size are indicated). There is no information in these attribute-lines that that will enable a client to associate them with a specific channel. To solve this issue MSRP WebRTC Clients MUST create SCTP associations with only 1 channel (that is, one stream in each direction). Section 5 of [I-D.jesup-rtcweb-data-protocol] allows applications to specify the number of streams for an SCTP association. It is usually the case that more streams are desirable to enable additional communication between browsers without the need for renegotiation and to create new Data Channels; this is not applicable to MSRP. Additional MSRP sessions require renegotion so that the meta-data [RFC5547] describing the intended use of the session can be exchanged. 5. Examples 5.1. SDP exchange The following example shows SDP that could be included in a SIP message to set up an MSRP session between Alice and Bob. Note that SDP does not permit line folding. A "\" in the examples shows a line continuation due to limitations in line length of this document. Neither the backslash nor the extra CRLF is included in the actual SDP. Alice makes an offer: m=application 54111 DTLS/SCTP 5000 c=IN IP4 79.97.215.79 a=sctpmap:5000 webrtc-DataChannel 1 a=webrtc-DataChannel:5000 \ stream=1;label="channel 1";subprotocol="msrp" a=accept-types:message/cpim text/plain text/html a=path:msrp://df7jal23ls0d.invalid:5000/98cjs;dc Dunkley & Llewellyn Expires November 11, 2013 [Page 5] Internet-Draft MSRP over WebRTC Data Channel May 2013 In this offer, Alice wishes to receive MSRP messages using the WebRTC Data Channel. She can accept message/cpim, text/plain, and text/html message bodies in SEND requests. Bob's answer to this offer could look like: m=application 63241 DTLS/SCTP 3000 c=IN IP4 79.97.215.84 a=sctpmap:3000 webrtc-DataChannel 1 a=webrtc-DataChannel:3000 stream=1;label="channel 1";subprotocol="msrp" a=accept-types:message/cpim text/plain a=path:msrp://jk3apo92lf5w.invalid:3000/20ksw;dc Here Bob wishes to receive the MSRP messages. He can accept only message/cpim and text/plain message bodies in SEND requests and has rejected the text/html content offered by Alice. 5.2. SEND Alice (MSRP DC) Bob | | |SEND F1 | |---------------------------->| |200 OK F2 | |<----------------------------| In the same scenario Alice sends an instant message to Bob (session details having been previously negotiated by some other mechanism - such as SDP. Dunkley & Llewellyn Expires November 11, 2013 [Page 6] Internet-Draft MSRP over WebRTC Data Channel May 2013 F1 SEND Alice -> Bob (transport DC) MSRP 6aef SEND To-Path: msrp://jk3apo92lf5w.invalid:3000/20ksw;dc From-Path: msrp://df7jal23ls0d.invalid:5000/98cjs;dc Success-Report: no Byte-Range: 1-*/* Message-ID: 87652 Content-Type: text/plain Hi Bob, I'm about to send you file.mpeg -------6aef$ F2 200 OK Bob -> Alice (transport DC) MSRP 6aef 200 OK To-Path: msrp://df7jal23ls0d.invalid:5000/98cjs;dc From-Path: msrp://jk3apo92lf5w.invalid:3000/20ksw;dc -------6aef$ 6. Security Considerations The WebRTC Data Channel [I-D.ietf-rtcweb-data-channel] provides secure communication between browsers. As such there are no specific security considerations for this draft. 7. IANA Considerations This specification does not require any IANA registry changes. 8. Acknowledgements Special thanks to Inaki Baz Castillo, Jose Luis Millan Villegas, and Victor Pascual, the authors of [I-D.ietf-sipcore-sip-websocket] which has inspired this draft. 9. References 9.1. Normative References [I-D.ietf-mmusic-sctp-sdp] Loreto, S. and G. Camarillo, "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Dunkley & Llewellyn Expires November 11, 2013 [Page 7] Internet-Draft MSRP over WebRTC Data Channel May 2013 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-03 (work in progress), January 2013. [I-D.ietf-rtcweb-data-channel] Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data Channels", draft-ietf-rtcweb-data-channel-04 (work in progress), February 2013. [I-D.jesup-rtcweb-data-protocol] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel Protocol", draft-jesup-rtcweb-data-protocol-04 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 9.2. Informative References [I-D.ietf-rtcweb-jsep] Uberti, J. and C. Jennings, "Javascript Session Establishment Protocol", draft-ietf-rtcweb-jsep-03 (work in progress), February 2013. [I-D.ietf-sipcore-sip-websocket] Castillo, I., Millan, J., and V. Pascual, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", draft-ietf-sipcore-sip-websocket-08 (work in progress), March 2013. [I-D.pd-dispatch-msrp-websocket] Dunkley, P., Llewellyn, G., and V. Pascual, "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", draft-pd-dispatch-msrp-websocket-01 (work in progress), January 2013. [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Dunkley & Llewellyn Expires November 11, 2013 [Page 8] Internet-Draft MSRP over WebRTC Data Channel May 2013 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5547] Garcia-Martin, M., Isomaki, M., Camarillo, G., Loreto, S., and P. Kyzivat, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", RFC 5547, May 2009. [WEBRTC-API] W3C, Bergkvist, A., Ed., Burnett, D., Ed., Jennings, C., Ed., and A. Narayanan, Ed., "WebRTC 1.0: Real-time Communication Between Browsers", September 2012. Appendix A. Implementation Guidelines _This section is non-normative._ A.1. MSRP WebRTC Client Considerations The JavaScript stack in web browsers does not have the ability to discover the local transport address used for originating WebRTC connections. Therefore the MSRP WebSocket Client constructs a domain name consisting of a random token followed by the ".invalid" top- level domain name, as stated in [RFC2606], and uses it within its From-Path headers. Authors' Addresses Peter Dunkley Crocodile RCS Ltd Forum 3, Parkway Solent Business Park, Whiteley Fareham PO15 7FH United Kingdom Email: peter.dunkley@crocodile-rcs.com Dunkley & Llewellyn Expires November 11, 2013 [Page 9] Internet-Draft MSRP over WebRTC Data Channel May 2013 Gavin Llewellyn Crocodile RCS Ltd Forum 3, Parkway Solent Business Park, Whiteley Fareham PO15 7FH United Kingdom Email: gavin.llewellyn@crocodile-rcs.com Dunkley & Llewellyn Expires November 11, 2013 [Page 10]