Re: [MMUSIC] 10 BUNDLE questions

Martin Thomson <martin.thomson@gmail.com> Mon, 22 April 2013 15:55 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1021F9075 for <mmusic@ietfa.amsl.com>; Mon, 22 Apr 2013 08:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPBRJj9Uv-oD for <mmusic@ietfa.amsl.com>; Mon, 22 Apr 2013 08:55:19 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ECB5621F9318 for <mmusic@ietf.org>; Mon, 22 Apr 2013 08:55:12 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hm14so1491299wib.11 for <mmusic@ietf.org>; Mon, 22 Apr 2013 08:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=yUuDb+AnrqL53jq9h3WtvX+zMaFKtLYCAGlrkKAwPns=; b=BWK8E2C/hKo4svNSYesinehXkhFIWKUJpwAotFfYe3v7n5UKq/WMLA0i27ABEpmUAJ CoDKkLPIhgfpopaz9q5oeJngJ5FJku1yejdsAI0MDOTFohIY+TxU3VQ0IG3rAIz3rKBJ t1TpLaxeGB6/3j7c8CFynrAFFRpMH6g1xOavq019NvmkyfefZa/EiWVCTUzm3BSlbDmY FH1iPqqXjpdNNquxNsQQzH5O8TTYuQmBoY5JaC0u3iBH5iYwoQIeM1nruj43+4bJ2AsS rkhaW0fYYQt4dNltv5Fj5zsb7bGf1ryKkmtGFf4mU1WSICPinaExsBnD4slNkpV/DkqG G5pg==
MIME-Version: 1.0
X-Received: by 10.194.235.196 with SMTP id uo4mr53675704wjc.30.1366646111858; Mon, 22 Apr 2013 08:55:11 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Mon, 22 Apr 2013 08:55:11 -0700 (PDT)
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB113494A47@xmb-aln-x02.cisco.com>
References: <CAOJ7v-0tr6_HAPwOnLD_De-LkNCsj1EfLhZL=G_B=k5tz9Hkwg@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB11348F0AF@xmb-aln-x02.cisco.com> <CABkgnnU1XW4vgC3rW-2DB15yMgc4GkhwQvYOuxmvBE4+9k0pDA@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB113494A47@xmb-aln-x02.cisco.com>
Date: Mon, 22 Apr 2013 08:55:11 -0700
Message-ID: <CABkgnnVpD_QVpY74F4VcFkhZmX1C3NPjyxhUPxkzUqPTYg1NrA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 10 BUNDLE questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 22 Apr 2013 15:55:20 -0000

On 22 April 2013 08:25, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>> In theory you can use multiple keys.  And it doesn't have any real
>> consequences.  That's not necessarily a useful property though.
>
> I just want to make sure there is not chance for a two time pad problem but I assume that will not be a problem and we can use the same sdes key when bundle does not get negotiated

The two time pad problem only arises if you have the same SSRC.
That's only possible with a shim, not if you have streams sharing the
same session.

There is a problem with SSRC collisions (in SSRC space only, even if
the collision isn't contemporaneous).  SRTP has always had that
problem and it's rare enough that no attacker could rely on it
happening.

> I think I am leaning towards once a bundle is set up, a new update to it can offer things in the bundle or not it the bundle. And if offered in the bundle, the answer can choose to put it in the bundle or not. But I want to avoid all things like the answer can move a m-line from one one bundle to another bundle or something like that. It's too complicated and I don't see the need for it.

That was my thought too.  That means that bundling is negotiated in
two ways: one to turn bundling on or off as a whole.  The second is
the choice to add a new stream - or allow a new stream to be added -
to a bundle, or not.  Once negotiated, you can't move them around.  If
you need that, drop the line and make another one.  That's not
especially difficult.