Re: [rtcweb] additional ICE info

Dan Wing <dwing@cisco.com> Wed, 25 September 2013 00:09 UTC

Return-Path: <dwing@cisco.com>
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 C669A21F9AE7 for <rtcweb@ietfa.amsl.com>; Tue, 24 Sep 2013 17:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.684
X-Spam-Level:
X-Spam-Status: No, score=-110.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Shghg6K2bTl4 for <rtcweb@ietfa.amsl.com>; Tue, 24 Sep 2013 17:09:09 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D421F8E3D for <rtcweb@ietf.org>; Tue, 24 Sep 2013 17:09:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1843; q=dns/txt; s=iport; t=1380067749; x=1381277349; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Rril74V9K1Eb+49dRE3ic1Aqlq3Z3V0cf/5rgOvLETg=; b=LKfuiDpwA2CkD5nLVgAjtZF3/t+BAGgIkl4KEzTlEo4llSUa5pifdzMN 0/YE5X+ydLMuJmgAcwyKyTG1BE+GQf2/e8CHAW8+sN/oYkFBvkB2IFqYx L6UHfvEQ0UkYeUbPT9ZddpZVBOXme/R+YbkIemO8FoZ8IaDFaFDeFCkeQ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFALwoQlKrRDoJ/2dsb2JhbABbgwc4rlmSVIEeFnSCJQEBAQMBeQUJAgtGFkEGExuHWAMJBQ28RQSMYoI4MweDHYEAA4k4jFyBaIEviReBfoUzg0Qc
X-IronPort-AV: E=Sophos;i="4.90,974,1371081600"; d="scan'208";a="89795077"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 25 Sep 2013 00:09:09 +0000
Received: from sjc-vpn3-476.cisco.com (sjc-vpn3-476.cisco.com [10.21.65.220]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8P098Ad027672; Wed, 25 Sep 2013 00:09:08 GMT
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <BLU169-W76F559C10477A2CDBB9D2F932E0@phx.gbl>
Date: Tue, 24 Sep 2013 17:10:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF892D04-86C2-4869-B261-38995F986550@cisco.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se>, <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se>, <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se>, <98A3CE39-1BC6-4A36-8DF0-A3932DCDA9AC@cisco.com> <BLU169-W76F559C10477A2CDBB9D2F932E0@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1508)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] additional ICE info
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: Wed, 25 Sep 2013 00:09:14 -0000

On Sep 23, 2013, at 10:00 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> 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.  

Yes, bandwidth is part of Microsoft's extensions to TURN as I'm sure you are aware (but others are probably not aware), http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx

The advantage of allowing routers along the path to see the bandwidth is they can influence their routing decisions to put the traffic on a better path (e.g., 3G versus microwave link versus satellite), prioritize the traffic, and do other things.  If the network always has sufficient bandwidth and thus no need to differentiate traffic, I agree there is no value and no purpose to tell the network anything.

> 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. 

-d