Re: [rtcweb] additional ICE info

On Sep 24, 2013, at 11:15 PM, Harald Alvestrand <harald@alvestrand.no> wrote:

> Thanks for the pointer!
> 
> The existence of that (public) document explains some strange features
> of some earlier Microsoft proposals that I was never able to get an
> explanation for.
> 
> This approach (which seems to have many of the properties of RSVP) seems
> to offer a solution to some problems that people have been solving by
> snooping SIP (which is impossible if SIP isn't used, and very hard when
> all the SIP channels are encrypted).

An additional difficulty, even if the SIP signaling is un-encrypted, is on complex (enterprise) networks the SIP signaling path and media path may go over different network equipment.  Our existing customers solve that problem by ensuring their network topology forces the paths to be congruent, but forcing such a network topology has other disadvantages (link costs go up, and becomes difficult to design around link failure).

> Is there a chance that we could get
> public-stable specification of the required pieces, so that other
> companies can dare to depend on it?

We recently published http://tools.ietf.org/html/draft-martinsen-mmusic-malice which does something similar.  We are not married to those exact bits-on-the-wire, but we see value in the signaling for both the network and the end hosts (such as the TURN server).

-d

> (public-stable, a term I just invented, includes independent RFC, info
> RFC and standards-track)
> 
> On 09/25/2013 02:10 AM, Dan Wing wrote:
>> 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
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> -- 
> Surveillance is pervasive. Go Dark.
> 