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

[RR] see inline

> Emil Ivov <mailto:emcho@jitsi.org>
> April 13, 2014 at 11:26 AM
>
> [...]
> 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.
[RR] I wasn't suggesting we create some kind of "ORTC ICE". I'm saying 
that ORTC provides the API toolset that allows you to be RFC compliant 
and do all the various ICE scenarios. I was also saying that you are in 
control of both sides in the sense that you do know what to 
expect/possible from the remote party's behaviours. You can predict how 
they will behave and that even with crazy SDP scenarios the ICE freezing 
rules are not a free-for-all with random ordering. Thus I do believe the 
implicit construction order with local:remote foundation matching rules 
would work fine for the various freezing scenarios. I cannot think of a 
scenario where that doesn't work even in the more complex scenarios 
(unless someone can point out some use cases where this implicit 
behaviour would be exceptionally difficult to handle). That's why I 
proposed the implicit behaviour.
>
>> The API does not allow changing of the ufrag:password.
> [RR] It's not just unnecessary, it's actually required they be the same.
>
> Is this actually true? If so, how are they passed during an ICE restart?
[RR] It's because ICE is being used for media consent (although there 
was discussion about using Dtls for consent but I never heard of a 
formal change) [ see 
http://tools.ietf.org/html/draft-ietf-rtcweb-security-05#section-4.2 ] 
As I last remember things, you aren't allowed to change your local 
ufrag:password for that reason. As for forcing an ICE restart, that is 
an issue. Although it could be as simple as "setRemoteCandidates(...)" 
with an empty list then filling it in with a new list to force a 
complete restart. Do we need to actually allow the web developer to 
change their local ufrag:password mid-session?

As for using a common ufrag:password, take a look at rfc5245:

        v=0
        o=jdoe 2890844526 2890842807 IN IP4 $L-PRIV-1.IP
        s=
        c=IN IP4 $NAT-PUB-1.IP
        t=0 0
        a=ice-pwd:asd88fgpdd777uzjYhagZg
        a=ice-ufrag:8hhY
        m=audio $NAT-PUB-1.PORT RTP/AVP 0
        b=RS:0
        b=RR:0
        a=rtpmap:0 PCMU/8000
        a=candidate:1 1 UDP 2130706431 $L-PRIV-1.IP $L-PRIV-1.PORT typ
        host
        a=candidate:2 1 UDP 1694498815 $NAT-PUB-1.IP $NAT-PUB-1.PORT typ
         srflx raddr $L-PRIV-1.IP rport $L-PRIV-1.PORT


The ICE information is connection level thus common across mlines, 
although candidates are specific to each mline.
>
>> 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.
[RR] WebRTC ICE. Because of media consent and attack scenarios, the 
ufrag:password must be set by the browser and not the web application. 
If Dtls was used for consent that wouldn't be true but I've not heard 
that formally changed (but I may be mistaken).
>
>>>
>> [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.
[RR] I think we agree. I was merely pointing out that I do not want to 
use ufrag:password as having any relationship to the freezing rules even 
though it could help derive some kind of relationship. I prefer simple 
RtcIceListener construction order with foundation local:remote matching 
rules as the implicit rules without deriving any meaning or 
interpretation at all from ice ufrag:password relationships (which could 
also be used as a factor in some/many use scenarios).
>
>
> 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.
[RR] see above statement ^.
>
>> 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.
[RR] True. That would not be a scenario where it would work. I wasn't 
suggesting we use it. In fact, I'm saying it should not be used even 
when it's possible to derive a relationship (i.e. RTP/RTCP relationship 
as meaningful for freezing). I prefer we ignore that relationship and 
focus exclusively on a simple implicit rules, i.e. construction order 
and foundation local:remote matching.
> [...]
>