Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations

Oleg Moskalenko <mom040267@gmail.com> Sun, 22 September 2013 00:57 UTC

Return-Path: <mom040267@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 63A0521F9CAF for <pntaw@ietfa.amsl.com>; Sat, 21 Sep 2013 17:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level:
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SUBJECT_FUZZY_TION=0.156]
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 107gmml6pRxt for <pntaw@ietfa.amsl.com>; Sat, 21 Sep 2013 17:57:02 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC8F21F9D30 for <pntaw@ietf.org>; Sat, 21 Sep 2013 17:57:01 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id m15so932346wgh.3 for <pntaw@ietf.org>; Sat, 21 Sep 2013 17:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SJ+zoSn5xRuBI/oEYpb8UNJkJ19NqcqgvYkAa7qQTO8=; b=e6OREcG64/a3wKe6aoYY7XG0HOYQI2loqMtHmqni7FQRM3MNqD5GYya3LCNaV2uX71 CPXZcwYsPhV+1RBCp/+Kl8DvzUg7ubPaIp43qhjHQg82Y8RusfDvWBydeha++WPPfr53 mNxpw+3FLPuOTENUQm6tTUJxpJ5prD6lWulennWLGdja2Ykhmf3JfKZiWxQ7JC6q8+ju JOL98YiTZ2zke6kZ51bMkoQ0YlGPLF82HMnQWwdo7vab2AzVZr7Xvn++V4EN+2KWwvxU r9uhwDl2Ytr3Y3XL1JKEB2tbMMjVrEsYLf0bTqJZwOSLQ1xbfIvmjiq9f+ikfgxS+DWK O4tA==
MIME-Version: 1.0
X-Received: by 10.180.10.33 with SMTP id f1mr8094134wib.44.1379811421259; Sat, 21 Sep 2013 17:57:01 -0700 (PDT)
Received: by 10.194.108.65 with HTTP; Sat, 21 Sep 2013 17:57:01 -0700 (PDT)
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BD01A8@MCHP04MSX.global-ad.net>
References: <9F33F40F6F2CD847824537F3C4E37DDF17BCF3A5@MCHP04MSX.global-ad.net> <523CCD06.3030902@gmail.com> <BLU169-W136A55AC013DA147313576D93220@phx.gbl> <523CD42E.8070102@gmail.com> <BLU169-W82036280852F26ED26283C93230@phx.gbl> <523D4F17.2040202@gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD01A8@MCHP04MSX.global-ad.net>
Date: Sat, 21 Sep 2013 17:57:01 -0700
Message-ID: <CALDtMrL5pT3MfbQufCphEKq0-pXj+JcfwW__wzG3T6wZ=TuWhg@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
Content-Type: multipart/alternative; boundary="001a11c1cb6e9f0f8504e6ee6177"
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "pntaw@ietf.org" <pntaw@ietf.org>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Subject: Re: [pntaw] New version of draft-hutton-rtcweb-nat-firewall-considerations
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: Sun, 22 Sep 2013 00:57:03 -0000

HTTP Connect, indeed, may allow a similar functionality. But it will
require two things: a proxy configuration in the browsers, and an HTTP
Proxy set by enterprise IT department. That may be a challenge for a new
WebRTC project in an enterprise environment.

This draft allows transparent connection and operation, unlike the HTTP
proxy case.

There are tools (websockify) which make possible to use this draft with the
existing TURN servers. Putting the burden on the TURN server provider and
maintainer is easier in most cases than negotiating new IT requirements
with the enterprise IT managers.

Of course, advanced TURN servers may include it as part of the TURN server
implementation.

Oleg



On Sat, Sep 21, 2013 at 3:48 PM, Hutton, Andrew <
andrew.hutton@siemens-enterprise.com> wrote:

>
> I just don't see any advantage in the TURN over Websockets approach over
> the HTTP Connect initiated tunnel which works without any new protocol and
> therefore works with existing TURN servers.
>
> Andy
>
>
>
> ________________________________________
> From: pntaw-bounces@ietf.org [pntaw-bounces@ietf.org] on behalf of Sergio
> Garcia Murillo [sergio.garcia.murillo@gmail.com]
> Sent: Saturday, September 21, 2013 8:47 AM
> To: Bernard Aboba
> Cc: pntaw@ietf.org
> Subject: Re: [pntaw] New version of
> draft-hutton-rtcweb-nat-firewall-considerations
>
> >
> > "So in 100% cases that TURN over TLS works, TURN over (secure)
> > websockets works too."
> >
> > [BA] Agree they would both traverse that firewall equally well, but
> > TURN over (secure) websockets only works if the TURN server supports
> > it, which most won't.   This makes mandating TURN over Webosckets
> > support in the browser a hard sell.
>
> We are already working on providing a working prototype of TURN over
> websocket that will show how easy would be to add it to both browser and
> server. In fact, on first phase, we will not change the TURN server at
> all but use a websockify proxy https://github.com/kanaka/websockify to
> the WS to TCP conversion.
>
> Best regards
> Sergio
>
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw
>