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

Lorenzo Miniero <lorenzo@meetecho.com> Mon, 20 May 2013 09:15 UTC

Return-Path: <lorenzo@meetecho.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 BA2CF21F8529 for <behave@ietfa.amsl.com>; Mon, 20 May 2013 02:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.419
X-Spam-Level:
X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_8BIT_HEADER=0.3]
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 HXdOxxAwRIPU for <behave@ietfa.amsl.com>; Mon, 20 May 2013 02:15:51 -0700 (PDT)
Received: from smtpdg10.aruba.it (smtpdg5.aruba.it [62.149.158.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2D99D21F856D for <behave@ietf.org>; Mon, 20 May 2013 02:15:31 -0700 (PDT)
Received: from localhost.localdomain ([143.225.229.163]) by smtpcmd05.ad.aruba.it with bizsmtp id e9FV1l00E3YAKuv019FVsx; Mon, 20 May 2013 11:15:29 +0200
Date: Mon, 20 May 2013 11:15:22 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Gustavo García <ggb@tokbox.com>
Message-ID: <20130520111522.1b7e2eb1@meetecho.com>
In-Reply-To: <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> <6F6B2040-A8C7-4B37-928E-5072F06E9894@tokbox.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; i686-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 20 May 2013 08:58:02 -0700
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, "behave@ietf.org" <behave@ietf.org>
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 09:15:57 -0000

Il giorno Sun, 19 May 2013 23:20:41 -0700
Gustavo García <ggb@tokbox.com> ha scritto:

> 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
> 


When I submitted that draft this summer, I had that exact purpose in
mind, that is taking care of corner edge cases like restrictive proxies
and the like. Of course it was not meant to be a solution, just a way
to foster discussion in that direction. In that discussion I also
mentioned some work we did about this in the past, which in part
apparently ended up in draft-hutton-rtcweb-nat-firewall-considerations:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg05041.html

At the time most people in the ML thought it was either too useless,
too complex or even harmful, considering it could be considered as a
"sneaky" way to circumvent rules added by a network administrator, and
so unacceptable. Anyway, as I said back then, a solution like this
doesn't have to be sneaky, and it could very well be conceived in order
to be admin-friendly rather than have a parrot and a wooden leg.

Whether we actually need something like this or TURN-over-443 is enough
I don't know: I still think it may be useful to tackle scenarios where
everything else fails (the "skype works here" effect), so I'd be glad
to be of help in that direction if needed.

Lorenzo



> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb