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

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Mon, 23 September 2013 09:28 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 AFBB221F8E85 for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 02:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level:
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, 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 fYJVygnmo4mW for <pntaw@ietfa.amsl.com>; Mon, 23 Sep 2013 02:28:17 -0700 (PDT)
Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A66CB21F9CC8 for <pntaw@ietf.org>; Mon, 23 Sep 2013 02:27:41 -0700 (PDT)
Received: by mail-bk0-f49.google.com with SMTP id r7so1043321bkg.36 for <pntaw@ietf.org>; Mon, 23 Sep 2013 02:27:40 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4lI4Y88km7OXqZuAo9XJeGTAliHZKD4Sgd5UHnHuSHI=; b=witRILz7BOG+KUI2RUF73glomfwLwrDiw7nAegQsOs7vdqFprpQmXnWrtAHsdaZ+GG H/QqVPMX2nZ61da+MR7SsPhEyovxYtt4JjpXR6ye8vAMxY+TYvc/OzMH1IRo24vVexTD 9YPi3tFbbBxG1raskRTlHjym4ZFyMCF4CExhz5+lyJfnDsgAO9+T103kD1xGhrTLe7DL le7Ck92ol5QOEUZoblgF67OrKCUJZgS/c4iRfhZFnBLIZpt4w9QLef882C3duZk+DL8h d293W3m755iDG6Nou39vRZbsvwWXTkIlhFOxLZ17XXVeqw+dNjmuqPmS9u0jS7UNnE2O hykA==
X-Received: by 10.204.123.199 with SMTP id q7mr17367260bkr.10.1379928460792; Mon, 23 Sep 2013 02:27:40 -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 a4sm8296316bko.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 02:27:39 -0700 (PDT)
Message-ID: <52400989.5010904@gmail.com>
Date: Mon, 23 Sep 2013 11:27:37 +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: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
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> <CALDtMrL5pT3MfbQufCphEKq0-pXj+JcfwW__wzG3T6wZ=TuWhg@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF17BD08EA@MCHP04MSX.global-ad.net>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17BD08EA@MCHP04MSX.global-ad.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, Oleg Moskalenko <mom040267@gmail.com>, "pntaw@ietf.org" <pntaw@ietf.org>
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: Mon, 23 Sep 2013 09:28:18 -0000

El 22/09/2013 22:57, Hutton, Andrew escribió:
> On: 22 September 2013 01:57 Oleg Moskalenko WroteL
>> 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.
> [AndyH] - The case of an enterprise WebRTC project taking place under the control of the enterprise IT department although within scope is not the prime reason for wanting the HTTP Connect mechanism.  There are various options for this use case and the important thing is that the browser behavior is standardized and understood by the IT department.

If there are various options already available, I would like them to get 
listed in the draft.

> Probably more important at least for early deployments is making sure that a WebRTC service external to the enterprise is accessible when there is no IT department or when the IT department is not WebRTC aware and just wants it to work.  The power of WebRTC is that it brings new type of media to the web and it just has to work by default with additional controls possible if the network administrator wants to use them. If an enterprise already has a Web/HTTP Proxy deployed and a firewall configured to allow web traffic to flow via the proxy then this should also work when accessing WebRTC services. This has nothing to do with an enterprise deploying WebRTC for its own use.I

I am all for "if an enterprise already has a Web/HTTP Proxy deployed and 
a firewall configured to allow web traffic to flow via the proxy then 
this should also work when accessing WebRTC services", but my real life 
experience is that it doesn't.


>> 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.
> [AndyH] As I tried to explain above the use case of prime importance is getting WebRTC to work with existing infrastructure and without requiring an enterprise to deploy stuff just because an enterprise user wants to use a WebRTC service maybe on a single use basis such communicating with a suppliers call centre.
>
>

I agree with you also in this and TURN over websockets does not require 
any deployment inside corporations in order to make it work.

Best regards
Sergio