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

"Tirumaleswar Reddy (tireddy)" <> Thu, 16 May 2013 04:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7ACD321F8F4D; Wed, 15 May 2013 21:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q5fSawCtmv0q; Wed, 15 May 2013 21:55:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75D7021F8EED; Wed, 15 May 2013 21:55:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9001; q=dns/txt; s=iport; t=1368680156; x=1369889756; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LljL0BCgc/S9OlnTFzucJdIefHsjX6E/UAyJHLdOQgQ=; b=PIexw9Qf5AmI9ND4K6nE9XGte8JPHzzaIVxWsMeT8Je5e+P+Wj2pCFIt rI65Jm1fvzKXgxLJ0qP6o2AwnE1iALNpnfx8UNFMaaPovHc2ZGSDi8DLt DHWrGSHxb+IbVqgRCB07/g/hXGEginpVv6nPPaBkIp4tDENzgspCnp9z2 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.87,681,1363132800"; d="scan'208,217"; a="211108161"
Received: from ([]) by with ESMTP; 16 May 2013 04:55:55 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4G4tt2i000540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 04:55:55 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 15 May 2013 23:55:55 -0500
From: "Tirumaleswar Reddy (tireddy)" <>
To: Bernard Aboba <>, "Hutton, Andrew" <>, "Chenxin (Xin)" <>, "" <>, "" <>
Thread-Topic: [rtcweb] FW: New Version Notification for draft-chenxin-behave-turn-websocket-00.txt
Thread-Index: AQHOUYdcX1lIz7P+wE24JCIYCsgyvJkG0ZaAgABst3A=
Date: Thu, 16 May 2013 04:55:54 +0000
Message-ID: <>
References: <>, <> <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl>
In-Reply-To: <BLU169-W4995BC8B88C6AD60F4CA5093A20@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B6DB83xmbrcdx10ciscoc_"
MIME-Version: 1.0
Subject: Re: [BEHAVE] [rtcweb] FW: 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: Thu, 16 May 2013 04:56:01 -0000

Please see inline [TR]

From: [] On Behalf Of Bernard Aboba
Sent: Wednesday, May 15, 2013 10:50 PM
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 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.

[TR] Firewalls with restrictive policies in addition to DPI use various other mechanisms like reputation, heuristics, HTTPS proxy etc to classify the traffic and block it.