Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99

Stephen Botzko <stephen.botzko@gmail.com> Mon, 07 August 2017 14:07 UTC

Return-Path: <stephen.botzko@gmail.com>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B017D132332 for <perc@ietfa.amsl.com>; Mon, 7 Aug 2017 07:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qKhr-Qvn0GOA for <perc@ietfa.amsl.com>; Mon, 7 Aug 2017 07:07:25 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 E4695132337 for <perc@ietf.org>; Mon, 7 Aug 2017 07:07:13 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id d71so5007094oih.0 for <perc@ietf.org>; Mon, 07 Aug 2017 07:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WMYq55wdYXCGUVqBAm3tBPuXRsDxWTLAwknOkMnqQzg=; b=n6yiWo5GH5uRPcS55Fl6L5g74ZDpMuoBrwTpgSRLVL6XXfbjEvDpLMJqWrvTKJvMj8 k6dGfMircEyIlIb7WO8BoSDD1hDziRk4GjtuLWBXmHH6ac8ROFpus3fCKXD0Q5ymSZaw tsjq5ACcyj14Bwx6fbBguxiBU8BD+BcZ4Si6nUND4eRLP1blO7OuZvsG7OMqb4jJhgVu t6IupiPUCbZA9r/nd8mu2EwT6zA3wXsPy2rpU9Y2c0qtyptc8tZilCZvDbmBwJYfwzNX eN20sNWloNJk/mlM+ZSDObyWEGUIXp6tzC7A7b8Of/EwHr0bQQYZs3eOmD0bqSHzKyVr 4Zxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WMYq55wdYXCGUVqBAm3tBPuXRsDxWTLAwknOkMnqQzg=; b=EOlC40OhLe82oLayzsd22QlIaxAP7L7laoo6D3pKgWDIlLUUcrmT+WMZqI46G48Fd4 z9SgNofLSUIDXjjNDXDODasUFPHL6sB7c0UuvHgsUtN9xdfH8vOURvbulia3eKwzDnMR L++Q/u+M4MCW3MkJVSywjCPau7GCcVMzG4M0AVDEBTbuBoCr7ui3uBQB2GYkoX1TX6/W tNQ1teChWLHIpF0IFdLJTOYXzj/tJzkeNeWJ9oCo3pkq9uPhAjbjxgWDTzTrY7khrFNI j3a+4BmJwG6BXSGNaaJF506wyE2IDBmePScRddGCScmZ6gM9GqJaGbgOrM70tfPVtwNq QU7w==
X-Gm-Message-State: AHYfb5iIdHZUKZYKIPYvwykNvBtohyNIFaa6cLNS3lL7gAtjDud3EOgA hSgGSDLcUfkDuvtxJT0wxTEZZrZukA==
X-Received: by 10.202.75.18 with SMTP id y18mr471392oia.68.1502114833138; Mon, 07 Aug 2017 07:07:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.108.2 with HTTP; Mon, 7 Aug 2017 07:07:12 -0700 (PDT)
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD7F1A99@DGGEMM506-MBX.china.huawei.com>
References: <CAMRcRGRW4JkyTSfUeDVWrXGAt0_x-yWhAzdKXDjkUJ0XH-P7cA@mail.gmail.com> <CAMRcRGSdPa6WDFDxCe=HxEsWA2fmb1_fEPBcybbgTsCRSGrdzQ@mail.gmail.com> <6E58094ECC8D8344914996DAD28F1CCD7F1970@DGGEMM506-MBX.china.huawei.com> <522888F9-8AC8-47CF-BA0F-A820ABEB9EC1@packetizer.com> <6E58094ECC8D8344914996DAD28F1CCD7F1A99@DGGEMM506-MBX.china.huawei.com>
From: Stephen Botzko <stephen.botzko@gmail.com>
Date: Mon, 07 Aug 2017 10:07:12 -0400
Message-ID: <CAMC7SJ4DNuxTeg6eUG8Oes6vXLdhkM+o2G-GucwuMnco+i6wdg@mail.gmail.com>
To: Roni Even <roni.even@huawei.com>
Cc: "Paul E. Jones" <paulej@packetizer.com>, "perc@ietf.org" <perc@ietf.org>, Suhas Nandakumar <suhasietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c15ed20a8af805562a5d8d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/NGba-JO9lcPxc4J3lmsDeyzyUFk>
Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 14:07:28 -0000

>>> [roni]the bridge will ask for conference number and password using
voice messages
I'm not seeing how perc's encryption (as proposed in Prague) supports
either audio prompts from the server to the client or DTMF from the client
to the server.

If there is an adjunct web interface for control, that might not matter -
since audio prompts can be streamed over that interface if that is desired,
and the client can easily use http for replies.  That approach separates
the conference control plane from the media distribution plane.

Though in your use case, another option is to allow an initial media
connection to the server that doesn't use double for the purpose of
voice/response - and once the user selects their conference, then that
media is torn down and replaced by media encrypted with the conference
keys.  That works for conference setup, but not other use cases (announcing
new attendees joining the conference, or warning that the conference ending
time is approaching for example).

Stephen


On Mon, Aug 7, 2017 at 8:33 AM, Roni Even <roni.even@huawei.com> wrote:

> Hi Paul,
>
> I agree that DTMF is not to the end user. On second thought I think that
> if DTMF will be used by the conference than there may be a separate entity
> that will handle DTMF. An example is when you call a conference dial-in
> number and the bridge will ask for conference number and password using
> voice messages.
>
> I think this may happen also in Webex when you want to join using your
> phone to dial in, you get prompted for conference ID
>
> Roni
>
>
>
> *From:* Paul E. Jones [mailto:paulej@packetizer.com]
> *Sent:* יום ב 07 אוגוסט 2017 14:59
> *To:* perc@ietf.org; Roni Even; Suhas Nandakumar; perc@ietf.org
>
> *Subject:* Re: [Perc] Confirmation of Consensus on PERC Double from IETF
> 99
>
>
>
> Roni,
>
> That particular issue is least concerning to me, since all endpoints I
> know won't play DTMF into a user's ear. AFAIK, only users over the PSTN
> might be affected, but then that suggests there's a gateway in the path and
> PERC is no longer securing the conference E2E. Thus, gateways need to stay
> out of PERC conferences.
>
> Paul
> ------------------------------
>
> *From:* Roni Even <roni.even@huawei.com>
> *Sent:* August 7, 2017 2:57:30 AM EDT
> *To:* Suhas Nandakumar <suhasietf@gmail.com>, "perc@ietf.org" <
> perc@ietf.org>
> *Subject:* Re: [Perc] Confirmation of Consensus on PERC Double from IETF
> 99
>
>
>
> Hi,
>
> I do not have a strong opinion but I am a bit puzzled about the DTMF issue.
>
> My understating so far was that the MD is the media distribution for a
> multipoint conferencing application. Typically in this cases the DTMF is
> for the multipoint application and not to the conference participants (The
> DTMF may even be suppressed by the conferencing bride) .
>
> So how will such application work without DTMF if it depended on it? I
> think that there should be some text about it (use DTMF in the signaling
> when there is a PERC MD e.g. SIP INFO?)
>
>
>
> Roni
>
>
>
> *From:* Perc [mailto:perc-bounces@ietf.org <perc-bounces@ietf.org>] *On
> Behalf Of *Suhas Nandakumar
> *Sent:* יום א 06 אוגוסט 2017 23:42
> *To:* perc@ietf.org
> *Subject:* Re: [Perc] Confirmation of Consensus on PERC Double from IETF
> 99
>
>
>
> Hello All
>
>
>
>    Following up on the consensus confirmation email, the chairs have
> considered all the inputs received from the people in the room and the
> inputs from people on the email list and determined there is consensus for
> the following 2 items.
>
>
>
> 1.   Allow MD to modify the 'M' (marker) bit.
>
>
>
> 2. Includes all the below
>
>     - Move the OHB information from header extension to payload
>
>     - RTX, RED and FlexFEC ordering : use the ordering of applying repair
> on the double-encrypted packet. (Option 'A' in the slides)
>
>     - DTMF : PERC will only support E2E DTMF and MD will not be able to
> read DTMF info sent as media
>
>
>
> Thanks for your inputs.
>
>
>
> Cheers
>
> Chairs
>
>
>
> On Thu, Jul 27, 2017 at 10:14 AM, Suhas Nandakumar <suhasietf@gmail.com>
> wrote:
>
>
>
> Hi All,
>
>
>
> At the IETF 99 meeting, we took hum on the following proposals and there
> was a strong consensus in the room in their favor, but we wish to gather
> any additional inputs on the list.
>
> So, if there are any additional inputs that was not expressed in the room,
> please send them to the list by *4th August.*
>
>
>
> First Consensus Call:
>
>    Allow MD to modify the 'M' (marker) bit.
>
>
>
> Second Consensus called made includes all the following 3 proposals as a
> singleton:
>
>     - Move the OHB information from header extension to payload
>
>     - RTX, RED and FlexFEC ordering : use the ordering of applying repair
> on the double-encrypted packet. (Option 'A' in the slides)
>
>     - DTMF : PERC will only support E2E DTMF and MD will not be able to
> read DTMF info sent as media
>
>
>
> Here are the notes from the meeting:
>
>   https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-01.txt
>
>
>
> Here are the slides corresponding to the above proposals :
>
>   https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-01.pdf
>
>
>
>
>
> Thanks
>
> Perc Chairs
>
>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>
>