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

["Chenxin (Xin)" <[e-mail]>]

Reply inline

Best Regards,
     Xin

From: Bernard Aboba [mailto:[e-mail]]
Sent: Thursday, May 16, 2013 1:20 AM
To: Hutton, Andrew; Chenxin (Xin); [e-mail]; [e-mail]
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.

[Xin]   With the development of websocket, there will be more and more web servers which support websocket. That means websocket will be treated the same as HTTP in the policy of FW or proxy server. Comparing with transporting the TCP packet directly on the Http port, Upgrade the HTTP to websocket and transport the data over it is more friendly to FW and proxy server. The possibility of the block of  the websocket data by the DPI is less than the TCP data.  So I think the benefit of turn over websocket is that it will increase the success rate when the rtcweb is used in the restrictive network, such as in airport or some hotel.

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.
[Xin]  If DPI can't inspect the content of TLS data, there is no difference. But considering DPI-SSL, which could inspect the TLS session, the turn over websocket will be has the benefit which has been said before.