Re: ICE candidate search freezing and reuse of usernameFrag/password for components

On 13.04.14, 16:56, Robin Raymond wrote:
>
> [RR] see inline comments
>
>> Emil Ivov <mailto:emcho@jitsi.org>
>> April 13, 2014 at 10:35 AM
>> [...]
>> [RR] Web application is in control of both sides, therefor it can use the
>> same logic to control construction order (or ensure at least one side
>> constructs the order respective to the other side).
>>
>> I don't think this is true. There are a number of gatwaying scenarios
>> where we may want to have media-level compatibility between a web
>> application and something else.
>
> [RR] Not really relevant to the issue but just as a point of clarity,
> because web apps don't do implicit signaling, and you are in control of
> signaling and what devices / services you interact with so therefor you
> are in control over how you interact. As you aren't randomly interacting
> with unknown systems, you know what you are going to get and expect.
> However, if you chose to signal with unknown / uncontrolled systems,
> that's still your choice and your pain on how to handle all the bizarre
> odd cases that arise. ORTC should just provide the tools so that you can
> be compliant with most reasonable deployments. You have full control
> over what happens and how you choose to meld those systems together.

ORTC claims to be using ICE. If so then we would need to make sure  ORTC 
ICE implementations be interoperable with non-ORTC ICE implementations.

Failing to do so would mean that we would also need to design a new 
NAT-traversal solution in addition to a web RTC API.

>>> So while not
>>> technically related, in practice they go hand in hand for most use cases.
>>> The ufrag:password for RTCP must be copied from RTP and since the web app
>>> isn't allowed to set a custom ufrag:password for security reasons
>>
>> You mean that as a restriction only for RTCP right? I don't see how
>> the reasons are security-related but I agree that setting a separate
>> password for RTCP is entirely unnecessary.
> [RR] It's not just unnecessary, it's actually required they be the same.
> The API does not allow changing of the ufrag:password.

Is this actually true? If so, how are they passed during an ICE restart?

> There's been past
> discussion about legality of changing ufrag:password to prevent various
> attacks and moving the agreement to Dtls.  I've not heard any conclusion
> to that argument so as far as I'm aware the ufrag:password is still not
> allowed to be set by the web application.

Is this statement made for WebRTC, ORTC or ICE in general? I fail to see 
how an application could ever use ICE without the possibility to set 
ufrag and password.

>>> thus the
>>> only way to make sure the ufrag:password match is via copying the
>>> credentials from an existing RtcIceListener. In theory you could tie some of
>>> the freezing behaviour based on that association
>>
>> Given how different streams can use the same or different ICE
>> credentials, I don't see how this could be achieved.
> [RR] Agreed, which is why even though the majority of the use cases, it
> works. It doesn't alway work which is why I prefer a different rule.

I don't understand how it covers any use cases at all but as long as we 
agree that it is not the right approach then I guess it's not worth 
dwelling on it.

>>> but I was suggesting we do
>>> it exclusively based on construction order and local:remote foundation
>>> matches and leave the ufrag:password copying as an independent and unrelated
>>> operation.
>>
>> Copying from where to where? Sorry, I guess I am still confused by
>> what password and ufrags could possibly have to do with freezing.
> [RR] The RtcIceListener contains the ufrag:password. All
> RtcIceTransports that derive from the same RtcIceListener must share the
> same ufrag:password because they share the same physical socket ports.
> If you want to create a different listener (i.e. different port like an
> RTCP port), you need to be able to copy the ufrag:password from the
> existing RtcIceListener since the web application is not allowed to
> manually change the ufrag:password. The freezing has nothing to do with
> this at all.

OK, then I guess I just don't know why it was mentioned in the original 
mail :). I must have missed something so feel free to ignore.

> It's just that freezing is mostly used in the RTP/RTCP port
> scenarios where the ufrag/password are shared.

It is actually used with audio/video scenarios just as often. I suppose 
that's where all the confusion is coming from. The candidate pairs of a 
video stream are supposed to be frozen until rtp pairs for the audio 
stream succeed. It wouldn't be possible to use ufrags and passwords to 
implement this however as the streams can use both the same and 
differing credentials.

Cheers,
Emil

-- 
https://jitsi.org

Received on Sunday, 13 April 2014 15:29:56 UTC