Re: [pntaw] TURN over websockets or just TURN.

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Wed, 25 September 2013 10:18 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4BB21F9E02 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 03:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aalFgD32mzt for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 03:18:55 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3C421F9B08 for <pntaw@ietf.org>; Wed, 25 Sep 2013 03:18:54 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id m15so5864511wgh.31 for <pntaw@ietf.org>; Wed, 25 Sep 2013 03:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Ak2xjv7teHBhtWXhLD3LjmBAfGjGoc0hPinudz9LNRs=; b=sI4GxtoBkfcfIqdpuIuALQzdjQEdeCPPsuXzQnliEd+7Yl5B/RwfSAxWctxV7kjeSs 0pn1EX8Iub5L3ZCCh615UCdh355gAzonxUtqC3nixhpf5JFgQJabagA1tnvDSAUBzVeK SLtuFnBlR7DWsnlwV8cbRTXHnIN4KUQZ2FucCiXSzXH++qsCeC2qBBC9Y6JZ7rSKsZEv f9SM2jO438Tp58FHhizGR7e2VXtpWujr5SuAgdq1K9VBB3WfmGPi0EEB0adR3k+l8oj+ 9ZEUTuLnFcdjR9v13LVbohKdRld+xMESCpaDR9vvzcQtHbHj/BlNqH8oP4yVW6lqrJP7 lWLA==
X-Received: by 10.194.240.101 with SMTP id vz5mr67156wjc.69.1380104331272; Wed, 25 Sep 2013 03:18:51 -0700 (PDT)
Received: from [192.168.1.45] (54.Red-83-61-124.dynamicIP.rima-tde.net. [83.61.124.54]) by mx.google.com with ESMTPSA id c4sm16347459wiz.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 03:18:50 -0700 (PDT)
Message-ID: <5242B888.6010000@gmail.com>
Date: Wed, 25 Sep 2013 12:18:48 +0200
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: pntaw@ietf.org
References: <9F33F40F6F2CD847824537F3C4E37DDF17BD44F6@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BD44F6@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [pntaw] TURN over websockets or just TURN.
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2013 10:18:56 -0000

Hi Andy,

Some comments inline.

Best regards
Sergio

El 25/09/2013 11:59, Hutton, Andrew escribió:
> Some thoughts on comparing the TURN over Websockets approach in draft-chenxin-behave-turn-websocket and the HTTP Connect (Without websocket) approach discussed in draft-hutton-rtcweb-nat-firewall-considerations.
>
> Please note that my motivation is simply to find a good solution to deploying WebRTC in the presence of web proxies / firewalls and I am not tied to any particular solution.

So am I  :)

> In the presence of an explicit proxy the websockets approach is to use HTTP CONNECT to traverse the proxy (RFC 6455) so the question is whether there are any advantages or disadvantages to wrapping TURN with the websockets layer as this cannot be about the use of HTTP CONNECT which is used by in both solutions
 From my understanding if you use secure websockets it will use HTTP 
CONNECT as any other HTTPS connection, but if non-secure websockets are 
used over port 80, HTTP CONNECT won't be done. Before anyone jumps in 
regarding using a non-secure websockets, let's remind that this would  
be as secure as TURN over TCP and that data will be already secured by 
DTLS.

> Websockets adds some overhead as there is an extra handshake that takes place with the server and there is some extra overhead in the data encapsulation.
Yes it is just one HTTP request/response and a max of 8 byte headers. 
However if TURN over websockets is run un-secured, you will have less 
processing overhead due to the TLS encription.
> The purpose of the extra HTTP handshake to upgrade to HTTP to a websockets connection is to allow an HTTP Server to use the same port for both HTTP and the websockets protocol.  However I don't think this is necessary for WebRTC media connections as it is very unlikely that a web server will want to handle WebRTC media/TURN at all never mind on the HTTP port as the media.
No, it isn't, the main purpose is to be able to traverse proxies with 
DPI that will drop the HTTP CONNECT with TURN over TLS. But, been an 
HTTP protocol, you would gain some extra functionalities for free.
> So does encapsulating the TURN data in websocket frames provide any benefit. I can imagine that there might be some scenarios in which using a websockets connection might work when TURN might not simply because the media is buried in further layers of encapsulation. However I don't know if this is really the case and also we are of course not trying to hide the fact that this is media.
>
> The extra websockets overhead for all the media packets is surely a drawback of this approach.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-------+-+-------------+-------------------------------+
      |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
      |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
      |N|V|V|V|       |S|             |   (if payload len==126/127)   |
      | |1|2|3|       |K|             |                               |
      +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
      |     Extended payload length continued, if payload len == 127  |
      + - - - - - - - - - - - - - - - +-------------------------------+
      |                               |Masking-key, if MASK set to 1  |
      +-------------------------------+-------------------------------+
      | Masking-key (continued)       |          Payload Data         |
      +-------------------------------- - - - - - - - - - - - - - - - +
      :                     Payload Data continued ...                :
      + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
      |                     Payload Data continued ...                |
      +---------------------------------------------------------------+

7 or 8 bytes from client to server (due to masking, which I think it could be avoided in this case) and 2 or 4bytes from server to client.

> Not encapsulating the TURN in websockets would also probably provide better control for those wanting to assert policies on the handling of media.
>
> Therefore as you can see I don't see the benefit of encapsulating TURN in websockets but I look forward to hearing other opinions and maybe I have missed something important.
>
> Regards
> Andy
>
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw