Re: DTLS-SDP and JSEP Conflicts

On 8/25/17 4:39 PM, Roman Shpount wrote:
>
> This is a really thorny issue which does not have a good solution. 
> Correct handling of ufrag change is one of the main reasons why tls-id 
> draft was written in the first place. Here is a little bit more 
> background on the problem:
>
> 1. If ICE restart was caused by 3pcc and resulted in connection to a 
> new device, new DTLS association is required. In some cases, 
> connection to a new device will also result in the new fingerprint 
> set. In some cases (like transfer withing the same organization which 
> uses the same pre-provisioned certificate), fingerprints will stay the 
> same and only ufrag will change. So, this means new DTLS association 
> should be established if ufrag changes due to device change.
>
> 2. If ICE restart is initiated when new network interfaces became 
> available, such as when WiFi became available on the mobile device. 
> This means that both existing candidates and new candidates can be 
> present during ICE restart. This also means, that in some situations, 
> even though ICE restart completes, the underlying transport does not 
> have to change and the same ICE candidate pair will be used after ICE 
> restart. Since this is the same ICE candidate pair, it will mean that 
> packets from old and new DTLS association can be received over the 
> same 5-tuple and they cannot be demultiplexed. This means DTLS 
> association should stay the same even if ufrag changes due to ICE 
> restart but when end points plans to re-use ICE candidates.

I hate to throw new engineering into the document at this point, but 
shouldn't it be possible to distinguish between these two circumstances 
by examining the candidates and determining whether they're completely 
new (versus having at least one in common with the existing connection)? 
This means that you won't know whether to restart DTLS until trickling 
has ended (for trickle), but you can solve that by not doing aggressive 
(or passive-aggressive) nomination -- just wait until you have all the 
candidates before you start connecting.

Does that sound like it would work?

/a

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic