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

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Mar 2015 09:52:59 +0000

Hi,

Below is some suggested text (the new text is in bold) to cover ICE "virtual connections" in the SCTP-SDP draft:

9.3.3.  TLS Role Determination

   If the m- line proto value is 'SCTP/DTLS', 'UDP/DTLS/SCTP' or
   'TCP/DTLS/SCTP', the 'active/passive' status is used to determine the
   (D)TLS roles of the endpoints.  Following the procedures in
   [RFC4572], the 'active' endpoint will take the (D)TLS client role.

   Once the DTLS connection has been established, the endpoints MUST NOT
   modify (as result of an offer/answer exchange) the TLS roles, or the
   'active/passive' status, of the endpoints, unless the underlying
   transport protocol is also modified (e.g. if an IP address- or port
   value associated with the transport protocol is modified).

   If the underlying transport protocol is modified, the endpoints MUST
   establish a new DTLS connection.  In such case the 'active/passive'
   status of the endpoints will again be determined following the
   procedures in [RFC4145], and the new status will be used to determine
   the (D)TLS roles of the endpoints associated with the new DTLS
   connection.

   NOTE: The procedure above is identical to the one defined for SRTP-
   DTLS in [RFC5763].

   NOTE: As described in [add-reference], if the Interactive
   Connectivity Establishment (ICE) mechanism [RFC5245] is used, all ICE
   candidates associated with an SCTP association on top of a DTLS
   connection as part of the same DTLS connection.  Thus, a switch from
   one candidate pair to another candidate pair will not trigger the
   establishment of a new DTLS connection.

12.2.  ICE Considerations

   At the time of writing this specification, no procedures have been

   defined for using ICE [RFC5245] together with SCTP as transport layer

   protocol.  Such procedures, including the associated SDP Offer/Answer

   procedures, are outside the scope of this specification, and might be

   defined in a future specification.

   When the transport layer protocol is UDP (in case of an SCTP

   association on top of a DTLS connection on top of UDP), if ICE is

   used, the ICE procedures defined in [RFC5245] are used.

   When the transport layer protocol is TCP (in case of an SCTP

   association on top of a DTLS connection on top of TCP), if ICE is

   used, the ICE procedures defined in [RFC6544] are used.

   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.  Thus, there will only be one DTLS handshake even if

   there are multiple valid candidate pairs, and shifting from one

   candidate pair to another will not impact the DTLS connection.  If

   new candidates are added, they will also be part of the same DTLS

   connection.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 28 Mar 2015 10:41:47 -0400

On 3/28/15 5:52 AM, Christer Holmberg wrote:

> *   NOTE: As described in [add-reference], if the Interactive*
> *   Connectivity Establishment (ICE) mechanism [RFC5245] is used,

> *   all ICE*
> *   candidates associated with an SCTP association on top of a DTLS*
> *   connection as part of the same DTLS connection.

I can't parse the above. Did you mean "*are* part of the same ..."?

> *   Thus, a switch from*
> *   one candidate pair to another candidate pair will not trigger the*
> *   establishment of a new DTLS connection.*

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Mar 2015 16:12:50 +0000

Hi,

Yes, I meant "are".

Thanks!

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎28/‎03/‎2015 16:41
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

        Thanks,
        Paul

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 30 Mar 2015 08:25:22 -0400

Wordsmithing: the more precise term would be "valid ICE candidate pair".
See inline...

Le 2015-03-28 05:52, Christer Holmberg a écrit :
> Hi,
> 
>  
> 
> Below is some suggested text (the new text is in bold) to cover ICE
> “virtual connections” in the SCTP-SDP draft:
> 
>  
> 
> *   Connectivity Establishment (ICE) mechanism [RFC5245] is used, all ICE*
> 

s/ICE candidates/valid ICE candidate pairs/

> 
> *   connection as part of the same DTLS connection.  Thus, a switch from*
> 
> *   Implementations MUST treat all ICE candidate pairs associated with a*

s/ICE candidate pairs/valid ICE candidate pairs/

> 
> *   an SCTP association on top of a DTLS connection as part of the same*
> 
> *   DTLS connection.  Thus, there will only be one DTLS handshake even if*
> 
> *   there are multiple valid candidate pairs, and shifting from one*
> 
> *   candidate pair to another will not impact the DTLS connection.  If*
> 
> *   new candidates are added, they will also be part of the same DTLS*

"If new candidate pairs are added to the valid list, ..."

> *   connection.*

Simon

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Mar 2015 13:10:37 +0000

Hi,

>> "virtual connections" in the SCTP-SDP draft:  
>> 
>>    'TCP/DTLS/SCTP', the 'active/passive' status is used to determine 
>>    the (D)TLS roles of the endpoints.  Following the procedures in
>>   Once the DTLS connection has been established, the endpoints MUST 
>>   NOT  modify (as result of an offer/answer exchange) the TLS roles, or 
>>   the 'active/passive' status, of the endpoints, unless the underlying
>>    If the underlying transport protocol is modified, the endpoints 
>>    MUST establish a new DTLS connection.  In such case the 'active/passive'
>>    procedures in [RFC4145], and the new status will be used to 
>>    determine the (D)TLS roles of the endpoints associated with the new DTLS
>>    connection.
>> 

I'll fix that.

Thanks!

Regards,

Christer

Simon

---

From: Roman Shpount <[email-masked]>
Date: Mon, 30 Mar 2015 10:21:18 -0400

>    value associated with the transport protocol is modified).
In case of ICE, how do you define modification of the underlying transport
protocol? IP address and port can obviously change to IP and port of
another candidate pair.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Mar 2015 16:46:36 +0000

Hi Roman,

The new note is intended to cover ICE.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:[email-masked]>
Sent: ‎30/‎03/‎2015 17:21
To: Christer Holmberg<mailto:[email-masked]>
Cc: mmusic<mailto:[email-masked]>
Subject: Re: [MMUSIC] SCTP-SDP: Virtual Connection impact

On Sat, Mar 28, 2015 at 5:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

In case of ICE, how do you define modification of the underlying transport protocol? IP address and port can obviously change to IP and port of another candidate pair.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 30 Mar 2015 13:19:26 -0400

Christer,

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

I believe more precise definition of behavior and additional text
clarification is needed here.
_____________
Roman Shpount

On Mon, Mar 30, 2015 at 12:46 PM, Christer Holmberg <
[email-masked]> wrote:

>  ------------------------------
> From: Roman Shpount <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: mmusic <[email-masked]>
>  In case of ICE, how do you define modification of the underlying
> transport protocol? IP address and port can obviously change to IP and port
> of another candidate pair.
>  _____________
> Roman Shpount
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 31 Mar 2015 17:00:38 +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.

Regards,

Christer

I believe more precise definition of behavior and additional text clarification is needed here.
_____________
Roman Shpount

On Mon, Mar 30, 2015 at 12:46 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 31 Mar 2015 13:36:05 -0400

On Tue, Mar 31, 2015 at 1:00 PM, Christer Holmberg <
[email-masked]> wrote:

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