Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

[Christer Holmberg <[e-mail]>]

Hi Roman,

>I have looked through the slides and I think they are misleading. To me they seem to imply that DTLS >association is orthogonal to transport and only gets re-established when fingerprint changes.

That was more or less the approach people wanted to take, when this was discussed in Dallas.

>In other words, even if the underlying transport changes, but fingerprint stays the same, the slides imply that >existing DTLS association continues to be used with the new transport. BTW, I think this is what Chrome is >currently doing. This behavior is against the proposed specification language ("If the underlying transport >protocol is modified, the endpoints MUST establish a new DTLS connection"). This also presents a serious >problem in the use case where third party call control is used to move the call between the several end point >that use the same site-wide certificate. All of those end points will present the same fingerprint, but the DTLS >connection will need to be re-established since the media connection is moved to a different device. This also >shows that fingerprint alone cannot be used to determine that connection moved to the new device.

I think the assumption people had was that, if the device changes, the fingerprint will also change.

Now, if we cannot make that assumption, we need to re-visit it.

>I thought the logic that made sense was:
>1. DTLS connection is re-established whenever underlying transport changes (already in the specification).
>2. Fingerprint and setup role MUST not change unless underlying transport changes as well (already in the >specification).
>3. Unless ICE is used, underlying transport is considered changed if 5-tuple for connection changes  (already >in the specification)

Correct.

>4. In case of ICE, the underlying transport is considered changed if ufrag and entire candidate list changed on >either side of the call (missing from the current specification).

We need to be clear what we mean by “entire candidate list”. Do you mean a new SDP, which only contains candidates that have never been used before during the session?

Obviously, the IP address:port properties may still be the same, so I guess the ufrag would have to be different – as you say.

BUT, I think someone in Dallas had a comment on why ufrag can’t be used. Justin? Ekr?

>In the proposed text, the issue that I have is with the phrase "Implementations MUST treat all ICE candidate >pairs associated with a an SCTP association on top of a DTLS connection as part of the same DTLS >connection". I am not 100% sure what this means and even if this is accurate. "All ICE candidate pairs >associated with a an SCTP association" is unclear to me. Does this refer only to the candidate pairs for the >current ICE session or to the candidate pairs for any future ICE sessions associated with this SCTP >association?

Current AND future. There are proposals about the possibility of dynamically adding new candidates during the session, and they would be part of the same DTLS connection.

>Original text from RFC 5763 ("Implementations MUST treat all ICE candidate pairs associated with a single >component as part of the same DTLS association") is more accurate but suffers from the fact that "single >component" is not well defined and because of this runs into similar issues. Does ICE re-start creates a new >component or is old component considered to be re-used? If component is specific to ICE session (ufrag pair), >can candidates from the previous session be re-used for negotiating a new component? If they can, how do >you de-mux packets received between old and new component if candidates were reused on both sides.

People had issues with the usage of “component” too, but I’d need to double check with the minutes/recording for the details.

And, my intention was not to deviate from the 5763 text on purpose. I for sure can use that text, if you think it is more accurate (assuming that there are no issues with usage of “component”).

Regards,

Christer