IETF Logo Mail Archive

Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)

Jonathan Lennox <jonathan@vidyo.com> Mon, 13 April 2015 15:11 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9646F1ACCE7 for <dispatch@ietfa.amsl.com>; Mon, 13 Apr 2015 08:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.796
X-Spam-Level:
X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, 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 kjZXdFmGI0dG for <dispatch@ietfa.amsl.com>; Mon, 13 Apr 2015 08:11:21 -0700 (PDT)
Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922171AC439 for <dispatch@ietf.org>; Mon, 13 Apr 2015 08:11:21 -0700 (PDT)
Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t3DF59IB017959; Mon, 13 Apr 2015 11:11:19 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1tpw3trvmt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2015 11:11:19 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 10:11:18 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)
Thread-Index: AQHQdfue4bwLOvj3f0qC3BYOomvJ051LYAqA
Date: Mon, 13 Apr 2015 15:11:18 +0000
Message-ID: <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com>
References: <55134454.9050302@ericsson.com> <DF642B61-47ED-4F33-BE7F-3F70FF80B294@nostrum.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552BC97E.1000601@alum.mit.edu>
In-Reply-To: <552BC97E.1000601@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_9171EFE9F7E54D1DB00FB42C4FA9111Evidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-13_03:2015-04-10,2015-04-13,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504130129
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/Jw2N4fC1Rgt8Yrq4tROTMls7K2M>
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2015 15:11:27 -0000

On Apr 13, 2015, at 9:49 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:

On 4/13/15 4:33 AM, Magnus Westerlund wrote:
On 2015-04-10 16:37, Robert Sparks wrote:
So, I think this should get chartered.
I have a couple of charter-bashing questions/comments.

It would be good to be clear what any interactions with the work in CLUE
might be.

I hope someone more active than me can step in an give their view here.
To me this should be possible to use with CLUE. I don't know if that
will be possible without any extensions to the clue part.

I *think* there will be a problem: that a mixer won't be able to insert the clue capture-id into the RTP/RTCP.

Roni and Jonathan should be able to be more definitive about this.

PERC will need the ability for the middleboxes to insert hop-by-hop header extensions and RTCP SSRC values — BUNDLE will need this for the mid values.

Once we work out how to do this securely, the same mechanism should work for capture-id for CLUE.

I think this is within the domain of what PERC is intending to trust middleboxes to do.

—
Jonathan Lennox
jonathan@vidyo.com<mailto:jonathan@vidyo.com>

v2.23.0 | Report a Bug | By Email