Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
Simon Pietro Romano <spromano@unina.it> Mon, 20 May 2013 17:11 UTC
Return-Path: <spromano@unina.it>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF2921F96CA; Mon, 20 May 2013 10:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.718
X-Spam-Level:
X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 fHKq8d3CV6TI; Mon, 20 May 2013 10:11:37 -0700 (PDT)
Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC28821F96B9; Mon, 20 May 2013 10:11:34 -0700 (PDT)
Received: from [143.225.162.130] ([143.225.162.130]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r4KHBWVP023559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 19:11:32 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_57A43A19-E216-43EE-9809-02D4AC87A6B4"
From: Simon Pietro Romano <spromano@unina.it>
In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net>
Date: Mon, 20 May 2013 19:11:31 +0200
Message-Id: <3094D7F4-1DBE-4557-8815-3067AE07E219@unina.it>
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> <20130520111522.1b7e2eb1@meetecho.com> <9F33F40F6F2CD847824537F3C4E37DDF1159CF9B@MCHP04MSX.global-ad.net>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
X-Mailer: Apple Mail (2.1283)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 17:11:42 -0000
I keep on thinking that the solution depicted in http://tools.ietf.org/id/draft-miniero-rtcweb-http-fallback-00.txt deserves attention. Simon Il giorno 20/mag/2013, alle ore 13:06, Hutton, Andrew ha scritto: > Regarding the HTTP fallback and whether this could be adapted to be a TURN over HTTP based solution then I think the same comments that were made on the TURN over websockets apply. What are the benefits of creating a new transport for TURN over what we can do using HTTP Connect as described in http://tools.ietf.org/html/draft-hutton-rtcweb-nat-firewall-considerations-00. > > Having said that I am really happy we are having this debate as we really need to find a solution here that the browser vendors will implement so I would really like to know which options they prefer. > > I really hope we can get draft-hutton-rtcweb-nat-firewall-considerations adopted and use it to document whatever the working group agrees on being the right solution. > > Regards > Andy > > >> -----Original Message----- >> From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] >> Sent: 20 May 2013 10:15 >> To: Gustavo García >> Cc: Hutton, Andrew; rtcweb@ietf.org; behave@ietf.org >> Subject: Re: [rtcweb] New Version Notification for draft-chenxin- >> behave-turn-websocket-00.txt >> >> 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 > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/
- [rtcweb] FW: New Version Notification for draft-c… Chenxin (Xin)
- Re: [rtcweb] FW: New Version Notification for dra… Hutton, Andrew
- Re: [rtcweb] FW: New Version Notification for dra… Bernard Aboba
- Re: [rtcweb] FW: New Version Notification for dra… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] FW: New Version Notification for dra… Hutton, Andrew
- Re: [rtcweb] FW: New Version Notification for dra… Chenxin (Xin)
- Re: [rtcweb] FW: New Version Notification for dra… Chenxin (Xin)
- Re: [rtcweb] New Version Notification for draft-c… Gustavo García
- Re: [rtcweb] New Version Notification for draft-c… Lorenzo Miniero
- Re: [rtcweb] New Version Notification for draft-c… Hutton, Andrew
- Re: [rtcweb] New Version Notification for draft-c… Simon Pietro Romano
- Re: [rtcweb] New Version Notification for draft-c… Hutton, Andrew
- [rtcweb] Why? Quality! New Version Notification f… Karl Stahl
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Simon Perreault
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Karl Stahl
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Simon Perreault
- Re: [rtcweb] [BEHAVE] New Version Notification fo… Hutton, Andrew
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Hutton, Andrew
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Chenxin (Xin)
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Bernard Aboba
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Olle E. Johansson
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Karl Stahl
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Karl Stahl
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Karl Stahl
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Matthew Kaufman (SKYPE)
- Re: [rtcweb] [BEHAVE] Why? Quality! New Version N… Simon Perreault
- Re: [rtcweb] New Version Notification for draft-c… Marc Petit-Huguenin
- Re: [rtcweb] New Version Notification for draft-c… Richard Barnes