Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

Roman Shpount <roman@telurix.com> Mon, 07 March 2016 17:44 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfc.amsl.com
Delivered-To: mmusic@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 332B81CD651 for <mmusic@ietfc.amsl.com>; Mon, 7 Mar 2016 09:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DQcFpVePhUV for <mmusic@ietfc.amsl.com>; Mon, 7 Mar 2016 09:44:30 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 116F91CD64A for <mmusic@ietf.org>; Mon, 7 Mar 2016 09:44:30 -0800 (PST)
Received: by mail-ig0-x22a.google.com with SMTP id ig19so30270096igb.0 for <mmusic@ietf.org>; Mon, 07 Mar 2016 09:44:30 -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; bh=kZeBqVjcPxUS/zhatAbL3w7Jkxdh8AGq+SRo8RgAHGY=; b=jw3zS/bAT8hFiBrxQ65+XHZU0Mc59A+42KxG+iWq69ahLJ/FGoCy8ZdKaxr2GBSveQ C89cDlKiy3HxQxqV+YAvLnnyZp4k8i3dt+nIKHhSezQsOynUqQPgrv6sNrs6urHmE239 PtjVz8RDVVZ5+khl6kVNHClapvOiEzOjVr2xjmFip1+h3NdXOGFxMOOEVQsRNapMNol/ nId74uSKMd8ywXrBw6InjgxDvuwNgGfnT+Fh1i/7X0/UIfiSpAPTxWCuWKzuJT5fDVig K06/v1j6R9GQsFWlltiKuc5IuMRToQsl2BliwECynZ159joTS/qldo16O2zURCebMAIT zQxw==
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; bh=kZeBqVjcPxUS/zhatAbL3w7Jkxdh8AGq+SRo8RgAHGY=; b=Mz5/JBjAqJBGX9BLPqGlxe3qTJtacpB3k4Bd7V/K2DrMcatqo/0iEYzdSMov+hm9zz ZvWwwBSwJLGhqB+O5O4VJBosH6FRkbZfq73QQvopHwMaEYWk2Txf83U+75rzhnqcg9xQ VR4FRjqlOkx3Phs9TezRIwoauNuEDFWUxdqey60IdtKYHRtyMLUo94v4gFT9LcycFDRl 2ms3cSMmzfpK4fIooT/Ex7ZGcHgybw02ocYjAKblTOfxDm5//seacCchxZKvmbO4H82F 78c2tS9rIXQ9adCTi7sGZz/qX9LLipQgCLp061jM3AIAigPXbahkDLpUSu/CM3pv8sNK P2xQ==
X-Gm-Message-State: AD7BkJLRoo5xI02NaRl7JXt9AV+T9xGIpIkmYG4P+OQASx5ax9Nbpw0u17/lsGq5xNy2RQ==
X-Received: by 10.50.137.35 with SMTP id qf3mr13686024igb.92.1457370770154; Mon, 07 Mar 2016 09:12:50 -0800 (PST)
Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id 94sm926219iok.39.2016.03.07.09.12.48 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 09:12:48 -0800 (PST)
Received: by mail-io0-f181.google.com with SMTP id m184so138614087iof.1 for <mmusic@ietf.org>; Mon, 07 Mar 2016 09:12:48 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.107.30.71 with SMTP id e68mr21082282ioe.145.1457370767854; Mon, 07 Mar 2016 09:12:47 -0800 (PST)
Received: by 10.36.105.77 with HTTP; Mon, 7 Mar 2016 09:12:47 -0800 (PST)
In-Reply-To: <56DDB1D2.6000801@alum.mit.edu>
References: <CABcZeBNJ6jdL7SfLaatfr28X83dVOafpi=jrM6bSJ-qpmj4RuA@mail.gmail.com> <CAD5OKxuK9wBG47d+SwBH_f8-PgMQJuxFRmMg9E4omjgqO0tNbQ@mail.gmail.com> <56D8D2E1.2030306@alum.mit.edu> <CAOJ7v-2eWFFzK_rtSkT5Q12qv5Cdug_Do1z=cAWvfJsKi0U94Q@mail.gmail.com> <56DCB31A.1010502@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E818F9@ESESSMB209.ericsson.se> <56DDA6B2.5080403@alum.mit.edu> <CAD5OKxts-yfXS2nxTfoqMiDO2GLWu4AF6WJdvsE_tFtewmmmCg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E8B57C@ESESSMB209.ericsson.se> <56DDB1D2.6000801@alum.mit.edu>
Date: Mon, 07 Mar 2016 12:12:47 -0500
X-Gmail-Original-Message-ID: <CAD5OKxuXiPGDZtNQvfhQGD0NdmDoCZ6hAgqQnih8-_p7GD56fQ@mail.gmail.com>
Message-ID: <CAD5OKxuXiPGDZtNQvfhQGD0NdmDoCZ6hAgqQnih8-_p7GD56fQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="001a1140d71eecbd58052d789266"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/RSE0qM5h0yXQYD_zxePc7cgGjGI>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 07 Mar 2016 17:44:31 -0000

On Mon, Mar 7, 2016 at 11:52 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 3/7/16 11:26 AM, Christer Holmberg wrote:
>
>> I suggest dtls-association-id. In my opinion there is no longer the same
>> need to be aligned with the name of the connection attribute.
>>
>
> This seems plausible. But I want to reserve judgement until the detailed
> semantics of the attribute are worked out:
>

I wanted to model this attribute on ICE ufrag

- is it numeric, or a token?
>

I was thinking something like this:
dtls-association-id-attr = "dtls-association-id" ":" dtls-association-id

dtls-association-id = 4*256dtls-association-id-char

dtls-association-id-char = ALPHA / DIGIT / "+" / "/"



> - any rules for how the value chosen?
>

The dtls-association-id attributes MUST be chosen randomly when new DTLS
association is requested.  The dtls-association-id attribute MUST contain
at least 24 bits of randomness.  This means that the dtls-association-id
attribute will be at least 4 characters long since the grammar for this
attribute allows for 6 bits of randomness per character.  The attribute MAY
be longer than 4 characters, respectively, of course, up to
256 characters.  The upper limit allows for buffer sizing
in implementations.  Its large upper limit allows for increased amounts of
randomness to be added over time.

- is it tied to an actual property of the association,
>    or is it just an arbitrary extra piece of state?
>

It is not tied to the association and it is an arbitrary piece of state.
DTLS protocol can be extended in the future to use dtls-association-id to
demux multiple DTLS associations over the same transport but this is out of
scope for now.


> - any rules for how the *next* value is chosen when
>    a new (replacement) association is being proposed?
>

New values is generated randomly.


> - when (if ever) can an id be reused?
>

The dtls-association-id should be reused while end point want to maintain
the same DTLS association. If either end point changes the
dtls-association-id value, this will indicate that new DTLS association
MUST be established.


> It is *possible* (though not likely) that the details may suggest a
> particular name that is more meaningful than "id".
>

Regards,
_____________
Roman Shpount