Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

[Roman Shpount <[e-mail]>]

On Fri, Aug 25, 2017 at 6:47 PM, Adam Roach <[e-mail]> wrote:

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

This will theoretically work, but can delay DTLS association setup in case
of tricket ICE past the point of being usable.

More importantly this is not how existing implementations work. They simply
do not start new DTLS association on ufrag change. This is for legacy
interop only, so we might as well do what legacy end points do and ignore
ufrag.

Regards,
_____________
Roman Shpount