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

Roman Shpount <roman@telurix.com> Wed, 10 February 2016 19:35 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 D739A1B2F07 for <mmusic@ietfa.amsl.com>; Wed, 10 Feb 2016 11:35:00 -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 mOZoT6YGWKi5 for <mmusic@ietfa.amsl.com>; Wed, 10 Feb 2016 11:34:59 -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 85CBC1B2F05 for <mmusic@ietf.org>; Wed, 10 Feb 2016 11:34:59 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id g203so6986654iof.2 for <mmusic@ietf.org>; Wed, 10 Feb 2016 11:34:59 -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=VCKNLPGk0WBnWBnrZCq/Z505OjB7kBoccw9Ba2KQs88=; b=CjZdbEQ8WzAYTy6EO2yMgEdk6qfNyKLJSLIMW4IvDJXQswaAvNTaz+IWhJ50P/sUFU IGuLjjNeFz1SL7gIQv/Yn/3QC2Wb+IVXb/59JiDvEFLPrzuC+mGAO43AsqxfsxMYm6Ke 5qJJFpcoj/dHKVkmgxVggRpj32vihGBGZ/0K5qw5vQCrx13lAw73mcgDmtNnajbsieM8 FyCQkkAtHTuAZSJQfDTaG9akK+KRZJZ/38fL39ftfcR0GVvAoQptZIaW8os09H2LVAaw ADQVWx8LVPwFeiBQiZOiQU7yzWWi/yt/qWyIVuYI0m+OO9q5BtU8LGsaa8VcLfJRMFI+ faPg==
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=VCKNLPGk0WBnWBnrZCq/Z505OjB7kBoccw9Ba2KQs88=; b=Cmghu2fbGizadp95K/E8eREpqrROXBJ/U9MER+HqOyJm+sdlKrT7JNAH5owmnRHP69 JUAT5dxHcVwNYLVLyiQMVzCUE3I5UEeq4AuhZmN9ByBhknVc/U0NQuZkGdXp47Rc14JR /yBwvpUo2wKGgQ1ZX1ZsDp/TBF0XNCSbqvBcY/w98mxYC7evvl2OlVi8cpXaf6hne9Ch XBzBUsQGc8QgA2F9F49ZHCxvFJP6tR7fMXUuv+NYbk2fmanUX8cbqmgjGfNLCiguq7HM UOUK5vE6zXGy2gO53y2ZRncvUJkWAYiqiJcjMtUPp9VSt95upGpFK7cCoPRs2rackm3t JkaQ==
X-Gm-Message-State: AG10YOR/Uz1hebaoELUy+gxhj9aiRwvoGCce/YLtngT61TB2gSOk00b3EMEsqbu6QrENiQ==
X-Received: by 10.107.128.75 with SMTP id b72mr37114014iod.87.1455132898872; Wed, 10 Feb 2016 11:34:58 -0800 (PST)
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id 186sm2392743iof.22.2016.02.10.11.34.57 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 11:34:57 -0800 (PST)
Received: by mail-io0-f172.google.com with SMTP id 9so32498952iom.1 for <mmusic@ietf.org>; Wed, 10 Feb 2016 11:34:57 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.157.70 with SMTP id g67mr37215925ioe.38.1455132896703; Wed, 10 Feb 2016 11:34:56 -0800 (PST)
Received: by 10.36.105.77 with HTTP; Wed, 10 Feb 2016 11:34:56 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DCAA98@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>
Date: Wed, 10 Feb 2016 14:34:56 -0500
X-Gmail-Original-Message-ID: <CAD5OKxsTZyeTg-TSdPAWQO30eX-AddtZt8w0NSVTW0_n9HD5Rg@mail.gmail.com>
Message-ID: <CAD5OKxsTZyeTg-TSdPAWQO30eX-AddtZt8w0NSVTW0_n9HD5Rg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1140b47268e6ce052b6f875a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/tYxo5Sa8vj4rw027PPWkDuwVXVo>
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 19:35:01 -0000

Hi Christer,

On Wed, Feb 10, 2016 at 5:29 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

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