Re: [tram] TURN over WebSocket

"Hutton, Andrew" <andrew.hutton@unify.com> Wed, 03 December 2014 09:00 UTC

Return-Path: <andrew.hutton@unify.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F8C1A1A5B for <tram@ietfa.amsl.com>; Wed, 3 Dec 2014 01:00:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4eOIt7gMlCq for <tram@ietfa.amsl.com>; Wed, 3 Dec 2014 01:00:24 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0001A1A19 for <tram@ietf.org>; Wed, 3 Dec 2014 01:00:24 -0800 (PST)
Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id E36941EB8421; Wed, 3 Dec 2014 10:00:22 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.125]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 10:00:22 +0100
From: "Hutton, Andrew" <andrew.hutton@unify.com>
To: Victor Pascual <victor.pascual@quobis.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Thread-Topic: [tram] TURN over WebSocket
Thread-Index: AQHQDtM3D1e3+t0AIUS5ldoZP7bRhJx9ioGw
Date: Wed, 03 Dec 2014 09:00:22 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1E61FB1B@MCHP04MSX.global-ad.net>
References: <913383AAA69FF945B8F946018B75898A2837AB1F@xmb-rcd-x10.cisco.com> <78A0E6E2-3F1D-4F02-A552-688AACCBE683@vidyo.com> <913383AAA69FF945B8F946018B75898A2837B095@xmb-rcd-x10.cisco.com> <CANO7kWC+s3E_pWkSfBBCqDpD2zaXBsErbJ1NiBJfXcdkqiRDRg@mail.gmail.com> <913383AAA69FF945B8F946018B75898A2837B709@xmb-rcd-x10.cisco.com> <CANO7kWDDVxiF_dNgO1zT-L0jCOue2_JKBJM6G_zQsiW7R1229Q@mail.gmail.com> <913383AAA69FF945B8F946018B75898A2837B8E7@xmb-rcd-x10.cisco.com> <CA+ag07bFQwUEqSC2A1X0Nc=guV_eLukuEaefQmWFaS3py5JLYA@mail.gmail.com> <913383AAA69FF945B8F946018B75898A2837B9B5@xmb-rcd-x10.cisco.com> <547E2069.4050307@gmail.com> <400774A5-BCCF-4CD4-A805-D88C13C34E22@quobis.com>
In-Reply-To: <400774A5-BCCF-4CD4-A805-D88C13C34E22@quobis.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF1E61FB1BMCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ptLZsLLHShMVlWpZA6HrQxIETmo
Cc: Jonathan Lennox <jonathan@vidyo.com>, "tram@ietf.org" <tram@ietf.org>, "[ACME] Victor Pascual Avila" <victor.pascual.avila@gmail.com>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>, "draft-chenxin-behave-turn-websocket@tools.ietf.org" <draft-chenxin-behave-turn-websocket@tools.ietf.org>, Simon Perreault <sperreault@jive.com>
Subject: Re: [tram] TURN over WebSocket
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Dec 2014 09:00:29 -0000

I would be good to close as many holes as possible with regards to webrtc connectivity but we have to be clear on which particular hole we are trying to close.

If I read the thread correctly it looks like the case we don’t currently have a solution for is when using a transparent proxy with unencrypted TURN on port 80.  I would like to understand why in the scenario that Sergio mentioned that WSS works but not TURNS over 443 and whether support for ALPN would fix that.

This is all about webrtc so I think there is an issue also with increasing complexity in the browser which needs to implement all the different mechanisms and also probably a bigger issue is getting the rtcweb working group and the browser vendors to support this mechanism and refer to it in draft-ietf-rtcweb-transports.

So I would say I am sympathetic to this but not yet totally convinced it closes a big enough hole to make it compelling for the browser vendors to implement.

Regards
Andy




From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Victor Pascual
Sent: 02 December 2014 21:55
To: Sergio Garcia Murillo
Cc: Jonathan Lennox; tram@ietf.org; [ACME] Victor Pascual Avila; Tirumaleswar Reddy (tireddy); draft-chenxin-behave-turn-websocket@tools.ietf.org; Simon Perreault
Subject: Re: [tram] TURN over WebSocket

Agree with Sergio. We're experiencing the same

-Victor

On Dec 2, 2014, at 9:26 PM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com<mailto:sergio.garcia.murillo@gmail.com>> wrote:
We control the client and the server, and you are asking me to wait until what is not in our control is changed. Obviously, not working for me

BTW, I am talking about real life experiences, when WSS works and TURNS over 443 doesn't.

Best regards
Sergio

On 02/12/2014 20:44, Tirumaleswar Reddy (tireddy) wrote:
why will it not work when ALPN is used ?

-Tiru

From: Sergio Garcia Murillo [mailto:sergio.garcia.murillo@gmail.com] ?
Sent: Wednesday, December 03, 2014 12:52 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Jonathan Lennox; [ACME] Victor Pascual Avila; Simon Perreault; tram@ietf.org<mailto:tram@ietf.org>; draft-chenxin-behave-turn-websocket@tools.ietf.org<mailto:draft-chenxin-behave-turn-websocket@tools.ietf.org>
Subject: RE: [tram] TURN over WebSocket


El 02/12/2014 20:04, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com<mailto:tireddy@cisco.com>> escribió:
>
> From: Simon Perreault [mailto:sperreault@jive.com<mailto:sperreault@jive.com>]
> Sent: Tuesday, December 02, 2014 10:19 PM
>
> To: Tirumaleswar Reddy (tireddy)
> Cc: Jonathan Lennox; Sergio Garcia Murillo; Victor Pascual Avila; draft-chenxin-behave-turn-websocket@tools.ietf.org<mailto:draft-chenxin-behave-turn-websocket@tools.ietf.org>; tram@ietf.org<mailto:tram@ietf.org>
> Subject: Re: [tram] TURN over WebSocket
>
>
>
>
>
> On Tue, Dec 2, 2014 at 9:34 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com<mailto:tireddy@cisco.com>> wrote:
>
> Transparent proxies like firewalls keep getting upgraded frequently to handle new applications, threats etc. If firewall has a feature to block WebRTC traffic then by sending traffic over WebSocket will not solve the problem.
>
>
>
> (As a participant...)
>
>
> This has also been discussed before. TURN-over-WebSockets is not a way for applications to circumvent policy.
>
>
>
> The problem is there are networks that are set up so that "the web" is open, through a transparent proxy. WebRTC is part of "the web". Making TURN fit the mould of "the web" is is not circumventing policy, it's making WebRTC work. You should not need to update your proxy/firewall config for WebRTC to just work if "the web" already does work.
>
>
>
> [TR] Okay, so looks like the problem can also be solved by running TURN over 443 similar to proposals in DPRIVE WG to run DNS over 443.
>
>

Good try! Unlucky enough, doesn't work.

Best regards
Sergio