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

<Markus.Isomaki@nokia.com> Wed, 25 September 2013 10:43 UTC

Return-Path: <Markus.Isomaki@nokia.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 9356721F9F20 for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 03:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.492
X-Spam-Level:
X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 1bwWaHnD2jeO for <pntaw@ietfa.amsl.com>; Wed, 25 Sep 2013 03:43:21 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id B119F21F9FAB for <pntaw@ietf.org>; Wed, 25 Sep 2013 03:43:18 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.49]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r8PAXONc014863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 25 Sep 2013 13:33:26 +0300
Received: from 008-AM1MPN1-042.mgdnok.nokia.com ([169.254.2.224]) by 008-AM1MMR2-015.mgdnok.nokia.com ([65.54.30.49]) with mapi id 14.03.0136.001; Wed, 25 Sep 2013 10:33:24 +0000
From: <Markus.Isomaki@nokia.com>
To: <sergio.garcia.murillo@gmail.com>, <pntaw@ietf.org>
Thread-Topic: [pntaw] TURN over websockets or just TURN.
Thread-Index: Ac651aqKgci54WbeToGdcCETWYgQigAAvTwAAAANf1A=
Date: Wed, 25 Sep 2013 10:33:23 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A0CB1CD@008-AM1MPN1-042.mgdnok.nokia.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BD44F6@MCHP04MSX.global-ad.net> <5242B888.6010000@gmail.com>
In-Reply-To: <5242B888.6010000@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IgC3RfpT360Wbh6Q8tif6x5LYORqgwCCiv9XMhrEGBxwSHYWSu6Wmw9Q6YXYKK1wR2nXH6MoQJ8/ncdeNK/GKksLXp48Yc2BYboSTBauAVDj4zXOox4WhmDlSDt7Bcry/QjizntIYgD3BQZjdvfvADhwtb1JVNS1iKzew4/Vzzd7JQWsYD5sq+1GM4zEXtQ2NLxq26f0379TfQRz4QwoV5B0EY8L8/C24y1cXCesRotO
x-originating-ip: [10.236.10.110]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
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:43:32 -0000

Hi Sergio,

Sergio Garcia Murillo wrote:
> 
> El 25/09/2013 11:59, Hutton, Andrew escribió:
> > 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.
> 

I believe this is the really crucial question. My recollection from test results posted to IETF HYBI WG mailing list is that these unsecure websockets connections actually fail quite regularly with proxies rendering them almost unusable. This is not about proxies deliberately blocking websockets, but deployed proxies that are totally unaware of websockets but expect only HTTP. 

Anyone has up-to-date data about this?

Markus