[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Behavior Engineering for Hindrance Avoidance                     X. Chen
Internet-Draft                                                    Huawei
Intended status: Standards Track                       S. Garcia Murillo
Expires: March 16, 2014                                          Medooze
                                                           O. Moskalenko
                                                              V. Pascual
                                                              L. Miniero
                                                      September 12, 2013

WebSocket Protocol as a Transport for Traversal Using Relays around NAT


   This document defines an extension to the Traversal Using Relays
   around NAT (TURN) protocol, in order to allow it to run over a
   WebSocket channel.  This will allow clients in restrictive networks
   to traverse them and effectively exchange and relay media or data
   over WebSockets.

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 March 16, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Chen, et al.             Expires March 16, 2014                 [Page 1]

Internet-Draft             TURN over Websocket            September 2013

   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.

1.  Introduction

   Traversal Using Relays around NAT (TURN) [RFC5766], which assigns a
   transport address allocation for clients and relays data between the
   address and the clients, is an extension to the Session Traversal
   Utilities for NAT [RFC5389] protocol.  TURN is used for NAT traversal
   in some complicated types of NAT network by UDP-based media sessions
   [RFC5766] or TCP-based media sessions [RFC6062].  It is also used in
   conjunction with the Interactive Connectivity Establishment (ICE)
   [RFC5245] technique.

   In some particularly restrictive networks though, e.g., a web proxy
   or firewall that only allows HTTP traffic to pass through, TURN UDP-
   based media sessions and TCP-based media sessions do not work.  These
   types of networks are often deployed in corporations, prisons,
   hotels, airports and other locations that may need to limit the
   access, and as such legitimate users trying to set up a real-time
   multimedia session in such a scenario would find themselves unable to
   do so.  This is a known issue and in fact the RTCWEB specification,
   which provides the means to realize direct interactive rich
   communications between two peers by using just their web browsers,
   has an explicit requirement to allow such peers to use some kind of
   fallback communication in HTTP-only networks, as specified in

   That said, this document is aimed at targeting such scenarios, and as
   such defines an extension to the standard TURN protocol that allows
   it to run over a WebSocket [RFC6455] channel.

   The WebSocket [RFC6455] protocol enables message exchange between
   clients and servers on top of a persistent TCP connection.
   Considering that the initial protocol handshake makes use of HTTP
   [RFC2616] semantics, thus allowing the WebSocket protocol to reuse
   existing HTTP infrastructure, this means that a client in a
   restrictive network would be able to exchange media over a WebSocket.
   Besides solving the HTTP fallback problem, this solution could also
   be easyly implemented and deployed within the existing RTCWEB

Chen, et al.             Expires March 16, 2014                 [Page 2]

Internet-Draft             TURN over Websocket            September 2013

   For what concerns the impact of such an extensions on the interaction
   with legacy peers making use of the services provided by a TURN
   server, the connection between the server and such peers would still
   be based on UDP as [RFC5766] or TCP as [RFC6062] in a seamless and
   transparent fashion.

          | TURN client to TURN server | TURN server to peer |
          |    WebSocket over TCP/TLS  |         UDP         |
          |                            |         TCP         |

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Deployment Topology

   Within the context of real-time multimedia communications and
   considering a scenario that involves two peers, an HTTP fallback
   mechanism may fall in basically three different network topologies:

3.1.  A topology whereas only one of the involved peers needs HTTP
      fallback for communication

                        |             |
         +--------------+ TURN Server +----------------+
         |    WS/WSS    |             |    UDP/TCP     |
         |              +-------------+                |
         |                                             |
         |                                             |
     +---+---+                                     +---+---+
     | Alice |                                     |  Bob  |
     +-------+                                     +-------+

                                 Figure 1

   In Figure 1, only one involved peer (Alice) is in a restrained
   network, which means Alice needs to make use of a WebSocket
   connection to traverse the firewall and/or proxy.  The situation for
   Bob is better, he could connect to the TURN server by UDP or TCP
   using the existing mechanisms.

Chen, et al.             Expires March 16, 2014                 [Page 3]

Internet-Draft             TURN over Websocket            September 2013

   When Alice wants to communicate with Bob, she needs to request a UDP
   or TCP allocation in the WebSocket server for Bob, which is then
   transferred to the WebSocket channel.  The WebSocket server will
   receive the request and handle it like a TURN server.  The processing
   of TURN messages is exactly the same as TURN UDP and TURN TCP, and
   the WebSocket server will also allocate a UDP or TCP relay address
   for Bob. The application data between Alice and Bob will be packaged
   and relayed to each other by the WebSocket server.

3.2.  A topology whereas both the involved peers need HTTP fallback for
      communication, using two different intermediaries

                +-------------+         +-------------+
                |             |         |             |
       +--------+ TURN Server +---------+ TURN Server +---------+
       | WS/WSS |             | UDP/TCP |             | WS/WSS  |
       |        +-------------+         +-------------+         |
       |                                                        |
       |                                                        |
   +---+---+                                                +---+---+
   | Alice |                                                |  Bob  |
   +-------+                                                +-------+

                                 Figure 2

   In Figure 2, both Alice and Bob are in restrictive networks, so both
   need a fallback mechanism.  In this slightly more complex scenario,
   both Alice and Bob each have been configred to refer to different
   WebSocket servers.  In this scenario, Alice and Bob need to request
   the TURN allocation in their own WebSocket server using a WebSocket

   Again, just as before the processing of TURN messages is exactly the
   same as TURN UDP and TURN TCP.  The only difference with previous
   sceneario is that, in this case, the involved WebSocket server have
   to relay the application data to each other by either UDP, TCP or
   other existing ways, using the existing TURN mechanics for the

   It is of course suggested that Alice and Bob allocate the same type
   of transport address, so that their reference WebSocket server could
   connect to each other by this address directly.

   The scenario would of course be simpler in case the TURN servers
   depicted in the figure above happen to be the same TURN server, i.e.,
   if Alice and Bob both referred to the same server.  In that case, it
   may be possible to relay the data internally instead of using an UDP/
   TCP connection.

Chen, et al.             Expires March 16, 2014                 [Page 4]

Internet-Draft             TURN over Websocket            September 2013

                         |             |
            +------------+ TURN Server +-----------+
            |  WS/WSS    |             |  WS/WSS   |
            |            +-------------+           |
            |                                      |
            |                                      |
        +---+---+                              +---+---+
        | Alice |                              |  Bob  |
        +-------+                              +-------+

                                 Figure 3

   However, this is an implementation decision, not affecting the TURN
   clients interaction with the TURN server and it will not be covered
   in detail within this specification.

4.  The WebSocket TURN Sub-Protocol

   The term WebSocket sub-protocol refers to an application-level
   protocol layered on top of a WebSocket connection.  This document
   specifies the WebSocket TURN sub-protocol for carrying TURN requests
   and responses through a WebSocket connection.

4.1.  Handshake

   The TURN Client and TURN Server negotiate usage of the WebSocket TURN
   sub-protocol during the WebSocket handshake procedure as defined in
   section 1.3 of [RFC6455].  The Client MUST include the value "turn"
   in the Sec-WebSocket-Protocol header in its handshake request.  The
   101 reply from the Server MUST contain "turn" in its corresponding
   Sec-WebSocket-Protocol header.

   Also, the TURN WebSocket Client shall set the Origin header if the
   TURN connection is createad in a Web context as defined in [RFC6454].
   Particularly, for WebRTC, the Origin header shall be set to the value
   of the URI of the HTML page creating the PeerConnection.

   Below is an example of a WebSocket handshake in which the Client
   requests the WebSocket TURN sub-protocol support from the Server:

     GET / HTTP/1.1
     Host: TURN-ws.example.com
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
     Origin: http://www.example.com
     Sec-WebSocket-Protocol: turn

Chen, et al.             Expires March 16, 2014                 [Page 5]

Internet-Draft             TURN over Websocket            September 2013

     Sec-WebSocket-Version: 13

   The handshake response from the Server accepting the WebSocket TURN
   sub-protocol would look as follows:

     HTTP/1.1 101 Switching Protocols
     Upgrade: websocket
     Connection: Upgrade
     Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
     Sec-WebSocket-Protocol: turn

   Once the negotiation has been completed, the WebSocket connection is
   established and can be used for the transport of TURN requests and
   responses.  The WebSocket messages transmitted over this connection
   MUST conform to the negotiated WebSocket sub-protocol.

4.2.  TURN message framing

   TURN messages shall be transported in unfragmented binary frames

   The WebSocket frame data shall be a valid TURN packet, so the length
   of the payload of the WebSocket frame shall be lower than the maximum
   size allowed (2^16 bytes) for a TURN request or response as defined
   in [RFC5766].

   TURN client using TURN over WebSockets should follow the
   recommendations in section 2.7 of [RFC5766] "Avoiding IP
   Fragmentation" when sending application data on the client-to-server-
   leg as messages could be relied over a UDP connection to the peer

4.3.  TURN Allocation

   This document extends both [RFC5766] (TURN UDP relay) and [RFC6062]
   (TURN TCP relay) with a new type of client-to-server connection, i.e.
   WebSocket.  For TURN allocations, WebSocket is a type of TCP client-
   to-server connection and is subject to all TURN TCP considerations.

   This specification strictly follows the allocation definition in
   section 5 in [RFC5766].  In the 5-tuple, the transport address is
   always TCP, of course, when WebSockets are used.  All definitions in
   the section 5 of [RFC5766] are applicable to the WebSockets TURN

Chen, et al.             Expires March 16, 2014                 [Page 6]

Internet-Draft             TURN over Websocket            September 2013

4.4.  TURN Operation

   The operation of the client, server and peer is the same as TURN UDP
   and TURN TCP, with the difference consisting in the new connection
   channel - WebSocket.

4.5.  TURN and TURNS URI WebSocket Transport Parameter

   This document defines the value "ws" as a transport parameter value
   for a TURN and TURNS URI [I-D.petithuguenin-behave-turn-uris] to be
   contacted using the TURN WebSocket sub-protocol as transport.

   The "turns" URI scheme MUST be used when TURN is run over Secure
   Websockets (WebSockets over TLS) and the "turn" scheme MUST be used

   The updated augmented BNF (Backus-Naur Form) for this parameter is
   the following (the original BNF for this parameter can be found in

     transport     = "udp" / "tcp" / "ws"  / transport-ext

4.6.  Impact on ICE candidates and SDP signalling

   This specification does not have any impact on ICE.  In fact, all the
   related candidates would be allocated at the TURN sever, and as such
   no modifications are needed in the SDP signaling in order to support
   the TURN over WebSockets operation.

5.  IANA Considerations

   RFC Editor Note: Please set the RFC number assigned for this document
   in the sub-sections below and remove this note.

5.1.  Registration of the WebSocket TURN Sub-Protocol

   This specification requests IANA to register the WebSocket TURN sub-
   protocol under the "WebSocket Subprotocol Name" Registry with the
   following data:

   Subprotocol Identifier:  turn

   Subprotocol Common Name:  WebSocket Transport for TURN

   Subprotocol Definition:  TBD: this document

Chen, et al.             Expires March 16, 2014                 [Page 7]

Internet-Draft             TURN over Websocket            September 2013

6.  Security Considerations


7.  Change Summary

   Note to RFC Editor: Please remove this whole section.

   The following are the major changes between the 00 and the 01
   versions of the draft:

   o  Removal of multiplexing and references to BCFP and other non
      related protocols

   o  Websocket TURN sub protocol specification

   o  TURN message framing inside Websocket

   o  Extension to turn and turns URI

   o  Impact analisys on ice candidates SDP negotiation

8.  Acknowledgements

   Paul Kyzivat helped with the formatting of this draft.

9.  References

9.1.  Normative References

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [RFC6062]  Perreault, S. and J. Rosenberg, "Traversal Using Relays
              around NAT (TURN) Extensions for TCP Allocations", RFC
              6062, November 2010.

9.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April

Chen, et al.             Expires March 16, 2014                 [Page 8]

Internet-Draft             TURN over Websocket            September 2013

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
              6455, December 2011.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

              Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P.
              Jones, "Traversal Using Relays around NAT (TURN) Uniform
              Resource Identifiers", draft-petithuguenin-behave-turn-
              uris-06 (work in progress), August 2013.

              Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use-cases and Requirements", draft-
              ietf-rtcweb-use-cases-and-requirements-11 (work in
              progress), June 2013.

Authors' Addresses

   Xin Chen

   Email: hangzhou.chenxin@huawei.com

   Sergio Garcia Murillo

   Email: sergio.garcia.murillo@gmail.com

   Oleg Moskalenko

   Email: olegm@yahoo-inc.com

Chen, et al.             Expires March 16, 2014                 [Page 9]

Internet-Draft             TURN over Websocket            September 2013

   Victor Pascual

   Email: victor.pascual@quobis.com

   Lorenzo Miniero

   Email: lorenzo@meetecho.com

Chen, et al.             Expires March 16, 2014                [Page 10]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/