Re: [rtcweb] additional ICE info

Bernard Aboba <> Tue, 24 September 2013 05:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3AF5911E80F5 for <>; Mon, 23 Sep 2013 22:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.473
X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fSFyJ9vwcp+r for <>; Mon, 23 Sep 2013 22:00:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 354D011E8102 for <>; Mon, 23 Sep 2013 22:00:26 -0700 (PDT)
Received: from BLU169-W76 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Sep 2013 22:00:20 -0700
X-TMN: [U8RcWoi9a3jyPEFTtaFOuxe/oGJd6U6X]
X-Originating-Email: []
Message-ID: <BLU169-W76F559C10477A2CDBB9D2F932E0@phx.gbl>
Content-Type: multipart/alternative; boundary="_55af0b3f-ccb6-4b86-950e-4c3df1150277_"
From: Bernard Aboba <>
To: Dan Wing <>
Date: Mon, 23 Sep 2013 22:00:18 -0700
Importance: Normal
In-Reply-To: <>
References: <> <> <> <07a601ceb64e$5caaba00$16002e00$>, <07b001ceb65f$ce3f0cf0$6abd26d0$>, <07e401ceb713$bef87a60$3ce96f20$>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Sep 2013 05:00:20.0042 (UTC) FILETIME=[F7D5B2A0:01CEB8E2]
Cc: "" <>
Subject: Re: [rtcweb] additional ICE info
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2013 05:00:32 -0000

Dan Wing said: 
"Another solution is MALICE which adds information to the ICE connectivity checks (bandwidth, drop preference, etc.) which can be DPI'd by network devices."
[BA]  I am fairly keen on adding some of this information to ICE, though not to assist DPI.   Rather, my concern is that with SDP being optional in WebRTC, some of the info that would otherwise be exchanged in the signaling channel may not be present, and if present, cannot necessarily be trusted, so that putting this into the ICE exchange has potential security value.  Also, in a situation where TURN servers are rented in the cloud, it can be useful to signal the maximum bandwidth that could be used for a given allocation.  To my mind, the issue to be fixed in the TURN REST API wasn't necessarily the ability to steal credentials, but the ability to misuse those credentials in a way that could impose significant cost on the victim.  The act of mis-using a TURN credential does not by itself impose that cost -- but pumping huge amounts of traffic through it would.