Subject: [MMUSIC] Question about global uniqueness of dtls-id

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Sep 2017 09:22:32 -0600

There is a bug where we are discussing if the the dtls-id needs to be globally unique or not. Can someone walk me though the logic of why it needs to be globally unique? I'm not finding it in the previous list discussion.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 16:13:12 +0000

Hi,

Does the GitHub discussion not answer the question?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: 01 September 2017 17:23
To: mmusic <[email-masked]>
Cc: Roman Shpount <[email-masked]>
Subject: [MMUSIC] Question about global uniqueness of dtls-id

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 1 Sep 2017 12:15:40 -0400

Cullen,

Imagine that call is established between end points A and B through a third
party call control element 3PCC.
3PCC then decides to connect end points A and C. 3PCC sends a request for
an offer to C (INVITE with no SDP in case of SIP).
When 3PCC gets offer from C, 3PCC send this offer to A.
As far as A is concerned this is just a re-offer on an existing connection,
so if tls-id must be different if new DTLS association is needed. If tls-id
just happens to be the same due to collision, this will either be treated
as invalid offer, if fingerprints has changed, or DTLS association will not
be created when it should have.

Essentially, because of 3PCC, connections can migrate between end points,
connecting, disconnecting, and re-connecting multiple end points. For each
end point this looks like a single connection to a 3PCC controller, but
tls-id generated by multiple unrelated end points and should not collide
between any of them.

I agree that 120 bits of randomness is excessive just to avoid collisions.
Amount of randomness was increased in order to securely identify TLS
connection and DTLS associations.

Regards,

_____________
Roman Shpount

On Fri, Sep 1, 2017 at 11:46 AM, Roman Shpount <[email-masked]> wrote:

> Cullen,
>
> Imagine that call is established between end points A and B through a
> third party call control element 3PCC.
> 3PCC then decides to connect end points A and C. 3PCC sends a request for
> an offer to C (INVITE with no SDP in case of SIP).
> When 3PCC gets offer from C, 3PCC send this offer to A.
> As far as A is concerned this is just a re-offer on an existing
> connection, so if tls-id must be different if new DTLS association is
> needed. If tls-id just happens to be the same due to collision, this will
> either be treated as invalid offer, if fingerprints has changed, or DTLS
> association will not be created when it should have.
>
> Essentially, because of 3PCC, connections can migrate between end points,
> connecting, disconnecting, and re-connecting multiple end points. For each
> end point this looks like a single connection to a 3PCC controller, but
> tls-id generated by multiple unrelated end points and should not collide
> between any of them.
>
> I agree that 120 bits of randomness is excessive just to avoid collisions.
> Amount of randomness was increased in order to securely identify TLS
> connection and DTLS associations.
>
> Regards,
>
> _____________
> Roman Shpount
>
> On Fri, Sep 1, 2017 at 11:22 AM, Cullen Jennings <[email-masked]> wrote:
>
>> There is a bug where we are discussing if the the dtls-id needs to be
>> globally unique or not. Can someone walk me though the logic of why it
>> needs to be globally unique? I'm not finding it in the previous list
>> discussion.
>>
>>
>>
>>
>>
>
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Sep 2017 11:28:50 -0600

Thank for helping my understand how we got where we are ... more inline ...

> On Sep 1, 2017, at 10:15 AM, Roman Shpount <[email-masked]> wrote:
> 
> Cullen,
> 
> Imagine that call is established between end points A and B through a third party call control element 3PCC.
> 3PCC then decides to connect end points A and C. 3PCC sends a request for an offer to C (INVITE with no SDP in case of SIP). 
> As far as A is concerned this is just a re-offer on an existing connection, so if tls-id must be different if new DTLS association is needed. If tls-id just happens to be the same due to collision, this will either be treated as invalid offer, if fingerprints has changed, or DTLS association will not be created when it should have.

I don't think that works for a bunch of reasons but to start with the 2nd offer to A would not have the right information in the o= lines of the the original offer/answer. In many cases (including WebRTC) that would cause it not to work as a re-offer. Other issues like it A was receiving video, the old I frame state might end up getting used. If A was sending, it would not know the the other end was now missing reference frames. 

SIP can deal with that by using the invite with replaces stuff from rfc3891 so that the 2nd offer sent to A can clearly be a new session not a reoffer on the old one. Similar things would be done by webrtc so it could deal with it by just creating a new PC for the 2nd offer and transfering the tracks over to the new PC. 

Section 5.2.2. of JSEP discussed this a bit how the o= lines need to be the same for a reoffer. 

> 
> Essentially, because of 3PCC, connections can migrate between end points, connecting, disconnecting, and re-connecting multiple end points. For each end point this looks like a single connection to a 3PCC controller, but tls-id generated by multiple unrelated end points and should not collide between any of them.
> 
> I agree that 120 bits of randomness is excessive just to avoid collisions. Amount of randomness was increased in order to securely identify TLS connection and DTLS associations.
> 
> Regards,
> 
> 
> 
> _____________
> Roman Shpount
> 
> Imagine that call is established between end points A and B through a third party call control element 3PCC.
> 3PCC then decides to connect end points A and C. 3PCC sends a request for an offer to C (INVITE with no SDP in case of SIP). 
> As far as A is concerned this is just a re-offer on an existing connection, so if tls-id must be different if new DTLS association is needed. If tls-id just happens to be the same due to collision, this will either be treated as invalid offer, if fingerprints has changed, or DTLS association will not be created when it should have.
> 
> Essentially, because of 3PCC, connections can migrate between end points, connecting, disconnecting, and re-connecting multiple end points. For each end point this looks like a single connection to a 3PCC controller, but tls-id generated by multiple unrelated end points and should not collide between any of them.
> 
> I agree that 120 bits of randomness is excessive just to avoid collisions. Amount of randomness was increased in order to securely identify TLS connection and DTLS associations.
> 
> Regards,
> 
> _____________
> Roman Shpount
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 1 Sep 2017 15:29:10 -0400

> SIP can deal with that by using the invite with replaces stuff from rfc3891 so that the 2nd offer sent to A can clearly be a new session not a reoffer on the old one. Similar things would be done b…

In principle this can be fixed by the B2BUA fiddling with the answer - 
rewriting the o-line as needed. OTOH, if it is doing that it can perhaps 
also rewrite the tls-id value if it isn't unique.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sun, 3 Sep 2017 17:17:14 -0400

Hi,

On Sep 1, 2017 1:28 PM, "Cullen Jennings" <[email-masked]> wrote:

I don't think that works for a bunch of reasons but to start with the 2nd
offer to A would not have the right information in the o= lines of the the
original offer/answer. In many cases (including WebRTC) that would cause it
not to work as a re-offer. Other issues like it A was receiving video, the
old I frame state might end up getting used. If A was sending, it would not
know the the other end was now missing reference frames.

Third party call control is something that is widely used as well. You are
correct that offer generation requires that information in o= line must be
preserved, but I am not aware of any reason why offer with non matching o=
line will not be processed if received from remote end point. This is very
common and will likely cause interop problems if prohibited.

I think new I frame should be always sent when new DTLS association is
established. I need to double check but I think it is already required
after ICE restart. If not, new I frame is a good idea after ICE restart or
communication transport 5 tuple change.

SIP can deal with that by using the invite with replaces stuff from rfc3891
so that the 2nd offer sent to A can clearly be a new session not a reoffer
on the old one. Similar things would be done by webrtc so it could deal
with it by just creating a new PC for the 2nd offer and transfering the
tracks over to the new PC.

Replaces header support is optional and it is not always enabled. In any
case, despite the fact that some call scenarios can be implemented using
other methods, third party call control is widely deployed and used, which
means offer/answer compliant end points would have to deal with such
scenarios.

Section 5.2.2. of JSEP discussed this a bit how the o= lines need to be the
same for a reoffer.

This section describes how offer is generated by JSEP compliant end points.
I do not think it puts those limitations on what offers should be processed
when received from remote, not necessarily JSEP compliant, end points, such
as WebRTC gateways.

Regards,
Roman Shpount