[MMUSIC] SCTP-SDP: Virtual Connection impact

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 28 March 2015 09:53 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508B41A700C for <mmusic@ietfa.amsl.com>; Sat, 28 Mar 2015 02:53:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru20W1yuPNHk for <mmusic@ietfa.amsl.com>; Sat, 28 Mar 2015 02:53:04 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4808B1A700A for <mmusic@ietf.org>; Sat, 28 Mar 2015 02:53:03 -0700 (PDT)
X-AuditID: c1b4fb30-f79996d000006ebb-54-551679fc0c0d
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 74.4E.28347.CF976155; Sat, 28 Mar 2015 10:53:01 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Sat, 28 Mar 2015 10:53:00 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: mmusic <mmusic@ietf.org>
Thread-Topic: SCTP-SDP: Virtual Connection impact
Thread-Index: AdBpPCnIe5AWsLgZRGGMCVgZi9S4ag==
Date: Sat, 28 Mar 2015 09:52:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D78274F@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D78274FESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje7fSrFQg2m/eC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujItHTrMUbMmvaFh9n7GB8XhiFyMnh4SAicS0tXNZIWwxiQv3 1rN1MXJxCAkcYZTYfGY1C4SzhFHicN9Wxi5GDg42AQuJ7n/aIA0iAjISezdtZgaxhQV0JI51 HWCBiBtKTGl5yAhh60m8ev0JLM4ioCrx+coiNhCbV8BX4vrNLUwgNiPQ4u+n1oDZzALiEree zGeCOEhAYsme88wQtqjEy8f/oA5Vklh7eDsLRH2+xNvfN9ghZgpKnJz5hGUCo9AsJKNmISmb haQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st 2cQIjImDW34b7GB8+dzxEKMAB6MSD++G4yKhQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeWpGan phakFsUXleakFh9iZOLglGpgXJi4viXzbspczbTm9TPqrM1XqF//57G0pfTqtf3Nl3um20xL LH3N+/j7w0cOe+2rbt0N+bu96ofhSZY//+bP58ya6n4lOHSFydGjFolZC65J7XtWvHd14tqH J5XsOApKHoQql51dc7jUS3DKjfbNCecmh/2beqf2UGrnFiX5sysy//LFv9onF67EUpyRaKjF XFScCABfqUL+agIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/yDmOTwLaZWn--U6JIcz7__FJW5c>
Subject: [MMUSIC] SCTP-SDP: Virtual Connection impact
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Mar 2015 09:53:07 -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