Re: [MMUSIC] DTLS-over-SCTP, anyone?

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 11 February 2016 13:06 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 657391B2CA9 for <mmusic@ietfa.amsl.com>; Thu, 11 Feb 2016 05:06:07 -0800 (PST)
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 RXXLyVRbGVsC for <mmusic@ietfa.amsl.com>; Thu, 11 Feb 2016 05:06:04 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09A71B2C7C for <mmusic@ietf.org>; Thu, 11 Feb 2016 05:06:03 -0800 (PST)
X-AuditID: c1b4fb3a-f79ce6d000005138-4b-56bc873942d3
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.C3.20792.9378CB65; Thu, 11 Feb 2016 14:06:01 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.151]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 11 Feb 2016 14:06:01 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] DTLS-over-SCTP, anyone?
Thread-Index: AdFifWfdkaVD/jTcSayjXmDCDAdsrgABI8dAAADlkIAACsv+IAAJBDYAAC5fwgAAF9Un8AARBt4AAALZElD///vhAP//QAqQ//4csMA=
Date: Thu, 11 Feb 2016 13:06:00 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37DD0027@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37DBF1AD@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1ACE19A359C@FR711WXCHMBA03.zeu.alcatel-lucent.com> <CAD5OKxtLn+g5fZtkbKoMqTCb-g25PSpcw5PLjOvWnNUayOn=sw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37DC39DB@ESESSMB209.ericsson.se> <56B94776.3090606@nteczone.com> <CAD5OKxuFX6VV6mEC7QeEwWzh5vQ70ezUSZUV6T-cz7D_CMacLA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37DCAA98@ESESSMB209.ericsson.se> <CAD5OKxsTZyeTg-TSdPAWQO30eX-AddtZt8w0NSVTW0_n9HD5Rg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37DCDC6C@ESESSMB209.ericsson.se> <CAD5OKxtsABVOdUAHqgoXtJCyYQUVJxovyQVD13-5h3A03SGjQA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37DCE497@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DCE497@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.146]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37DD0027ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7ma5l+54wg45bphZTlz9msZhxYSqz A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyuh8mlywaTljRc/xtewNjD8WMXYxcnJICJhI fJh4gxXCFpO4cG89G4gtJHCYUeL/dyCbC8hewijx8u50li5GDg42AQuJ7n/aIDUiAqoSf79P ZgIJMwuoS1xdHAQSFhbQlbjWeoYJokRPYsL+FkYIu0ziwpITYONZgFpfzzsLFucV8JVY3rCf HWLVO1aJH0cmsIHM5BTwk3i9OwCkhhHotO+n1oDNZBYQl7j1ZD4TxMkCEkv2nGeGsEUlXj7+ B/WKksSPDZdYIOrzJf583QC1S1Di5MwnLBMYRWchGTULSdksJGWzwD7TlFi/Sx+iRFFiSvdD dghbQ6J1zlx2ZPEFjOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQIj7eCW31Y7GA8+dzzE KMDBqMTDu6Fjd5gQa2JZcWXuIUYJDmYlEV6rsj1hQrwpiZVVqUX58UWlOanFhxilOViUxHnX OK8PExJITyxJzU5NLUgtgskycXBKNTCWb5x35IrJI5twmRifpaFtxZfFl/VssFB++Fr6YbYx 54KbLD/W7ly/pfQYW5JYpPH3TU9Lw24dPDld49mFmSZrLptZrCq24+s3n1ztv+LQvXXu8/xe Tdi1cUL2DpHj6RdEDu64EfGv/VDkT2WN2ztW1NurTl68IbZ08RPmbduZbjhf/d/25n/cUSWW 4oxEQy3mouJEAOO7oF6wAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/qju7cwevnGmIAGdT5DZ78wJQPqY>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 11 Feb 2016 13:06:07 -0000

Hi Roman,

What about the following new section 3.2:

    “3.2.  Change of Local Transport Parameters

      If an endpoint modifies its local transport parameters (IP address
      and/or port), and if the modification requires a new DTLS
      association, the endpoint MUST either change its DTLS role, its
      fingerprint value and/or use the SDP 'dtls-connection' attribute with
      a 'new' value Section 4.

      If the underlying transport explicitly prohibits a DTLS
      association to span multiple transports, the SDP 'dtls-connection'
      attribute MUST be set to 'new' if the transport is changed.  An
      example of such case is when DTLS is carried over SCTP, as described
      in [RFC6083].”

Regards,

Christer

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 11. helmikuuta 2016 9:09
To: Roman Shpount
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?

Hi Roman,

Your suggestion looks good. I’ll take it as a WGLC comment, and add it in the post-WGLC version of the draft :)

Regards,

Christer

From: Roman Shpount [mailto:roman@telurix.com]
Sent: 10. helmikuuta 2016 22:42
To: Christer Holmberg
Cc: mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: Re: [MMUSIC] DTLS-over-SCTP, anyone?


On Wed, Feb 10, 2016 at 2:58 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
>>> I think we can add the following to section 7.1 of dtls-sdp:
>>>
>>> If DTLS is transmitted over a reliable transport and if DTLS procedures for retransmissions are not used, for instance as described in
>>> RFC 6083 for DTLS over SCTP, then DTLS association MUST NOT span across multiple transports. Using 'dtls-connection' attribute with
>>> an 'existing' value in combination with change of such a reliable transport should be treated as an error and DTLS association MUST be
>>> terminated.
>>
>> Your text as such looks ok. But, do we really want to add it as a generic restriction in draft-dtls-sdp? Shouldn't it be
>> specific for DTLS-over-SCTP instead? What if someone defines DTLS-over-<new-fancy-reliable-transport> and they DO allow span?
>
> The reason multiple DTLS associations cannot span across several SCTP association is due to SCTP association handling DTLS packet
> retransmission and DTLS procedures for retransmissions not being used. We can make a generic statement or limit this to RFC 6083
> only, but I think, stating the reason why DTLS association cannot span multiple transports is important.

I agree.

But, again DTLS-over-SCTP is described in draft-sctp-sdp, so I think such text belongs there.


How about saying the following in draft-dtls-sdp:

If DTLS is transmitted over a transport that prohibits spanning of DTLS association across multiple transports, such as DTLS over SCTP as described in RFC 6083, then 'dtls-connection' attribute MUST be set to 'new' every time transport is changed.

And you can put the previous language in draft-sctp-sdp

This way each draft only specified things relevant to itself.

Regards,
_____________
Roman Shpount