Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt

Gustavo García <ggb@tokbox.com> Mon, 20 May 2013 06:20 UTC

Return-Path: <ggb@tokbox.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313C821F8FFA for <behave@ietfa.amsl.com>; Sun, 19 May 2013 23:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 zajJjEWR0aTu for <behave@ietfa.amsl.com>; Sun, 19 May 2013 23:20:49 -0700 (PDT)
Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with SMTP id 83F7B21F8FDF for <behave@ietf.org>; Sun, 19 May 2013 23:20:49 -0700 (PDT)
Received: from mail-pb0-f46.google.com ([209.85.160.46]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKUZnAv+/bemdl/XlGHSuuKBkQ3vdeKctT@postini.com; Sun, 19 May 2013 23:20:49 PDT
Received: by mail-pb0-f46.google.com with SMTP id rq2so853043pbb.5 for <behave@ietf.org>; Sun, 19 May 2013 23:20:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=MEEnF9UQJaddOPR545NYv3a4ivMh/sm93NYqgTI5ADI=; b=Vjei2rI137/Kjd0Iazyducq0NWYZXwtyKJGOLKYAq9qLyVqLWS/EykZFA5vz+KLDcg Wux7Roe2c6+SsXA/1xCw2hvhD/LHc4d+AScHfcoHEfVmSJzoljOUq9KWdifsMtF7W558 kcd7FXOOiWDQ3GNH4LfRbZiFBprw1rGTH/ls1SNcRllqZ5uWYCdiEbHw0qDVtZTaUPfv bEwy42jtfr/lHuKrf2NkT9TOn9eZBKQEGXfzFciluRsVrw1uz0Vw7bYBL9GQiDjFvlrv PVb8sklLzpLDTZmCgqUot4gO8nUoH2ohHD6TTefM4ZO37KiFhol9T3UBFWo+jfg2Jfqx clWA==
X-Received: by 10.68.204.35 with SMTP id kv3mr59429626pbc.87.1369030847027; Sun, 19 May 2013 23:20:47 -0700 (PDT)
X-Received: by 10.68.204.35 with SMTP id kv3mr59429616pbc.87.1369030846920; Sun, 19 May 2013 23:20:46 -0700 (PDT)
Received: from [192.168.10.222] (ginger.tokbox.com. [216.38.134.117]) by mx.google.com with ESMTPSA id wi6sm22724942pbc.22.2013.05.19.23.20.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 May 2013 23:20:45 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= <ggb@tokbox.com>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net>
Date: Sun, 19 May 2013 23:20:41 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com>
References: <9E34D50A21D1D1489134B4D770CE03974C6DC83A@szxeml538-mbs.china.huawei.com>, <9F33F40F6F2CD847824537F3C4E37DDF11599668@MCHP04MSX.global-ad.net> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <9F33F40F6F2CD847824537F3C4E37DDF1159A209@MCHP04MSX.global-ad.net>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQlTwOqNMt0KuOOQEvX+sQevL65WCFWNvzEbQ2Vs5NFtqQLOh0BZyN8LUPGwYiS0i8cIbI//qjdLxrVH3EYDa0GPleA78m/9XLfOqzdrJf03GEOi8+Ok9dlwaEXAmND4fMrqsW0J8V3WLfYvmuEmDE+/DN7zBQ==
X-Mailman-Approved-At: Mon, 20 May 2013 08:58:02 -0700
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "behave@ietf.org" <behave@ietf.org>, "Chenxin \(Xin\)" <hangzhou.chenxin@huawei.com>
Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 06:20:55 -0000

I agree that TURN over websockets doesn't solve much more scenarios than TURN/TLS.   If trying to fix HTTP Proxy traversal why not doing it over HTTP that aside of philosophical discussions would be the solution with better success rate?  Otherwise we will have to continue answering for another 10 years "why is this app not working if skype does".

Something like this draft sent some months ago but perhaps for TURN instead of direct connections:
http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt

On 16/05/2013, at 01:28, Hutton, Andrew wrote:

> I agree with Bernard's comments regarding the impact of DPI but of course such DPI devices do what they do and we can't and even don't want to stop them from doing it. However for the case when policy is such that the firewall will only allow traffic to traverse that comes from the HTTP Proxy or a network specific TURN server and there is no deliberate policy to block WebRTC media we need a solution and this is what draft-hutton-rtcweb-nat-firewall-considerations-00 addresses.
> 
> So far I don't see the benefit that TURN over websockets would have in this scenario and it needs additional implementation in the browser and the TURN server.
> 
> Regards
> Andy
> 
> 
>> -----Original Message-----
>> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
>> Sent: 15 May 2013 18:20
>> To: Hutton, Andrew; Chenxin (Xin); behave@ietf.org; rtcweb@ietf.org
>> Subject: RE: [rtcweb] FW: New Version Notification for draft-chenxin-
>> behave-turn-websocket-00.txt
>> 
>> Andrew Hutton said:
>>> When we wrote the draft http://tools.ietf.org/html/draft-hutton-
>> rtcweb-nat-firewall-considerations-00 we did not include this option
>> because we did not see the benefit of additional transport options for
>> TURN given that the existing options (E.g. TURN/TCP and TURN/TLS) seem
>> to be meet our needs.
>>> 
>>> So what would be the benefits that justify this addition transport
>> option for TURN?
>> 
>> [BA] In my experience,  institutions with very restrictive security
>> policies (e.g. those that don't allow UDP in or out) also tend to
>> deploy other measures such as deep packet inspection.   So just because
>> some traffic is allowed in or out on port 80 does not mean that
>> TURN/TCP will be allowed on that port - a DPI box may examine the
>> traffic and complain if it doesn't see HTTP being used.  On the other
>> hand, unless the DPI box is upgraded, it will also complain about
>> websockets.  So I think draft-chenxin only helps in a situation where
>> TURN over Websockets would be allowed when TURN/TCP would not be.  That
>> scenario is rare, at least at the moment.
>> 
>> The argument for TURN over Websocket/TLS is even more difficult to
>> make. While DPI boxes may examine traffic destined to port 443
>> carefully to make sure that TLS is really being used,  assuming that
>> the DPI box does not see anything it considers fishy, the TLS exchange
>> will complete and the DPI box will lose visibility.  After TLS is
>> running, the DPI box does not have much information available to
>> distinguish TURN/TLS from HTTP over TLS, with or without websockets --
>> and those things it does have (such as packet size) are as likely to
>> result in an objection to websocket transport as TURN/TLS.  So I'm not
>> sure that draft-chenxin will help in that situation either.
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb