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

Roman Shpount <roman@telurix.com> Wed, 10 February 2016 00:05 UTC

Return-Path: <roman@telurix.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 506631B3216 for <mmusic@ietfa.amsl.com>; Tue, 9 Feb 2016 16:05:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 99I18CNcxyI0 for <mmusic@ietfa.amsl.com>; Tue, 9 Feb 2016 16:05:04 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD461B321D for <mmusic@ietf.org>; Tue, 9 Feb 2016 16:05:03 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id f81so5109115iof.0 for <mmusic@ietf.org>; Tue, 09 Feb 2016 16:05:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=crblmUbYPiBZ0NPiajVGU+QUSzZIfJ8EApg2LyN2ONk=; b=TXOzcyWS3i/Nhe0zBB+1zbZUFBA2dklaSW7Q4/Uv2Er1APdtF0byGaBq2spIjDQVX0 Hrl8yjNuYN69bzqbmCE3jBaTz8tx/Q6lms0jcqfbeKHcROXCHjyueMkUlTRm2EB7bsdO xc0OFJeVVfph7VA6XpHwqHHjJ/4X8c6VwH4n7IZPQcfnAYvmcwgzncTKLvKhi8/iARq7 64UI7lAqBp1IjfGspNovWpenyl5v9bqAID+U71gImiE/VOMG1FnVisB+B6tKtfSoow+T p/ElutzkD8cqpqcwiSskIw8XkpaMiD/owBX/NjkyrmtAGMw0mDuFw5O6okZDsT9DWswg oENw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=crblmUbYPiBZ0NPiajVGU+QUSzZIfJ8EApg2LyN2ONk=; b=XvwaqjmXLng4PnZGgPZX+UIBul8zhv1kiGpoFQnFACoP98HKjwVpqhpuwZ3bc81Z9D zH2mJCKcaPjlBvHK5Mwk+IjQyFXyXCoSszAfWkFtIXTCwY+DHsLLGsEvPkXkpbpZHsVb s8XNFowe2HT+CknJBkttEcC54J34l84WpnTVKI0gBc+orH6JShEitnUdb1/BvxhWz3T1 679lytxB4wuilgOao2DisBIiXEpqR3waJL1xvX/LSEkiwil2J/g5GIKmCSqmzIUB4E1/ 0vvAIMDZH6VooVX/UU1gwgJm+fFJfbsiqKYXU9iF0Wrf05i0YvrtYd88p5oOTyJwkgkf SwMA==
X-Gm-Message-State: AG10YORMPUVT9efj1gbdbYqCgDVKMl3xbDrIGE6FhH09pngP38HdM8AWQRjxYwFINjDGug==
X-Received: by 10.107.132.12 with SMTP id g12mr15666596iod.145.1455062702308; Tue, 09 Feb 2016 16:05:02 -0800 (PST)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id n3sm547632iga.9.2016.02.09.16.05.01 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Feb 2016 16:05:01 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id 5so3441983igt.0 for <mmusic@ietf.org>; Tue, 09 Feb 2016 16:05:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.33.51 with SMTP id o19mr7218110igi.2.1455062700703; Tue, 09 Feb 2016 16:05:00 -0800 (PST)
Received: by 10.36.105.77 with HTTP; Tue, 9 Feb 2016 16:05:00 -0800 (PST)
In-Reply-To: <56B94776.3090606@nteczone.com>
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>
Date: Tue, 09 Feb 2016 19:05:00 -0500
X-Gmail-Original-Message-ID: <CAD5OKxuFX6VV6mEC7QeEwWzh5vQ70ezUSZUV6T-cz7D_CMacLA@mail.gmail.com>
Message-ID: <CAD5OKxuFX6VV6mEC7QeEwWzh5vQ70ezUSZUV6T-cz7D_CMacLA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="089e0158b06666d0ce052b5f2f9d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/iDmeIan1-w91I1_jr9G5TQDazFQ>
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: Wed, 10 Feb 2016 00:05:06 -0000

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.

_____________
Roman Shpount

On Mon, Feb 8, 2016 at 8:57 PM, Christian Groves <
Christian.Groves@nteczone.com> wrote:

> Hello
>
> I think the fact that the draft doesn't support DTLS-over-SCTP has been
> known for some time. No one has been pushing for its inclusion. I'd be
> happy if it was left out to be able to progress the draft.
>
> Alternatively we can do what I think Albrecht is suggesting. Reserve proto
> values for DTLS/SCTP/IP and SCTP/UDP/IP in the draft and indicate their use
> by SDP should be defined in a future specification. I don't think its worth
> solving that problem now.
>
> Regards, Christian
>
> On 9/02/2016 7:45 AM, Christer Holmberg wrote:
>
>>
>> Hi,
>>
>> > The problem with DTLS-over-SCTP (RFC 6083) is that it is not fully
>> compatible with draft-ietf-mmusic-dtls-sdp.
>>
>> > In particular, RFC 6083 does not allow DTLS association span across
>> multiple SCTP associations, but
>>
>> > draft-ietf-mmusic-dtls-sdp allows to preserve DTLS association through
>> a transport change. The most likely
>>
>> > solution to this is updating RFC 6083, but, if no one is using
>> DTLS-over-SCTP, it would be easier just to say
>>
>> > that DTLS-over-SCTP is not supported.
>>
>> **If** we decide to keep DTLS-over-SCTP in the draft, my suggestion would
>> be to say that “DTLS preservation over transport change” does not apply to
>> DTLS-over-SCTP, with a reference to RFC 6083.
>>
>> Then, if someone at some point updates RFC 6083, the SCTP-SDP spec also
>> has to be updated.
>>
>> I do NOT want to delay draft-sctp-sdp until a possible RFC 6083 update
>> has been done (assuming people would agree to do it in the first place).
>>
>> Regards,
>>
>> Christer
>>
>> _____________
>> Roman Shpount
>>
>> On Mon, Feb 8, 2016 at 10:12 AM, Schwarz, Albrecht (Nokia - DE) <
>> albrecht.schwarz@nokia.com <mailto:albrecht.schwarz@nokia.com>> wrote:
>>
>>     Hello Christer,
>>
>>     the titel of the (future) RFC will not exclude any SCTP transport
>>     modes.
>>
>>     And a comprehensive and future safe protocol specification should
>>     cover all existing ones, which is “DTLS/SCTP/IP” as well as
>>     “SCTP/UDP/IP” (RFC 6951).
>>
>>     These two SCTP transport modes should be indicated as well,
>>     independent of potential intentions to be used soon.
>>
>>     Codepoint space could be reserved, placeholder sections tagged as
>>     “not yet supported” of “for further studies”, etc, but the worst
>>     case would be any kind of interaction issues in future.
>>
>>     My view,
>>
>>     Albrecht
>>
>>     *From:*mmusic [mailto:mmusic-bounces@ietf.org
>>     <mailto:mmusic-bounces@ietf.org>] *On Behalf Of *EXT Christer
>> Holmberg
>>     *Sent:* Montag, 8. Februar 2016 15:33
>>     *To:* mmusic <mmusic@ietf.org <mailto:mmusic@ietf.org>>
>>     *Subject:* [MMUSIC] DTLS-over-SCTP, anyone?
>>
>>     Hi,
>>
>>     draft-ietf-mmusic-sctp-sdp currently defines the SDP O/A
>>     procedures for SCTP, SCTP-over-DTLS, and DTLS-over-SCTP.
>>
>>     As we know, SCTP-over-DTLS is used for the WebRTC data channel.
>>
>>     My question is: does anyone intend to use DTLS-over-SCTP?
>>
>>     Regards,
>>
>>     Christer
>>
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>