Re: Question about global uniqueness of dtls-id

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


> On Sep 1, 2017, at 10:15 AM, Roman Shpount <[email protected]> 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.

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
> 
> On Fri, Sep 1, 2017 at 11:46 AM, Roman Shpount <[email protected]> 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 protected]> 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.
> 
> 
> 
> 
>  
> 
> 
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic