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

Simon Pietro Romano <> Mon, 20 May 2013 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EF2921F96CA; Mon, 20 May 2013 10:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.718
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fHKq8d3CV6TI; Mon, 20 May 2013 10:11:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CC28821F96B9; Mon, 20 May 2013 10:11:34 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (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 <>
In-Reply-To: <>
Date: Mon, 20 May 2013 19:11:31 +0200
Message-Id: <>
References: <> <> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl> <> <> <> <>
To: "Hutton, Andrew" <>
X-Mailer: Apple Mail (2.1283)
X-Mailman-Approved-At: Tue, 21 May 2013 09:10:43 -0700
Cc: "" <>, Lorenzo Miniero <>, "" <>, =?iso-8859-1?Q?Gustavo_Garc=EDa?= <>
Subject: Re: [BEHAVE] [rtcweb] New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 May 2013 17:11:42 -0000

I keep on thinking that the solution depicted in deserves attention.


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
> 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 []
>> Sent: 20 May 2013 10:15
>> To: Gustavo García
>> Cc: Hutton, Andrew;;
>> 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 <> 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:
>> 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:
>> 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 []
>>>>> Sent: 15 May 2013 18:20
>>>>> To: Hutton, Andrew; Chenxin (Xin);;
>>>>> Subject: RE: [rtcweb] FW: New Version Notification for
>>>>> draft-chenxin- behave-turn-websocket-00.txt
>>>>> Andrew Hutton said:
>>>>>> When we wrote the draft
>>>>> 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 mailing list
> _______________________________________________
> rtcweb mailing list

                           				      ( O-O )
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /