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

Hey Robin,

On 13.04.14, 19:44, Robin Raymond wrote:
>
> [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.

OK. In order for that to be true, you would need:

a) a predictable unfreeze behaviour. I think that would mostly be 
satisfied by using the order in which streams are created although we 
may want to add a few helper methods.

b) you need to be able to set ICE ufrags and passwords before ICE 
processing starts and at any point during the lifetime of the application.

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

I agree this would be good in most cases. Still, I am thinking 
applications might want to do things like replacing media streams for 
example and it might be helpful if the API allowed that to happen (i.e. 
the new stream has to replace the old one in the unfreeze order).

The ICE stacks that I have worked with have been determining order based 
on the way streams are passed to them, but that was entirely independent 
of a stream's life cycle.  I am a bit worried here that, if we only rely 
on stream creation we may put ourselves in complicated situations.

I am not currently familiar enough with the ORTC API to come up with a 
specific example, so if no one else thinks this is a problem, then fine.

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

What does this have to do with allowing the application to specify a 
ufrag and a password?

> (although there
> was discussion about using Dtls for consent but I never heard of a
> formal change)

I don't think there is one and I believe consent freshness is still 
verified through ICE:

http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-02

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

I don't see anything in there that says the application has to be 
prevented from specifying or changing the ICE ufrag and pwd attributes. 
Could you please point me to the specific text?

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

Which would take us back to creating a new ORTC ICE protcol.

> Do we need to actually allow the web developer to
> change their local ufrag:password mid-session?

Yes. Who else would do it if not them?

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

Yes, although I may have lost you because I am not sure why you are 
saying this. The ufrag and pwd password attributes can of course be 
either session level or media level or even both at the same time. They 
can also be session level in one offer and media level in the next.

http://tools.ietf.org/html/rfc5245#section-15.4:

    The "ice-pwd" and "ice-ufrag" attributes can appear at either the
    session-level or media-level.

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

Does this actually exist?

> Because of media consent and attack scenarios, the
> ufrag:password must be set by the browser and not the web application.

Well, this is neither true nor possible. The browser has no way of 
knowing what the ufrag and the password are and the only way of learning 
them would be for the application to set them.

The current WebRTC API does that through SDP blobs, which while 
generated by a browser, are very much left to the application to 
control, transport and set in a peer. So, if you remove the possibility 
for an application to set them, you would basically break ICE.

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

Not reliably, no.

Emil


-- 
https://jitsi.org

Received on Sunday, 13 April 2014 18:34:17 UTC