From nobody Wed Apr 1 10:28:09 2015 Return-Path: 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 B6CF71A0271 for ; Wed, 1 Apr 2015 10:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 q2z5GjeRmAFj for ; Wed, 1 Apr 2015 10:28:07 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (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 837901A0266 for ; Wed, 1 Apr 2015 10:27:37 -0700 (PDT) Received: by lajy8 with SMTP id y8so42005541laj.0 for ; Wed, 01 Apr 2015 10:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZdIGmiR9eYrN4gacgHsZK07ErpkMmAydVk7pLS8G3F0=; b=QT/b4X2ryu8jRVn+rNX2OAkVdp3pMXPboz9WGqmvtLJDPujpBA13s+x/9Q2Dk03ln1 TPtm+AIXHFsuDulbhYvIX9+j+hzUTFlMruNdtsqr+PLNN87rBnJA1Ln6O/JzXyNh6F21 QO1DSHaWkGQenOsELMy3jpqRtp6gkQYNz+/Mz4J4oso6qDGaULAKeg+rwzu2aVxPSmKL +FHX4fogIcYsY20bDsFTFYKDwF9cibCoYQBLRRdFsPvg7PPWwKmdqtw4BQoJZhp/jxCi i1csAGiz9aRLyB7SA9KvuC+3Lz6Fcc1hnF2UvNypP3is0J6DL/AviUqcHB9wLrv2mo8l m6hg== MIME-Version: 1.0 X-Received: by 10.152.37.164 with SMTP id z4mr36494899laj.5.1427909256100; Wed, 01 Apr 2015 10:27:36 -0700 (PDT) Received: by 10.25.128.207 with HTTP; Wed, 1 Apr 2015 10:27:36 -0700 (PDT) Date: Wed, 1 Apr 2015 12:27:36 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=089e0141a73afb41e00512ad076e Archived-At: Cc: Cullen Jennings Subject: [dispatch] WG review of draft-mohali-dispatch-cause-for-service-number X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:28:08 -0000 --089e0141a73afb41e00512ad076e Content-Type: text/plain; charset=UTF-8 Hi all, As posted on the mailing list prior to IETF-92 and as mentioned during the DISPATCH WG session last week, the proposal is to progress this document as AD sponsored: http://datatracker.ietf.org/doc/draft-mohali-dispatch-cause-for-service-number Please review and provide any comments. In addition, please indicate whether or not you support progression of the document as AD sponsored no later than Wednesday, April 15, 2015. Regards, Mary Barnes DISPATCH WG co-chair --089e0141a73afb41e00512ad076e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

As posted on the mailing list p= rior to IETF-92 and as mentioned during the DISPATCH WG session last week, = the proposal is to progress this document as AD sponsored:

Please review and provide an= y comments.=C2=A0 In addition, please indicate whether or not you support p= rogression of the document as AD sponsored no later than Wednesday, April 1= 5, 2015.

Regards,
Mary Barnes
= DISPATCH WG co-chair
--089e0141a73afb41e00512ad076e-- From nobody Wed Apr 1 14:56:07 2015 Return-Path: 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 8AF651A884B for ; Wed, 1 Apr 2015 14:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.532 X-Spam-Level: X-Spam-Status: No, score=-96.532 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, J_CHICKENPOX_62=0.6, J_CHICKENPOX_72=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 pZ_S0-dGIG6Q for ; Wed, 1 Apr 2015 14:56:02 -0700 (PDT) Received: from msk-mail-app01.ti.ru (msk-mail-app01.ti.ru [89.20.149.130]) by ietfa.amsl.com (Postfix) with ESMTP id A995F1A897C for ; Wed, 1 Apr 2015 14:56:00 -0700 (PDT) Received: from [151.252.67.122] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 9715266 for dispatch@ietf.org; Thu, 02 Apr 2015 00:55:58 +0300 From: "Anton Tveretin" To: dispatch@ietf.org Date: Thu, 02 Apr 2015 02:55:30 +0500 MIME-Version: 1.0 Message-ID: <551C6952.8898.A804EC9@fas_vm.surguttel.ru> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Archived-At: Subject: [dispatch] More on my draft (draft-tveretin-dispatch-remote-00) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:56:03 -0000 Hello Dale and all, Few days ago I found my older (2011) notes on PICKUP method. :) There, I indeed suggested to use Replaces: header to refer to the affected dialog. Thus, message body for PICKUP and REJECT method is actually not needed. It it was present, it would be relayed in a 3xx-6xx response or a BYE request (as a detailed error or redirection message). Also, Subject: header could not be relayed, it is logged by Ctd. Few abbreviations I suggest (I will include them in -01 version): Calling>Cg, Called>Cd, Controlling>Ctg, Controlled>Ctd, Affected dialog>AfD, Inspection dialog (between Ctg and Ctd)>InD. ANSWER body could be used to indicate how to answer (thank you, Dale!). But this topic needs further discussion and some formalism. Regards, Anton From nobody Thu Apr 9 14:29:27 2015 Return-Path: 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 015961B3018 for ; Thu, 9 Apr 2015 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 IESONfpQCJce for ; Thu, 9 Apr 2015 14:29:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F139E1B3287 for ; Thu, 9 Apr 2015 14:29:23 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t39LT4M8029240 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2015 16:29:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Magnus Westerlund" Date: Thu, 09 Apr 2015 16:29:03 -0500 Message-ID: In-Reply-To: <55134454.9050302@ericsson.com> References: <55134454.9050302@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: DISPATCH list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 21:29:26 -0000 For the record, I'd love to see this get chartered. I think the charter is on the right track. It might be worth mentioning the drafts in the charter as "inputs" to the work. Is anyone else interested in working on this? /Ben On 25 Mar 2015, at 18:27, Magnus Westerlund wrote: > Dispatch, > > AVTCORE WG has discussed a couple of proposals that discusses > end-to-end > security in centralized RTP based conferences. > > Drafts for these Proposals: > https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ > https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/ > https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ > > In these discussions one has reached the conclusion that this work > requires its own venue to continue the work. Therefore a number of > interested has put together a initial draft charter for a new WG. > > Please review and provide feedback. > > > Name: Privacy Enhanced RTP Conferencing (PERC) > Area: ART > Chairs: TBD > Mailing List: > > Motivation for new WG > --------------------- > > RTP-based real-time multi-party interactive media conferencing is > today > in widespread use. Many of the deployments uses one or more centrally > located media distribution devices that perform selective forwarding > or > mixes media streams received from the participating endpoints. The > media > transport protocol commonly used is RTP (RFC3550). There are various > signaling systems used to establish these multi-party conferences. > > These conferences require security to ensure that the RTP media and > related meta data of the conference is kept private to the set of > invited participants and only other devices trusted by those > participants with their media. At the same time, multi-party media > conferences do need source authentication and integrity checks to > protect against modifications, insertions or replay attacks. Media > distribution devices supporting these conferences may also perform RTP > header changes and often consume and create RTCP messages for > efficient > media handling. > > To date, deployment models for these multi-party media distribution > devices do not enable them to perform their functions without having > keys to decrypt the participants’ media, primarily using Secure RTP > (RFC3711) to provide session security. > > A new architecture model and related specifications is needed, with a > focused effort from the RTP and Security communities. > > WG Objectives > ------------- > > This WG will work on a solution that enables centralized SRTP based > conferencing where the central device distributing the media is not > required to be trusted with the keys to decrypt the participant’s > media. > The media must be kept confidential and authenticated between an > originating endpoint and the explicitly allowed receiving endpoints or > other devices. Further it is desired that a solution still provide > replay protection so that the media distribution devices can’t > replay > previous parts of the media. > > The solution must also provide security for each hop between endpoints > and multi-party media distribution devices and between multi-party > media > distribution devices. The RTCP messages and RTP header extensions > required for the media distribution device to perform the selective > media forwarding may require both source authentication and integrity > as > well as confidentiality. The solution may also consider providing > end-to-end security for a subset of the RTCP messages or header > extensions. > > The solution should be usable from both SIP and WebRTC endpoints that > implement the extension defined by this WG. > > This WG will perform the following work: > > 1. Define a general architecture and RTP topology(s) that enables > end-to-end media security for multi-party RTP conferencing. > > 2. Define the trust model and describe the resulting security > properties. > > 3. Specify any necessary extensions to SRTP. > > 4. Define a Key Management Function that distributes the keys. The > system needs to be able to bind the media to the sender of the > media’s identity and/or the identity of the conference. > > Collaboration > ------------- > > If there is identification of missing protocols or functionalities, > such > work can be requested to be done in another working group with a > suitable charter or by requests for chartering it in this WG or > another > WG. Potential work that might require work in other WGs are DTLS > extensions (TLS) as well as RTP header extensions (AVTEXT). This > requires strong collaboration with the security area. We will notify > SIPREC, W3C WebRTC, AVTCore, and other related groups about this work. > > Non-Goals > --------- > > The WG is not chartered to extend any signaling system used to > establish > the RTP based conferences. It will however, need to consider in its > architecture how the solution may integrate with these systems. > > Will not consider non-real-time usages, multicast based media > distribution, or Security descriptions-based keying. > > Goals and Milestones > -------------------- > > TBD Submit architecture or framework specification to IESG (Standards > Track) > > TBD Submit protocol specification(s) to IESG (Standards Track) > > > > > Cheers > > Magnus Westerlund > (AVTCORE WG chair) > > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Apr 10 05:03:44 2015 Return-Path: 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 350321B2CE8 for ; Fri, 10 Apr 2015 05:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 j8nEkPz8CsQi for ; Fri, 10 Apr 2015 05:03:41 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C28C1B2C78 for ; Fri, 10 Apr 2015 05:03:39 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-6f-5527bc1990bc Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.4B.19337.91CB7255; Fri, 10 Apr 2015 14:03:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Fri, 10 Apr 2015 14:03:37 +0200 Message-ID: <5527BC19.5000103@ericsson.com> Date: Fri, 10 Apr 2015 14:03:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell References: <55134454.9050302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvja7UHvVQgxnneCzmd55mt1g6aQGr A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXxYtIhxoIn5hV/zq9ha2A8rNvFyMkhIWAi saFpExuELSZx4d56MFtI4CijxKy/FV2MXED2ckaJe/vOMoIkeAW0JX6dawIrYhFQlWj9fJ0V xGYTsJC4+aMRLC4qECzR9KKRHaJeUOLkzCcsILaIgJLE8+atYDYzUO/5U53MILawQKTE76d9 7BCL4yS+nzoHNIeDg1PAXmLJEX0Qk1lAU2L9Ln2ITnmJ5q2zmSGqtSUamjpYJzAKzkKybBZC xywkHQsYmVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBAbqwS2/VXcwXn7jeIhRgINRiYf3 QZp6qBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGCMP7J59 mSV1j/s8m6k9LN+e7S58uekcw8bFMuENy06bhu9xYXWWr59WfLfivMP2iguyKR1Cvq9sllwq Ltnxs7PHTaigTLEpTr4pvVhYsXPzxpOJPk7FD6X69l5SmZ0a0bBeJ3aK2pGs4+zWKy59Pj15 1W4liYuXr9+eqLk4ZN/CPzdT/b01liixFGckGmoxFxUnAgCUZmwBNQIAAA== Archived-At: Cc: DISPATCH list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 12:03:43 -0000 On 2015-04-09 23:29, Ben Campbell wrote: > For the record, I'd love to see this get chartered. I think the charter > is on the right track. It might be worth mentioning the drafts in the > charter as "inputs" to the work. > > Is anyone else interested in working on this? To be clear, one benefit of getting the work out of my WG (AVTCORE) is that I can be an active contributor, rather than a chair of this. I do hope that people speak up, we had close to 20 persons in the room when we had a drafting session of the charter in Dallas. Cheers Magnus > > /Ben > > On 25 Mar 2015, at 18:27, Magnus Westerlund wrote: > >> Dispatch, >> >> AVTCORE WG has discussed a couple of proposals that discusses end-to-end >> security in centralized RTP based conferences. >> >> Drafts for these Proposals: >> https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ >> https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/ >> >> https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ >> >> In these discussions one has reached the conclusion that this work >> requires its own venue to continue the work. Therefore a number of >> interested has put together a initial draft charter for a new WG. >> >> Please review and provide feedback. >> >> >> Name: Privacy Enhanced RTP Conferencing (PERC) >> Area: ART >> Chairs: TBD >> Mailing List: >> >> Motivation for new WG >> --------------------- >> >> RTP-based real-time multi-party interactive media conferencing is today >> in widespread use. Many of the deployments uses one or more centrally >> located media distribution devices that perform selective forwarding or >> mixes media streams received from the participating endpoints. The media >> transport protocol commonly used is RTP (RFC3550). There are various >> signaling systems used to establish these multi-party conferences. >> >> These conferences require security to ensure that the RTP media and >> related meta data of the conference is kept private to the set of >> invited participants and only other devices trusted by those >> participants with their media. At the same time, multi-party media >> conferences do need source authentication and integrity checks to >> protect against modifications, insertions or replay attacks. Media >> distribution devices supporting these conferences may also perform RTP >> header changes and often consume and create RTCP messages for efficient >> media handling. >> >> To date, deployment models for these multi-party media distribution >> devices do not enable them to perform their functions without having >> keys to decrypt the participants’ media, primarily using Secure RTP >> (RFC3711) to provide session security. >> >> A new architecture model and related specifications is needed, with a >> focused effort from the RTP and Security communities. >> >> WG Objectives >> ------------- >> >> This WG will work on a solution that enables centralized SRTP based >> conferencing where the central device distributing the media is not >> required to be trusted with the keys to decrypt the participant’s media. >> The media must be kept confidential and authenticated between an >> originating endpoint and the explicitly allowed receiving endpoints or >> other devices. Further it is desired that a solution still provide >> replay protection so that the media distribution devices can’t replay >> previous parts of the media. >> >> The solution must also provide security for each hop between endpoints >> and multi-party media distribution devices and between multi-party media >> distribution devices. The RTCP messages and RTP header extensions >> required for the media distribution device to perform the selective >> media forwarding may require both source authentication and integrity as >> well as confidentiality. The solution may also consider providing >> end-to-end security for a subset of the RTCP messages or header >> extensions. >> >> The solution should be usable from both SIP and WebRTC endpoints that >> implement the extension defined by this WG. >> >> This WG will perform the following work: >> >> 1. Define a general architecture and RTP topology(s) that enables >> end-to-end media security for multi-party RTP conferencing. >> >> 2. Define the trust model and describe the resulting security >> properties. >> >> 3. Specify any necessary extensions to SRTP. >> >> 4. Define a Key Management Function that distributes the keys. The >> system needs to be able to bind the media to the sender of the >> media’s identity and/or the identity of the conference. >> >> Collaboration >> ------------- >> >> If there is identification of missing protocols or functionalities, such >> work can be requested to be done in another working group with a >> suitable charter or by requests for chartering it in this WG or another >> WG. Potential work that might require work in other WGs are DTLS >> extensions (TLS) as well as RTP header extensions (AVTEXT). This >> requires strong collaboration with the security area. We will notify >> SIPREC, W3C WebRTC, AVTCore, and other related groups about this work. >> >> Non-Goals >> --------- >> >> The WG is not chartered to extend any signaling system used to establish >> the RTP based conferences. It will however, need to consider in its >> architecture how the solution may integrate with these systems. >> >> Will not consider non-real-time usages, multicast based media >> distribution, or Security descriptions-based keying. >> >> Goals and Milestones >> -------------------- >> >> TBD Submit architecture or framework specification to IESG (Standards >> Track) >> >> TBD Submit protocol specification(s) to IESG (Standards Track) >> >> >> >> >> Cheers >> >> Magnus Westerlund >> (AVTCORE WG chair) >> >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Apr 10 05:19:58 2015 Return-Path: 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 1DA9A1B2D64 for ; Fri, 10 Apr 2015 05:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kr4TDEADFBMU for ; Fri, 10 Apr 2015 05:19:56 -0700 (PDT) Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (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 D66651B2D62 for ; Fri, 10 Apr 2015 05:19:55 -0700 (PDT) Received: by qkx62 with SMTP id 62so27782549qkx.0 for ; Fri, 10 Apr 2015 05:19:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AMgWMKaj3VpC83PboDOaUeT7Qp/qoojOF1LR3RP9ubA=; b=YQQC5bIa82700EYhbUYkXh46IFCBIw3IDHvE+HOtvvovhYSCA8gj+EzbsWCusXhaJV iUFOLfy+quKyKePjzbuIePw1cCNiyARHr9EhwRVaCAYopuUW1NTB4gxKiBGWYb9UClP7 dAk62ODcrA7qgomWLSxv+kWRxnUAj7fydODfqljgLPPm8i84bz2G3gkgFkHCCg2YN2Hv nLbwMsg4HpG+1FrSEWmpUr6Vthxh3LBCVgYMiY2no/HLVq69d6vYrzVq9BofscofcGo7 YKFmm3YyQrjQKjgBHT6Sn/EkNeTb6d+OfjdB7mDyrcWqNvJAHN3bSTkNbaHbY3zj/Z+t QA/A== X-Gm-Message-State: ALoCoQkNUv8eRscRviHXwj44J4PCsRYXcY78UXx81beU1/WPICSdkyPOmRdKRL+PcxygLANOnQyU X-Received: by 10.55.53.72 with SMTP id c69mr2119422qka.67.1428668394953; Fri, 10 Apr 2015 05:19:54 -0700 (PDT) Received: from [192.168.1.43] (modemcable233.42-178-173.mc.videotron.ca. [173.178.42.233]) by mx.google.com with ESMTPSA id c20sm1461047qka.21.2015.04.10.05.19.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2015 05:19:54 -0700 (PDT) Message-ID: <5527BFE8.4030003@jive.com> Date: Fri, 10 Apr 2015 08:19:52 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell , Magnus Westerlund References: <55134454.9050302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: DISPATCH list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 12:19:57 -0000 Le 2015-04-09 17:29, Ben Campbell a écrit : > For the record, I'd love to see this get chartered. I think the charter > is on the right track. It might be worth mentioning the drafts in the > charter as "inputs" to the work. > > Is anyone else interested in working on this? Most definitely. Simon From nobody Fri Apr 10 07:37:31 2015 Return-Path: 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 D4DA61A0263 for ; Fri, 10 Apr 2015 07:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 vhn4ObHZBd6W for ; Fri, 10 Apr 2015 07:37:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 950631A024E for ; Fri, 10 Apr 2015 07:37:25 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3AEbOC2022045 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Apr 2015 09:37:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <5527E01F.9040507@nostrum.com> Date: Fri, 10 Apr 2015 09:37:19 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55134454.9050302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 14:37:29 -0000 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. What is the motivation for declaring any extensions to signalling systems out of scope? (Not saying I see any that need to be created, but I'm surprised that it's not something that the group might need to investigate rather than making that call at chartering time)? RjS On 4/9/15 4:29 PM, Ben Campbell wrote: > For the record, I'd love to see this get chartered. I think the > charter is on the right track. It might be worth mentioning the drafts > in the charter as "inputs" to the work. > > Is anyone else interested in working on this? > > /Ben > > On 25 Mar 2015, at 18:27, Magnus Westerlund wrote: > >> Dispatch, >> >> AVTCORE WG has discussed a couple of proposals that discusses end-to-end >> security in centralized RTP based conferences. >> >> Drafts for these Proposals: >> https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ >> >> https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framework/ >> >> https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ >> >> In these discussions one has reached the conclusion that this work >> requires its own venue to continue the work. Therefore a number of >> interested has put together a initial draft charter for a new WG. >> >> Please review and provide feedback. >> >> >> Name: Privacy Enhanced RTP Conferencing (PERC) >> Area: ART >> Chairs: TBD >> Mailing List: >> >> Motivation for new WG >> --------------------- >> >> RTP-based real-time multi-party interactive media conferencing is today >> in widespread use. Many of the deployments uses one or more centrally >> located media distribution devices that perform selective forwarding or >> mixes media streams received from the participating endpoints. The media >> transport protocol commonly used is RTP (RFC3550). There are various >> signaling systems used to establish these multi-party conferences. >> >> These conferences require security to ensure that the RTP media and >> related meta data of the conference is kept private to the set of >> invited participants and only other devices trusted by those >> participants with their media. At the same time, multi-party media >> conferences do need source authentication and integrity checks to >> protect against modifications, insertions or replay attacks. Media >> distribution devices supporting these conferences may also perform RTP >> header changes and often consume and create RTCP messages for efficient >> media handling. >> >> To date, deployment models for these multi-party media distribution >> devices do not enable them to perform their functions without having >> keys to decrypt the participants’ media, primarily using Secure RTP >> (RFC3711) to provide session security. >> >> A new architecture model and related specifications is needed, with a >> focused effort from the RTP and Security communities. >> >> WG Objectives >> ------------- >> >> This WG will work on a solution that enables centralized SRTP based >> conferencing where the central device distributing the media is not >> required to be trusted with the keys to decrypt the participant’s media. >> The media must be kept confidential and authenticated between an >> originating endpoint and the explicitly allowed receiving endpoints or >> other devices. Further it is desired that a solution still provide >> replay protection so that the media distribution devices can’t replay >> previous parts of the media. >> >> The solution must also provide security for each hop between endpoints >> and multi-party media distribution devices and between multi-party media >> distribution devices. The RTCP messages and RTP header extensions >> required for the media distribution device to perform the selective >> media forwarding may require both source authentication and integrity as >> well as confidentiality. The solution may also consider providing >> end-to-end security for a subset of the RTCP messages or header >> extensions. >> >> The solution should be usable from both SIP and WebRTC endpoints that >> implement the extension defined by this WG. >> >> This WG will perform the following work: >> >> 1. Define a general architecture and RTP topology(s) that enables >> end-to-end media security for multi-party RTP conferencing. >> >> 2. Define the trust model and describe the resulting security >> properties. >> >> 3. Specify any necessary extensions to SRTP. >> >> 4. Define a Key Management Function that distributes the keys. The >> system needs to be able to bind the media to the sender of the >> media’s identity and/or the identity of the conference. >> >> Collaboration >> ------------- >> >> If there is identification of missing protocols or functionalities, such >> work can be requested to be done in another working group with a >> suitable charter or by requests for chartering it in this WG or another >> WG. Potential work that might require work in other WGs are DTLS >> extensions (TLS) as well as RTP header extensions (AVTEXT). This >> requires strong collaboration with the security area. We will notify >> SIPREC, W3C WebRTC, AVTCore, and other related groups about this work. >> >> Non-Goals >> --------- >> >> The WG is not chartered to extend any signaling system used to establish >> the RTP based conferences. It will however, need to consider in its >> architecture how the solution may integrate with these systems. >> >> Will not consider non-real-time usages, multicast based media >> distribution, or Security descriptions-based keying. >> >> Goals and Milestones >> -------------------- >> >> TBD Submit architecture or framework specification to IESG (Standards >> Track) >> >> TBD Submit protocol specification(s) to IESG (Standards Track) >> >> >> >> >> Cheers >> >> Magnus Westerlund >> (AVTCORE WG chair) >> >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Apr 10 08:57:43 2015 Return-Path: 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 CBF831A6F7A for ; Fri, 10 Apr 2015 08:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 dtUxqLlSnGrd for ; Fri, 10 Apr 2015 08:57:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 20E561A6F20 for ; Fri, 10 Apr 2015 08:57:39 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3AFvSnl028851 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2015 10:57:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Robert Sparks" Date: Fri, 10 Apr 2015 10:57:28 -0500 Message-ID: <809E8D45-6EC7-457D-B24B-8330A14BC0D5@nostrum.com> In-Reply-To: <5527E01F.9040507@nostrum.com> References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 15:57:41 -0000 On 10 Apr 2015, at 9:37, Robert Sparks wrote: > What is the motivation for declaring any extensions to signalling > systems out of scope? (Not saying I see any that need to be created, > but I'm surprised that it's not something that the group might need to > investigate rather than making that call at chartering time)? I'm curious how that limitation interacts with the key-management deliverables. If there are assumptions underlying these, it would be good to explicitly state them in the charter. From nobody Mon Apr 13 01:34:10 2015 Return-Path: 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 084D81B2EDA for ; Mon, 13 Apr 2015 01:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 AabnlQIm9RGg for ; Mon, 13 Apr 2015 01:34:07 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CB01B2ED3 for ; Mon, 13 Apr 2015 01:34:06 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-83-552b7f7c6d44 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.88.19337.C7F7B255; Mon, 13 Apr 2015 10:34:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Mon, 13 Apr 2015 10:33:59 +0200 Message-ID: <552B7F5C.9060107@ericsson.com> Date: Mon, 13 Apr 2015 10:33:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Robert Sparks , References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> In-Reply-To: <5527E01F.9040507@nostrum.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+JvjW5tvXaowbqbHBZLJy1gtbg2p5HN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4MroWPKIreCuSMX9x71sDYx3BboYOTkkBEwk dnw9zQxhi0lcuLeerYuRi0NI4CijxPq7PSwQznJGiVXt79hAqngFtCWWNXSzgtgsAqoSfzf/ ZQex2QQsJG7+aASrERUIlmh60cgOUS8ocXLmExYQW0TAVmLJpS2MILawQKTE76d9YDVCArUS +xd0gtVwAs0/9uQ3UA0HB7OApsT6XfogYWYBeYnmrbOZIcq1JRqaOlgnMArMQrJhFkLHLCQd CxiZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEBuXBLb9VdzBefuN4iFGAg1GJh/fBK61Q IdbEsuLK3EOM0hwsSuK8dsaHQoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwZjz8tXzH8glX ntbNOe/q4nIvlpPrpcPS9CsmGt+izFWv3ZkbpSgiv/vlG545U6WlpC8fKW6cvvHgxLkWawou T3snF+Czp9ely0L2xzH7eXM7nq/vUDvYMKH3XddJ60NCavPW+fP6H2Gc/0V464zWJUp2/c3L lX/w3gh6VJ64K75qZc3iEn4xdSWW4oxEQy3mouJEAMpzTh4rAgAA Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 08:34:09 -0000 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. > > What is the motivation for declaring any extensions to signalling > systems out of scope? (Not saying I see any that need to be created, but > I'm surprised that it's not something that the group might need to > investigate rather than making that call at chartering time)? > My reasons is to keep this WG focused on what it actually needs to produce and not get completely tied up in discussion of exactly how one will integrate this into ones signalling system. So I know people want this in WebRTC and SIP based conferences. I haven't heard anyone saying CLUE, but that is likely. These integrations are quite different, especially in what pieces you will trust when it comes to client software. Thus, my view was that WG working with signalling systems is the ones that should provide any necessary integration towards the framework. I do note that this consideration of integration is mentioned in this paragraph under Non-Goals: "The WG is not chartered to extend any signaling system used to establish the RTP based conferences. It will however, need to consider in its architecture how the solution may integrate with these systems." But, I guess one could be more explicit and require the WG to consider how one integrate into WebRTC, SIP and CLUE so that the framework is functional for these systems. When it comes to the key-management function, I think there exists an assumption here. That is that signalling and its nodes can't be trusted, only possible be used as a transport for key-management system information. But that will require that the communication fails if someone strips or modify such information. Does this help clarify the situation. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Apr 13 06:50:01 2015 Return-Path: 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 23B701A1A94 for ; Mon, 13 Apr 2015 06:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 CdOjbm3L22Ln for ; Mon, 13 Apr 2015 06:49:54 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1E71A1A99 for ; Mon, 13 Apr 2015 06:49:52 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-07v.sys.comcast.net with comcast id FRo51q0012AWL2D01RpsWT; Mon, 13 Apr 2015 13:49:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id FRpq1q00W3Ge9ey01RpqAr; Mon, 13 Apr 2015 13:49:52 +0000 Message-ID: <552BC97E.1000601@alum.mit.edu> Date: Mon, 13 Apr 2015 09:49:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> In-Reply-To: <552B7F5C.9060107@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1428932992; bh=NkvtUcQbhoIIcACi9eiHugm9PoxKLD7iWqReJdFR44w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FBVxJZhl4/G0Djfj9i/+LMCzqEReIRjIVX5DaVSHLfxKxr0afPXYaVmrchUUI1LXy gQ74ejXm1fJWE8gE08l6xOsa9hS/72YK8lhlEQ70Uwc1ijtusDtf3MeiWfl42X1sPe cizX4EOqaBX1oMmgX7c3qG4XaOmFDxUoflonGQ9DLQO9EFDAbSudXU9qy/+Bt6pW5g Kn4o8jemeNmcP9Fs+csPT8nSGK+cH3bDmLJycWKFb7JiEB0nziv/uT/EFMpVWSKIoP 1CchXv/nPy9/fgI8dGSc108BUOAoWQ1c111sw+58ppbzT1A4YJffJc3bpqfTLm+nOI VJC+IfmJ+n6VQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 13:50:00 -0000 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. Thanks, Paul >> What is the motivation for declaring any extensions to signalling >> systems out of scope? (Not saying I see any that need to be created, but >> I'm surprised that it's not something that the group might need to >> investigate rather than making that call at chartering time)? >> > > My reasons is to keep this WG focused on what it actually needs to > produce and not get completely tied up in discussion of exactly how one > will integrate this into ones signalling system. So I know people want > this in WebRTC and SIP based conferences. I haven't heard anyone saying > CLUE, but that is likely. These integrations are quite different, > especially in what pieces you will trust when it comes to client > software. Thus, my view was that WG working with signalling systems is > the ones that should provide any necessary integration towards the > framework. > > > I do note that this consideration of integration is mentioned in this > paragraph under Non-Goals: > > "The WG is not chartered to extend any signaling system used to > establish the RTP based conferences. It will however, need to consider > in its architecture how the solution may integrate with these systems." > > But, I guess one could be more explicit and require the WG to consider > how one integrate into WebRTC, SIP and CLUE so that the framework is > functional for these systems. > > When it comes to the key-management function, I think there exists an > assumption here. That is that signalling and its nodes can't be trusted, > only possible be used as a transport for key-management system > information. But that will require that the communication fails if > someone strips or modify such information. > > Does this help clarify the situation. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Apr 13 08:11:29 2015 Return-Path: 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 ; 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 ; 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 ; 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 To: Paul Kyzivat 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> <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: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:11:27 -0000 --_000_9171EFE9F7E54D1DB00FB42C4FA9111Evidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBcHIgMTMsIDIwMTUsIGF0IDk6NDkgQU0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1 bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCg0KT24gNC8x My8xNSA0OjMzIEFNLCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCk9uIDIwMTUtMDQtMTAgMTY6 MzcsIFJvYmVydCBTcGFya3Mgd3JvdGU6DQpTbywgSSB0aGluayB0aGlzIHNob3VsZCBnZXQgY2hh cnRlcmVkLg0KSSBoYXZlIGEgY291cGxlIG9mIGNoYXJ0ZXItYmFzaGluZyBxdWVzdGlvbnMvY29t bWVudHMuDQoNCkl0IHdvdWxkIGJlIGdvb2QgdG8gYmUgY2xlYXIgd2hhdCBhbnkgaW50ZXJhY3Rp b25zIHdpdGggdGhlIHdvcmsgaW4gQ0xVRQ0KbWlnaHQgYmUuDQoNCkkgaG9wZSBzb21lb25lIG1v cmUgYWN0aXZlIHRoYW4gbWUgY2FuIHN0ZXAgaW4gYW4gZ2l2ZSB0aGVpciB2aWV3IGhlcmUuDQpU byBtZSB0aGlzIHNob3VsZCBiZSBwb3NzaWJsZSB0byB1c2Ugd2l0aCBDTFVFLiBJIGRvbid0IGtu b3cgaWYgdGhhdA0Kd2lsbCBiZSBwb3NzaWJsZSB3aXRob3V0IGFueSBleHRlbnNpb25zIHRvIHRo ZSBjbHVlIHBhcnQuDQoNCkkgKnRoaW5rKiB0aGVyZSB3aWxsIGJlIGEgcHJvYmxlbTogdGhhdCBh IG1peGVyIHdvbid0IGJlIGFibGUgdG8gaW5zZXJ0IHRoZSBjbHVlIGNhcHR1cmUtaWQgaW50byB0 aGUgUlRQL1JUQ1AuDQoNClJvbmkgYW5kIEpvbmF0aGFuIHNob3VsZCBiZSBhYmxlIHRvIGJlIG1v cmUgZGVmaW5pdGl2ZSBhYm91dCB0aGlzLg0KDQpQRVJDIHdpbGwgbmVlZCB0aGUgYWJpbGl0eSBm b3IgdGhlIG1pZGRsZWJveGVzIHRvIGluc2VydCBob3AtYnktaG9wIGhlYWRlciBleHRlbnNpb25z IGFuZCBSVENQIFNTUkMgdmFsdWVzIOKAlCBCVU5ETEUgd2lsbCBuZWVkIHRoaXMgZm9yIHRoZSBt aWQgdmFsdWVzLg0KDQpPbmNlIHdlIHdvcmsgb3V0IGhvdyB0byBkbyB0aGlzIHNlY3VyZWx5LCB0 aGUgc2FtZSBtZWNoYW5pc20gc2hvdWxkIHdvcmsgZm9yIGNhcHR1cmUtaWQgZm9yIENMVUUuDQoN CkkgdGhpbmsgdGhpcyBpcyB3aXRoaW4gdGhlIGRvbWFpbiBvZiB3aGF0IFBFUkMgaXMgaW50ZW5k aW5nIHRvIHRydXN0IG1pZGRsZWJveGVzIHRvIGRvLg0KDQrigJQNCkpvbmF0aGFuIExlbm5veA0K am9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+DQoNCg== --_000_9171EFE9F7E54D1DB00FB42C4FA9111Evidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIg MTMsIDIwMTUsIGF0IDk6NDkgQU0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBr eXppdmF0QGFsdW0ubWl0LmVkdSIgY2xhc3M9IiI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj5PbiA0LzEzLzE1IDQ6MzMgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3Rl OjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIDIwMTUt MDQtMTAgMTY6MzcsIFJvYmVydCBTcGFya3Mgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+U28sIEkgdGhpbmsgdGhpcyBzaG91bGQgZ2V0IGNoYXJ0 ZXJlZC48YnIgY2xhc3M9IiI+DQpJIGhhdmUgYSBjb3VwbGUgb2YgY2hhcnRlci1iYXNoaW5nIHF1 ZXN0aW9ucy9jb21tZW50cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCB3b3VsZCBi ZSBnb29kIHRvIGJlIGNsZWFyIHdoYXQgYW55IGludGVyYWN0aW9ucyB3aXRoIHRoZSB3b3JrIGlu IENMVUU8YnIgY2xhc3M9IiI+DQptaWdodCBiZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQpJIGhvcGUgc29tZW9uZSBtb3JlIGFjdGl2ZSB0aGFuIG1lIGNhbiBz dGVwIGluIGFuIGdpdmUgdGhlaXIgdmlldyBoZXJlLjxiciBjbGFzcz0iIj4NClRvIG1lIHRoaXMg c2hvdWxkIGJlIHBvc3NpYmxlIHRvIHVzZSB3aXRoIENMVUUuIEkgZG9uJ3Qga25vdyBpZiB0aGF0 PGJyIGNsYXNzPSIiPg0Kd2lsbCBiZSBwb3NzaWJsZSB3aXRob3V0IGFueSBleHRlbnNpb25zIHRv IHRoZSBjbHVlIHBhcnQuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIi Pg0KSSAqdGhpbmsqIHRoZXJlIHdpbGwgYmUgYSBwcm9ibGVtOiB0aGF0IGEgbWl4ZXIgd29uJ3Qg YmUgYWJsZSB0byBpbnNlcnQgdGhlIGNsdWUgY2FwdHVyZS1pZCBpbnRvIHRoZSBSVFAvUlRDUC48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSb25pIGFuZCBKb25hdGhhbiBzaG91bGQgYmUg YWJsZSB0byBiZSBtb3JlIGRlZmluaXRpdmUgYWJvdXQgdGhpcy48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlBFUkMg d2lsbCBuZWVkIHRoZSBhYmlsaXR5IGZvciB0aGUgbWlkZGxlYm94ZXMgdG8gaW5zZXJ0IGhvcC1i eS1ob3AgaGVhZGVyIGV4dGVuc2lvbnMgYW5kIFJUQ1AgU1NSQyB2YWx1ZXMg4oCUIEJVTkRMRSB3 aWxsIG5lZWQgdGhpcyBmb3IgdGhlIG1pZCB2YWx1ZXMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj5PbmNlIHdlIHdvcmsgb3V0IGhvdyB0byBkbyB0aGlzIHNlY3VyZWx5 LCB0aGUgc2FtZSBtZWNoYW5pc20gc2hvdWxkIHdvcmsgZm9yIGNhcHR1cmUtaWQgZm9yIENMVUUu PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5rIHRoaXMgaXMg d2l0aGluIHRoZSBkb21haW4gb2Ygd2hhdCBQRVJDIGlzIGludGVuZGluZyB0byB0cnVzdCBtaWRk bGVib3hlcyB0byBkby48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PuKA lCZuYnNwOzwvZGl2Pg0KPGRpdj5Kb25hdGhhbiBMZW5ub3g8L2Rpdj4NCjxkaXY+PGEgaHJlZj0i bWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSIgY2xhc3M9IiI+am9uYXRoYW5AdmlkeW8uY29tPC9h PjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_9171EFE9F7E54D1DB00FB42C4FA9111Evidyocom_-- From nobody Mon Apr 13 08:24:35 2015 Return-Path: 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 5A1541ACD76 for ; Mon, 13 Apr 2015 08:24:34 -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 b48wZDVsE0xC for ; Mon, 13 Apr 2015 08:24:33 -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 6D4C21ACD2E for ; Mon, 13 Apr 2015 08:24:33 -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 t3DFJtft025256; Mon, 13 Apr 2015 11:24:31 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1tpw3trvw5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2015 11:24:31 -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:24:30 -0500 From: Jonathan Lennox To: Paul Kyzivat Thread-Topic: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC) Thread-Index: AQHQdfue4bwLOvj3f0qC3BYOomvJ051LYAqAgAADrwA= Date: Mon, 13 Apr 2015 15:24:29 +0000 Message-ID: <463392F2-346E-4D03-977B-C7EB1BB74E58@vidyo.com> References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552BC97E.1000601@alum.mit.edu> <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com> In-Reply-To: <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com> 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_463392F2346E4D03977BC7EB1BB74E58vidyocom_" 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-1504130131 Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:24:34 -0000 --_000_463392F2346E4D03977BC7EB1BB74E58vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBBcHIgMTMsIDIwMTUsIGF0IDExOjExIEFNLCBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFu QHZpZHlvLmNvbTxtYWlsdG86am9uYXRoYW5AdmlkeW8uY29tPj4gd3JvdGU6DQoNCg0KT24gQXBy IDEzLCAyMDE1LCBhdCA5OjQ5IEFNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVk dTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQoNCk9uIDQvMTMvMTUgNDoz MyBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6DQpPbiAyMDE1LTA0LTEwIDE2OjM3LCBSb2Jl cnQgU3BhcmtzIHdyb3RlOg0KU28sIEkgdGhpbmsgdGhpcyBzaG91bGQgZ2V0IGNoYXJ0ZXJlZC4N CkkgaGF2ZSBhIGNvdXBsZSBvZiBjaGFydGVyLWJhc2hpbmcgcXVlc3Rpb25zL2NvbW1lbnRzLg0K DQpJdCB3b3VsZCBiZSBnb29kIHRvIGJlIGNsZWFyIHdoYXQgYW55IGludGVyYWN0aW9ucyB3aXRo IHRoZSB3b3JrIGluIENMVUUNCm1pZ2h0IGJlLg0KDQpJIGhvcGUgc29tZW9uZSBtb3JlIGFjdGl2 ZSB0aGFuIG1lIGNhbiBzdGVwIGluIGFuIGdpdmUgdGhlaXIgdmlldyBoZXJlLg0KVG8gbWUgdGhp cyBzaG91bGQgYmUgcG9zc2libGUgdG8gdXNlIHdpdGggQ0xVRS4gSSBkb24ndCBrbm93IGlmIHRo YXQNCndpbGwgYmUgcG9zc2libGUgd2l0aG91dCBhbnkgZXh0ZW5zaW9ucyB0byB0aGUgY2x1ZSBw YXJ0Lg0KDQpJICp0aGluayogdGhlcmUgd2lsbCBiZSBhIHByb2JsZW06IHRoYXQgYSBtaXhlciB3 b24ndCBiZSBhYmxlIHRvIGluc2VydCB0aGUgY2x1ZSBjYXB0dXJlLWlkIGludG8gdGhlIFJUUC9S VENQLg0KDQpSb25pIGFuZCBKb25hdGhhbiBzaG91bGQgYmUgYWJsZSB0byBiZSBtb3JlIGRlZmlu aXRpdmUgYWJvdXQgdGhpcy4NCg0KUEVSQyB3aWxsIG5lZWQgdGhlIGFiaWxpdHkgZm9yIHRoZSBt aWRkbGVib3hlcyB0byBpbnNlcnQgaG9wLWJ5LWhvcCBoZWFkZXIgZXh0ZW5zaW9ucyBhbmQgUlRD UCBTU1JDIHZhbHVlcyDigJQgQlVORExFIHdpbGwgbmVlZCB0aGlzIGZvciB0aGUgbWlkIHZhbHVl cy4NCg0KU2hvdWxkIGJlIOKAnFNERVPigJ0gdmFsdWVzLCBzb3JyeS4NCg0KDQpPbmNlIHdlIHdv cmsgb3V0IGhvdyB0byBkbyB0aGlzIHNlY3VyZWx5LCB0aGUgc2FtZSBtZWNoYW5pc20gc2hvdWxk IHdvcmsgZm9yIGNhcHR1cmUtaWQgZm9yIENMVUUuDQoNCkkgdGhpbmsgdGhpcyBpcyB3aXRoaW4g dGhlIGRvbWFpbiBvZiB3aGF0IFBFUkMgaXMgaW50ZW5kaW5nIHRvIHRydXN0IG1pZGRsZWJveGVz IHRvIGRvLg0KDQrigJQNCkpvbmF0aGFuIExlbm5veA0Kam9uYXRoYW5AdmlkeW8uY29tPG1haWx0 bzpqb25hdGhhbkB2aWR5by5jb20+DQoNCg0K --_000_463392F2346E4D03977BC7EB1BB74E58vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0BB87B8A5CDD9747B59A0F8BA3F0D3C0@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIg MTMsIDIwMTUsIGF0IDExOjExIEFNLCBKb25hdGhhbiBMZW5ub3ggJmx0OzxhIGhyZWY9Im1haWx0 bzpqb25hdGhhbkB2aWR5by5jb20iIGNsYXNzPSIiPmpvbmF0aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMTMsIDIwMTUsIGF0IDk6 NDkgQU0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0 LmVkdSIgY2xhc3M9IiI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5P biA0LzEzLzE1IDQ6MzMgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIDIwMTUtMDQtMTAgMTY6MzcsIFJv YmVydCBTcGFya3Mgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+U28sIEkgdGhpbmsgdGhpcyBzaG91bGQgZ2V0IGNoYXJ0ZXJlZC48YnIgY2xhc3M9 IiI+DQpJIGhhdmUgYSBjb3VwbGUgb2YgY2hhcnRlci1iYXNoaW5nIHF1ZXN0aW9ucy9jb21tZW50 cy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCB3b3VsZCBiZSBnb29kIHRvIGJlIGNs ZWFyIHdoYXQgYW55IGludGVyYWN0aW9ucyB3aXRoIHRoZSB3b3JrIGluIENMVUU8YnIgY2xhc3M9 IiI+DQptaWdodCBiZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQpJIGhvcGUgc29tZW9uZSBtb3JlIGFjdGl2ZSB0aGFuIG1lIGNhbiBzdGVwIGluIGFuIGdpdmUg dGhlaXIgdmlldyBoZXJlLjxiciBjbGFzcz0iIj4NClRvIG1lIHRoaXMgc2hvdWxkIGJlIHBvc3Np YmxlIHRvIHVzZSB3aXRoIENMVUUuIEkgZG9uJ3Qga25vdyBpZiB0aGF0PGJyIGNsYXNzPSIiPg0K d2lsbCBiZSBwb3NzaWJsZSB3aXRob3V0IGFueSBleHRlbnNpb25zIHRvIHRoZSBjbHVlIHBhcnQu PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSSAqdGhpbmsqIHRo ZXJlIHdpbGwgYmUgYSBwcm9ibGVtOiB0aGF0IGEgbWl4ZXIgd29uJ3QgYmUgYWJsZSB0byBpbnNl cnQgdGhlIGNsdWUgY2FwdHVyZS1pZCBpbnRvIHRoZSBSVFAvUlRDUC48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpSb25pIGFuZCBKb25hdGhhbiBzaG91bGQgYmUgYWJsZSB0byBiZSBtb3Jl IGRlZmluaXRpdmUgYWJvdXQgdGhpcy48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBF UkMgd2lsbCBuZWVkIHRoZSBhYmlsaXR5IGZvciB0aGUgbWlkZGxlYm94ZXMgdG8gaW5zZXJ0IGhv cC1ieS1ob3AgaGVhZGVyIGV4dGVuc2lvbnMgYW5kIFJUQ1AgU1NSQyB2YWx1ZXMg4oCUIEJVTkRM RSB3aWxsIG5lZWQgdGhpcyBmb3IgdGhlIG1pZCB2YWx1ZXMuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5TaG91bGQgYmUg4oCcU0RFU+KAnSB2YWx1ZXMsIHNvcnJ5LjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5PbmNlIHdlIHdvcmsgb3V0IGhvdyB0byBkbyB0aGlzIHNlY3VyZWx5LCB0aGUgc2FtZSBt ZWNoYW5pc20gc2hvdWxkIHdvcmsgZm9yIGNhcHR1cmUtaWQgZm9yIENMVUUuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5rIHRo aXMgaXMgd2l0aGluIHRoZSBkb21haW4gb2Ygd2hhdCBQRVJDIGlzIGludGVuZGluZyB0byB0cnVz dCBtaWRkbGVib3hlcyB0byBkby48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Kb25h dGhhbiBMZW5ub3g8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFu QHZpZHlvLmNvbSIgY2xhc3M9IiI+am9uYXRoYW5AdmlkeW8uY29tPC9hPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_463392F2346E4D03977BC7EB1BB74E58vidyocom_-- From nobody Mon Apr 13 08:42:26 2015 Return-Path: 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 7AF8E1ACDBF for ; Mon, 13 Apr 2015 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 dJ91b4s9mhBz for ; Mon, 13 Apr 2015 08:42:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 F08B81ACDBC for ; Mon, 13 Apr 2015 08:42:23 -0700 (PDT) Received: from unnumerable.local (mobile-166-173-184-248.mycingular.net [166.173.184.248]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3DFgMrM098476 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Apr 2015 10:42:23 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-184-248.mycingular.net [166.173.184.248] claimed to be unnumerable.local Message-ID: <552BE3D8.80902@nostrum.com> Date: Mon, 13 Apr 2015 10:42:16 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552BC97E.1000601@alum.mit.edu> <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com> <463392F2-346E-4D03-977B-C7EB1BB74E58@vidyo.com> In-Reply-To: <463392F2-346E-4D03-977B-C7EB1BB74E58@vidyo.com> Content-Type: multipart/alternative; boundary="------------080600070504060207000607" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:42:25 -0000 This is a multi-part message in MIME format. --------------080600070504060207000607 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 4/13/15 10:24 AM, Jonathan Lennox wrote: > >> On Apr 13, 2015, at 11:11 AM, Jonathan Lennox > > wrote: >> >> >>> On Apr 13, 2015, at 9:49 AM, Paul Kyzivat >> > 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. > > Should be “SDES” values, sorry. If SDES is an assumption, it should land in the charter. I hope it's not an assumption, and that you'll be able to use other tools. > >> >> 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 >> > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------080600070504060207000607 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 4/13/15 10:24 AM, Jonathan Lennox wrote:

On Apr 13, 2015, at 11:11 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:


On Apr 13, 2015, at 9:49 AM, Paul Kyzivat <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.

Should be “SDES” values, sorry.
If SDES is an assumption, it should land in the charter.
I hope it's not an assumption, and that you'll be able to use other tools.


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




_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------080600070504060207000607-- From nobody Mon Apr 13 08:51:48 2015 Return-Path: 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 970611ACDB9 for ; Mon, 13 Apr 2015 08:51:47 -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 Uy4areXCrU4l for ; Mon, 13 Apr 2015 08:51:46 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 3CCAE1ACD9C for ; Mon, 13 Apr 2015 08:51:46 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t3DFjvEB009256; Mon, 13 Apr 2015 11:51:45 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1tpw3drve4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2015 11:51:44 -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:51:44 -0500 From: Jonathan Lennox To: Robert Sparks Thread-Topic: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC) Thread-Index: AQHQdfue4bwLOvj3f0qC3BYOomvJ051LYAqAgAADrwCAAAT3AIAAAqUA Date: Mon, 13 Apr 2015 15:51:44 +0000 Message-ID: <849A06BA-DB74-4850-B798-0983FCFC3300@vidyo.com> References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552BC97E.1000601@alum.mit.edu> <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com> <463392F2-346E-4D03-977B-C7EB1BB74E58@vidyo.com> <552BE3D8.80902@nostrum.com> In-Reply-To: <552BE3D8.80902@nostrum.com> 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_849A06BADB744850B7980983FCFC3300vidyocom_" 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-1504130135 Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:51:47 -0000 --_000_849A06BADB744850B7980983FCFC3300vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Apr 13, 2015, at 11:42 AM, Robert Sparks > wrote: On 4/13/15 10:24 AM, Jonathan Lennox wrote: On Apr 13, 2015, at 11:11 AM, Jonathan Lennox > wrote: On Apr 13, 2015, at 9:49 AM, Paul Kyzivat > 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 =97 BUNDLE will need this for the mid value= s. Should be =93SDES=94 values, sorry. If SDES is an assumption, it should land in the charter. I hope it's not an assumption, and that you'll be able to use other tools. Oh, this stupid name collision. I mean RTCP SDES packets, =93Source Description=94 (as defined in RFC 3550)= , not SDP Security Descriptions (RFC 4568). I think Security Descriptions should absolutely not be used for PERC, I thi= nk it would completely break the security model (barring magical secure sid= e-channels). --_000_849A06BADB744850B7980983FCFC3300vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7FA79E4CB1732A489BB5F20AA7CCA6B1@vidyo.com> Content-Transfer-Encoding: quoted-printable
On Apr 13, 2015, at 11:42 AM, Robert Sparks <rjsparks@nostrum.com> wrote:=



On 4/13/15 10:24 AM, Jonathan Lennox wrote:<= br class=3D"">

On Apr 13, 2015, at 11:11 AM, Jonathan Lennox <jonathan@v= idyo.com> wrote:


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

On 4/13/15 4:33 AM, Magnus Westerlund wrote:
On 2015-04-10 16:37, Robert Sparks wro= te:
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 ho= p-by-hop header extensions and RTCP SSRC values =97 BUNDLE will need this f= or the mid values.

Should be =93SDES=94 values, sorry.
If SDES is an assumption, it should land in the charter.
I hope it's not an assumption, and that you'll be able to use other tools.<= /div>

Oh, this stupid name collision.

I mean RTCP SDES packets, =93Source Description=94 (as defined in RFC = 3550), not SDP Security Descriptions (RFC 4568).

I think Security Descriptions should absolutely not be used for PERC, = I think it would completely break the security model (barring magical secur= e side-channels).
--_000_849A06BADB744850B7980983FCFC3300vidyocom_-- From nobody Mon Apr 13 09:27:44 2015 Return-Path: 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 99C131ACE05 for ; Mon, 13 Apr 2015 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 eZEYYR_UYFgh for ; Mon, 13 Apr 2015 09:27:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2419B1ACE02 for ; Mon, 13 Apr 2015 09:27:41 -0700 (PDT) Received: from unnumerable.local (mobile-166-173-184-248.mycingular.net [166.173.184.248]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3DGRdvY002868 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Apr 2015 11:27:40 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-184-248.mycingular.net [166.173.184.248] claimed to be unnumerable.local Message-ID: <552BEE75.4010406@nostrum.com> Date: Mon, 13 Apr 2015 11:27:33 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jonathan Lennox References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552BC97E.1000601@alum.mit.edu> <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com> <463392F2-346E-4D03-977B-C7EB1BB74E58@vidyo.com> <552BE3D8.80902@nostrum.com> <849A06BA-DB74-4850-B798-0983FCFC3300@vidyo.com> In-Reply-To: <849A06BA-DB74-4850-B798-0983FCFC3300@vidyo.com> Content-Type: multipart/alternative; boundary="------------010101000906000804010201" Archived-At: Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 16:27:42 -0000 This is a multi-part message in MIME format. --------------010101000906000804010201 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 4/13/15 10:51 AM, Jonathan Lennox wrote: > >> On Apr 13, 2015, at 11:42 AM, Robert Sparks > > wrote: >> >> >> >> On 4/13/15 10:24 AM, Jonathan Lennox wrote: >>> >>>> On Apr 13, 2015, at 11:11 AM, Jonathan Lennox >>> > wrote: >>>> >>>> >>>>> On Apr 13, 2015, at 9:49 AM, Paul Kyzivat >>>> > 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. >>> >>> Should be “SDES” values, sorry. >> If SDES is an assumption, it should land in the charter. >> I hope it's not an assumption, and that you'll be able to use other >> tools. > > Oh, this stupid name collision. > > I mean RTCP SDES packets, “Source Description” (as defined in RFC > 3550), not SDP Security Descriptions (RFC 4568). > > I think Security Descriptions should absolutely not be used for PERC, > I think it would completely break the security model (barring magical > secure side-channels). Good - thanks for the clarification. --------------010101000906000804010201 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 4/13/15 10:51 AM, Jonathan Lennox wrote:

On Apr 13, 2015, at 11:42 AM, Robert Sparks <rjsparks@nostrum.com> wrote:



On 4/13/15 10:24 AM, Jonathan Lennox wrote:

On Apr 13, 2015, at 11:11 AM, Jonathan Lennox <jonathan@vidyo.com> wrote:


On Apr 13, 2015, at 9:49 AM, Paul Kyzivat <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.

Should be “SDES” values, sorry.
If SDES is an assumption, it should land in the charter.
I hope it's not an assumption, and that you'll be able to use other tools.

Oh, this stupid name collision.

I mean RTCP SDES packets, “Source Description” (as defined in RFC 3550), not SDP Security Descriptions (RFC 4568).

I think Security Descriptions should absolutely not be used for PERC, I think it would completely break the security model (barring magical secure side-channels).
Good - thanks for the clarification.

--------------010101000906000804010201-- From nobody Mon Apr 13 14:32:06 2015 Return-Path: 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 4A1A81A8855 for ; Mon, 13 Apr 2015 14:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 sI3AwUAn_FIx for ; Mon, 13 Apr 2015 14:32:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C5CAF1A8848 for ; Mon, 13 Apr 2015 14:32:03 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3DLVxx5091076 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2015 16:32:00 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <552C35CE.8010206@nostrum.com> Date: Mon, 13 Apr 2015 16:31:58 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ben Campbell , Magnus Westerlund References: <55134454.9050302@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DISPATCH list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 21:32:05 -0000 On 4/9/15 16:29, Ben Campbell wrote: > For the record, I'd love to see this get chartered. I think the > charter is on the right track. It might be worth mentioning the drafts > in the charter as "inputs" to the work. > > Is anyone else interested in working on this? We're definitely interested in implementing client functionality to support the requirements outlined in draft-jones-avtcore-private-media-reqts. I am willing to provide feedback on the work and to convey information back from our implementation team as the specifications progress. On 4/10/15 09:37, Robert Sparks wrote: > What is the motivation for declaring any extensions to signalling > systems out of scope? (Not saying I see any that need to be created, > but I'm surprised that it's not something that the group might need to > investigate rather than making that call at chartering time)? I think that the expertise required to make PERC successful is somewhat different than that involved in extending SIP in a sensible fashion. I would prefer this WG talk about the nature of the information that needs to be exchanged in order to make the system work, and then have a separate effort that discusses how to encode it at the signaling layer. I suspect that the majority of this information will be conveyed in SDP for SIP and JSEP, and that the corresponding specification work would take place in MMUSIC. From that perspective, it would probably be good to mention MMUSIC in the "Collaboration" section of the charter. Based on the architecture as proposed in the drafts, there will probably be one or more new interfaces that don't presently exist (e.g. to convey identity information from the key server to the participants). These aren't extensions to "any signaling system used to establish the RTP based conferences," and there aren't existing protocols that clearly handle them (as far as I know). I think the charter should be clear on whether development of protocols for these interfaces are in scope. If they're not, we should at least have some idea of where they *will* be developed. On 4/13/15 08:49, Paul Kyzivat wrote: > I *think* there will be a problem: that a mixer won't be able to > insert the clue capture-id into the RTP/RTCP. One of the really important characteristics of the current proposals is that they allow the MCU (not really a mixer, more of a switcher) to read, add, modify, and remove RTP header extensions. There is a mechanism for end-to-end encryption of some extension headers if the endpoints require that property, but it's optional. /a From nobody Mon Apr 13 17:27:54 2015 Return-Path: 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 8D59E1B2B72 for ; Mon, 13 Apr 2015 17:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 MIdESX8b5HMP for ; Mon, 13 Apr 2015 17:27:50 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689A51B2B70 for ; Mon, 13 Apr 2015 17:27:50 -0700 (PDT) Received: from ppp118-209-112-179.lns20.mel4.internode.on.net ([118.209.112.179]:53077 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YhogY-0004DF-Au for dispatch@ietf.org; Tue, 14 Apr 2015 10:26:38 +1000 Message-ID: <552C5F01.3090207@nteczone.com> Date: Tue, 14 Apr 2015 10:27:45 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> In-Reply-To: <552B7F5C.9060107@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:27:52 -0000 Hello, Please see below [CNG]. Regards, Christian >> What is the motivation for declaring any extensions to signalling >> systems out of scope? (Not saying I see any that need to be created, but >> I'm surprised that it's not something that the group might need to >> investigate rather than making that call at chartering time)? >> > My reasons is to keep this WG focused on what it actually needs to > produce and not get completely tied up in discussion of exactly how one > will integrate this into ones signalling system. So I know people want > this in WebRTC and SIP based conferences. I haven't heard anyone saying > CLUE, but that is likely. These integrations are quite different, > especially in what pieces you will trust when it comes to client > software. Thus, my view was that WG working with signalling systems is > the ones that should provide any necessary integration towards the > framework. [CNG] I don't see CLUE being a lot different from normal SIP based conferences apart from the RTP header issue raised by Paul K. All CLUE is really doing is providing metadata to endpoints to allow them to select media captures more intelligently. If an endpoint is using private media there may be some consideration of "how much" CLUE metadata to provide to a 3rd party switch. > > > I do note that this consideration of integration is mentioned in this > paragraph under Non-Goals: > > "The WG is not chartered to extend any signaling system used to > establish the RTP based conferences. It will however, need to consider > in its architecture how the solution may integrate with these systems." [CNG] I think this is the important thing. Whilst the proposed WG may not actually do extensions, I think its important to consider how PERC will be integrated and this should be documented up front as part of the architecture. I think that will be an aid to further discussions. > > But, I guess one could be more explicit and require the WG to consider > how one integrate into WebRTC, SIP and CLUE so that the framework is > functional for these systems. > > When it comes to the key-management function, I think there exists an > assumption here. That is that signalling and its nodes can't be trusted, > only possible be used as a transport for key-management system > information. But that will require that the communication fails if > someone strips or modify such information. > > Does this help clarify the situation. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Apr 13 17:35:28 2015 Return-Path: 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 614271B2B8B for ; Mon, 13 Apr 2015 17:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2FjuwE4T5YJN for ; Mon, 13 Apr 2015 17:35:26 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338BF1B2B87 for ; Mon, 13 Apr 2015 17:35:26 -0700 (PDT) Received: from ppp118-209-112-179.lns20.mel4.internode.on.net ([118.209.112.179]:53169 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1Yhonu-0005NO-O8 for dispatch@ietf.org; Tue, 14 Apr 2015 10:34:14 +1000 Message-ID: <552C60CA.3000807@nteczone.com> Date: Tue, 14 Apr 2015 10:35:22 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552BC97E.1000601@alum.mit.edu> <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com> In-Reply-To: <9171EFE9-F7E5-4D1D-B00F-B42C4FA9111E@vidyo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:35:27 -0000 Hello Jonathon, On 14/04/2015 1:11 AM, Jonathan Lennox wrote: > >> On Apr 13, 2015, at 9:49 AM, Paul Kyzivat > > 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. [CNG] Is this something we need to address in draft-ietf-clue-rtp-mapping, e.g. the captureID shouldn't be encrypted to facilitate switching? Any CLUE endpoint type may use the CaptureID header extension. I guess we don't want the situation where an endpoint encrypts the captureID and then a middlebox appends another captureID to switched RTP stream. Regards, Christian From nobody Tue Apr 14 07:00:19 2015 Return-Path: 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 A313C1A0277 for ; Tue, 14 Apr 2015 07:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Uo1l9tDHUnOk for ; Tue, 14 Apr 2015 07:00:15 -0700 (PDT) Received: from alum-mailsec-scanner-4.mit.edu (alum-mailsec-scanner-4.mit.edu [18.7.68.15]) by ietfa.amsl.com (Postfix) with ESMTP id 43EC91A00C2 for ; Tue, 14 Apr 2015 07:00:01 -0700 (PDT) X-AuditID: 1207440f-f792a6d000001284-28-552d1d60f01c Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 57.5A.04740.06D1D255; Tue, 14 Apr 2015 10:00:00 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t3EDxxki024733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 14 Apr 2015 10:00:00 -0400 Message-ID: <552D1D5E.1090504@alum.mit.edu> Date: Tue, 14 Apr 2015 09:59:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> In-Reply-To: <552C5F01.3090207@nteczone.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixO6iqJsgqxtqcOWHmsXSSQtYHRg9liz5 yRTAGMVtk5RYUhacmZ6nb5fAnXFk/STmgv1yFfdWdrA0MD6W6GLk5JAQMJFoPvCeEcIWk7hw bz1bFyMXh5DAZUaJlh+HGSGc/0wSrdtPsYBU8QpoS+yY28kMYrMIqEp0d29mArHZBLQk5hz6 D1YjKpAs0fLqFlS9oMTJmU/AbBEBUYn5Kxaxg9jCApESv5/2gdlCAnsZJda0uYHYnAI6El++ /gSbzyxgJjFv80MoW16ieets5gmM/LOQjJ2FpGwWkrIFjMyrGOUSc0pzdXMTM3OKU5N1i5MT 8/JSi3RN9HIzS/RSU0o3MUICkH8HY9d6mUOMAhyMSjy8J3x0QoVYE8uKK3MPMUpyMCmJ8lqy 6YYK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE9wA+U401JrKxKLcqHSUlzsCiJ86ovUfcTEkhP LEnNTk0tSC2CycpwcChJ8J6XBmoULEpNT61Iy8wpQUgzcXCCDOeSEilOzUtJLUosLcmIB8Vk fDEwKkFSPEB7j4C08xYXJOYCRSFaTzEqSolDJARAEhmleXBjYWnlFaM40JfCvL9BqniAKQmu +xXQYCagwVkqWiCDSxIRUlINjOFCcXvf3e7+x/1YPbEyaGvSDYtv5s4yp22N/q7+YaJ6U86y 43pV7IOX13VKnqjNnhax6JTuvkQ56cqmhe0Z33YyBDmHxrvmd/QWTy+X+ORVF3f8eLPll6V3 HV8YVS/6Yuh9eMJ95aAwDc7r5jPvd3va+LzZkzZVzjFX9oM6u5FZrP1UlpocJZbijERDLeai 4kQATzo63wYDAAA= Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:00:17 -0000 On 4/13/15 8:27 PM, Christian Groves wrote: > Hello, > > Please see below [CNG]. > > Regards, Christian >>> What is the motivation for declaring any extensions to signalling >>> systems out of scope? (Not saying I see any that need to be created, but >>> I'm surprised that it's not something that the group might need to >>> investigate rather than making that call at chartering time)? >>> >> My reasons is to keep this WG focused on what it actually needs to >> produce and not get completely tied up in discussion of exactly how one >> will integrate this into ones signalling system. So I know people want >> this in WebRTC and SIP based conferences. I haven't heard anyone saying >> CLUE, but that is likely. These integrations are quite different, >> especially in what pieces you will trust when it comes to client >> software. Thus, my view was that WG working with signalling systems is >> the ones that should provide any necessary integration towards the >> framework. > [CNG] I don't see CLUE being a lot different from normal SIP based > conferences apart from the RTP header issue raised by Paul K. All CLUE > is really doing is providing metadata to endpoints to allow them to > select media captures more intelligently. If an endpoint is using > private media there may be some consideration of "how much" CLUE > metadata to provide to a 3rd party switch. You highlight an interesting point. If the goal is for the participants to conference without trusting the intermediary that does the "switching", then they may also not trust that intermediary to see the clue metadata that describes the media and the participants. There might need to be a way for the advertisements by the endpoints to be encrypted, so that the intermediary can only collect them and pass them on to the other endpoints. Thanks, Paul >> I do note that this consideration of integration is mentioned in this >> paragraph under Non-Goals: >> >> "The WG is not chartered to extend any signaling system used to >> establish the RTP based conferences. It will however, need to consider >> in its architecture how the solution may integrate with these systems." > [CNG] I think this is the important thing. Whilst the proposed WG may > not actually do extensions, I think its important to consider how PERC > will be integrated and this should be documented up front as part of the > architecture. I think that will be an aid to further discussions. > >> >> But, I guess one could be more explicit and require the WG to consider >> how one integrate into WebRTC, SIP and CLUE so that the framework is >> functional for these systems. >> >> When it comes to the key-management function, I think there exists an >> assumption here. That is that signalling and its nodes can't be trusted, >> only possible be used as a transport for key-management system >> information. But that will require that the communication fails if >> someone strips or modify such information. >> >> Does this help clarify the situation. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Apr 14 13:05:44 2015 Return-Path: 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 E404C1AD067 for ; Tue, 14 Apr 2015 13:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 t3ukQGhFYeQk for ; Tue, 14 Apr 2015 13:05:35 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 142701AD06F for ; Tue, 14 Apr 2015 13:05:35 -0700 (PDT) Received: from [192.168.1.20] (cpe-98-27-48-15.nc.res.rr.com [98.27.48.15]) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t3EK5UGK004774 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2015 16:05:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1429041931; bh=Wb2jCDOkQHRODznxzqrI1RgFePewAMJqsQLXOB+mHzs=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=ajsOckPncmZtVemZPfhnWS0BNeF0jxLyaR1QhzdSU/se27UPuMVdoxtqwqD5evIu6 jZ+mMw7+0Bp3GFDnPOsizE3cdQYvLcXfPF42mLspZlRSrmWJ+rFu9hYO3APSIcqyGu crfgINsZo0LzIOYE8WRKOYNqqbDqPrWnn3O2B9L4= From: "Paul E. Jones" To: "Ben Campbell" , "Magnus Westerlund" Date: Tue, 14 Apr 2015 20:05:35 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.21372.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: DISPATCH list 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 Reply-To: "Paul E. Jones" List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 20:05:43 -0000 Ben, It perhaps goes without saying that I'm interested in working on this. Paul ------ Original Message ------ From: "Ben Campbell" To: "Magnus Westerlund" Cc: "DISPATCH list" Sent: 4/9/2015 5:29:03 PM Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP=20 Conferencing (PERC) >For the record, I'd love to see this get chartered. I think the charter= =20 >is on the right track. It might be worth mentioning the drafts in the=20 >charter as "inputs" to the work. > >Is anyone else interested in working on this? > >/Ben > >On 25 Mar 2015, at 18:27, Magnus Westerlund wrote: > >>Dispatch, >> >>AVTCORE WG has discussed a couple of proposals that discusses=20 >>end-to-end >>security in centralized RTP based conferences. >> >>Drafts for these Proposals: >>https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ >>https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framew= ork/ >>https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ >> >>In these discussions one has reached the conclusion that this work >>requires its own venue to continue the work. Therefore a number of >>interested has put together a initial draft charter for a new WG. >> >>Please review and provide feedback. >> >> >>Name: Privacy Enhanced RTP Conferencing (PERC) >>Area: ART >>Chairs: TBD >>Mailing List: >> >>Motivation for new WG >>--------------------- >> >>RTP-based real-time multi-party interactive media conferencing is=20 >>today >>in widespread use. Many of the deployments uses one or more centrally >>located media distribution devices that perform selective forwarding=20 >>or >>mixes media streams received from the participating endpoints. The=20 >>media >>transport protocol commonly used is RTP (RFC3550). There are various >>signaling systems used to establish these multi-party conferences. >> >>These conferences require security to ensure that the RTP media and >>related meta data of the conference is kept private to the set of >>invited participants and only other devices trusted by those >>participants with their media. At the same time, multi-party media >>conferences do need source authentication and integrity checks to >>protect against modifications, insertions or replay attacks. Media >>distribution devices supporting these conferences may also perform RTP >>header changes and often consume and create RTCP messages for=20 >>efficient >>media handling. >> >>To date, deployment models for these multi-party media distribution >>devices do not enable them to perform their functions without having >>keys to decrypt the participants=E2=80=99 media, primarily using Secure= RTP >>(RFC3711) to provide session security. >> >>A new architecture model and related specifications is needed, with a >>focused effort from the RTP and Security communities. >> >>WG Objectives >>------------- >> >>This WG will work on a solution that enables centralized SRTP based >>conferencing where the central device distributing the media is not >>required to be trusted with the keys to decrypt the participant=E2=80=99= s=20 >>media. >>The media must be kept confidential and authenticated between an >>originating endpoint and the explicitly allowed receiving endpoints or >>other devices. Further it is desired that a solution still provide >>replay protection so that the media distribution devices can=E2=80=99t= replay >>previous parts of the media. >> >>The solution must also provide security for each hop between endpoints >>and multi-party media distribution devices and between multi-party=20 >>media >>distribution devices. The RTCP messages and RTP header extensions >>required for the media distribution device to perform the selective >>media forwarding may require both source authentication and integrity=20 >>as >>well as confidentiality. The solution may also consider providing >>end-to-end security for a subset of the RTCP messages or header=20 >>extensions. >> >>The solution should be usable from both SIP and WebRTC endpoints that >>implement the extension defined by this WG. >> >>This WG will perform the following work: >> >>1. Define a general architecture and RTP topology(s) that enables >> end-to-end media security for multi-party RTP conferencing. >> >>2. Define the trust model and describe the resulting security >> properties. >> >>3. Specify any necessary extensions to SRTP. >> >>4. Define a Key Management Function that distributes the keys. The >> system needs to be able to bind the media to the sender of the >> media=E2=80=99s identity and/or the identity of the conference. >> >>Collaboration >>------------- >> >>If there is identification of missing protocols or functionalities,=20 >>such >>work can be requested to be done in another working group with a >>suitable charter or by requests for chartering it in this WG or=20 >>another >>WG. Potential work that might require work in other WGs are DTLS >>extensions (TLS) as well as RTP header extensions (AVTEXT). This >>requires strong collaboration with the security area. We will notify >>SIPREC, W3C WebRTC, AVTCore, and other related groups about this work. >> >>Non-Goals >>--------- >> >>The WG is not chartered to extend any signaling system used to=20 >>establish >>the RTP based conferences. It will however, need to consider in its >>architecture how the solution may integrate with these systems. >> >>Will not consider non-real-time usages, multicast based media >>distribution, or Security descriptions-based keying. >> >>Goals and Milestones >>-------------------- >> >>TBD Submit architecture or framework specification to IESG (Standards >>Track) >> >>TBD Submit protocol specification(s) to IESG (Standards Track) >> >> >> >> >>Cheers >> >>Magnus Westerlund >>(AVTCORE WG chair) >> >> >>---------------------------------------------------------------------- >>Services, Media and Network features, Ericsson Research EAB/TXM >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 10 7148287 >>F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>---------------------------------------------------------------------- >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Apr 14 16:12:18 2015 Return-Path: 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 1085E1B3057 for ; Tue, 14 Apr 2015 16:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 taOKTG9h6dx1 for ; Tue, 14 Apr 2015 16:12:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809591B3056 for ; Tue, 14 Apr 2015 16:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6946; q=dns/txt; s=iport; t=1429053134; x=1430262734; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=RGH8aFNvEwbqg2ExrntKgDDscN2nY9pAHOrvXBdg/1s=; b=WV4FhH+ks0BsE2xqxtE9Armg8fNTmQblBTZCausF8d0VjQHVUAYkhdhT LDAmnx4WHtClvJyz+mmAxBpC+6DQVn5rBu1FuCfWzAsL7FBRcxFACGQhH k/2mAkzQ+GEZEYfG3VWUNGquRPvnSlwU4rNAal8dWDP1m41Jx8kGhOlPl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AcBQAmni1V/4cNJK1TCYMMUlwFxzkMhTFOAoFETAEBAQEBAX6EHwEBAQMBAQEBNy4GEAkEAQgRAQIBAgEKFAkiDAsUAwYJAQQBEggTiAcIDcpDAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEiyeEICsGOIMRgRYFhiaKaIN5hzWDN5AYIoNvb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,578,1422921600"; d="scan'208";a="408754207" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-1.cisco.com with ESMTP; 14 Apr 2015 23:12:12 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3ENCCcn032401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 23:12:12 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.214]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 14 Apr 2015 18:12:12 -0500 From: "David Benham (dbenham)" To: "dispatch@ietf.org" , "ben@nostrum.com" Thread-Topic: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC) Thread-Index: AdB3CIWIxzHYODvwQv+pmhwOwoSRPw== Date: Tue, 14 Apr 2015 23:12:11 +0000 Message-ID: <0683D6CB32AC424D8AF52C0F660E5DC56B984445@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.132.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 23:12:17 -0000 > Date: Thu, 09 Apr 2015 16:29:03 -0500 > From: "Ben Campbell" > To: "Magnus Westerlund" > Cc: DISPATCH list > Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP > Conferencing (PERC) > Message-ID: > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > For the record, I'd love to see this get chartered. I think the charter > is on the right track. It might be worth mentioning the drafts in the > charter as "inputs" to the work. >=20 > Is anyone else interested in working on this? Yes, fully behind this! David Benham > /Ben >=20 > On 25 Mar 2015, at 18:27, Magnus Westerlund wrote: >=20 > > Dispatch, > > > > AVTCORE WG has discussed a couple of proposals that discusses > > end-to-end > > security in centralized RTP based conferences. > > > > Drafts for these Proposals: > > https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqt= s/ > > https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media- > framework/ > > https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ > > > > In these discussions one has reached the conclusion that this work > > requires its own venue to continue the work. Therefore a number of > > interested has put together a initial draft charter for a new WG. > > > > Please review and provide feedback. > > > > > > Name: Privacy Enhanced RTP Conferencing (PERC) > > Area: ART > > Chairs: TBD > > Mailing List: > > > > Motivation for new WG > > --------------------- > > > > RTP-based real-time multi-party interactive media conferencing is > > today > > in widespread use. Many of the deployments uses one or more centrally > > located media distribution devices that perform selective forwarding > > or > > mixes media streams received from the participating endpoints. The > > media > > transport protocol commonly used is RTP (RFC3550). There are various > > signaling systems used to establish these multi-party conferences. > > > > These conferences require security to ensure that the RTP media and > > related meta data of the conference is kept private to the set of > > invited participants and only other devices trusted by those > > participants with their media. At the same time, multi-party media > > conferences do need source authentication and integrity checks to > > protect against modifications, insertions or replay attacks. Media > > distribution devices supporting these conferences may also perform RTP > > header changes and often consume and create RTCP messages for > > efficient > > media handling. > > > > To date, deployment models for these multi-party media distribution > > devices do not enable them to perform their functions without having > > keys to decrypt the participants? media, primarily using Secure RTP > > (RFC3711) to provide session security. > > > > A new architecture model and related specifications is needed, with a > > focused effort from the RTP and Security communities. > > > > WG Objectives > > ------------- > > > > This WG will work on a solution that enables centralized SRTP based > > conferencing where the central device distributing the media is not > > required to be trusted with the keys to decrypt the participant?s > > media. > > The media must be kept confidential and authenticated between an > > originating endpoint and the explicitly allowed receiving endpoints or > > other devices. Further it is desired that a solution still provide > > replay protection so that the media distribution devices can?t > > replay > > previous parts of the media. > > > > The solution must also provide security for each hop between endpoints > > and multi-party media distribution devices and between multi-party > > media > > distribution devices. The RTCP messages and RTP header extensions > > required for the media distribution device to perform the selective > > media forwarding may require both source authentication and integrity > > as > > well as confidentiality. The solution may also consider providing > > end-to-end security for a subset of the RTCP messages or header > > extensions. > > > > The solution should be usable from both SIP and WebRTC endpoints that > > implement the extension defined by this WG. > > > > This WG will perform the following work: > > > > 1. Define a general architecture and RTP topology(s) that enables > > end-to-end media security for multi-party RTP conferencing. > > > > 2. Define the trust model and describe the resulting security > > properties. > > > > 3. Specify any necessary extensions to SRTP. > > > > 4. Define a Key Management Function that distributes the keys. The > > system needs to be able to bind the media to the sender of the > > media?s identity and/or the identity of the conference. > > > > Collaboration > > ------------- > > > > If there is identification of missing protocols or functionalities, > > such > > work can be requested to be done in another working group with a > > suitable charter or by requests for chartering it in this WG or > > another > > WG. Potential work that might require work in other WGs are DTLS > > extensions (TLS) as well as RTP header extensions (AVTEXT). This > > requires strong collaboration with the security area. We will notify > > SIPREC, W3C WebRTC, AVTCore, and other related groups about this work. > > > > Non-Goals > > --------- > > > > The WG is not chartered to extend any signaling system used to > > establish > > the RTP based conferences. It will however, need to consider in its > > architecture how the solution may integrate with these systems. > > > > Will not consider non-real-time usages, multicast based media > > distribution, or Security descriptions-based keying. > > > > Goals and Milestones > > -------------------- > > > > TBD Submit architecture or framework specification to IESG (Standards > > Track) > > > > TBD Submit protocol specification(s) to IESG (Standards Track) > > > > > > > > > > Cheers > > > > Magnus Westerlund > > (AVTCORE WG chair) > > > > > > ---------------------------------------------------------------------- > > Services, Media and Network features, Ericsson Research EAB/TXM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F?r?gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Apr 16 11:02:46 2015 Return-Path: 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 42F321B341B for ; Thu, 16 Apr 2015 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Prd1toJ3DZRS for ; Thu, 16 Apr 2015 11:02:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B732F1B341A for ; Thu, 16 Apr 2015 11:02:43 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3GI2dlv062131 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2015 13:02:40 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <552FF93F.4000107@nostrum.com> Date: Thu, 16 Apr 2015 13:02:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Kyzivat , dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> In-Reply-To: <552D1D5E.1090504@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:02:45 -0000 On 4/14/15 08:59, Paul Kyzivat wrote: > On 4/13/15 8:27 PM, Christian Groves wrote: >> Hello, >> >> Please see below [CNG]. >> >> Regards, Christian >>>> What is the motivation for declaring any extensions to signalling >>>> systems out of scope? (Not saying I see any that need to be >>>> created, but >>>> I'm surprised that it's not something that the group might need to >>>> investigate rather than making that call at chartering time)? >>>> >>> My reasons is to keep this WG focused on what it actually needs to >>> produce and not get completely tied up in discussion of exactly how one >>> will integrate this into ones signalling system. So I know people want >>> this in WebRTC and SIP based conferences. I haven't heard anyone saying >>> CLUE, but that is likely. These integrations are quite different, >>> especially in what pieces you will trust when it comes to client >>> software. Thus, my view was that WG working with signalling systems is >>> the ones that should provide any necessary integration towards the >>> framework. >> [CNG] I don't see CLUE being a lot different from normal SIP based >> conferences apart from the RTP header issue raised by Paul K. All CLUE >> is really doing is providing metadata to endpoints to allow them to >> select media captures more intelligently. If an endpoint is using >> private media there may be some consideration of "how much" CLUE >> metadata to provide to a 3rd party switch. > > You highlight an interesting point. > > If the goal is for the participants to conference without trusting the > intermediary that does the "switching", then they may also not trust > that intermediary to see the clue metadata that describes the media > and the participants. There might need to be a way for the > advertisements by the endpoints to be encrypted, so that the > intermediary can only collect them and pass them on to the other > endpoints. These are sent in RTP header extensions, right? RFC6904 lets you encrypt selected header extensions end-to-end. In the current PERC proposals, anything encrypted with RFC6904 would be visible to the participants, but not to the MCU. /a From nobody Thu Apr 16 11:24:03 2015 Return-Path: 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 568A61B3428 for ; Thu, 16 Apr 2015 11:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 HacuX_JBe251 for ; Thu, 16 Apr 2015 11:24:01 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346901B3410 for ; Thu, 16 Apr 2015 11:24:01 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-04v.sys.comcast.net with comcast id GiMW1q0042S2Q5R01iQ0l2; Thu, 16 Apr 2015 18:24:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-16v.sys.comcast.net with comcast id GiPw1q00Q3Ge9ey01iPzrG; Thu, 16 Apr 2015 18:24:00 +0000 Message-ID: <552FFE3C.80104@alum.mit.edu> Date: Thu, 16 Apr 2015 14:23:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Adam Roach , dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> In-Reply-To: <552FF93F.4000107@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429208640; bh=01HuHJe3rkC2WUR6aoe4xbapF6UWaUXHf3J6ChcI9II=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oD0scw8BuFv9DMArBLJJk4OjGDkjClOWyxetv1NTyC2YFfL4H1z/R8wd5d7G0HR9+ TL7tje7ND3+rEkVg1eSXl2x7KqEgxW0EYE2xpHoxJSW1Y1ehE106comUQj+gOHc4RO Ge8lC6mhoNwJEb/jQnyOrTd0tGXGRJBUXbvkjtto/zW1SWbWOEx44P2XddWEo5FWzW 5xEp7FrHyp7vnM5gVptFyi3X0KNkh2gg1czVdJbRdcTIg6tGJ7T7yGXHvlJ5Q0FsvJ yfwEM6e5+IsBawDwfdcZZFIgNDyt+OG1Y1O0GJmVw8/QgJS8ZqAPXDkECOhRXjjYUi 9O+6+7E29CxaQ== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:24:02 -0000 On 4/16/15 2:02 PM, Adam Roach wrote: > On 4/14/15 08:59, Paul Kyzivat wrote: >> On 4/13/15 8:27 PM, Christian Groves wrote: >>> Hello, >>> >>> Please see below [CNG]. >>> >>> Regards, Christian >>>>> What is the motivation for declaring any extensions to signalling >>>>> systems out of scope? (Not saying I see any that need to be >>>>> created, but >>>>> I'm surprised that it's not something that the group might need to >>>>> investigate rather than making that call at chartering time)? >>>>> >>>> My reasons is to keep this WG focused on what it actually needs to >>>> produce and not get completely tied up in discussion of exactly how one >>>> will integrate this into ones signalling system. So I know people want >>>> this in WebRTC and SIP based conferences. I haven't heard anyone saying >>>> CLUE, but that is likely. These integrations are quite different, >>>> especially in what pieces you will trust when it comes to client >>>> software. Thus, my view was that WG working with signalling systems is >>>> the ones that should provide any necessary integration towards the >>>> framework. >>> [CNG] I don't see CLUE being a lot different from normal SIP based >>> conferences apart from the RTP header issue raised by Paul K. All CLUE >>> is really doing is providing metadata to endpoints to allow them to >>> select media captures more intelligently. If an endpoint is using >>> private media there may be some consideration of "how much" CLUE >>> metadata to provide to a 3rd party switch. >> >> You highlight an interesting point. >> >> If the goal is for the participants to conference without trusting the >> intermediary that does the "switching", then they may also not trust >> that intermediary to see the clue metadata that describes the media >> and the participants. There might need to be a way for the >> advertisements by the endpoints to be encrypted, so that the >> intermediary can only collect them and pass them on to the other >> endpoints. > > > These are sent in RTP header extensions, right? RFC6904 lets you encrypt > selected header extensions end-to-end. In the current PERC proposals, > anything encrypted with RFC6904 would be visible to the participants, > but not to the MCU. No. The advertisements are send over a data channel. In a conference usage, they (and the RTP media) are sent to the mixer. Then the mixer can consolidate the advertisements it has received, and the corresponding media, in any manner it wants. The consolidated advertisements are sent out to the participants. The mixer needs to respond to the advertisements. Doing so it indicates which media it wants to receive, which will affect what media it can offer. Superficially it is hard to conceive of how a mixer could do its job without being able to decode the advertisements it receives. One possibility for a mixer is to "pass through" a merge of all the advertisements it receives to all the other participants - effectively treating them as blobs that are combined together. *In principle* it might be possible for the mixer to do this without being able to read the substance of those advertisements. But that would certainly require some major redesign of the CLUE mechanisms. And even then it wouldn't work for more common usages such as where the mixer is making the decisions about switching sources based on voice activity. Thanks, Paul From nobody Thu Apr 16 11:29:32 2015 Return-Path: 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 E070D1B2F0D for ; Thu, 16 Apr 2015 11:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 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] 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 l5vzgwlZPFzS for ; Thu, 16 Apr 2015 11:29:19 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 6944D1B3434 for ; Thu, 16 Apr 2015 11:29:18 -0700 (PDT) Received: by wgin8 with SMTP id n8so89963322wgi.0 for ; Thu, 16 Apr 2015 11:29:17 -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:from:date :message-id:subject:to:cc:content-type; bh=YzicK/tp1gzUes2B8VhhtpWaK8EGILVkf8n9w6HU0sA=; b=Qra2a5e8QqJ3GZaHHBkjrfT95mEYa2PzeJM36P+u4vyxy4m9MYSA1eimlf9HZOksos gttYkTIii9IPnx/1TFpWdbNJWR5NirnMNG2BXCPdPCtEb78bBCwK6i+FzypiiOssUeT7 WSv4Um+vg5ctDG2148i28WVB4pYUbvV0BjQzVIg9oYbfvIW9cLtM0mQDUE6rVW9ezusF IZm5oikIuQHk2NVWJfuBMJ+uGe8DWq58qM4bQD1xowNkBb6tjvPWyZhULT9Ya1UvG5DL X9SRk9pYsUyIaJBdNTZXK6axaqEaqGfuIcVUFSxha/9+ip6Cy+ja8ZzXxY0EHk2Lq9Yd p8Zw== X-Gm-Message-State: ALoCoQmFrrnY9zzUz+1VSosgSSgZ6jbjxk0ykXRwmS3+/nRArrQZR21RFQWPGi3LzdssbF/z28T0 X-Received: by 10.180.99.39 with SMTP id en7mr7655834wib.31.1429208957160; Thu, 16 Apr 2015 11:29:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.205.87 with HTTP; Thu, 16 Apr 2015 11:28:36 -0700 (PDT) In-Reply-To: <552FFE3C.80104@alum.mit.edu> References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> <552FFE3C.80104@alum.mit.edu> From: Eric Rescorla Date: Thu, 16 Apr 2015 11:28:36 -0700 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d0418280833a5620513dba45b Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:29:25 -0000 --f46d0418280833a5620513dba45b Content-Type: text/plain; charset=UTF-8 I'm still trying to wrap my head around this problem, but in a general case, it may not be possible for PERC to support every possible advanced conferencing feature and that's OK. Security without any compromises is rare. And since I haven't said this already: I'm in favor of this effort. -Ekr On Thu, Apr 16, 2015 at 11:23 AM, Paul Kyzivat wrote: > On 4/16/15 2:02 PM, Adam Roach wrote: > >> On 4/14/15 08:59, Paul Kyzivat wrote: >> >>> On 4/13/15 8:27 PM, Christian Groves wrote: >>> >>>> Hello, >>>> >>>> Please see below [CNG]. >>>> >>>> Regards, Christian >>>> >>>>> What is the motivation for declaring any extensions to signalling >>>>>> systems out of scope? (Not saying I see any that need to be >>>>>> created, but >>>>>> I'm surprised that it's not something that the group might need to >>>>>> investigate rather than making that call at chartering time)? >>>>>> >>>>>> My reasons is to keep this WG focused on what it actually needs to >>>>> produce and not get completely tied up in discussion of exactly how one >>>>> will integrate this into ones signalling system. So I know people want >>>>> this in WebRTC and SIP based conferences. I haven't heard anyone saying >>>>> CLUE, but that is likely. These integrations are quite different, >>>>> especially in what pieces you will trust when it comes to client >>>>> software. Thus, my view was that WG working with signalling systems is >>>>> the ones that should provide any necessary integration towards the >>>>> framework. >>>>> >>>> [CNG] I don't see CLUE being a lot different from normal SIP based >>>> conferences apart from the RTP header issue raised by Paul K. All CLUE >>>> is really doing is providing metadata to endpoints to allow them to >>>> select media captures more intelligently. If an endpoint is using >>>> private media there may be some consideration of "how much" CLUE >>>> metadata to provide to a 3rd party switch. >>>> >>> >>> You highlight an interesting point. >>> >>> If the goal is for the participants to conference without trusting the >>> intermediary that does the "switching", then they may also not trust >>> that intermediary to see the clue metadata that describes the media >>> and the participants. There might need to be a way for the >>> advertisements by the endpoints to be encrypted, so that the >>> intermediary can only collect them and pass them on to the other >>> endpoints. >>> >> >> >> These are sent in RTP header extensions, right? RFC6904 lets you encrypt >> selected header extensions end-to-end. In the current PERC proposals, >> anything encrypted with RFC6904 would be visible to the participants, >> but not to the MCU. >> > > No. The advertisements are send over a data channel. In a conference > usage, they (and the RTP media) are sent to the mixer. Then the mixer can > consolidate the advertisements it has received, and the corresponding > media, in any manner it wants. The consolidated advertisements are sent out > to the participants. > > The mixer needs to respond to the advertisements. Doing so it indicates > which media it wants to receive, which will affect what media it can offer. > Superficially it is hard to conceive of how a mixer could do its job > without being able to decode the advertisements it receives. > > One possibility for a mixer is to "pass through" a merge of all the > advertisements it receives to all the other participants - effectively > treating them as blobs that are combined together. *In principle* it might > be possible for the mixer to do this without being able to read the > substance of those advertisements. > > But that would certainly require some major redesign of the CLUE > mechanisms. And even then it wouldn't work for more common usages such as > where the mixer is making the decisions about switching sources based on > voice activity. > > Thanks, > Paul > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d0418280833a5620513dba45b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm still trying to wrap my head around this problem, = but in a general case,
it may not be possible for PERC to support every= possible advanced conferencing
feature and that's OK. Securi= ty without any compromises is rare.

And since I ha= ven't said this already: I'm in favor of this effort.
-Ekr


<= div class=3D"gmail_quote">On Thu, Apr 16, 2015 at 11:23 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 4/16/15 2:02 PM, Adam Roa= ch wrote:
On 4/14/15 08:59, Paul Kyzivat wrote:
On 4/13/15 8:27 PM, Christian Groves wrote:
Hello,

Please see below [CNG].

Regards, Christian
What is the motivation for declaring any extensions to signalling
systems out of scope? (Not saying I see any that need to be
created, but
I'm surprised that it's not something that the group might need to<= br> investigate rather than making that call at chartering time)?

My reasons is to keep this WG focused on what it actually needs to
produce and not get completely tied up in discussion of exactly how one
will integrate this into ones signalling system. So I know people want
this in WebRTC and SIP based conferences. I haven't heard anyone saying=
CLUE, but that is likely. These integrations are quite different,
especially in what pieces you will trust when it comes to client
software. Thus, my view was that WG working with signalling systems is
the ones that should provide any necessary integration towards the
framework.
[CNG] I don't see CLUE being a lot different from normal SIP based
conferences apart from the RTP header issue raised by Paul K. All CLUE
is really doing is providing metadata to endpoints to allow them to
select media captures more intelligently. If an endpoint is using
private media there may be some consideration of "how much" CLUE<= br> metadata to provide to a 3rd party switch.

You highlight an interesting point.

If the goal is for the participants to conference without trusting the
intermediary that does the "switching", then they may also not tr= ust
that intermediary to see the clue metadata that describes the media
and the participants. There might need to be a way for the
advertisements by the endpoints to be encrypted, so that the
intermediary can only collect them and pass them on to the other
endpoints.


These are sent in RTP header extensions, right? RFC6904 lets you encrypt selected header extensions end-to-end. In the current PERC proposals,
anything encrypted with RFC6904 would be visible to the participants,
but not to the MCU.

No. The advertisements are send over a data channel. In a conference usage,= they (and the RTP media) are sent to the mixer. Then the mixer can consoli= date the advertisements it has received, and the corresponding media, in an= y manner it wants. The consolidated advertisements are sent out to the part= icipants.

The mixer needs to respond to the advertisements. Doing so it indicates whi= ch media it wants to receive, which will affect what media it can offer. Su= perficially it is hard to conceive of how a mixer could do its job without = being able to decode the advertisements it receives.

One possibility for a mixer is to "pass through" a merge of all t= he advertisements it receives to all the other participants - effectively t= reating them as blobs that are combined together. *In principle* it might b= e possible for the mixer to do this without being able to read the substanc= e of those advertisements.

But that would certainly require some major redesign of the CLUE mechanisms= . And even then it wouldn't work for more common usages such as where t= he mixer is making the decisions about switching sources based on voice act= ivity.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--f46d0418280833a5620513dba45b-- From nobody Thu Apr 16 11:29:56 2015 Return-Path: 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 DE02F1B3437 for ; Thu, 16 Apr 2015 11:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PiXcWBSKT8FV for ; Thu, 16 Apr 2015 11:29:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8E2811B3434 for ; Thu, 16 Apr 2015 11:29:42 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3GITcIR064392 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2015 13:29:40 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <552FFF92.9040709@nostrum.com> Date: Thu, 16 Apr 2015 13:29:38 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Paul Kyzivat , dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> <552FFE3C.80104@alum.mit.edu> In-Reply-To: <552FFE3C.80104@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:29:56 -0000 On 4/16/15 13:23, Paul Kyzivat wrote: > The advertisements are send over a data channel. Is this like a "data channel" in the same sense that WebRTC uses that term? If so, I think there are some good ways to handle this in line with PERC's goals (there are reasonable ways to ensure that the data channels terminate at the trusted key management node rather than the mixer). /a From nobody Thu Apr 16 11:59:48 2015 Return-Path: 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 978DD1B34B5 for ; Thu, 16 Apr 2015 11:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 Si5Jmw6kPCvC for ; Thu, 16 Apr 2015 11:59:42 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7AF1B34B4 for ; Thu, 16 Apr 2015 11:59:42 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-01v.sys.comcast.net with comcast id Gizd1q0012XD5SV01izhPx; Thu, 16 Apr 2015 18:59:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-20v.sys.comcast.net with comcast id Gizh1q00A3Ge9ey01izhPW; Thu, 16 Apr 2015 18:59:41 +0000 Message-ID: <5530069C.3040008@alum.mit.edu> Date: Thu, 16 Apr 2015 14:59:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Adam Roach , dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> <552FFE3C.80104@alum.mit.edu> <552FFF92.9040709@nostrum.com> In-Reply-To: <552FFF92.9040709@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429210781; bh=fqLo+s1lx6Al0e9RmVuBp28XM/R1blivyosQZjLB60M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ixebC8P7MkvWeBZCN+63I65aDgnkYeNIcRIQxG8HXhKSYQD7eqKPBMVTjfyscC1+X wHkhKztfDhUiJ1MZaegGZ89UbTvhhc+AXvDqT9Wap2a7zeaTDgYFl4oJnQHWtWCYlD brrVYkBEVRAartbo5PYtuMHXwqECch1kZY61jaEdF6+D5xNwucQm2WOgpO1udMzxSB OrfjMYWYmJnSIIbBQijEOdRNgauFGgTETyL/8E3rhUP6pWRBOgV+RYXRzhToZfI++4 FDTDmHWwz7w+f0rX4Q7za6UTy+yCrkswrG0QOIbV23Rd/CJJ3Xlnojvv16AuR8/KrR rbCSPJCfM0rzw== Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:59:43 -0000 On 4/16/15 2:29 PM, Adam Roach wrote: > On 4/16/15 13:23, Paul Kyzivat wrote: >> The advertisements are send over a data channel. > > Is this like a "data channel" in the same sense that WebRTC uses that > term? Yes. Chosen in order to facilitate the possibility of WebRTC clients for CLUE. > If so, I think there are some good ways to handle this in line > with PERC's goals (there are reasonable ways to ensure that the data > channels terminate at the trusted key management node rather than the > mixer). I fear we are talking past one another. Conceivably it would be possible to separate the signaling logic of clue from the media mixing logic, so that there could be a *trusted* entity that manages the keys and also does the mixing of clue advertisements, but that offloads the actual media "mixing" (switching in this case) to an untrusted media box. But it will require some careful thought, and probably changes to clue. I guess that would be a CLUEv2, and we shouldn't get too hung up on it right now. Thanks, Paul From nobody Thu Apr 16 12:00:51 2015 Return-Path: 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 2547C1B3528 for ; Thu, 16 Apr 2015 12:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 cH6H44br17t3 for ; Thu, 16 Apr 2015 12:00:48 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831C31B34FF for ; Thu, 16 Apr 2015 12:00:33 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-07v.sys.comcast.net with comcast id GizJ1q0092XD5SV01j0YJ1; Thu, 16 Apr 2015 19:00:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-20v.sys.comcast.net with comcast id Gj0W1q00S3Ge9ey01j0XXK; Thu, 16 Apr 2015 19:00:32 +0000 Message-ID: <553006CE.8080009@alum.mit.edu> Date: Thu, 16 Apr 2015 15:00:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Eric Rescorla References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> <552FFE3C.80104@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429210832; bh=yYhHFVQN7kAzX8oR5a1zCiSIYh4L5AqsJSs04OqhPEY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=suSYY5DXL3YSRA6NysgWKMrrXfCJWNfKdxFM+OLvkgTKOwYJwFrZoTVRo7M91g7jq tDm4wuzEA5UxaKu5DNZuIM5hOkLJk1oYp7Z6Zi2TP1hbgcTcx2pUCjx33qV8KrI3VB LrRbKxt8zjXjB+DUBHIKn/xQ4AY3GvRqB6ugNL06T29V4XHH9cZTXWS3hD2Wi0A5+a L0QZ77Xtxem7cshB75FwcA2qLyyCJnlmfsNykYcsqrZXDrvV8gpcKPNuIN0GQQOjTP XYnyzkWGNb0rtUw3coP1ykiSbs0s8Gw7Dee6P94HEX3NPMHxxivuiRvy60vujDbLHX IQBTVLNsntPgg== Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 19:00:50 -0000 On 4/16/15 2:28 PM, Eric Rescorla wrote: > I'm still trying to wrap my head around this problem, but in a general case, > it may not be possible for PERC to support every possible advanced > conferencing > feature and that's OK. Security without any compromises is rare. I agree. Thanks, Paul > And since I haven't said this already: I'm in favor of this effort. > > -Ekr > > > On Thu, Apr 16, 2015 at 11:23 AM, Paul Kyzivat > wrote: > > On 4/16/15 2:02 PM, Adam Roach wrote: > > On 4/14/15 08:59, Paul Kyzivat wrote: > > On 4/13/15 8:27 PM, Christian Groves wrote: > > Hello, > > Please see below [CNG]. > > Regards, Christian > > What is the motivation for declaring any > extensions to signalling > systems out of scope? (Not saying I see any that > need to be > created, but > I'm surprised that it's not something that the > group might need to > investigate rather than making that call at > chartering time)? > > My reasons is to keep this WG focused on what it > actually needs to > produce and not get completely tied up in discussion > of exactly how one > will integrate this into ones signalling system. So > I know people want > this in WebRTC and SIP based conferences. I haven't > heard anyone saying > CLUE, but that is likely. These integrations are > quite different, > especially in what pieces you will trust when it > comes to client > software. Thus, my view was that WG working with > signalling systems is > the ones that should provide any necessary > integration towards the > framework. > > [CNG] I don't see CLUE being a lot different from normal > SIP based > conferences apart from the RTP header issue raised by > Paul K. All CLUE > is really doing is providing metadata to endpoints to > allow them to > select media captures more intelligently. If an endpoint > is using > private media there may be some consideration of "how > much" CLUE > metadata to provide to a 3rd party switch. > > > You highlight an interesting point. > > If the goal is for the participants to conference without > trusting the > intermediary that does the "switching", then they may also > not trust > that intermediary to see the clue metadata that describes > the media > and the participants. There might need to be a way for the > advertisements by the endpoints to be encrypted, so that the > intermediary can only collect them and pass them on to the other > endpoints. > > > > These are sent in RTP header extensions, right? RFC6904 lets you > encrypt > selected header extensions end-to-end. In the current PERC > proposals, > anything encrypted with RFC6904 would be visible to the > participants, > but not to the MCU. > > > No. The advertisements are send over a data channel. In a conference > usage, they (and the RTP media) are sent to the mixer. Then the > mixer can consolidate the advertisements it has received, and the > corresponding media, in any manner it wants. The consolidated > advertisements are sent out to the participants. > > The mixer needs to respond to the advertisements. Doing so it > indicates which media it wants to receive, which will affect what > media it can offer. Superficially it is hard to conceive of how a > mixer could do its job without being able to decode the > advertisements it receives. > > One possibility for a mixer is to "pass through" a merge of all the > advertisements it receives to all the other participants - > effectively treating them as blobs that are combined together. *In > principle* it might be possible for the mixer to do this without > being able to read the substance of those advertisements. > > But that would certainly require some major redesign of the CLUE > mechanisms. And even then it wouldn't work for more common usages > such as where the mixer is making the decisions about switching > sources based on voice activity. > > Thanks, > Paul > > > _________________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/__listinfo/dispatch > > > From nobody Thu Apr 16 18:06:05 2015 Return-Path: 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 2976A1A8755 for ; Thu, 16 Apr 2015 18:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yQGsYZuocl4n for ; Thu, 16 Apr 2015 18:05:59 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9614B1A8742 for ; Thu, 16 Apr 2015 18:05:59 -0700 (PDT) Received: from ppp118-209-40-101.lns20.mel4.internode.on.net ([118.209.40.101]:51429 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YiuhT-0004Wa-5T for dispatch@ietf.org; Fri, 17 Apr 2015 11:04:07 +1000 Message-ID: <55305C6F.4020704@nteczone.com> Date: Fri, 17 Apr 2015 11:05:51 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <55134454.9050302@ericsson.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> <552FFE3C.80104@alum.mit.edu> <552FFF92.9040709@nostrum.com> <5530069C.3040008@alum.mit.edu> In-Reply-To: <5530069C.3040008@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 01:06:04 -0000 Hello Paul and Adam, On 17/04/2015 4:59 AM, Paul Kyzivat wrote: > On 4/16/15 2:29 PM, Adam Roach wrote: >> On 4/16/15 13:23, Paul Kyzivat wrote: >>> The advertisements are send over a data channel. >> >> Is this like a "data channel" in the same sense that WebRTC uses that >> term? > > Yes. Chosen in order to facilitate the possibility of WebRTC clients > for CLUE. > >> If so, I think there are some good ways to handle this in line >> with PERC's goals (there are reasonable ways to ensure that the data >> channels terminate at the trusted key management node rather than the >> mixer). [CNG] The CLUE datachannel currently is terminated at the mixer. It needs to have access to the Advertisements in order for it to formulate the Advertisements that sent to other CLUE enabled endpoints. > > I fear we are talking past one another. > > Conceivably it would be possible to separate the signaling logic of > clue from the media mixing logic, so that there could be a *trusted* > entity that manages the keys and also does the mixing of clue > advertisements, but that offloads the actual media "mixing" (switching > in this case) to an untrusted media box. > But it will require some careful thought, and probably changes to clue. [CNG] It depends on your ambition level. CLUE v1 can still be used albeit in a simpler form. E.g. An endpoint using PERC probably shouldn't send XCARD information information about the participants. Basically it shouldn't send any metadata it doesn't want a mixer to access. There's still quite a few attributes that would be useful for capture selection and rendering that I couldn't see a problem with a mixer having access to. If you want to pass XCARD information etc. securely through a mixer to a remote CLUE endpoint via CLUE then that's going to need work in CLUE. > > I guess that would be a CLUEv2, and we shouldn't get too hung up on it > right now. [CNG] I do think its still worthwhile discussing as part of the architecture how mixing is controlled in a PERC architecture. I think its important we're on the same page. CLUE may have a role here. BTW I do support this work. Regards, Christian > > Thanks, > Paul > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Wed Apr 22 10:22:54 2015 Return-Path: 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 BFB521B38BF for ; Wed, 22 Apr 2015 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qlVTATsPg-x3 for ; Wed, 22 Apr 2015 10:22:51 -0700 (PDT) Received: from mlbxsmtpout01.harris.com (mlbxsmtpout01.harris.com [192.52.234.91]) by ietfa.amsl.com (Postfix) with ESMTP id 608FD1B38B6 for ; Wed, 22 Apr 2015 10:22:40 -0700 (PDT) X-AuditID: c034ea5a-f790f6d000003dea-54-5537d8df56a2 Received: from MLBMXCAHT22.cs.myharris.net (mlbmxcaht22.cs.myharris.net [10.64.224.24]) by mlbxsmtpout01.harris.com (mail) with SMTP id 92.5F.15850.FD8D7355; Wed, 22 Apr 2015 13:22:39 -0400 (EDT) Received: from ROCMXCAHT22.cs.myharris.net (10.64.228.25) by MLBMXCAHT22.cs.myharris.net (10.64.224.24) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 22 Apr 2015 13:22:39 -0400 Received: from ROCMXUS21.cs.myharris.net ([fe80::1161:8dee:2d75:5ac]) by ROCMXCAHT22.cs.myharris.net ([::1]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 13:22:38 -0400 From: "Monnes, Peter" To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 Thread-Index: AdB9IO1ULVs6EZUHTMaMwmkQ9n9ULQ== Date: Wed, 22 Apr 2015 17:22:37 +0000 Message-ID: <9238BBB44BF24943AB06F370EBCC3E4C29A33474@ROCMXUS21.cs.myharris.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.228.55] Content-Type: multipart/alternative; boundary="_000_9238BBB44BF24943AB06F370EBCC3E4C29A33474ROCMXUS21csmyha_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42LhcnggoXv/hnmoQdteWYulkxawOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+v1l+wF66Uqfu3kaWBcJ97FyMEhIWAisWi1chcjJ5ApJnHh 3no2EFtI4CijxKfzjl2MXED2bkaJiY9+MEM4axklvj28zQxSxSagJbF4xxwmEFtEQFvi6Kou sLiwgIPE79MPGCHirhLXj61nh7D1JFbemQhWzyKgKjHt0mqwel6BAImF65aAxRmBrvh+ag2Y zSwgLnHryXwmiOsEJJbsOc8MYYtKvHz8jxXCVpB49vcoM0R9vsSCS88ZIWYKSpyc+YQF5Ekh AXmJdcdcJjCKzEIydRaSjllIOiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHcnKSK 4tySAgNDvYzEoqLMYr3k/NxNjMD4OWDyKmoH4/JX9ocYBTgYlXh4V7CbhwqxJpYVV+YeYpTg YFYS4eU6CRTiTUmsrEotyo8vKs1JLT7EKM3BoiTOW3HbLFRIID2xJDU7NbUgtQgmy8TBKdXA aKYSfViPy86l7ZUu32eLBvaU9PTz189uX8Tf/KDiQNXve7vkjzr/KuT97yz8YIXzDZ74t5ck S++94tCffnVbFH/W2n4Pj6+d1zS6v7hOMlwV73tAI2jj24brh5111ksZMvgLr2wWLF+0Seiz gUly5mKeugiHG5Eis7Uz2+TXnpt6b75Di2eDEktxRqKhFnNRcSIAsII5PJsCAAA= Archived-At: Subject: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:22:52 -0000 --_000_9238BBB44BF24943AB06F370EBCC3E4C29A33474ROCMXUS21csmyha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've reviewed and support the publication of the Internet draft: "Session I= nitiation Protocol (SIP) Instance ID usage by the Open Mobile Alliance Push= -to-talk over Cellular draft-allen-dispatch-poc-instanceid-usage-02". This draft is important for the completion of 3GPP Mission Critical Push to= Talk work and so progressing this draft is a priority. Peter Monnes Harris Corporation --_000_9238BBB44BF24943AB06F370EBCC3E4C29A33474ROCMXUS21csmyha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I've reviewed and supp= ort the publication of the Internet draft: "Session Initiation = Protocol (SIP) Instance ID usage by the Open Mobile Alliance Push-to-talk o= ver Cellular draft-allen-dispatch-poc-instanceid-usage-02".  

 

This draft is importan= t for the completion of 3GPP Mission Critical Push to Talk work and so prog= ressing this draft is a priority.

 

Peter Monnes

Harris  Corporation

--_000_9238BBB44BF24943AB06F370EBCC3E4C29A33474ROCMXUS21csmyha_-- From nobody Thu Apr 23 19:32:13 2015 Return-Path: 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 047201A00F7 for ; Thu, 23 Apr 2015 19:32:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "From" X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 HJZxK2uTn-VA for ; Thu, 23 Apr 2015 19:32:11 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2C11A0067 for ; Thu, 23 Apr 2015 19:32:02 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-07v.sys.comcast.net with comcast id KeXg1q00553iAfU01eY2qo; Fri, 24 Apr 2015 02:32:02 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-10v.sys.comcast.net with comcast id KeY11q00S1KKtkw01eY2S5; Fri, 24 Apr 2015 02:32:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id t3O2W12F020277 for ; Thu, 23 Apr 2015 22:32:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t3O2W1tI020274; Thu, 23 Apr 2015 22:32:01 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) From: worley@alum.mit.edu (Dale R. Worley) To: dispatch@ietf.org In-Reply-To: <9238BBB44BF24943AB06F370EBCC3E4C29A33474@ROCMXUS21.cs.myharris.net> (pmonnes@harris.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 23 Apr 2015 22:32:00 -0400 Message-ID: <87r3ra2r4v.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429842722; bh=I53YPYdDDxDrYd6B2RR9cONZuvipUbtpCzghjLfNEsE=; h=Received:Received:Received:Received:From:From:To:Subject:Date: Message-ID; b=tuNmcNqlji0pVX4nnmVaSKI1blukNbBg0vsvmbpHBjomQ9tF/cieHbbrYUwk7+5lp KGxKZ7R3Fdu6d+1DGaP9e/aEjEI64zOhIX2p3z50pGIGfBL4OGmiTgw0z8jcVXD1Re g9d2sc/xOxdqGzyURfUsq//OAhsqLyBiryIg4ZR2biX/waKzFow+mPjiX0ywrct0ud Z9RCHpFzFNKyjTQbAPPbyK3Io78458iPnQr4Q6ozmYcOd7sJWw/TTvqhkg5+MtWl6k ZyLUM271gJrDteak499TC+QocBPhPuzuaHhFvQyULPXTmm76GvYAFXUNbZvvaffewE cf2yaqi7hKJ+Q== Archived-At: Subject: Re: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 02:32:12 -0000 "Monnes, Peter" writes: > I've reviewed and support the publication of the Internet draft: > "Session Initiation Protocol (SIP) Instance ID usage by the Open > Mobile Alliance Push-to-talk over Cellular > draft-allen-dispatch-poc-instanceid-usage-02". The issues this draft addresses should be resolved. (I haven't studied the issues enough myself to know if this draft covers them properly, but it appears to do so to the extent of my knowledge.) The draft could use some editing. In particular, section 2 references a things that should be properly footnoted. For example: OMA PoC 1.0 OMA PoC 2.0 OMA PoC 3.0 Open Mobile Alliance [the URL is given inline, whereas a footnote would be better] "another update of the OMA PoC enabler for Push-To-Talk over 3GPP Long Term Evolution (LTE) networks" "OMA has defined an architecture..." Also, the word "enabler" is used (also in the abstract), but not in a standard way, so needs defining. Dale From nobody Fri Apr 24 09:30:47 2015 Return-Path: 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 AEE7D1A0385 for ; Fri, 24 Apr 2015 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 Wvc152lyEYDV for ; Fri, 24 Apr 2015 09:30:44 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043071A0015 for ; Fri, 24 Apr 2015 09:30:43 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-05v.sys.comcast.net with comcast id KsVf1q0055E3ZMc01sWjk3; Fri, 24 Apr 2015 16:30:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-18v.sys.comcast.net with comcast id KsWi1q00T3Ge9ey01sWjHQ; Fri, 24 Apr 2015 16:30:43 +0000 Message-ID: <553A6FB2.7000204@alum.mit.edu> Date: Fri, 24 Apr 2015 12:30:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <87r3ra2r4v.fsf@hobgoblin.ariadne.com> In-Reply-To: <87r3ra2r4v.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1429893043; bh=Eaa7/1tK3djF8ivnicwN4vk7M/iubortcC0axkpkG34=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WX/5JwjOZehznCEaiJNMHinKLRYJRX8f7x3CqCI5ITissfDQ5OoacAtVnN0LYKmLJ LMV1rbvOjOjBCu3rIJz6gjZ3rDrsoDLdPMWcQGiBBfd2OSSEBn/NSsaw4MVf3YfWyJ naQK6B/UL9hNvdiipzGn6tZoJA5qtsbSqF3YtddHU2F5SrJJBoxA+xK57He0MAnMym Dc9zBfXZQsxXi+kkGdu0v1AyWG6T0LvxRqhTR008OUKFaI8ofQGmoZdI0juqCE3N2W 0iIVD05iaOQ6WjSgHP4T2JfAihRv1BP0QkNuCWsaoc8AIr2ucs+cE8NIHFHJTWIv2E 3vHIlwnsf7uRg== Archived-At: Subject: Re: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 16:30:45 -0000 I just looked at this draft. Thank you for adding clear explanation of the problem you are trying to solve! Just to clarify. This IMEI instance id is included in requests by the device: - REGISTER - the PUBLISH to the participting PoC function - each PoC request. (What messages are used for this???) ISTM that the device is well aware that the REGISTER and the PUBLISH are being directed to a device that is presumably trusted, and will end there. But how does the device ensure that the other requests containing this also go to a trusted device that will remove the IMEI? ISTM that you don't really need to use the IMEI for this. Some other unique id would do. It only needs to correlate the *concurrent* use of multiple addresses. For instance, each time the device turns on and registers it could use a different id, so that there would not be correlation over long periods of time. Also, I think this draft should be reviewed by ECRIT people. Presumably some are on this list too, but it might be good to send a heads-up to the ecrit list. Thanks, Paul On 4/23/15 10:32 PM, Dale R. Worley wrote: > "Monnes, Peter" writes: >> I've reviewed and support the publication of the Internet draft: >> "Session Initiation Protocol (SIP) Instance ID usage by the Open >> Mobile Alliance Push-to-talk over Cellular >> draft-allen-dispatch-poc-instanceid-usage-02". > > The issues this draft addresses should be resolved. (I haven't studied > the issues enough myself to know if this draft covers them properly, but > it appears to do so to the extent of my knowledge.) > > The draft could use some editing. In particular, section 2 references a > things that should be properly footnoted. For example: > > OMA PoC 1.0 > OMA PoC 2.0 > OMA PoC 3.0 > Open Mobile Alliance [the URL is given inline, whereas a footnote would > be better] > "another update of the OMA PoC enabler for Push-To-Talk over 3GPP Long > Term Evolution (LTE) networks" > "OMA has defined an architecture..." > > Also, the word "enabler" is used (also in the abstract), but not in a > standard way, so needs defining. > > Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Sun Apr 26 12:59:05 2015 Return-Path: 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 1D1861A03A1 for ; Sun, 26 Apr 2015 12:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.732 X-Spam-Level: X-Spam-Status: No, score=-97.732 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 IJwFpkoihzzG for ; Sun, 26 Apr 2015 12:59:03 -0700 (PDT) Received: from msk-mail-app01.ti.ru (msk-mail-app01.ti.ru [89.20.149.130]) by ietfa.amsl.com (Postfix) with ESMTP id 578031A0007 for ; Sun, 26 Apr 2015 12:59:02 -0700 (PDT) Received: from [151.252.66.185] (account fas_vm@surguttel.ru HELO surguttel.ru) by msk-mail-app01.ti.ru (CommuniGate Pro SMTP 5.2.20) with ESMTPA id 10469659 for dispatch@ietf.org; Sun, 26 Apr 2015 22:58:59 +0300 From: "Anton Tveretin" To: dispatch@ietf.org Date: Mon, 27 Apr 2015 00:58:31 +0500 MIME-Version: 1.0 Message-ID: <553D4367.14793.165CC40@fas_vm.surguttel.ru> Priority: normal X-mailer: Pegasus Mail for Windows (4.70) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Antivirus: avast! (VPS 150426-0, 26.04.2015), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [dispatch] Against RFC 3891 :) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 19:59:05 -0000 Hello All, Few more notes about my draft. The question is, should the Ctg request the caller (RFC 3891) or the callee to pick up a call? The former, in addition to charging issues, brings up the following: 1. Routing to the caller, which could be hindered by line hunting. I know there is a recently published RFC about this. 2. Call barring policy at either side. 3. Information for the callee only (if it could be). Clearly, this is not possible with RFC 3891. It is not specified in draft-worley-sipping-pickup-01, nor in draft-tveretin-dispatch-remote-00, but will be in -01 version (Subject: header). Of course, I do not want to restrict applicability of the RFC 3891. Regards, Anton. From nobody Sun Apr 26 14:31:55 2015 Return-Path: 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 73E671A92DD for ; Sun, 26 Apr 2015 14:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 u9db36tUon3m for ; Sun, 26 Apr 2015 14:31:53 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3261A0145 for ; Sun, 26 Apr 2015 14:31:53 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-11v.sys.comcast.net with comcast id LlXi1q0052PT3Qt01lXsY9; Sun, 26 Apr 2015 21:31:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-14v.sys.comcast.net with comcast id LlXr1q00X3Ge9ey01lXsKx; Sun, 26 Apr 2015 21:31:52 +0000 Message-ID: <553D5947.40500@alum.mit.edu> Date: Sun, 26 Apr 2015 17:31:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <553D4367.14793.165CC40@fas_vm.surguttel.ru> In-Reply-To: <553D4367.14793.165CC40@fas_vm.surguttel.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1430083912; bh=wF1wzrqt0iPVi1Y7ShQ0TbKeNTA6ETt7dvoG40lwCSw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k4NLVD78/Yyl8j49/vpvHAy17e0XSsLb6OadzeLSgSyI5GZkL4sAbjMBUgYyBJtQH zsPL2Cq2t058vjyczR+7VyX8gJ+J95atAUPU0LY9t+5hRM8SoihjqaKHYmLKS9G6JK GW+DQpOqFLOAFF+1pTVwodce2b7VSGhA5qkOFagildEYJiu0rw6NYBRcyiw3Z6VGi3 hKqeG1+Hn7x/oqJgjeOUKXZFUAiZuXjhLWBTcjnVzWaFAMl0zKG+j6+3GrgUJNEVeb MvjEPW4Yn/KWp+hi2r7zRQ01i+2N7YwOlH0EYx6Jit/hKBpDB2iZdwGqtDVZ20ZFUI pI2XBTYIPNf9w== Archived-At: Subject: Re: [dispatch] Against RFC 3891 :) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 21:31:54 -0000 On 4/26/15 3:58 PM, Anton Tveretin wrote: > Hello All, > Few more notes about my draft. > The question is, should the Ctg request the caller (RFC 3891) or the callee to pick up a call? I'm not sure I understand your question. When you say "pick up a call" do you mean: 1) answer the call? 2) initiate a call that will replace the initial one? 3) pay for the call? If you mean *answer* then the question is nonsense. If you mean *pay for* then the answer is presumably that the Ctg device should choose which one it has sufficient control over. (I guess it often will be the case that it doesn't have authorization to control them both.) And I think that is also the answer if you meant *pay for*. Thanks, Paul > The former, in addition to charging issues, brings up the following: > 1. Routing to the caller, which could be hindered by line hunting. I know there is a recently > published RFC about this. > 2. Call barring policy at either side. > 3. Information for the callee only (if it could be). Clearly, this is not possible with RFC 3891. It > is not specified in draft-worley-sipping-pickup-01, nor in draft-tveretin-dispatch-remote-00, but > will be in -01 version (Subject: header). > Of course, I do not want to restrict applicability of the RFC 3891. > Regards, > Anton. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Apr 27 09:40:00 2015 Return-Path: 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 008541A89FE for ; Mon, 27 Apr 2015 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 8kf_IeNlWOcO for ; Mon, 27 Apr 2015 09:39:58 -0700 (PDT) Received: from server-12.bemta-105.messagelabs.com (mail1.bemta105.messagelabs.com [62.25.80.157]) by ietfa.amsl.com (Postfix) with ESMTP id 508B01A898F for ; Mon, 27 Apr 2015 09:39:57 -0700 (PDT) X-Env-Sender: Richard.Allen3@homeoffice.gsi.gov.uk X-SpamWhitelisted: IP whitelist X-StarScan-Received: X-StarScan-Version: 7.13; banners=homeoffice.gsi.gov.uk,-,- X-VirusChecked: Checked From: Allen Richard To: "dispatch@ietf.org" Thread-Topic: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 Thread-Index: AdCBCMSLHfIGPGmjT8mQXvSJU3DGmw== Date: Mon, 27 Apr 2015 16:39:45 +0000 Message-ID: <1E80BA6F6526374AA13EF37036BEEDBA92EA3E58@sdccmm8017.Poise.HomeOffice.Local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1E80BA6F6526374AA13EF37036BEEDBA92EA3E58sdccmm8017Poise_" MIME-Version: 1.0 Archived-At: Subject: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 16:40:00 -0000 --_000_1E80BA6F6526374AA13EF37036BEEDBA92EA3E58sdccmm8017Poise_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am the lead representative for the Home Office (UK Government) in 3GPP, = where we are working to standardise push to talk functionality for UK Emer= gency Services for the Emergency Services Mobile Communication Programme (= ESMCP). We (Home Office) have reviewed this draft and support the progress= ion of this internet draft. Internet draft: "Session Initiation Protocol (SIP) Instance ID usage by th= e Open Mobile Alliance Push-to-talk over Cellular draft-allen-dispatch-poc= -instanceid-usage-02". This draft as very important to meet our specific user requirements that a= user can use multiple devices, so we support prioritising the progression= of this draft. Kind Regards, Richard Richard Allen Senior Technical Analyst Emergency Services Mobile Communication Programme Crime and Policing Group 1st Floor Peel Building, Home Office 2 Marsham Street London SW1P 4DF Web: www.homeoffice.gsi.gov.uk ________________________________ This email and any files transmitted with it=20are private and intended so= ley for the use of the individual or entity to whom they are addressed. If= you have received this email in error, please return it to the address it= came from telling them it is not for you and then delete it from your sys= tem. This email message has been swept for computer viruses. ________________________________ ********************************************************************** This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your s= ystem. This email message has been swept for computer viruses. ********************************************************************** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Vodafone in partnership with= Symantec. (CCTM Certificate=20Number 2009/09/0052.) This email has been c= ertified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. --_000_1E80BA6F6526374AA13EF37036BEEDBA92EA3E58sdccmm8017Poise_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am the lead representative for the Ho= me Office (UK Government) in 3GPP, where we are working to standardise pus= h to talk functionality for UK Emergency Services for the Emergency Services Mobile Communication Programme (ESMCP). We (Home Office) have re= viewed this draft and support the progression of this internet draft.=

 

Intern= et draft: "Session Initiation Protocol (S= IP) Instance ID usage by the Open Mobile Alliance Push-to-talk over Cellul= ar draft-allen-dispatch-poc-instanceid-usage-02".  

 

This draft as very important to meet ou= r specific user requirements that a user can use multiple devices, so we s= upport prioritising the progression of this draft.

 

Kind Regards,

Richard

 

Richard Allen

 <= /p>

Senior Technical Analyst<= o:p>

Emergency Services Mobile= Communication Programme
Crime and Policing Group

 <= /p>

1st Floor Peel Building, Ho= me Office 2 Marsham Street London SW1P 4DF

Web: www.homeoffice.gsi.gov.uk =

 

<= span style=3D"font-size:12.0pt;font-family:"Arial","sans-se= rif";color:#7030A0">

 

This email and any files tr= ansmitted with it are private and intended soley for the use of the indivi= dual or entity to whom they are addressed. If you have received this email in error, please return it to the address it came from telling= them it is not for you and then delete it from your system. This email me= ssage has been swept for computer viruses.

 

<= span style=3D"font-size:12.0pt;font-family:"Arial","sans-se= rif";color:#7030A0">

 

**********************************************************************<= br />This email and any files transmitted with it are private and intended=
solely for the use of=20the individual or entity to whom they are ad= dressed.
If you have received this email in error please return it to= the address
it came from telling them it is not for you and then del= ete it from your system.
This email message has been swept for comput= er viruses.

********************************************************= **************

***********************************************= ***********************


The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Vodafone in partnership with= Symantec. (CCTM Certificate Number 2009/09/0052.) This email has been cer= tified virus free.
Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes.

--_000_1E80BA6F6526374AA13EF37036BEEDBA92EA3E58sdccmm8017Poise_-- From nobody Thu Apr 30 04:45:13 2015 Return-Path: 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 54DBF1AD255 for ; Thu, 30 Apr 2015 04:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 wk-f_MCBStW2 for ; Thu, 30 Apr 2015 04:45:10 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0801ACE3B for ; Thu, 30 Apr 2015 04:45:09 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-f9-554215c4485a Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DF.83.04401.4C512455; Thu, 30 Apr 2015 13:45:08 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.223]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Thu, 30 Apr 2015 13:45:07 +0200 From: Ivo Sedlacek To: Allen Richard , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 Thread-Index: AdCBCMSLHfIGPGmjT8mQXvSJU3DGmwCMV0AA Date: Thu, 30 Apr 2015 11:45:07 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011288A248@ESESSMB301.ericsson.se> References: <1E80BA6F6526374AA13EF37036BEEDBA92EA3E58@sdccmm8017.Poise.HomeOffice.Local> In-Reply-To: <1E80BA6F6526374AA13EF37036BEEDBA92EA3E58@sdccmm8017.Poise.HomeOffice.Local> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011288A248ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje4RUadQgwlTxSyWTlrAanFvaiOr A5PH558mHkuW/GQKYIrisklJzcksSy3St0vgymjdupytYKNxxc3N15kbGD/pdDFyckgImEh0 nj3NCGGLSVy4t56ti5GLQ0jgKKPEjv+3mSCcJYwSv/dvZAGpYhPQk5i45QgriC0ikCwx/9xG sG5hATeJ99sesEDE3SUaumZC1RhJfH/8FMxmEVCV+D79CDuIzSvgK7Fy22UmEFtIIEKied0K oBoODk6BSIn+m2BjGAVkJa7+6QUbzywgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpS4On05 E0R9vkTbia0sEKsEJU7OfMIygVFkFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI 4gsY2VcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbVwS2/VXcwXn7jeIhRgINRiYd3QY9j qBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGKVmndyo/+jD w5cOUY1xghWCoQ8ZTty6mKfb94DnH4uG7+LLsrcrLnDxh59Pm7e9O7KM49WKI7rNks26M2bN WF5R0itxUL/tR+9GV0mVH4+9DdxfHc/ukdSNaevd+n1luLvBZNWWixfXGDtzs779PDNU4n1G k6Ji7P0TOVb/dlm/fKAXstj6gBJLcUaioRZzUXEiAO4klhOLAgAA Archived-At: Subject: Re: [dispatch] draft-allen-dispatch-poc-instanceid-usage-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 11:45:12 -0000 --_000_39B5E4D390E9BD4890E2B310790061011288A248ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I reviewed http://www.ietf.org/id/draft-allen-dispatch-poc-instanceid-usage= -02.txt and the draft seems in a good shape. I identified one comment. COMMENT: ------------------------------------------------------------------- The exception case in last paragraph of section 6 (copied below) can be ext= ended to any SIP network server serving the UA similarly as the PTT Server = performing the Participating PoC Function. > The OMA PoC usage of the instance ID as > defined in this document adds an additional exception to the usage of > "sip.instance" media feature tag containing the GSMA IMEI URN in the > Contact header field of non-register requests and responses. Since > the PTT Server performing the Participating PoC Function does not > include the Instance ID in requests and responses that it generates > and sends towards the remote party the privacy concerns with > including the Instance ID in the Contact header field of non-register > requests and responses are addressed. ------------------------------------------------------------------- Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B310790061011288A248ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I reviewed http://www.ietf.org/id/draft-allen-dis= patch-poc-instanceid-usage-02.txt and the draft seems in a good shape.=

 

I identified one comment.

 

COMMENT:

-------------------------------------------------= ------------------

The exception case in last paragraph of section 6= (copied below) can be extended to any SIP network server serving the UA si= milarly as the PTT Server performing the Participating PoC Function.

 

>   The OMA PoC usage of the instanc= e ID as

>   defined in this document adds an= additional exception to the usage of

>   "sip.instance" media f= eature tag containing the GSMA IMEI URN in the

>   Contact header field of non-regi= ster requests and responses.  Since

>   the PTT Server performing the Pa= rticipating PoC Function does not

>   include the Instance ID in reque= sts and responses that it generates

>   and sends towards the remote par= ty the privacy concerns with

>   including the Instance ID in the= Contact header field of non-register

>   requests and responses are addre= ssed.

-------------------------------------------------= ------------------

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B310790061011288A248ESESSMB301erics_--