Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

Roman Shpount <roman@telurix.com> Sun, 31 May 2015 00:09 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 3F6671B2A61 for <mmusic@ietfa.amsl.com>; Sat, 30 May 2015 17:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 RzJ3fVxNXH40 for <mmusic@ietfa.amsl.com>; Sat, 30 May 2015 17:09:49 -0700 (PDT)
Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) (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 9B51C1B2A5A for <mmusic@ietf.org>; Sat, 30 May 2015 17:09:49 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so38661250igb.0 for <mmusic@ietf.org>; Sat, 30 May 2015 17:09:49 -0700 (PDT)
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=3TBn4G2UxKgQ3Wi2Ub1OPXKzNTXcH9nFKWw9/QkoIjg=; b=MGyJuy4eLWf95Auo7YK/+3AyhKaH8009M7QNn0QL7jE9miiIKSQqO/SQk3lnF8cSZR 3yg5H5tS5iZACIoItb8VtrI+I//ygMECCU2EGcNiRXFvsc26qFyJKEvYL/m8kGN7H8Kx D3CDkMlG2UGErjWrWJVbZx51E9bKecDHxv7NPunyeswjk3izKVCpM+Nxx20A6Olty68l ZCkl8mH1WDvKlFp+UtQYVAVJEc8zqF4rNmSYb1zWGS9eGuBdDg6NW8Vuvpf2BnP2xUgu 8mvMSlokD8jp4OMkYrfQN2Fhm1dl9QwONDF/aAdxQRavGcdeiGN8SCMYOwD8+vVGhdyN Fo3w==
X-Gm-Message-State: ALoCoQlNRLnF5b0+EDfW64PGJuw+Xhq/Bo++CkteMGGEyOedZzxeWBI2+LOargFaaM+GmGrWF6Ej
X-Received: by 10.107.136.38 with SMTP id k38mr18367340iod.56.1433030988965; Sat, 30 May 2015 17:09:48 -0700 (PDT)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by mx.google.com with ESMTPSA id o15sm4667627igw.11.2015.05.30.17.09.46 for <mmusic@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2015 17:09:47 -0700 (PDT)
Received: by igbjd9 with SMTP id jd9so38673861igb.1 for <mmusic@ietf.org>; Sat, 30 May 2015 17:09:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.32.73 with SMTP id sj9mr1722642icb.96.1433030986171; Sat, 30 May 2015 17:09:46 -0700 (PDT)
Received: by 10.36.89.70 with HTTP; Sat, 30 May 2015 17:09:46 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D86E94F@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D852384@ESESSMB209.ericsson.se> <55634C34.4080304@alum.mit.edu> <5565838D.2020005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D866141@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E7D3EEB@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAD5OKxuEpmMVfScf62bs=y+9PyYbejfa2OmsHYq=dStTZmjdVg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D8689E9@ESESSMB209.ericsson.se> <55665BFA.4020600@nteczone.com> <CAD5OKxsukfKG=bW-5QWu35AQQX_Eve8YM0cQ=xc=B=obnzKQdQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D86C915@ESESSMB209.ericsson.se> <547EE95EB794FD4DB8062F7A4C86D0BC4A36371A@FR712WXCHMBA13.zeu.alcatel-lucent.com> <CAD5OKxsu=uYqpFQ2Rko9gViCxRdiOudF6wbd618jy6CEFnjV_w@mail.gmail.com> <CAD5OKxu2TzURek3TqdjCq=EU4C4NoYKidFJM6wgqptUpz52GJQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D86E94F@ESESSMB209.ericsson.se>
Date: Sat, 30 May 2015 20:09:46 -0400
Message-ID: <CAD5OKxvHZzHwvhmvV_LdP8WG072NYqYRucGJ=6t4kex5p8KqCA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=bcaec51a8be2e20c0d0517558620
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/t1VIVHggHx4iNcdHOhUQFgxIRqo>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
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: <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: Sun, 31 May 2015 00:09:51 -0000

On Fri, May 29, 2015 at 1:24 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>
> >I would suggest "use_srtp" extension must always be enabled for DTLS
> session used in bundle.
>
> Assuming SRTP is supported, I assume. If a node doesn't support SRTP to
> begin with, or if an application is never going to offer (or accept if
> offered) SRTP, I guess there is no reason to mandate "use_srtp".
>
> Now, there are statements in RFC 5764 saying e.g.:
>
>         "This extension MUST only be used when the data being transported
> is RTP or RTCP [RFC3550]."
>
> That of course makes sense for a non-BUNDLE DTLS connection, but I wonder
> whether we somehow explicitly need to say that it doesn't apply for BUNDLE?
>
>
Another big question how would current browser implementations handle a
DTLS connection without "use_srtp" extension. I have a strong suspicion
that DTLS session setup will fail without this extension present. I think,
WebRTC enabled browsers currently export SRTP key material during session
setup even if no SRTP traffic is ever sent or received by this connection
and fail the entire connection if key export fails. This, most likely, can
be modified to only export SRTP key material when SRTP session is actually
created and defining some sort of fall back procedure when a media track is
actually added to a connection without "use_srtp" (either failure or
require renegotiation with new transport).

To conclude, the group can either decide that all DTLS sessions in bundle
should be setup with "use_srtp" extension and keep the current
implementations working as they are currently coded, or allow not to
include this extension and fix the implementations.
_____________
Roman Shpount