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

[Roman Shpount <[e-mail]>]

Hi Christer,


On Wed, Apr 1, 2015 at 3:42 PM, Christer Holmberg <
[e-mail]> wrote:

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

*If this is the approach, then the specification language will need to
change. It says something different now where DTLS connection gets
re-established every time underlying transport changes, not when
fingerprint changes. In particular, the case when fingerprint stays the
same but the transport changes is treated differently.*

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

*Per the provided use case this assumption is incorrect. There needs to be
a way to detect that device changed. Neither fingerprint no IP/port change
in case of ICE provides the accurate indication of the device change.*


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

*Once again, if the logic from the slides is to be followed this will need
to change.*


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

*Ufrag change can be due to iCE re-start (which means fingerprint cannot
change) or due to device change (fingerprint can change). There is no easy
way to distinguish the two.*



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

*I was not talking about candidates here. I was talking about ICE
sessions.  Do you mean the current ICE session (and all the current and
future candidates) or current and future ICE sessions?*

 >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”).
>
>
*Neither text is ideal. I think we are dealing with fundamental problem
here and this problem get sidestepped by using fuzzy terms. The problem is
figuring out if the end point communicates with the new device or with the
existing one in cases when ICE is used. Right now the mechanism for this is
only defined for non-ICE case, with some guidelines for ICE, which are,
from my point of view, are insufficient.*
_____________
Roman Shpount