Internet DRAFT - draft-chenxin-behave-turn-websocket
draft-chenxin-behave-turn-websocket
Behavior Engineering for Hindrance Avoidance X. Chen
Internet-Draft Huawei
Intended status: Standards Track S. Garcia Murillo
Expires: March 16, 2014 Medooze
O. Moskalenko
Yahoo
V. Pascual
Quobis
L. Miniero
Meetecho
September 12, 2013
WebSocket Protocol as a Transport for Traversal Using Relays around NAT
(TURN)
draft-chenxin-behave-turn-websocket-01
Abstract
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
[I-D.ietf-rtcweb-use-cases-and-requirements](F37).
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
framework.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
connection.
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
purpose.
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
(FIN:1,opcode:%x2).
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
client.
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
connections.
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
otherwise.
The updated augmented BNF (Backus-Naur Form) for this parameter is
the following (the original BNF for this parameter can be found in
[I-D.petithuguenin-behave-turn-uris]):
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
TBD.
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
2010.
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
2011.
[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.
[I-D.petithuguenin-behave-turn-uris]
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.
[I-D.ietf-rtcweb-use-cases-and-requirements]
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
Huawei
Email: hangzhou.chenxin@huawei.com
Sergio Garcia Murillo
Medooze
Email: sergio.garcia.murillo@gmail.com
Oleg Moskalenko
Yahoo
Email: olegm@yahoo-inc.com
Chen, et al. Expires March 16, 2014 [Page 9]
Internet-Draft TURN over Websocket September 2013
Victor Pascual
Quobis
Email: victor.pascual@quobis.com
Lorenzo Miniero
Meetecho
Email: lorenzo@meetecho.com
Chen, et al. Expires March 16, 2014 [Page 10]
