Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

[Roman Shpount <[e-mail]>]

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

>
>    1. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to
>    restart? The primary rationale outlined in RFC5245 for restarting ICE is
>    changing the destination (IP address or port) of an ongoing media stream --
>    which would commonly involve changing to a different physical device. While
>    it would, in theory, be possible to transfer the TLS state associated with
>    the connection between devices, this is rather cumbersome (and, as far as I
>    know, not generally supported by TLS libraries). From that perspective, it
>    is my opinion that the DTLS-SDP document is correct that an ICE restart
>    necessitates a new DTLS connection; and I conclude that JSEP needs to
>    change.
>
>
> 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.

So, we have two situations which both will result in some interop problems
regardless of which decision we will make. Taking into account that most of
existing ICE with DTLS implementations use ephemeral certificates, 3pcc
will likely result in change of both ufrag and fingerprints. Because of
this, I think not establishing new DTLS association on ufrag change is a
safer option. Which means JSEP text is probably a safer option, especially
where WebRTC is concerned.

This being said, going forward tls-id should be used to make sure this is
resolved in unambiguous manner.

Regards,
_____________
Roman Shpount