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

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Apr 2015 10:47:23 +0000

Hi Roman,

>>> The note tells what does not trigger setup of the new DTLS connection in case of ICE. It does not specify what does. I also 
>>> think it is ambiguous. Current language implies that all candidate pairs associated with SCTP association are the same 
>>> transport.  Does this mean that if SCTP connection is not re-established and ICE is used, new DTLS session is not started? 
>>> Or does it mean that a new DTLS connection is setup for each new ICE session? What about ICE restart (i.e. ufrag change 
>>> between the same end points when the same candidate sets are reused on both sides)?
>> 
>> The idea is that a change of the fingerprint would trigger a new DTLS connection.
>>
>>But, in order to avoid the receiving-packets-associated-with-old-keys issue (raised by yourself earlier) the suggestion was that the transport 5-tuple also needs to change.
>> 
>> I agree some wording is needed about that.
>
> The idea was also that fingerprint can only change if underlying transport changes as well. I think we need to define what this means in case of ICE, since 5-tuple
> change, when ICE is used, is not necessarily a transport change (as in cases when it is a change between the candidate pairs).

Correct, and that is what the "virtual connection" is all about. A change to another candidate pair is NOT considered a transport change. 

In fact, Justin found text in RFC 5763 (section 6.7.1) which already defines that:

	"Implementations MUST treat all ICE candidate pairs associated with a single component as part of the
	same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid 
	candidate pairs."

I used this text (with some minor changes) in my suggested text for the SCTP-SDP draft. I was supposed to also reference 5763, but I see that I forgot to replace "[add-reference]" with "[RFC5763]".

> I think the intent is, that in case of ICE, DTLS fingerprint can change only if new ufrag is used (new ICE session) and entire candidate list 
> changes (not an ICE restart on existing candidates). I would really like to see if the rest of the people on the list agree and this decision is documented somewhere.

With or without ICE, the idea is that a fingerprint change is *only* allowed if the DTLS connection is moved to another device/stack, e.g. in the case of 3pcc.

Below is the link to the slides Justin prepared:

http://www.ietf.org/proceedings/92/slides/slides-92-mmusic-8.pdf

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 1 Apr 2015 11:29:22 -0400

Hi Christer,

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

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?

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.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 1 Apr 2015 19:42:27 +0000

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.

>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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 1 Apr 2015 17:21:40 -0400

Hi Christer,

On Wed, Apr 1, 2015 at 3:42 PM, Christer Holmberg <
[email-masked]> 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.
>
>
>

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

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

> changes as well (already in the >specification).
>
> 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.
>
>
>

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

> "Implementations MUST treat all ICE candidate >pairs associated with a an
> accurate. "All ICE candidate pairs >associated with a an SCTP association"
> 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
> issues. Does ICE re-start creates a new >component or is old component
> 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
> 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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 Apr 2015 08:43:16 +0000

Hi Roman,

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

Ok.

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

The text will be fixed.

Of course, whatever solution will be for the ICE case, it could also be applicable for the non-ICE case. But, the non-ICE case is easier, because we know a change in the 5-tuple will trigger a new DTLS connection - no matter if the fingerprint etc change or not.

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

Correct.

One possible way would be to use the SDP connection attribute, with a "new" value. However, usage of the attribute is currently not allowed for SRTP-DTLS.

There was also a suggestion to use SIP replace, but we need to define an SDP mechanism.

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

I could not find a clear definition of "ICE session", but I would assume it applies to current and future ICE sessions - assuming e.g. an ICE restart triggers a new ICE session.

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

So, the question is: how do we know whether we are communicating with a new device?

Again, for the non-ICE case I think we can use a 5-tuple change as indicator.

For ICE, it seems like we can't use fingerprint, and we can't use ufrag. What about if BOTH the fingerprint and ufrag change?

Regards,

Christer

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Apr 2015 15:09:29 -0400

Hi Christer,

On Thu, Apr 2, 2015 at 4:43 AM, Christer Holmberg <
[email-masked]> wrote:

> Of course, whatever solution will be for the ICE case, it could also be
> applicable for the non-ICE case. But, the non-ICE case is easier, because
> we know a change in the 5-tuple will trigger a new DTLS connection - no
> matter if the fingerprint etc change or not.
>

We still have ambiguity here. The slides seem to imply that if the
fingerprint stayed the same but 5-tuple changed, this is the same DTLS
connection. The current proposed text says that this a new connection.

> One possible way would be to use the SDP connection attribute, with a
> "new" value. However, usage of the attribute is currently not allowed for
> SRTP-DTLS.
>
>
I would be fine with this. For instance new DTLS connection is only
established when connection "new" attribute is present or if fingerprint or
setup role changes. Connection "new", or fingerprint and setup role changes
are only allowed if underlying transport changes as well in such a way that
packets for the new connection can be demuxed from the packets for the old
DTLS connection based on the transport. This should be backwards compatible
and will address all of my issues.

Do you know why connection attribute was disallowed in SRTP-DTLS?

> There was also a suggestion to use SIP replace, but we need to define an

Agreed. This problem should be orthogonal to SIP signaling and should be
resolved within SDP.

> For ICE, it seems like we can't use fingerprint, and we can't use ufrag.
> What about if BOTH the fingerprint and ufrag change?
>
>
The problem we are dealing with is when several devices use a
pre-provisioned site-wide certificate. For instance we typically use domain
certificates for SIPS on multiple servers and would like to use them for
DTLS as well. Since the certificate is the same, the fingerprint is the
same across multiple devices. When third party call control is used in such
deployment, the connection can move from one device to another, but the
fingerprint will stay the same. So we have a situation where fingerprint
stays the same, but ufrag changes. The problem is how to distinguish this
from ICE-restart, where fingerprint stays the same but ufrag changes. One
option is to examine the candidate list and apply see that it does not
intersect with the currently used candidates, but this seems extremely
brittle. The other option is to add something like connection new attribute
and to make sure new DTLS connection is set.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Apr 2015 16:57:28 -0400

> There was also a suggestion to use SIP replace, but we need to define an SDP mechanism.

Well, when using SIP replace the session-id (o-line) should change. And 
it is supposed to remain unchanged within a dialog.

So from an SDP perspective a totally new session-id value can be taken 
as an indication. But this affects the complete SDP session, not just a 
single m-line or bundle.

ISTM that a=connection:new is the better answer. The forbidding of this 
for SRTP-DTLS seems like a bug rather than a feature. Does anyone know 
the reason for it?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 2 Apr 2015 17:49:09 -0400

On Thu, Apr 2, 2015 at 4:57 PM, Paul Kyzivat <[email-masked]> wrote:

> Well, when using SIP replace the session-id (o-line) should change. And it
> is supposed to remain unchanged within a dialog.
>
> So from an SDP perspective a totally new session-id value can be taken as
> an indication. But this affects the complete SDP session, not just a single
> m-line or bundle.
>

There are also third party call control scenarios where media from several
different agents is aggregated into a single SDP session. One example would
be a solution where audio conferencing server and video SFU are aggregated
to appear as a single solution using a separate signaling agent. Using
entire new session id will not work in such case, since DTLS connection for
only one of the media lines might need to be re-established with the other
m= lines reusing existing connections.

> for SRTP-DTLS seems like a bug rather than a feature. Does anyone know the
> reason for it?
>

I do agree a=connection:new is the better answer. One problem that I see
with it, that it re-establishes all the protocols running on the same m=
line which support it. For instance if you have SCTP and DTLS used on the
same m= line, both will be reset when a=connection:new is specified. I am
not sure how big of the problem this is for SCTP or other protocols and if
you would ever need to re-start SCTP without restarting DTLS or vice verse.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Apr 2015 14:37:27 +0000

Hi,
…

>I do agree a=connection:new is the better answer. One problem that I see with it, that it re-establishes all the protocols >running on the same m= line which support it. For instance if you have SCTP and DTLS used on the same m= line, both will >be reset when a=connection:new is specified. I am not sure how big of the problem this is for SCTP or other protocols and >if you would ever need to re-start SCTP without restarting DTLS or vice verse.

Assuming the DTLS connection is re-established due to change of device, the SCTP association would obviously also have to be re-established. 

(In fact, I believe re-establishing the SCTP association would more or less eliminate the risk of receiving packets associated with the old DTLS connection.)

Perhaps there could be cases where the SCTP association needs to be re-established, but not the DTLS connection. And, the SCTP stack itself could of course do that, without touching the DTLS connection, but I think we would simply say that the draft mechanism doesn't support explicit O/A negotiation of such action.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Apr 2015 14:40:52 +0000

Hi,

>ISTM that a=connection:new is the better answer. The forbidding of this for SRTP-DTLS seems like a bug rather than a >feature. Does anyone know the reason for it?

I don't know the reason, but I ASSUME the reason was because the connection attribute was defined for a connection oriented transport (TCP), which SRTP-DTLS is not (well, at least it wasn't when SRTP-DTLS was defined - after that we got TCP-ICE etc).

In any case, I don't think it would be too late to allow usage of the attribute for SRTP-DTLS. It would be a straight forward mechanism, which could be used both in the ICE and non-ICE case. 

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 3 Apr 2015 12:52:11 -0400

On Fri, Apr 3, 2015 at 10:37 AM, Christer Holmberg <
[email-masked]> wrote:

> (In fact, I believe re-establishing the SCTP association would more or
> less eliminate the risk of receiving packets associated with the old DTLS
> connection.)
>

I think you have the layering wrong, if SCTP is running on top of DTLS,
then you can still receive DTLS packets for the old DTLS session. It should
not be relevant to the current discussion since in case of device change
both should be reset. Without device change both should stay connected.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 3 Apr 2015 13:00:48 -0400

On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg <
[email-masked]> wrote:

>
> In any case, I don't think it would be too late to allow usage of the
> attribute for SRTP-DTLS. It would be a straight forward mechanism, which
> could be used both in the ICE and non-ICE case.
>

I agree this is not too late to allow usage of the attribute for SRTP-DTLS
or any other protocol running on top of DTLS, but there are several
backward compatibility questions:

First of all, should the DTLS connection be reset on the transport
(5-tuple) change in the non-ICE case if fingerprint stayed the same and the
connection attribute is not present? Current specification says that it
should, so this needs to be preserved for backwards compatibility.

Also, should sending connection attribute set to "existing" and changing
the underlying transport be allowed? If backwards compatibility to be
maintained, it should not.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Apr 2015 18:00:05 +0000

Hi,

There are obviously "combinations" that are ambiguous, but you'll find that elsewhere too.

Or, we simply define an order in which things (5-tuple changes, attribute values etc) are checked.

Or, we do NOT use the attribute for non-ICE.

Or, we do something else - but we DO need to solve this.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎03/‎04/‎2015 20:00
To: Christer Holmberg<mailto:[email-masked]>
Cc: Paul Kyzivat<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

I agree this is not too late to allow usage of the attribute for SRTP-DTLS or any other protocol running on top of DTLS, but there are several backward compatibility questions:

First of all, should the DTLS connection be reset on the transport (5-tuple) change in the non-ICE case if fingerprint stayed the same and the connection attribute is not present? Current specification says that it should, so this needs to be preserved for backwards compatibility.

Also, should sending connection attribute set to "existing" and changing the underlying transport be allowed? If backwards compatibility to be maintained, it should not.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2015 11:13:23 +0000

Hi,

Any comments on this from others? We need to solve it.

Anyone has issues with allowing connection:new for SRTP-DTLS and SCTP-DTLS, and use that as a trigger to re-negotiate DTLS?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 3. huhtikuuta 2015 21:00
To: Roman Shpount
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Apr 2015 13:01:19 -0400

On 4/7/15 7:13 AM, Christer Holmberg wrote:
> Anyone has issues with allowing connection:new for SRTP-DTLS and
> SCTP-DTLS, and use that as a trigger to re-negotiate DTLS?

ISTM that this is being considered tactically. Maybe that is the best 
for now, but perhaps there should be consideration of a strategic 
approach to this as well.

What I mean is that this seems to be a back handed way to introduce 
multipath support into protocols (specifically DTLS) that don't support 
it. Perhaps multipath ought to be officially added to all the protocols 
that potentially need ICE, and then ICE would simply be one way to 
populate the paths.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 3. huhtikuuta 2015 21:00
> *To:* Roman Shpount
> *Cc:* [email-masked]; Paul Kyzivat
> *Subject:* Re: [MMUSIC] SCTP-SDP: Virtual Connection impact
>
> Hi,
>
> ------------------------------------------------------------------------
>
> *From: *Roman Shpount <mailto:[email-masked]>
> *Sent: *‎03/‎04/‎2015 20:00
> *To: *Christer Holmberg <mailto:[email-masked]>
> *Cc: *Paul Kyzivat <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Subject: *Re: [MMUSIC] SCTP-SDP: Virtual Connection impact
>
> On Fri, Apr 3, 2015 at 10:40 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>
> I agree this is not too late to allow usage of the attribute for
> SRTP-DTLS or any other protocol running on top of DTLS, but there are
> several backward compatibility questions:
>
> (5-tuple) change in the non-ICE case if fingerprint stayed the same and
> the connection attribute is not present? Current specification says that
> it should, so this needs to be preserved for backwards compatibility.
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 8 Apr 2015 14:44:25 -0400

On Wed, Apr 8, 2015 at 1:01 PM, Paul Kyzivat <[email-masked]> wrote:

> ISTM that this is being considered tactically. Maybe that is the best for
> now, but perhaps there should be consideration of a strategic approach to
> this as well.
>
> multipath support into protocols (specifically DTLS) that don't support it.
> Perhaps multipath ought to be officially added to all the protocols that
> potentially need ICE, and then ICE would simply be one way to populate the
> paths.
>
>
This will still leave the question of how to determine when the multipath
protocol running over ICE communicates with the new end point (i.e.
connection needs to be re-established) or when this is a path update and
the connection needs to be preserved. For ICE there is no easy way to
determine if what currently is happening is ICE-restart on the existing
connection which should allow existing mutlipath protocol session to
continue vs setting up ICE to a new end point which would require new
connection setup. This problem currently affects DTLS, but I assume this
will apply also to other multipath protocols which require externally
initiated connection handshake when running over ICE. This can be addressed
on the protocol side (connection new attribute which will apply to DTLS) or
on ICE side (some sort of indication if this is a new end-point or
re-start). Protocol side change seemed to be the less disruptive and more
backwards compatible option in case of DTLS.

The reason DTLS is running into problems with ICE, is due to the fact that
it was not design to run multiple sessions over the same connection and
does not allow setting up a new session unsolicited using transport
messages only, which are properties of RTP for which ICE was originally
designed. Extending DTLS so that it is possible to multiplex several DTLS
sessions over the same connection, and initiate new session setup using
transport level messages, would be a better strategic solution.
Unfortunately this is not going to be backwards compatible and would
further complicate design and implementation.

>From my personal point of view, DTLS in combination with ICE is a design
mess. It would be much cleaner and strategic if instead two separate
protocols this was a single protocol which was responsible
for authentication, encryption negotiation, connection path discovery, path
updates, and communication consent. These are closely related tasks and
ideally they should be handled together instead of one on top of the other.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Apr 2015 08:22:53 +0000

Hi,

>ISTM that this is being considered tactically. Maybe that is the best for now, but perhaps there should be consideration of a strategic approach to this as well.
>
>What I mean is that this seems to be a back handed way to introduce multipath support into protocols (specifically DTLS) that don't support it. Perhaps multipath ought to be officially added to all the protocols that potentially need ICE, and then ICE would simply be one way to populate >the paths.
>
> This will still leave the question of how to determine when the multipath protocol running over ICE communicates with the new end point (i.e. connection needs to be re-established) or when this is a path update and the connection needs to be preserved. For ICE there is no easy way to determine if what >currently is happening is ICE-restart on the existing connection which should allow existing mutlipath protocol session to continue vs setting up ICE to a new end point which would require new connection setup. This problem currently affects DTLS, but I assume this will apply also to other multipath >protocols which require externally initiated connection handshake when running over ICE. This can be addressed on the protocol side (connection new attribute which will apply to DTLS) or on ICE side (some sort of indication if this is a new end-point or re-start). Protocol side change seemed to be the less >disruptive and more backwards compatible option in case of DTLS. 
>
>The reason DTLS is running into problems with ICE, is due to the fact that it was not design to run multiple sessions over the same connection and does not allow setting up a new session unsolicited using transport messages only, which are properties of RTP for which ICE was originally designed. Extending >DTLS so that it is possible to multiplex several DTLS sessions over the same connection, and initiate new session setup using transport level messages, would be a better strategic solution. Unfortunately this is not going to be backwards compatible and would further complicate design and implementation.
>
>From my personal point of view, DTLS in combination with ICE is a design mess. It would be much cleaner and strategic if instead two separate protocols this was a single protocol which was responsible for authentication, encryption negotiation, connection path discovery, path updates, and communication >consent. These are closely related tasks and ideally they should be handled together instead of one on top of the other.

So, what is your suggestion? :)

Regards,

Christer

---

From: Simon Perreault <[email-masked]>
Date: Wed, 15 Apr 2015 09:32:08 -0400

> So, what is your suggestion? :)

I feel Christer's pain. This has been discussed to death. We have
reached the point where it's "text or STFU". I don't care about this
anymore so I'll STFU.

Simon

---

From: Roman Shpount <[email-masked]>
Date: Wed, 15 Apr 2015 14:16:28 -0400

On Wed, Apr 15, 2015 at 9:32 AM, Simon Perreault <[email-masked]>
wrote:

> protocols this was a single protocol which was responsible for
> authentication, encryption negotiation, connection path discovery, path
> updates, and communication >consent. These are closely related tasks and

For the sake of history, Christer suggested using connection:new with DTLS
in offer/answer. Paul asked if this is "strategic" enough. I sent the
response that strategic solution would be to fix DTLS/ICE combo and make it
a single multi-path secure protocol. If needed, I can try to write a draft
for such protocol which combines DTLS and ICE functionality. This is not
the hard part. The hard part is convincing others (primarily browser
vendors) that they should adopt this. So, if anybody is interested in such
new protocol, let me know. Otherwise I would shut up and wait for ICE/DTLS
problems either get resolved or become so bad that the new protocol would
be unavoidable.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Apr 2015 16:18:28 -0400

On 4/15/15 2:16 PM, Roman Shpount wrote:
> On Wed, Apr 15, 2015 at 9:32 AM, Simon Perreault <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> For the sake of history, Christer suggested using connection:new with
> DTLS in offer/answer. Paul asked if this is "strategic" enough. I sent
> the response that strategic solution would be to fix DTLS/ICE combo and
> make it a single multi-path secure protocol. If needed, I can try to
> write a draft for such protocol which combines DTLS and ICE
> functionality. This is not the hard part. The hard part is convincing
> others (primarily browser vendors) that they should adopt this. So, if
> anybody is interested in such new protocol, let me know. Otherwise I
> would shut up and wait for ICE/DTLS problems either get resolved or
> become so bad that the new protocol would be unavoidable.

I didn't intend to propose that the tactical solution not be done.
A strategic one will take longer than people want to wait.

But I did mean to suggest that we ought to start looking at the 
strategic solution - that ICE ought to simply be one way to discover 
multiple paths for a multipath transport, rather than being used in lieu 
of defining multipath versions of those transports.

	Thanks,
	Paul

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 15 Apr 2015 17:32:40 -0400

> A strategic one will take longer than people want to wait.

Agreed.

>
> But I did mean to suggest that we ought to start looking at the strategic
> solution - that ICE ought to simply be one way to discover multiple paths
> for a multipath transport, rather than being used in lieu of defining
> multipath versions of those transports.
>

As far as strategic directions are concerned, ICE has no reason to exist on
its own. It would always needs to be paired with security and this implies
DTLS. DTLS on the other hand, can benefit greatly from ICE functionality so
that it can traverse NAT environments and recover from path failures. If
ICE and DTLS handshakes are unified, then connection setup can be
accelerated. Finally, ICE and DTLS implement a lot of common functionality
in different ways, so there two implementation of mutual party
authentication, keep-alive, role determination, structured data
encapsulation and parsing. Having a single implementation of all of those
would make protocol more reliable and secure.

What I am trying to say is that I do not see future versions of ICE running
without DTLS, so strategically it would be better to extend DTLS to include
ICE functionality and end up with a single consistent secure protocol.

One more thing: DTLS would also need to be extended to work well with
offer/answer and bundle. This would means some sort of ID field, similar to
RTP SSRC in all DTLS packets to allow to multiplex multiple DTLS sessions
over the same transport channel both during setup and normal operations.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Apr 2015 12:57:30 +0000

Hi,
 
>But I did mean to suggest that we ought to start looking at the strategic solution - that ICE ought to simply be one way to discover multiple paths for a multipath transport, rather than being used in lieu of defining multipath versions of those transports.
>
>As far as strategic directions are concerned, ICE has no reason to exist on its own. It would always needs to be paired with security and this implies DTLS. DTLS on the other hand, can benefit greatly from ICE functionality so that it can traverse NAT environments and recover from path failures. If ICE and DTLS >handshakes are unified, then connection setup can be accelerated. Finally, ICE and DTLS implement a lot of common functionality in different ways, so there two implementation of mutual party authentication, keep-alive, role determination, structured data encapsulation and parsing. Having a single >implementation of all of those would make protocol more reliable and secure.
>
>What I am trying to say is that I do not see future versions of ICE running without DTLS, so strategically it would be better to extend DTLS to include ICE functionality and end up with a single consistent secure protocol.

DTLS 1.4 :)

For now, my suggestion is still to use the SDP connection:new attribute. It's a relatively simple thing to do, and it does not require big re-work of the DTLS and ICE. 

Unless I've missed it, I have not seen any input why it would not work.

>One more thing: DTLS would also need to be extended to work well with offer/answer and bundle. This would means some sort of ID field, similar to RTP SSRC in all DTLS packets to allow to multiplex multiple DTLS sessions over the same transport channel both during setup and normal operations.

Not sure I understand. BUNDLE uses a single DTLS session for all media associated with a 5-tuple.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 16 Apr 2015 13:34:10 -0400

On Thu, Apr 16, 2015 at 8:57 AM, Christer Holmberg <
[email-masked]> wrote:

> >What I am trying to say is that I do not see future versions of ICE
> running without DTLS, so strategically it would be better to extend DTLS to
> include ICE functionality and end up with a single consistent secure
> protocol.
>
> DTLS 1.4 :)
>

Or DTLS 2.0. In any case not now, but may be in the future.

> For now, my suggestion is still to use the SDP connection:new attribute.
> It's a relatively simple thing to do, and it does not require big re-work
> of the DTLS and ICE.
>

I agree. I cannot see any reason why "connection:new" should not work for
now. Furthermore, at least for me, it would solve some real implementation
problems.

> associated with a 5-tuple.

BUNDLE was designed around the DTLS limitations so it is using a single
DTLS session. This means, for instance, that you cannot BUNDLE data channel
and BFCP. This is fine for now, but not ideal from long-term, "strategic",
point of view.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Apr 2015 14:13:49 -0400

On 4/16/15 1:34 PM, Roman Shpount wrote:

> DTLS session. This means, for instance, that you cannot BUNDLE data
> channel and BFCP. This is fine for now, but not ideal from long-term,
> "strategic", point of view.

But you could with bfcp over data channel.

	Thanks,
	Paul