From nobody Wed Jul 6 11:59:01 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0BC12D595 for ; Wed, 6 Jul 2016 11:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.937 X-Spam-Level: X-Spam-Status: No, score=-15.937 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n-kpZ3KLxWc for ; Wed, 6 Jul 2016 11:58:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD4912D1F0 for ; Wed, 6 Jul 2016 11:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3115; q=dns/txt; s=iport; t=1467831537; x=1469041137; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1J78GFOi9dzzjISEARSLkA0xpNTHlalLgFVPjYV/ArI=; b=mWHv1axZt4feubvLo7/iog0i3KrRMAjaAdxDCayyPw1AVTLssY99kzJA p9m5O9uFGMNARTagQEv2fYhrbV/ybiroFCqA5AzIw2bNP/jiT7lDIk6Pf c9XoSLXmxvQ0ZhZwEohD/o0lDzx2/EJPHPLymRV0QUknz2XnEb2d0vZGE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgDRU31X/5tdJa1cgz6BUga5FYF3h?= =?us-ascii?q?hgCgSo4FAEBAQEBAQFlJ4RMAQEEATouBAoDBQcEAgEIDgMBAwEBAR4JBzIUAwY?= =?us-ascii?q?IAgQOBQiIIAi8WAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4RNhCqFcQWOBIsPA?= =?us-ascii?q?Y4/jzGQCQEeNoIIHIFMbodzfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,320,1464652800"; d="scan'208";a="121138265" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 18:58:56 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u66Iwupa014006 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 18:58:56 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 13:58:56 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 13:58:56 -0500 From: "David Benham (dbenham)" To: Cullen Jennings Thread-Topic: [Perc] Names, Names, Names Thread-Index: AQHRrICWOP3UL3UDSEmXJm/18tBYeKAME+aQ Date: Wed, 6 Jul 2016 18:58:56 +0000 Message-ID: <8e25142375c6424e847afe587030f425@XCH-RCD-020.cisco.com> References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.35.132.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Names, Names, Names X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:59:00 -0000 Given these are names of entities, Distributor is better than Distribution = in the naming; thus, Key Distributor works. Also, Media Distribution Devi= ce was written in to the groups charter specifically because was generic (n= ot tied to any specific topology) and deemed reasonably descriptive, so it = would be only modestly different, and parallel to Key Distributor name to c= all it the Media Distributor.=20 MDD >> Media Distributor KMF >> Key Distributor=20 -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Wednesday, May 11, 2016 1:50 PM To: Cullen Jennings Cc: perc@ietf.org Subject: Re: [Perc] Names, Names, Names > KMF - change to "Key Server" or "Key Manger" The role here is Key Distribution. In some old systems, this is called the= KDC, or Key Distribution Center. Russ -----Original Message----- From: Cullen Jennings [mailto:fluffy@iii.ca]=20 Sent: Thursday, May 12, 2016 9:57 AM To: Emil Ivov Cc: Paul Jones ; perc@ietf.org Subject: Re: [Perc] Names, Names, Names > On May 11, 2016, at 4:18 PM, Emil Ivov wrote: >=20 > On Wed, May 11, 2016 at 3:45 PM, Cullen Jennings wrote: >>=20 >>> On May 11, 2016, at 3:08 AM, Emil Ivov wrote: >>>=20 >>>=20 >>>=20 >>> On Wednesday, 11 May 2016, Paul E. Jones wrote. >>>=20 >>> MDD - change to "Media Switch" or "Switch". >>>=20 >>> Switching Conference Server is the original term we used, I think. I ha= ve no strong preference on this one. >>>=20 >>> Why is it again that we are not using SFU here? >>>=20 >>> Emil >>>=20 >>=20 >> Some people felt the "Forward" part implied an architecture where it onl= y forwarded without modifying. PERC supports that arch but also supports so= me sort of modifications so we needed a moe general term. I was hoping that= Switch or Media Switch might avoid that problem in that a SFU is one type = of Media Switch but there are other types that both forward and modify. Wor= k for you? >=20 > I feel that if we have a common denominator between topologies then it > should be defined and named in the topologies draft. I also feel that > terms like SFU are often used in a way that is generic enough (so much > so that 7667 uses it without actually defining it). Most importantly > though, I believe the gain of using a common and well known term would > far outweigh the potential confusion of it not being perfectly exact. >=20 > In other words: I cannot believe that someone would ever look at PERC > and say: "oh wait this thing talks about the 3.7 topo from 7667 and I > really am more like the one in 3.8 so nah ... no go." >=20 Good point. I mostly find topologies too baffling to bother reading but agr= ee this should be aligned. =20 > That said, I don't believe that this is the most important issue we > are facing now, so I could live with whatever. I am sure we could use > the extra exercise on our brains anyway ;) >=20 > Emil From nobody Wed Jul 6 12:07:48 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0C412D5C7 for ; Wed, 6 Jul 2016 12:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pc_yA5UhE52J for ; Wed, 6 Jul 2016 12:07:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D373112D5A5 for ; Wed, 6 Jul 2016 12:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57650; q=dns/txt; s=iport; t=1467832064; x=1469041664; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cse0tBEUNnck+ksA58BUzNT5YC1X+kTUyU5aLeGJ9NU=; b=Ljar5RZbOisZ6hm01Gf4RWdfSoLeyD5XtCCHM/tO0MdTkJqClgEsmIlW uYqtxr7xfKEBFEPyPMqtwZGVDimK8qWP2rLcs3So1gzQaRVIR928k/fhq QYnYT10S6LipSoopBMnBsdsDpgdWsIC6ylrAh/KbsqCfp2fh4fJLnXnIa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgClVn1X/4QNJK1cgnBOVnwGrQWKA?= =?us-ascii?q?YIPgXckhXQCHIEOOBQBAQEBAQEBZSeETAEBBSMKTBACAQgRBAEBIQEGAwICAh8?= =?us-ascii?q?FDBQJCAIEAQ0EAQiIDgMXDqxsiycNhCcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXB?= =?us-ascii?q?YYnhE2CQ4IUH4JLgloFmF80AYYIhi6CCY8xiBeHcgEeNoNwbodzfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,320,1464652800"; d="scan'208,217";a="122927116" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jul 2016 19:07:43 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u66J7hHq005366 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 19:07:43 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 14:07:43 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 14:07:43 -0500 From: "David Benham (dbenham)" To: Suhas Nandakumar , "rlb@ipv.sx" Thread-Topic: [Perc] IETF 96 - PERC Preliminary Agenda Thread-Index: AQHR0wGzvfW7FbWrkkCTehH4jVtXN6ALzHYg Date: Wed, 6 Jul 2016 19:07:42 +0000 Message-ID: <6069874fa0d64d679a32b696bfde6bcb@XCH-RCD-020.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.35.132.36] Content-Type: multipart/alternative; boundary="_000_6069874fa0d64d679a32b696bfde6bcbXCHRCD020ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] IETF 96 - PERC Preliminary Agenda X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 19:07:47 -0000 --_000_6069874fa0d64d679a32b696bfde6bcbXCHRCD020ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVxdWVzdCBhIDEwLTE1IG1pbiBzZWdtZW50IG9uIHRoZSBGcmFtZXdvcmsgV0cgZG9jLCBwcmlt YXJpbHkgYSBicmllZiBsZXZlbCBzZXQgYW5kIHJldmlldyBUbyBEb3MuICBBdCB0aGUgZW5kIGlz IGZpbmUuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGVy Yy1wcml2YXRlLW1lZGlhLWZyYW1ld29yay8NCg0KRnJvbTogU3VoYXMgTmFuZGFrdW1hciBbbWFp bHRvOnN1aGFzaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgSnVuZSAzMCwgMjAxNiAx MDo0MSBBTQ0KVG86IHBlcmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtQZXJjXSBJRVRGIDk2IC0gUEVS QyBQcmVsaW1pbmFyeSBBZ2VuZGENCg0KSGVsbG8gQWxsDQoNCiBUaGlzIGlzIHRoZSBhZ2VuZGEg cGxhbm5pbmcgdGltZSBmb3IgUEVSQydzIElFVEYgOTYgbWVldGluZy4NCg0KV2UgaGF2ZSAyIGhv dXIgc2xvdCBhcHByb3ZlZCBvbiBGcmlkYXkgSnVseSAyMiBAIDEwOjAwIEFNLiBIZXJlIGlzIGEg ZHJhZnQgYWdlbmRhIGJhc2VkIG9uIHBlbmRpbmcgd29yayBpdGVtcy4NCg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk2L2FnZW5kYS9wZXJjLw0KDQoNCldlIHdvdWxkIGxv dmUgdG8gaGVhciBjb21tZW50cy9mZWVkYmFjayBvbiB0aGUgaXRlbXMgbGlzdGVkLg0KDQoNCg0K Q2hlZXJzDQpSaWNoYXJkL1N1aGFzDQo= --_000_6069874fa0d64d679a32b696bfde6bcbXCHRCD020ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDFENzdFLkZCQTQ4NzkwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMTA8L3c6Wm9vbT4N Cjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OlRyYWNrTW92ZXMv Pg0KPHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdh aW5zdFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZh bGlkPg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4N Cjx3OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9s ZGVyVGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6 TGlkVGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WC1OT05FPC93OkxpZFRoZW1lQXNpYW4+ DQo8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNjcmlw dD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNoaWZ0UmV0dXJuLz4NCjx3OkJy ZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8dzpFbmFi bGVPcGVuVHlwZUtlcm5pbmcvPg0KPC93OkNvbXBhdGliaWxpdHk+DQo8bTptYXRoUHI+DQo8bTpt YXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtCaW4gbTp2YWw9ImJlZm9yZSIv Pg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNtYWxsRnJhYyBtOnZhbD0ib2Zm Ii8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOnJNYXJnaW4gbTp2 YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIvPg0KPG06d3JhcEluZGVudCBt OnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4NCjxtOm5hcnlMaW0gbTp2 YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRlbnRTdHlsZXMgRGVmTG9ja2Vk U3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIERlZlNlbWlIaWRkZW49ImZh bHNlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5IiBMYXRlbnRTdHlsZUNvdW50 PSIzNzEiPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIwIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRl eCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iaW5kZXggMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImluZGV4IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDgi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9InRvYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i dG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA3Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDgiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3Jt YWwgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3RlIHRleHQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiB0ZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Imhl YWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290ZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iaW5kZXggaGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFibGUgb2YgZmln dXJlcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbnZlbG9wZSBhZGRyZXNzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290 bm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiByZWZlcmVu Y2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibGluZSBudW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0icGFnZSBudW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90ZSByZWZlcmVu Y2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90ZSB0ZXh0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Im1hY3Jv Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYSBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikxpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 Ikxpc3QgQnVsbGV0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 Ikxpc3QgQnVsbGV0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 Ikxpc3QgTnVtYmVyIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQ2xvc2luZyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBU ZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENv bnRpbnVlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJM aXN0IENvbnRpbnVlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTWVzc2FnZSBIZWFkZXIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTEiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNhbHV0YXRpb24iLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGF0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRl eHQgRmlyc3QgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBGaXJzdCBJ bmRlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3RlIEhlYWRpbmciLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iQm9keSBUZXh0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJC bG9jayBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikh5cGVybGluayIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJGb2xsb3dlZEh5cGVybGluayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEb2N1bWVudCBNYXAiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iUGxhaW4gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJFLW1h aWwgU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVG9wIG9mIEZvcm0iLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBCb3R0b20gb2YgRm9ybSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJOb3JtYWwgKFdlYikiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBY3Jvbnlt Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQWRkcmVzcyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJIVE1MIENpdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBDb2RlIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJI VE1MIEtleWJvYXJkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgUHJlZm9ybWF0dGVkIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgU2FtcGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IkhUTUwgVHlwZXdyaXRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFZhcmlhYmxlIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBUYWJsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJhbm5vdGF0aW9uIHN1YmplY3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm8gTGlzdCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJPdXRsaW5lIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENs YXNzaWMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBDb2xvcmZ1bCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1 bW5zIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBH cmlkIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlk IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA4Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIExpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIExpc3QgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDgiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIDNEIGVmZmVjdHMgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBl ZmZlY3RzIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29udGVtcG9yYXJ5Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgUHJvZmVzc2lvbmFsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFN1YnRsZSAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFN1YnRsZSAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9IlRhYmxlIFdlYiAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IkJhbGxvb24gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBUaGVt ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIE5h bWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGln aHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIg TmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3Qg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0i TWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJD b2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1l PSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBO YW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0iUmV2 aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzQiIFFG b3JtYXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJRdW90ZSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMCIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0 IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xv cmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJM aWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0g R3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJE YXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5h bWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3Qg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIi IE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9 Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwg TGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGln aHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQg NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3Qg MiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVt IEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFj Y2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBO YW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAx IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0 IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRp dW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1l PSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIi IE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNo YWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5h bWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlk IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwg U2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxOSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIEVtcGhh c2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMxIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFJl ZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBUYWJsZSAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQyIiBOYW1lPSJQbGFpbiBUYWJsZSAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQzIiBOYW1lPSJQ bGFpbiBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ1IiBOYW1lPSJQbGFpbiBUYWJsZSA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlkIFRhYmxlIExpZ2h0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDciIE5hbWU9IkdyaWQgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBE YXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1l PSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExp Z2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBU YWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9y ZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdo dCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFi bGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1 bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDci IE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxl IDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIi IE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFj Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0 IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw IiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO YW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt ZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 IkdyaWQgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNj ZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxl IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9 Ikxpc3QgVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9y ZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1l PSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJs ZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBU YWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJs ZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUg MiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFi bGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUg NyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgi IE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxl IDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcg Q29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFj Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO YW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1 IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENv bG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2Nl bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFt ZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDUiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBE YXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xv cmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9 Ikxpc3QgVGFibGUgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFy ayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3Jm dWwgQWNjZW50IDYiLz4NCjwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1m b250LWFsdDoiQ2FsaXN0byBNVCI7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmlj LWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250 LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDExMDczMDU3MjcgMCAwIDQxNSAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsN Cgltc28tZm9udC1hbHQ6IkNlbnR1cnkgR290aGljIjsNCgltc28tZm9udC1jaGFyc2V0OjA7DQoJ bXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7 DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5MjkgMTA3Mzc4NjExMSA5IDAgNDE1IDA7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7 DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsN Cgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVy bGluZTpzaW5nbGU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsN Cgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFu c2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVyLW1hcmdp bjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+Lyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1u YW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRz dHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGlu IDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNj aWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0eWxlPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5 bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXF1ZXN0IGEgMTAtMTUgbWluIHNlZ21lbnQg b24gdGhlIEZyYW1ld29yayBXRyBkb2MsIHByaW1hcmlseSBhIGJyaWVmIGxldmVsDQogc2V0IGFu ZCByZXZpZXcgVG8gRG9zLjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsgPC9z cGFuPkF0IHRoZSBlbmQgaXMgZmluZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGVyYy1wcml2YXRlLW1lZGlh LWZyYW1ld29yay8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt cGVyYy1wcml2YXRlLW1lZGlhLWZyYW1ld29yay88L2E+PG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFu PjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+DQog U3VoYXMgTmFuZGFrdW1hciBbbWFpbHRvOnN1aGFzaWV0ZkBnbWFpbC5jb21dIDxicj4NCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IFRodXJzZGF5LCBK dW5lIDMwLCAyMDE2IDEwOjQxIEFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlRvOjwvc3Bhbj48L2I+IHBlcmNAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBbUGVyY10gSUVURiA5NiAtIFBFUkMg UHJlbGltaW5hcnkgQWdlbmRhPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhlbGxv IEFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5i c3A7VGhpcyBpcyB0aGUgYWdlbmRhIHBsYW5uaW5nIHRpbWUgZm9yIFBFUkMncyBJRVRGIDk2IG1l ZXRpbmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5XZSBoYXZlIDIgaG91ciBzbG90IGFwcHJvdmVkIG9uIEZyaWRheSBKdWx5IDIyIEAgMTA6 MDAgQU0uIEhlcmUgaXMgYSBkcmFmdCBhZ2VuZGEgYmFzZWQgb24gcGVuZGluZyB3b3JrIGl0ZW1z LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk2L2FnZW5kYS9wZXJjLyI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk2L2FnZW5kYS9wZXJjLzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5XZSB3b3VsZCBsb3ZlIHRvIGhlYXIgY29tbWVudHMvZmVlZGJh Y2sgb24gdGhlIGl0ZW1zIGxpc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlJpY2hhcmQvU3VoYXM8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_6069874fa0d64d679a32b696bfde6bcbXCHRCD020ciscocom_-- From nobody Thu Jul 7 07:39:14 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE112D759 for ; Thu, 7 Jul 2016 07:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=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 MObCOAHfrrRp for ; Thu, 7 Jul 2016 07:39:11 -0700 (PDT) Received: from smtp125.iad3a.emailsrvr.com (smtp125.iad3a.emailsrvr.com [173.203.187.125]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11BF12D692 for ; Thu, 7 Jul 2016 07:39:11 -0700 (PDT) Received: from smtp16.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D05A118042C; Thu, 7 Jul 2016 10:39:07 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp16.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8C4C2180447; Thu, 7 Jul 2016 10:39:07 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.92.108.34] (184-23-135-130.dedicated.static.sonic.net [184.23.135.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Thu, 07 Jul 2016 10:39:07 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <8e25142375c6424e847afe587030f425@XCH-RCD-020.cisco.com> Date: Thu, 7 Jul 2016 07:39:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2325FC01-E28D-4149-AB93-F09791994610@iii.ca> References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> <8e25142375c6424e847afe587030f425@XCH-RCD-020.cisco.com> To: David Benham X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] Names, Names, Names X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 14:39:13 -0000 I like that.=20 > On Jul 6, 2016, at 11:58 AM, David Benham (dbenham) = wrote: >=20 > Given these are names of entities, Distributor is better than = Distribution in the naming; thus, Key Distributor works. Also, Media = Distribution Device was written in to the groups charter specifically = because was generic (not tied to any specific topology) and deemed = reasonably descriptive, so it would be only modestly different, and = parallel to Key Distributor name to call it the Media Distributor.=20 >=20 > MDD >> Media Distributor > KMF >> Key Distributor=20 >=20 >=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Wednesday, May 11, 2016 1:50 PM > To: Cullen Jennings > Cc: perc@ietf.org > Subject: Re: [Perc] Names, Names, Names >=20 >=20 >> KMF - change to "Key Server" or "Key Manger" >=20 > The role here is Key Distribution. In some old systems, this is = called the KDC, or Key Distribution Center. >=20 > Russ >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca]=20 > Sent: Thursday, May 12, 2016 9:57 AM > To: Emil Ivov > Cc: Paul Jones ; perc@ietf.org > Subject: Re: [Perc] Names, Names, Names >=20 >> On May 11, 2016, at 4:18 PM, Emil Ivov wrote: >>=20 >> On Wed, May 11, 2016 at 3:45 PM, Cullen Jennings = wrote: >>>=20 >>>> On May 11, 2016, at 3:08 AM, Emil Ivov wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Wednesday, 11 May 2016, Paul E. Jones = wrote. >>>>=20 >>>> MDD - change to "Media Switch" or "Switch". >>>>=20 >>>> Switching Conference Server is the original term we used, I think. = I have no strong preference on this one. >>>>=20 >>>> Why is it again that we are not using SFU here? >>>>=20 >>>> Emil >>>>=20 >>>=20 >>> Some people felt the "Forward" part implied an architecture where it = only forwarded without modifying. PERC supports that arch but also = supports some sort of modifications so we needed a moe general term. I = was hoping that Switch or Media Switch might avoid that problem in that = a SFU is one type of Media Switch but there are other types that both = forward and modify. Work for you? >>=20 >> I feel that if we have a common denominator between topologies then = it >> should be defined and named in the topologies draft. I also feel that >> terms like SFU are often used in a way that is generic enough (so = much >> so that 7667 uses it without actually defining it). Most importantly >> though, I believe the gain of using a common and well known term = would >> far outweigh the potential confusion of it not being perfectly exact. >>=20 >> In other words: I cannot believe that someone would ever look at PERC >> and say: "oh wait this thing talks about the 3.7 topo from 7667 and I >> really am more like the one in 3.8 so nah ... no go." >>=20 >=20 > Good point. I mostly find topologies too baffling to bother reading = but agree this should be aligned. =20 >=20 >> That said, I don't believe that this is the most important issue we >> are facing now, so I could live with whatever. I am sure we could use >> the extra exercise on our brains anyway ;) >>=20 >> Emil >=20 >=20 >=20 From nobody Fri Jul 8 07:32:29 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E14C712D18B; Fri, 8 Jul 2016 07:32:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708143223.32050.81175.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 07:32:23 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-01.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:32:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : Encrypted Key Transport for Secure RTP Authors : John Mattsson David A. McGrew Dan Wing Cullen Jennings Filename : draft-ietf-perc-srtp-ekt-diet-01.txt Pages : 18 Date : 2016-07-08 Abstract: Encrypted Key Transport (EKT) is an extension to Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, Rollover Counters, and other information within SRTP. This facility enables SRTP to work for decentralized conferences with minimal control by allowing a common key to be used across multiple endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 07:32:50 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4A612D740; Fri, 8 Jul 2016 07:32:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708143245.32042.47215.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 07:32:45 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-double-01.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 14:32:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : SRTP Double Encryption Procedures Authors : Cullen Jennings Paul E. Jones Adam Roach Filename : draft-ietf-perc-double-01.txt Pages : 13 Date : 2016-07-08 Abstract: In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some RTP parameters, while still providing strong end-to-end security guarantees. This document defines SRTP procedures that use two separate but related cryptographic contexts to provide "hop-by-hop" and "end-to-end" security guarantees. Both the end-to-end and hop-by-hop cryptographic transforms can utilize an authenticated encryption with associated data scheme or take advantage of future SRTP transforms with different properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-perc-double-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 12:08:42 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 128D912D592; Fri, 8 Jul 2016 12:08:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708190837.32063.63357.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 12:08:37 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-01.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:08:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing Authors : Paul E. Jones David Benham Christian Groves Filename : draft-ietf-perc-private-media-framework-01.txt Pages : 19 Date : 2016-07-08 Abstract: This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end-to-end within the context of a switched conferencing environment where media distribution devices are not trusted with the end-to-end media encryption keys. The solution aims to build upon existing security mechanisms defined for the real-time transport protocol (RTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 18:56:33 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC4812D10E for ; Fri, 8 Jul 2016 18:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdKhM94Lxqpl for ; Fri, 8 Jul 2016 18:56:30 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 5722112D105 for ; Fri, 8 Jul 2016 18:56:30 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u691uSWJ019149 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Jul 2016 21:56:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1468029389; bh=tUDAUKviYD/T0i3seKF5mL3VbZpbf7uTT2O/HrfaqjA=; h=From:To:Subject:Date:Reply-To; b=CbTNPP0SIO+4vqJwRnFjAxKKL5JDZ8s2zJ1NUNUB6kyrRh8KMxHDjk+kLcuQToK2P 2PJISFrCTTs0c87ZTIMRmfQL31pZEtCfXjODwQIJIcyFfSBe0cpM3LJ4Mm3YpPC/jZ flWALaWVLghgOmJLijaW7bY/JME5AYmNvUovg+8A= From: "Paul E. Jones" To: "perc@ietf.org" Date: Sat, 09 Jul 2016 01:56:30 +0000 Message-Id: User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Fri, 08 Jul 2016 21:56:29 -0400 (EDT) Archived-At: Subject: [Perc] Fw: I-D Action: draft-jones-perc-dtls-tunnel-03.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2016 01:56:32 -0000 Folks, I just wanted to let you know that I published version -03 of the DTLS=20 Tunnel spec for PERC. I'll present on the significant changes made to=20 this draft during the meeting. Paul ------ Forwarded Message ------ From: internet-drafts@ietf.org To: i-d-announce@ietf.org Sent: 7/8/2016 2:57:10 PM Subject: I-D Action: draft-jones-perc-dtls-tunnel-03.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : A DTLS Tunnel between Media Distributor and=20 Key Distributor to Facilitate Key Exchange Author : Paul Jones Filename : draft-jones-perc-dtls-tunnel-03.txt Pages : 15 Date : 2016-07-08 Abstract: This document defines a DTLS tunneling protocol for use in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the media distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the media distributor. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-perc-dtls-tunnel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-jones-perc-dtls-tunnel-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-jones-perc-dtls-tunnel-03 Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Sat Jul 16 01:39:51 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36C12D094 for ; Sat, 16 Jul 2016 01:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 v2MWh_IAItrM for ; Sat, 16 Jul 2016 01:39:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D33F712B057 for ; Sat, 16 Jul 2016 01:39:47 -0700 (PDT) Received: from dhcp-8ee3.meeting.ietf.org (dhcp-8ee3.meeting.ietf.org [31.133.142.227]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u6G8diSc065987 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Sat, 16 Jul 2016 03:39:47 -0500 (CDT) (envelope-from adam@nostrum.com) To: "perc@ietf.org" From: Adam Roach Message-ID: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> Date: Sat, 16 Jul 2016 10:39:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 08:39:49 -0000 Mozilla has started looking into implementation of a PERC KMF, and have run into a bit of a snag with the tunnel protocol. Right now, the current tunnel i-d plans on using the reliability of the underlying TLS handshake (client hello/server hello/finished/finished) to ensure that required information is exchanged between the KMF and the MDD. Unfortunately, this won't work. The *reason* it won't work is that TLS 1.3 (which we'll certainly want to support) performs a three-way handshake instead of a four-way handshake. So the message that we planned to use to send the HBH key from the KMF to the MDD simply doesn't exist. This means that we'll need some additional reliability mechanism. We can roll our own -- but (as SIP taught us) that's not an awesome thing to do -- or we can re-use something that already works. As we worked through how best to do this, something relatively simple presented itself. If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: * ICE gives us the keepalives we need to maintain NAT and firewall pinholes * ICE provides a means for finding which of UDP or TCP will work through the firewall * SCTP provides reliability for exchanging messages pertaining to supported ciphersuites and hop-by-hop keys * SCTP provides multiple channels that can be used to carry multiple DTLS associations Basically, this means we move away from a custom binary protocol for the tunnel and re-use existing designs. It's easier to specify, and (at least, for the architectures we've been considering) much easier to implement. It's worth noting that the MDD would only need to support ice-lite, assuming it's deployed on a publicly-routable address. +------+------+------+------+ | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here +------+------+------+------+ | SCTP | <- Provides control channel reliability, channel IDs +---------------------------+ | DTLS | <- DTLS here is the KMF <-> MDD connection +---------------------------+ | ICE | <- Provides keepalives, firewall traversal +---------------------------+ | UDP or TCP | +---------------------------+ I know it's kind of a step back from the tunnel protocol we've been designing at so far, but it looks a lot cleaner, and allows for re-use of already debugged components that will largely exist in implementations (or that can be trivially sourced from commercially-friendly open source projects). Overall -- and in addition to the other advantages -- I think this will be easier to specify and easier to implement. /a From nobody Mon Jul 18 06:15:26 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D3E12DB38 for ; Mon, 18 Jul 2016 06:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 k7ihUgbC24H4 for ; Mon, 18 Jul 2016 06:15:14 -0700 (PDT) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (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 42FA012DAAF for ; Mon, 18 Jul 2016 06:10:14 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 91C3CA0426; Mon, 18 Jul 2016 09:10:11 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0B37CA0366; Mon, 18 Jul 2016 09:10:10 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.61.244.43] ([UNAVAILABLE]. [173.38.220.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Mon, 18 Jul 2016 09:10:11 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> Date: Mon, 18 Jul 2016 08:02:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 13:15:19 -0000 So agree that snag kills the current plan. Running a webrtc data channel looks like the most hideously complicated = thing we could do. How about we just use a TLS connection made from the = KMF to the MDD? I don=E2=80=99t think the head of line issue or the = putting the MDD behind a NAT are practical enough use cases to justify = the complexity.=20 > On Jul 16, 2016, at 4:39 AM, Adam Roach wrote: >=20 > Mozilla has started looking into implementation of a PERC KMF, and = have run into a bit of a snag with the tunnel protocol. Right now, the = current tunnel i-d plans on using the reliability of the underlying TLS = handshake (client hello/server hello/finished/finished) to ensure that = required information is exchanged between the KMF and the MDD. >=20 > Unfortunately, this won't work. The *reason* it won't work is that TLS = 1.3 (which we'll certainly want to support) performs a three-way = handshake instead of a four-way handshake. So the message that we = planned to use to send the HBH key from the KMF to the MDD simply = doesn't exist. >=20 > This means that we'll need some additional reliability mechanism. >=20 > We can roll our own -- but (as SIP taught us) that's not an awesome = thing to do -- or we can re-use something that already works. As we = worked through how best to do this, something relatively simple = presented itself. If we use a stack similar to what we're using for = WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >=20 > * ICE gives us the keepalives we need to maintain NAT and firewall > pinholes > * ICE provides a means for finding which of UDP or TCP will work > through the firewall > * SCTP provides reliability for exchanging messages pertaining to > supported ciphersuites and hop-by-hop keys > * SCTP provides multiple channels that can be used to carry multiple > DTLS associations >=20 > Basically, this means we move away from a custom binary protocol for = the tunnel and re-use existing designs. It's easier to specify, and (at = least, for the architectures we've been considering) much easier to = implement. It's worth noting that the MDD would only need to support = ice-lite, assuming it's deployed on a publicly-routable address. >=20 >=20 > +------+------+------+------+ > | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here > +------+------+------+------+ > | SCTP | <- Provides control channel = reliability, channel IDs > +---------------------------+ > | DTLS | <- DTLS here is the KMF <-> MDD = connection > +---------------------------+ > | ICE | <- Provides keepalives, firewall = traversal > +---------------------------+ > | UDP or TCP | > +---------------------------+ >=20 >=20 > I know it's kind of a step back from the tunnel protocol we've been = designing at so far, but it looks a lot cleaner, and allows for re-use = of already debugged components that will largely exist in = implementations (or that can be trivially sourced from = commercially-friendly open source projects). Overall -- and in addition = to the other advantages -- I think this will be easier to specify and = easier to implement. >=20 > /a >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Wed Jul 20 03:57:08 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F209E12D5A0 for ; Wed, 20 Jul 2016 03:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGnjlIMpNN-5 for ; Wed, 20 Jul 2016 03:57:02 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 0886C12D5B0 for ; Wed, 20 Jul 2016 03:57:02 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id i5so62779897wmg.0 for ; Wed, 20 Jul 2016 03:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fewWQri+ZIDG7vnsPM+9+WtHV/s9zFRcjTALBPn8Nts=; b=yQMW7GCFC33B1470/csf+9pQ1ddAGTEuVoeW31VdwwMEkmW947tWhwuo1R0kenlaax 3/E8Kyd7R56GLRI12YofgCFkMB5nmM2POARBu44Ay7WT4Eio7c5aaGS57cnWEaNvkY2q L76yWC3tOrYIbURdYzpZYfV/xS3oOWqA+NStRHl7Usu1+/sYaTtaqRSSNHtr1lkFZSCv TxckehObAtVsJbVAw6j4C9JsePfGSgfLV3amH59hJyzu6tf2WLaLtY2HW+c/+Ffptte6 73yRm56nkxOaSTMjDeW8klFdOG+2ugZmLJQF1U1ydNTQTnSo1ux3jvvKAyglLcAzT7Hc 4Vnw== 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; bh=fewWQri+ZIDG7vnsPM+9+WtHV/s9zFRcjTALBPn8Nts=; b=WrAZk+u2iGC7ME+I355wKhZhOEXKPGXkkEY01znQ/hyHSdHOoRriopAtZ9Q4ZARr+p KM1ssRVkPT1TsZ7gTYXrkQa332fdOgedmv7iuHrvFuNVPk53sr2a/B2k+LM6/7MmIzhS GV3Fdm+IeaZoJvVzumTfxfppaA8FstBpjtCVaXr63urp6ggKWl8v3fNlUQjmY1vX2R18 aCZXWeq3RoUDL9GUIb3Xs/UJHL81VEeT/cetmtzdxm4pyzQyn63CE4ttfxw/PvMGv3/Q bmYHEaZFKziLZGKb/4DtdQL1IoTKszttmi5adQeCyBbaKrYEMAMod/fz3SK8lwQTZIGc RILw== X-Gm-Message-State: ALyK8tLippCeyK+v+YspuUPJhBBX+NxnXgOVz9M45rfkdOh3AdRgBdbhVvfPMAOYusUP0CcNkD+TTjUiq6ahdA== X-Received: by 10.195.20.33 with SMTP id gz1mr698916wjd.13.1469012220289; Wed, 20 Jul 2016 03:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.117.67 with HTTP; Wed, 20 Jul 2016 03:56:59 -0700 (PDT) In-Reply-To: References: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Wed, 20 Jul 2016 12:56:59 +0200 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a113676828fab6705380f0f6e Archived-At: Cc: "Paul E. Jones" , Eric Rescorla , Adam Roach , "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 10:57:07 -0000 --001a113676828fab6705380f0f6e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello everybody, I understand the point of Emil because as implementer I am worried about having hard restrictions which avoid or hinder the implementation of features requested by the market, and this could make PERC unusable. So I think that firstly we should reach consensus about which features or uses cases must be allowed to be implemented and then discuss the low level details taking into account that we won't can add restrictions which avoid these features. This may also apply to others WGs and not only to PERC. Even having support for rid, mid, etc. could ease the design of PERC. Ones of the features affected with the current status are: 1 - Video quality switching (simulcast) 2 - Dominant Speaker switching These features must also offer an high QoE for the users. For that, the experience tells me that it should be performed in the SFU side. In our current implementation: 1 - Video quality switching (simulcast) is performed rewriting SSRCs, seqnums and timestams 2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums andt timestams. Notice that it would be consider and attack [1] when it is the best way (easy, efficient and with high QoE) we found to implement this feature. This is working in the WebRTC context using endpoints like Chrome or Firefox. To implement them following current PERC status: Could (1) be implemented without SSRCs rewriting and using RID instead? I think so, but should be ensure that endpoints support that before make SSRC immutable? Could (2) be implemented without SSRCs rewriting and using MID instead? Could (2) be implemented even without adding a specific RTP stream using idea [2] ? I think so, but should be ensure that endpoints support that before make SSRC immutable? These questions tell me that if endpoints does not support them, features requested by the market and PERC will be incompatible :S. Best regards!! Refs [1] https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4 [2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html 2016-05-26 1:12 GMT+02:00 Emil Ivov : > > > On Wednesday, 25 May 2016, Eric Rescorla wrote: > >> >> >> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov wrote: >> >>> >>> >>> On 25.05.16 =D0=B3. 15:20, Paul E. Jones wrote: >>> >>>> Emil, >>>> >>>> You are saying that endpoints would negotiate via signaling which SSRC >>>> value(s) to use before actually joining the conference? >>>> >>> >>> It's awesome how you would always attribute to me the least appealing o= f >>> all possible interpretations :). >>> >>> Whether or not we negotiate SSRCs should not be within PERC's scope. Fo= r >>> the record this is how WebRTC works anyway (courtesy of some of the peo= ple >>> on this list) but the matter is completely orthogonal to PERC. >>> >>> What I was suggesting is the possibility for PERC endpoints and MDD to >>> negotiate whether or not they will be dealing with a single end-to-end = SSRC >>> space, or whether they will have separate HBH and E2E SSRC spaces. >>> >>> This way you get to only implement the single end-to-end option in your >>> endpoints and to not support the other one. >>> >>> Does this make more sense? >>> >>> That doesn't strike me as terribly appealing, honestly. Between that >>>> and the pain of dealing with conflicting SSRCs, I might favor the >>>> latter. What I'd prefer most, though, is neither and just let endpoin= ts >>>> do their thing. >>>> >>>> I'd still like to hear confirmation that receiving browsers will >>>> definitely be doing the right thing w.r.t. receiving simulcast streams= . >>>> Adam seemed to suggest Firefox will be doing the right thing (probably >>>> before PERC is done). What about popular browsers? >>>> >>> >>> I think at this point the answers that I've heard are for both browsers= : >>> we are not doing this now. >> >> >> As far as Firefox goes, we're not doing this now because PERC isn't read= y. >> > > So you are saying that simulcast itself is not a good enough reason to > implement receiver-side simulcast support ... but a minor optimization > to PERC is ... > > Obviously I don't need to be explained the reasoning. I am glad you have > this plan. > > I only wish we would have a clearer view of everyone's intended delivery > dates since we are about to block PERC on them. > > > We're looking at it soon and plan to try to implement it pretty much as >> soon as it's baked enough to do. >> >> >> it's not part of webrtc 1.0. >> >> >> Is it even something that could be in WebRTC 1.0? I.e., does it require >> changes? >> > > How would you tell FF what group an RID corresponds to? > > Emil > >> >> >> >> >>> we'd like to do it in the future. >>> >> >> Yes. >> >> -Ekr >> >> >> >> >>> What I'd like to avoid is PERC having a firm dependence on this last >>> statement and for it to only be usable when it comes true. >>> >>> Emil >>> >>> >>>> Paul >>>> >>>> ------ Original Message ------ >>>> From: "Emil Ivov" >>>> To: "Paul E. Jones" >>>> Cc: "Adam Roach" ; "Cullen Jennings" = ; >>>> perc@ietf.org >>>> Sent: 5/25/2016 2:23:43 PM >>>> Subject: Re: [Perc] Request for decision review >>>> >>>> Paul, >>>>> >>>>> I have answered your points below but we did gloss over the suggestio= n >>>>> I made and I consider it important: >>>>> >>>>> We can allow SSRC rewriting and make it negotiable by signalling. Thi= s >>>>> way SFUs can state they support rewriting/immutability/both and >>>>> endpoints can choose to use what's available or reject the session as >>>>> unsupported. >>>>> >>>>> I believe this should address the concerns that have been expressed s= o >>>>> far. >>>>> >>>>> Now for the rest of the points: >>>>> >>>>> On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote: >>>>> >>>>>> Emil, >>>>>> >>>>>> Since we are not enforcing a requirement that endpoints select a >>>>>>>> distinct SSRC per media flow, there is a potential conflict in the >>>>>>>> number space used E2E. >>>>>>>> >>>>>>> >>>>>>> As I have been insisting many times already: We have the option to >>>>>>> mandate that SFUs preserve the SSRC space. That's not hard to >>>>>>> implement. It's not a great option but it is a possibility. >>>>>>> >>>>>>> We can also say that whether or not SFUs do that rewrite is a featu= re >>>>>>> that has to be signalled so clients can choose whether to support i= t >>>>>>> or not. This should address your concern. >>>>>>> >>>>>> >>>>>> The SFU has nothing to do with the E2E SSRC collision problem. When >>>>>> an >>>>>> endpoints sends out an RTP packet and it goes though an SFU that >>>>>> changes >>>>>> the SSRC, there is a HBH SSRC and an E2E SSRC. I fully agree that t= he >>>>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot >>>>>> control >>>>>> the fact that the E2E SSRCs collide. >>>>>> >>>>> >>>>> The SFU has everytihng to do with the E2E collision problem and it's >>>>> potential solutions. What you describe is one way to handle things. >>>>> Another one would be to just make SSRC conflicts obvious to senders s= o >>>>> that they would apply 3550 resolution. That's pretty easy to implemen= t. >>>>> >>>>> The 64 bit identifier is just a hack to work >>>>>>>> around that problem. If the problem didn't exist, we could use SSR= C >>>>>>>> values to look up the context as it was I intended in SRTP. >>>>>>>> >>>>>>> >>>>>>> E2E PERC is NOT SRTP. We may choose to make it look like it is and = I >>>>>>> see why that is appealing but not doing it is by no means "a hack". >>>>>>> >>>>>> >>>>>> Of course it's SRTP. It just happens to be two passes of SRTP, but >>>>>> it's >>>>>> nonetheless SRTP. >>>>>> >>>>> >>>>> Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock >>>>> SRTP endpoint would do anything meaningful with them. So what you are >>>>> looking is to just optimize implementations, which is relevant but no= t >>>>> the primary concern. >>>>> >>>>> What PERC is adding are some additional steps between >>>>>> each pass for HBH authentication of packets at the sender (and the >>>>>> reverse at the receiver). The MDD doesn't have two steps: it just >>>>>> does >>>>>> one normal SRTP decryption for the packet received and one SRTP >>>>>> encryption step sending the packet. The only special requirement PE= RC >>>>>> introduces is that if the MDD changes either the PT field or sequenc= e >>>>>> number, the original values have to be added to the packet inside an >>>>>> RTP >>>>>> header extension called OHB (if not already present). >>>>>> >>>>>> >>>>>> The problem with using a 64 bit value is that any existing SRTP >>>>>>>> library >>>>>>>> would have to change to associate the context that way. >>>>>>>> >>>>>>> >>>>>>> So just to be clear ... we are lamenting about changing an int to a >>>>>>> long? >>>>>>> >>>>>> >>>>>> No, lamenting that this would not align with what RFC 3711 says to u= se >>>>>> to identify the context. >>>>>> >>>>> >>>>> Again, 3711 applies to HBH. We are trying to reuse as much of it for >>>>> E2E as possible and that's admirable but it's not a reason why we >>>>> should significantly disrupt existing implementations. >>>>> >>>>> Further, if we >>>>>>>> wish to break up the PERC processing into two steps, that HBH SSRC >>>>>>>> would >>>>>>>> have to be extracted and passed in by the application. While I >>>>>>>> think the >>>>>>>> intent with Double is for this to be an autonomous operation, it >>>>>>>> might >>>>>>>> not be implemented that way for two reasons: >>>>>>>> 1) If there is a desire to do HBH FEC, the process might be to >>>>>>>> encrypt >>>>>>>> E2E -> FEC -> HBH. So the second call to the SRTP library would ne= ed >>>>>>>> that HBH SSRC passed in when doing these steps in reverse to >>>>>>>> introduce >>>>>>>> that 64-bit context ID. >>>>>>>> >>>>>>> >>>>>>> Em ... you'd have to explain this in a bit more detail because I fa= il >>>>>>> to see how FEC is any different than regular media. As you say it >>>>>>> yourself, it all just works out properly as long as you do your FEC >>>>>>> after E2E and before HBH as that way the SFU would be able to de- o= r >>>>>>> re-FEC. >>>>>>> >>>>>> >>>>>> Historically, there were two options for FEC. Either we do FEC firs= t >>>>>> and then SRTP, or SRTP first then FEC. The order has to match at bo= th >>>>>> the sender and receiver. Either way, it generally makes very little >>>>>> difference. >>>>>> >>>>>> An MDD might want to be a good citizen and reconstruct lost packets >>>>>> before sending a stream to a receiver. In order to do that, the >>>>>> sender >>>>>> will either need to do SRTP (both passes) then FEC or it could do th= e >>>>>> first SRTP pass (the E2E encryption pass) then FEC then SRTP for the >>>>>> HBH. It really depends on what we want that FEC flow to look like. >>>>>> Do >>>>>> we want it to be FEC over a bunch of E2E+HBH encrypted packets or ju= st >>>>>> over the E2E packets. (The latter would be parallel to the current >>>>>> FEC >>>>>> order of "FEC then SRTP". >>>>>> >>>>>> So, thinking of how this might be implemented in an SRTP library, if >>>>>> we >>>>>> allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when th= e >>>>>> application encrypts the packet, it would pass the packet into the >>>>>> SRTP >>>>>> libtary once to encrypt HBH. >>>>>> >>>>> >>>>> You mean E2E here. >>>>> >>>>> It then does whatever FEC processing it >>>>>> wants, then it calls into the SRTP library again to encrypt the seco= nd >>>>>> pass (HBH pass). It could be two entirely instances of the SRTP >>>>>> library >>>>>> that handles each pass. On the MDD, it decrypts the flow and does >>>>>> whatevever FEC magic it wants to do. There is only one SRTP operati= on >>>>>> at the MDD, so no problem. At the receiver, it decrypts the packet >>>>>> received using HBH decryption. It then does whatever FEC processing = it >>>>>> needs to do. Next, it would call into the SRTP library to decrypt f= or >>>>>> E2E. If the SSRCs never change, this works fine. One could impleme= nt >>>>>> this using two instances of an SRTP library today. If a single >>>>>> library >>>>>> is used, then the only requirement is to ensure the second call into >>>>>> the >>>>>> library does not encounter issues with the replay database (since it >>>>>> might otherwise think it's a replayed packet). In either case, the >>>>>> crypto context would be looked up as per RFC 3711 using SSRC. If, >>>>>> however, the SSRC value is allowed to change, then the second call >>>>>> into >>>>>> the SRTP library (same or different instance of the library) would b= e >>>>>> a >>>>>> problem since Alice and Bob both used SSRC 1. The collision is goin= g >>>>>> to >>>>>> prevent the library from working properly. >>>>>> >>>>> >>>>> I still fail to see how FEC changes any of this (for better or worse)= . >>>>> The problem you describe here is exactly the same with or without FEC >>>>> and it's what we are having the argument about. >>>>> >>>>> If we take the approach of using a 64-bit identifier (in contradictio= n >>>>>> to RFC 3711) >>>>>> >>>>> >>>>> :) ... It is NOT in contradiction with 3711 because layers of >>>>> encryptions are not part of 3711. We simply need to set the >>>>> expectations right for implementers. >>>>> >>>>> to identify the crypto context, then we would need to pass >>>>>> that identifier into the SRTP library when attempting to decrypt the >>>>>> packet, because it could not simply discover it by looking at the >>>>>> packet >>>>>> (which it could do normally since the SSRC value is right there in t= he >>>>>> packet). It would be necessary to make a call like >>>>>> srtp_unprotect(context, packet, stream_identifiier) (where >>>>>> stream_identifier is something that identifies the stream other than >>>>>> the >>>>>> SSRC per 3711, like E2E_SSRC || HBH_SSRC). >>>>>> >>>>>> A beautiful thing about SRTP today >>>>>> >>>>> >>>>> You mean PERC here and not SRTP (even if PERC does simply apply a >>>>> second srtp unprotect it is still not stock 3711). >>>>> >>>>> is the library can operate on streams >>>>>> without the application having to pass in such identifiers. The >>>>>> stream >>>>>> is self-identifying. But, we lose that elegance when we modify the >>>>>> SSRC >>>>>> in the MDD when we break the operation into two passes to handle thi= s >>>>>> FEC order. >>>>>> >>>>> >>>>> So we have an aesthetic concern because we have to change int-s to >>>>> long-s and that's why we are having a 100 mail thread. I am speechles= s. >>>>> >>>>> 2) It might be desirable to implement the PERC logic by just having a >>>>>>>> two-step wrapper around the existing SRTP library to avoid making >>>>>>>> changes to the core library. (I'd prefer built-in support for >>>>>>>> Double, >>>>>>>> but I can appreciate how some might prefer to not change an >>>>>>>> otherwise >>>>>>>> working library.) >>>>>>>> >>>>>>> >>>>>>> As I said, being able to reuse SRTP libraries with no change is a >>>>>>> great optimization if we get it but I really don't think the >>>>>>> alternative is anywhere near the complexity that would justify >>>>>>> banning >>>>>>> SSRC re-writing. >>>>>>> >>>>>> >>>>>> At least we agree that it would be a good goal to find an approach >>>>>> that >>>>>> would eliminate or minimize changes to the SRTP logic. :) >>>>>> >>>>>> Now to the complexity part... that's in the thread you're having wit= h >>>>>> Cullen which, as I understand, is an expression of a concern that >>>>>> receiving endpoints are not going to properly handle multiple >>>>>> simulcast >>>>>> streams coming toward them. >>>>>> >>>>>> Since I don't work for a browser vendor, I cannot speak to their >>>>>> plans. >>>>>> I can only assume that proper handling of received simulcast flows >>>>>> would >>>>>> be implemented per the current drafts. And if that's the case, then= I >>>>>> don't think changing the SSRC would be needed. If receiving endpoin= ts >>>>>> fail to do that, then you're right that this could be a problem. >>>>>> >>>>> >>>>> Let's be clear on this. There is absolutely nothing wrong or standard >>>>> breaking in the way browsers handle simulcast reception today. They >>>>> are simply not simulcast aware and the SFU hides it from them. >>>>> >>>>> There is no reason why that would be labelled a bad practice even whe= n >>>>> RID does go through all of the IETF process. >>>>> >>>>> Also, the availability of this option (simulcast unaware receivers) >>>>> and its existence today make the motivation for RID support on the >>>>> receiving end pretty low. It does not give you anything extra in term= s >>>>> of functionality. There are no substantial benefits from doing it (an= d >>>>> no it doesn't allow for significantly simpler SFUs ... those would >>>>> still have to keep 95% of their existing logic). We can decide to mak= e >>>>> PERC dependent on it and hope that this would sway all browser vendor= s >>>>> ... or we could also try to lower the burden on PERC adoption. >>>>> >>>>> Again, as stated in the beginning of this mail: it sounds like a >>>>> compromise may lie in the option for PERC to allow an SSRC rewriting >>>>> mode combined with the option for endpoints to not support it. In >>>>> other words we can have part of the PERC signalling indicate whether >>>>> the client and the server support these modes and whether they use >>>>> them. This is not beautiful (by any means) but it wouldn't prevent >>>>> either of us to do things their way. >>>>> >>>>> Emil >>>>> -- https://jitsi.org >>>>> >>>> >>>> >>>> >>> -- >>> https://jitsi.org >>> >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >> >> > > -- > sent from my mobile > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a113676828fab6705380f0f6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everybody,
I understand the = point of Emil because as implementer I am worried about having hard restric= tions which avoid or hinder the implementation of features requested by the= market, and this could make PERC unusable.

So I think that fi= rstly we should reach consensus about which features or uses cases must= be allowed to be implemented and then discuss the low level details taking= into account that we won't can add restrictions which avoid these feat= ures.
This may also apply to others WGs and not only to PERC. Even= having support for rid, mid, etc. could ease the design of PERC.
<= br>
Ones of the features affected with the current status are:
=C2=A0 1 - Video quality switching (simulcast)
= =C2=A0 2 - Dominant Speaker switching

These features must also offer an high QoE for the users. For that, the e= xperience tells me that it should be performed in the SFU side. In our curr= ent implementation:
=C2=A0 1 - Video quality switching (simulcast) is pe= rformed rewriting SSRCs, seqnums and timestams
=C2=A0 2 - Dominant Speak= er switching is performed rewriting SSRCs, seqnums andt timestams. Notice = that it would be consider and attack [1]= when it is the best way (easy, efficient and
with high QoE) we found t= o implement this feature.

This is working in the We= bRTC context using endpoints like Chrome or Firefox. To implement them foll= owing current PERC status:
Could (1) be implemented with= out SSRCs rewriting and using RID instead?
I think so, but should be ens= ure that endpoints support that before make SSRC immutable?
C= ould (2) be implemented without SSRCs rewriting and using MID instead? Coul= d (2) be implemented even without adding a specific RTP stream using idea <= a href=3D"https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.htm= l" target=3D"_blank">[2]?
I think so, but should be ensure that endp= oints support that before make SSRC immutable?

These ques= tions tell me that if endpoints does not support them, features requested b= y the market and PERC will be incompatible :S.

Best regards!!

2016-05-26 1:12 GMT+02:00 Emil Iv= ov <emcho@jitsi.org>:


On Wednesday, 25 May 2016, Eric Rescorla <ekr@rtfm.com> wrote:

<= br>
On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <emcho@jitsi.org> wrote:


On 25.05.16 =D0=B3. 15:20, Paul E. Jones wrote:
Emil,

You are saying that endpoints would negotiate via signaling which SSRC
value(s) to use before actually joining the conference?

It's awesome how you would always attribute to me the least appealing o= f all possible interpretations :).

Whether or not we negotiate SSRCs should not be within PERC's scope. Fo= r the record this is how WebRTC works anyway (courtesy of some of the peopl= e on this list) but the matter is completely orthogonal to PERC.

What I was suggesting is the possibility for PERC endpoints and MDD to nego= tiate whether or not they will be dealing with a single end-to-end SSRC spa= ce, or whether they will have separate HBH and E2E SSRC spaces.

This way you get to only implement the single end-to-end option in your end= points and to not support the other one.

Does this make more sense?

That doesn't strike me as terribly appealing, honestly.=C2=A0 Between t= hat
and the pain of dealing with conflicting SSRCs, I might favor the
latter.=C2=A0 What I'd prefer most, though, is neither and just let end= points
do their thing.

I'd still like to hear confirmation that receiving browsers will
definitely be doing the right thing w.r.t. receiving simulcast streams.
Adam seemed to suggest Firefox will be doing the right thing (probably
before PERC is done). What about popular browsers?

I think at this point the answers that I've heard are for both browsers= : we are not doing this now.

As far as Fire= fox goes, we're not doing this now because PERC isn't ready.
<= /div>
=C2=A0
So you are sayin= g that simulcast itself is not a good enough reason to implement=C2=A0=C2= =A0receiver-side simulcast support ... but a minor optimization to=C2=A0PER= C is ...

Obviously I don't need to be explained the= reasoning. I am glad you have this plan.

I only wish we= would have a clearer view of everyone's intended delivery dates since = we are about to block PERC on them.


We're looking at it= soon and plan to try to implement it pretty much as soon as it's baked= enough to do.


it's not part of webrtc 1.0.

Is= it even something that could be in WebRTC 1.0? I.e., does it require chang= es?

How woul= d you tell FF what group an RID corresponds to?

Emil=C2=A0
=


<= /div>
=C2=A0
we'd like to do it= in the future.

Yes.

-Ekr
=C2=A0



What I'd like to avoid is PERC having a firm dependence on this last st= atement and for it to only be usable when it comes true.

Emil


Paul

------ Original Message ------
From: "Emil Ivov" <emcho@jitsi.org>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "Adam Roach" <adam@nostrum.com>; "Cullen Je= nnings" <fluffy@iii.ca>;
perc@ietf.org
Sent: 5/25/2016 2:23:43 PM
Subject: Re: [Perc] Request for decision review

Paul,

I have answered your points below but we did gloss over the suggestion
I made and I consider it important:

We can allow SSRC rewriting and make it negotiable by signalling. This
way SFUs can state they support rewriting/immutability/both and
endpoints can choose to use what's available or reject the session as unsupported.

I believe this should address the concerns that have been expressed so
far.

Now for the rest of the points:

On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote:
Emil,

Since we are not enforcing a requirement that endpoints select a
distinct SSRC per media flow, there is a potential conflict in the
number space used E2E.

As I have been insisting many times already: We have the option to
mandate that SFUs preserve the SSRC space. That's not hard to
implement. It's not a great option but it is a possibility.

We can also say that whether or not SFUs do that rewrite is a feature
that has to be signalled so clients can choose whether to support it
or not. This should address your concern.

The SFU has nothing to do with the E2E SSRC collision problem.=C2=A0 When a= n
endpoints sends out an RTP packet and it goes though an SFU that changes the SSRC, there is a HBH SSRC and an E2E SSRC.=C2=A0 I fully agree that the=
SFU can ensure that the HBH SSRCs do not collide, but it cannot control
the fact that the E2E SSRCs collide.

The SFU has everytihng to do with the E2E collision problem and it's potential solutions. What you describe is one way to handle things.
Another one would be to just make SSRC conflicts obvious to senders so
that they would apply 3550 resolution. That's pretty easy to implement.=

The 64 bit identifier is just a hack to work
around that problem. If the problem didn't exist, we could use SSRC
values to look up the context as it was I intended in SRTP.

E2E PERC is NOT SRTP. We may choose to make it look like it is and I
see why that is appealing but not doing it is by no means "a hack"= ;.

Of course it's SRTP.=C2=A0 It just happens to be two passes of SRTP, bu= t it's
nonetheless SRTP.

Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock
SRTP endpoint would do anything meaningful with them. So what you are
looking is to just optimize implementations, which is relevant but not
the primary concern.

What PERC is adding are some additional steps between
each pass for HBH authentication of packets at the sender (and the
reverse at the receiver).=C2=A0 The MDD doesn't have two steps: it just= does
one normal SRTP decryption for the packet received and one SRTP
encryption step sending the packet.=C2=A0 The only special requirement PERC=
introduces is that if the MDD changes either the PT field or sequence
number, the original values have to be added to the packet inside an RTP header extension called OHB (if not already present).


The problem with using a 64 bit value is that any existing SRTP
library
would have to change to associate the context that way.

So just to be clear ... we are lamenting about changing an int to a
long?

No, lamenting that this would not align with what RFC 3711 says to use
to identify the context.

Again, 3711 applies to HBH. We are trying to reuse as much of it for
E2E as possible and that's admirable but it's not a reason why we should significantly disrupt existing implementations.

Further, if we
wish to break up the PERC processing into two steps, that HBH SSRC
would
have to be extracted and passed in by the application. While I
think the
intent with Double is for this to be an autonomous operation, it might
not be implemented that way for two reasons:
1) If there is a desire to do HBH FEC, the process might be to encrypt
E2E -> FEC -> HBH. So the second call to the SRTP library would need<= br> that HBH SSRC passed in when doing these steps in reverse to introduce
that 64-bit context ID.

Em ... you'd have to explain this in a bit more detail because I fail to see how FEC is any different than regular media. As you say it
yourself, it all just works out properly as long as you do your FEC
after E2E and before HBH as that way the SFU would be able to de- or
re-FEC.

Historically, there were two options for FEC.=C2=A0 Either we do FEC first<= br> and then SRTP, or SRTP first then FEC.=C2=A0 The order has to match at both=
the sender and receiver.=C2=A0 Either way, it generally makes very little difference.

An MDD might want to be a good citizen and reconstruct lost packets
before sending a stream to a receiver.=C2=A0 In order to do that, the sende= r
will either need to do SRTP (both passes) then FEC or it could do the
first SRTP pass (the E2E encryption pass) then FEC then SRTP for the
HBH.=C2=A0 It really depends on what we want that FEC flow to look like.=C2= =A0 Do
we want it to be FEC over a bunch of E2E+HBH encrypted packets or just
over the E2E packets.=C2=A0 (The latter would be parallel to the current FE= C
order of "FEC then SRTP".

So, thinking of how this might be implemented in an SRTP library, if we
allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when the
application encrypts the packet, it would pass the packet into the SRTP
libtary once to encrypt HBH.

You mean E2E here.

=C2=A0It then does whatever FEC processing it
wants, then it calls into the SRTP library again to encrypt the second
pass (HBH pass).=C2=A0 It could be two entirely instances of the SRTP libra= ry
that handles each pass.=C2=A0 On the MDD, it decrypts the flow and does
whatevever FEC magic it wants to do.=C2=A0 There is only one SRTP operation=
at the MDD, so no problem.=C2=A0 At the receiver, it decrypts the packet received using HBH decryption. It then does whatever FEC processing it
needs to do.=C2=A0 Next, it would call into the SRTP library to decrypt for=
E2E.=C2=A0 If the SSRCs never change, this works fine.=C2=A0 One could impl= ement
this using two instances of an SRTP library today.=C2=A0 If a single librar= y
is used, then the only requirement is to ensure the second call into the library does not encounter issues with the replay database (since it
might otherwise think it's a replayed packet).=C2=A0 In either case, th= e
crypto context would be looked up as per RFC 3711 using SSRC.=C2=A0 If,
however, the SSRC value is allowed to change, then the second call into
the SRTP library (same or different instance of the library) would be a
problem since Alice and Bob both used SSRC 1.=C2=A0 The collision is going = to
prevent the library from working properly.

I still fail to see how FEC changes any of this (for better or worse).
The problem you describe here is exactly the same with or without FEC
and it's what we are having the argument about.

If we take the approach of using a 64-bit identifier (in contradiction
to RFC 3711)

:) ... It is NOT in contradiction with 3711 because layers of
encryptions are not part of 3711. We simply need to set the
expectations right for implementers.

=C2=A0to identify the crypto context, then we would need to pass
that identifier into the SRTP library when attempting to decrypt the
packet, because it could not simply discover it by looking at the packet (which it could do normally since the SSRC value is right there in the
packet).=C2=A0 It would be necessary to make a call like
srtp_unprotect(context, packet, stream_identifiier) (where
stream_identifier is something that identifies the stream other than the SSRC per 3711, like E2E_SSRC || HBH_SSRC).

A beautiful thing about SRTP today

You mean PERC here and not SRTP (even if PERC does simply apply a
second srtp unprotect it is still not stock 3711).

is the library can operate on streams
without the application having to pass in such identifiers.=C2=A0 The strea= m
is self-identifying.=C2=A0 But, we lose that elegance when we modify the SS= RC
in the MDD when we break the operation into two passes to handle this
FEC order.

So we have an aesthetic concern because we have to change int-s to
long-s and that's why we are having a 100 mail thread. I am speechless.=

2) It might be desirable to implement the PERC logic by just having a
two-step wrapper around the existing SRTP library to avoid making
changes to the core library. (I'd prefer built-in support for Double, but I can appreciate how some might prefer to not change an otherwise
working library.)

As I said, being able to reuse SRTP libraries with no change is a
great optimization if we get it but I really don't think the
alternative is anywhere near the complexity that would justify banning
SSRC re-writing.

At least we agree that it would be a good goal to find an approach that
would eliminate or minimize changes to the SRTP logic. :)

Now to the complexity part... that's in the thread you're having wi= th
Cullen which, as I understand, is an expression of a concern that
receiving endpoints are not going to properly handle multiple simulcast
streams coming toward them.

Since I don't work for a browser vendor, I cannot speak to their plans.=
I can only assume that proper handling of received simulcast flows would be implemented per the current drafts.=C2=A0 And if that's the case, th= en I
don't think changing the SSRC would be needed.=C2=A0 If receiving endpo= ints
fail to do that, then you're right that this could be a problem.

Let's be clear on this. There is absolutely nothing wrong or standard breaking in the way browsers handle simulcast reception today. They
are simply not simulcast aware and the SFU hides it from them.

There is no reason why that would be labelled a bad practice even when
RID does go through all of the IETF process.

Also, the availability of this option (simulcast unaware receivers)
and its existence today make the motivation for RID support on the
receiving end pretty low. It does not give you anything extra in terms
of functionality. There are no substantial benefits from doing it (and
no it doesn't allow for significantly simpler SFUs ... those would
still have to keep 95% of their existing logic). We can decide to make
PERC dependent on it and hope that this would sway all browser vendors
... or we could also try to lower the burden on PERC adoption.

Again, as stated in the beginning of this mail: it sounds like a
compromise may lie in the option for PERC to allow an SSRC rewriting
mode combined with the option for endpoints to not support it. In
other words we can have part of the PERC signalling indicate whether
the client and the server support these modes and whether they use
them. This is not beautiful (by any means) but it wouldn't prevent
either of us to do things their way.

Emil
-- https= ://jitsi.org



--
https://= jitsi.org

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


=
--
sent from my mobile

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




--
Miguel Par= =C3=ADs D=C3=ADaz
------------------------------------------------------= ------------------
Computer/Software engineer.
Researcher and archite= ct in http://www.kuren= to.org
h= ttp://twitter.com/mparisdiaz
---------------------------------------= ---------------------------------
--001a113676828fab6705380f0f6e-- From nobody Wed Jul 20 05:34:33 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754AE12D1C8 for ; Wed, 20 Jul 2016 05:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa4AosFBsIHt for ; Wed, 20 Jul 2016 05:34:26 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 9179612D1B2 for ; Wed, 20 Jul 2016 05:34:26 -0700 (PDT) Received: from [192.168.5.189] (h-213.61.227.39.host.de.colt.net [213.61.227.39]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u6KCYMZ7007022 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 08:34:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1469018065; bh=Z3dl9xI6NuvnS/fzt2uziSpyeGVreuMeLfsM0Ol8mEc=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=TbbA+NG9iqNm3D7j9+CPSzTIMEqi+2f3/lqoKIw6oTptRovYMzIHvyjWpNttQYDV1 WM7eQrMANxtkQIBWgFukqrdWhISKN7fbuTdYW1gf1RsnHbd416b1YzgiD5p/Vr2hYA +v0/xn9X9gJGHKqHe0CLKBOM6pTJNu1ey8HCBxEw= From: "Paul E. Jones" To: =?utf-8?q?Miguel=20Par=c3=ads=20D=c3=adaz?= , "Emil Ivov" Date: Wed, 20 Jul 2016 12:34:26 +0000 Message-Id: In-Reply-To: User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB314FC995-3571-4653-84B8-6CC9C9231C5E" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Wed, 20 Jul 2016 08:34:25 -0400 (EDT) Archived-At: Cc: Eric Rescorla , Adam Roach , "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:34:32 -0000 --------=_MB314FC995-3571-4653-84B8-6CC9C9231C5E Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Miguel, The current design of PERC is one where there is an E2E encryption step=20 using regular SRTP. An intermediary does not have the E2E keys and,=20 therefore, cannot change anything about the packet. Then, that packet=20 is encrypted HBH using a different key that the next hop device will=20 have. Assuming the next hop device is an MDD (nor "Media Distributor"),= =20 that device could have the liberty of changing the sequence numbers and,= =20 in fact, it will be obliged to do so if it does not always forward all=20 of the streams (since not forwarding some streams will mean the=20 cryptographic context gets out of sync). So in the typical case, the MDD will change the sequence number and=20 might insert a new header extension to carry the original value. It=20 might also change the payload type value. How, as the endpoint receives a packet, it will decrypt the HBH packet=20 and reconstruct the E2E packet using the OHB field. But what is there? = =20 Well, it's the original packet as created by the sending endpoint. Even= =20 if we change the SSRC or sequence number, the original values are there=20 and preserved. So, other than out of necessity (sequence number changed= =20 to keep crypto context in sync and PT changed to ensure the right PT=20 value is received as expected), I'm still not convinced that changing=20 the SSRC really buys us anything. Sure, we could change it. We=20 actually has space in the OHB originally to allow that. But for what=20 purpose? Changing or not changing an SSRC value should not have any=20 affect whatsoever on the QoE. (I'm not saying the SSRC has no=20 importance, but I question the need to rewrite them.) I'm not sure how the other identifiers you mention might help improve=20 QoE. Maybe expand on that little? One important point to consider in all of this is that WebRTC browsers=20 MUST be PERC-aware, else they cannot participate in conferences. If=20 they're not PERC-aware, then there would have to be a middlebox that=20 "downgrades" for those older browsers and it can rewrite whatever it=20 wants, since it would be in possession of keys and would strip off one=20 layer of encryption to produce a legacy SRTP flow (or no SRTP at all). Paul ------ Original Message ------ From: "Miguel Par=C3=ADs D=C3=ADaz" To: "Emil Ivov" Cc: "Eric Rescorla" ; "Paul E. Jones"=20 ; "Adam Roach" ;=20 "perc@ietf.org" ; "Cullen Jennings" Sent: 7/20/2016 6:56:59 AM Subject: Re: [Perc] Request for decision review >Hello everybody, >I understand the point of Emil because as implementer I am worried=20 >about having hard restrictions which avoid or hinder the implementation= =20 >of features requested by the market, and this could make PERC unusable. > >So I think that firstly we should reach consensus about which features=20 >or uses cases must be allowed to be implemented and then discuss the=20 >low level details taking into account that we won't can add=20 >restrictions which avoid these features. >This may also apply to others WGs and not only to PERC. Even having=20 >support for rid, mid, etc. could ease the design of PERC. > >Ones of the features affected with the current status are: > 1 - Video quality switching (simulcast) > 2 - Dominant Speaker switching > >These features must also offer an high QoE for the users. For that, the= =20 >experience tells me that it should be performed in the SFU side. In our= =20 >current implementation: > 1 - Video quality switching (simulcast) is performed rewriting SSRCs,= =20 >seqnums and timestams > 2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums= =20 >andt timestams. Notice that it would be consider and attack [1] when it= =20 >is the best way (easy, efficient and >with high QoE) we found to implement this feature. > >This is working in the WebRTC context using endpoints like Chrome or=20 >Firefox. To implement them following current PERC status: >Could (1) be implemented without SSRCs rewriting and using RID instead? >I think so, but should be ensure that endpoints support that before=20 >make SSRC immutable? >Could (2) be implemented without SSRCs rewriting and using MID instead?= =20 >Could (2) be implemented even without adding a specific RTP stream=20 >using idea [2]? >I think so, but should be ensure that endpoints support that before=20 >make SSRC immutable? > >These questions tell me that if endpoints does not support them,=20 >features requested by the market and PERC will be incompatible :S. > >Best regards!! > >Refs >[1]=20 >https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.= 4 >[2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html > >2016-05-26 1:12 GMT+02:00 Emil Ivov : >> >> >>On Wednesday, 25 May 2016, Eric Rescorla wrote: >>> >>> >>>On Wed, May 25, 2016 at 1:43 PM, Emil Ivov wrote: >>>> >>>> >>>>On 25.05.16 =D0=B3. 15:20, Paul E. Jones wrote: >>>>>Emil, >>>>> >>>>>You are saying that endpoints would negotiate via signaling which=20 >>>>>SSRC >>>>>value(s) to use before actually joining the conference? >>>> >>>>It's awesome how you would always attribute to me the least=20 >>>>appealing of all possible interpretations :). >>>> >>>>Whether or not we negotiate SSRCs should not be within PERC's scope.= =20 >>>>For the record this is how WebRTC works anyway (courtesy of some of=20 >>>>the people on this list) but the matter is completely orthogonal to=20 >>>>PERC. >>>> >>>>What I was suggesting is the possibility for PERC endpoints and MDD=20 >>>>to negotiate whether or not they will be dealing with a single=20 >>>>end-to-end SSRC space, or whether they will have separate HBH and=20 >>>>E2E SSRC spaces. >>>> >>>>This way you get to only implement the single end-to-end option in=20 >>>>your endpoints and to not support the other one. >>>> >>>>Does this make more sense? >>>> >>>>>That doesn't strike me as terribly appealing, honestly. Between=20 >>>>>that >>>>>and the pain of dealing with conflicting SSRCs, I might favor the >>>>>latter. What I'd prefer most, though, is neither and just let=20 >>>>>endpoints >>>>>do their thing. >>>>> >>>>>I'd still like to hear confirmation that receiving browsers will >>>>>definitely be doing the right thing w.r.t. receiving simulcast=20 >>>>>streams. >>>>>Adam seemed to suggest Firefox will be doing the right thing=20 >>>>>(probably >>>>>before PERC is done). What about popular browsers? >>>> >>>>I think at this point the answers that I've heard are for both=20 >>>>browsers: we are not doing this now. >>> >>>As far as Firefox goes, we're not doing this now because PERC isn't=20 >>>ready. >> >>So you are saying that simulcast itself is not a good enough reason to= =20 >>implement receiver-side simulcast support ... but a minor=20 >>optimization to PERC is ... >> >>Obviously I don't need to be explained the reasoning. I am glad you=20 >>have this plan. >> >>I only wish we would have a clearer view of everyone's intended=20 >>delivery dates since we are about to block PERC on them. >> >> >>>We're looking at it soon and plan to try to implement it pretty much=20 >>>as soon as it's baked enough to do. >>> >>> >>>>it's not part of webrtc 1.0. >>> >>>Is it even something that could be in WebRTC 1.0? I.e., does it=20 >>>require changes? >> >>How would you tell FF what group an RID corresponds to? >> >>Emil >>> >>> >>> >>>>we'd like to do it in the future. >>> >>>Yes. >>> >>>-Ekr >>> >>> >>> >>>> >>>>What I'd like to avoid is PERC having a firm dependence on this last= =20 >>>>statement and for it to only be usable when it comes true. >>>> >>>>Emil >>>> >>>>> >>>>>Paul >>>>> >>>>>------ Original Message ------ >>>>>From: "Emil Ivov" >>>>>To: "Paul E. Jones" >>>>>Cc: "Adam Roach" ; "Cullen Jennings"=20 >>>>>; >>>>>perc@ietf.org >>>>>Sent: 5/25/2016 2:23:43 PM >>>>>Subject: Re: [Perc] Request for decision review >>>>> >>>>>>Paul, >>>>>> >>>>>>I have answered your points below but we did gloss over the=20 >>>>>>suggestion >>>>>>I made and I consider it important: >>>>>> >>>>>>We can allow SSRC rewriting and make it negotiable by signalling.=20 >>>>>>This >>>>>>way SFUs can state they support rewriting/immutability/both and >>>>>>endpoints can choose to use what's available or reject the session= =20 >>>>>>as >>>>>>unsupported. >>>>>> >>>>>>I believe this should address the concerns that have been=20 >>>>>>expressed so >>>>>>far. >>>>>> >>>>>>Now for the rest of the points: >>>>>> >>>>>>On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote: >>>>>>>Emil, >>>>>>> >>>>>>>>>Since we are not enforcing a requirement that endpoints select=20 >>>>>>>>>a >>>>>>>>>distinct SSRC per media flow, there is a potential conflict in=20 >>>>>>>>>the >>>>>>>>>number space used E2E. >>>>>>>> >>>>>>>>As I have been insisting many times already: We have the option=20 >>>>>>>>to >>>>>>>>mandate that SFUs preserve the SSRC space. That's not hard to >>>>>>>>implement. It's not a great option but it is a possibility. >>>>>>>> >>>>>>>>We can also say that whether or not SFUs do that rewrite is a=20 >>>>>>>>feature >>>>>>>>that has to be signalled so clients can choose whether to=20 >>>>>>>>support it >>>>>>>>or not. This should address your concern. >>>>>>> >>>>>>>The SFU has nothing to do with the E2E SSRC collision problem. =20 >>>>>>>When an >>>>>>>endpoints sends out an RTP packet and it goes though an SFU that=20 >>>>>>>changes >>>>>>>the SSRC, there is a HBH SSRC and an E2E SSRC. I fully agree=20 >>>>>>>that the >>>>>>>SFU can ensure that the HBH SSRCs do not collide, but it cannot=20 >>>>>>>control >>>>>>>the fact that the E2E SSRCs collide. >>>>>> >>>>>>The SFU has everytihng to do with the E2E collision problem and=20 >>>>>>it's >>>>>>potential solutions. What you describe is one way to handle=20 >>>>>>things. >>>>>>Another one would be to just make SSRC conflicts obvious to=20 >>>>>>senders so >>>>>>that they would apply 3550 resolution. That's pretty easy to=20 >>>>>>implement. >>>>>> >>>>>>>>>The 64 bit identifier is just a hack to work >>>>>>>>>around that problem. If the problem didn't exist, we could use=20 >>>>>>>>>SSRC >>>>>>>>>values to look up the context as it was I intended in SRTP. >>>>>>>> >>>>>>>>E2E PERC is NOT SRTP. We may choose to make it look like it is=20 >>>>>>>>and I >>>>>>>>see why that is appealing but not doing it is by no means "a=20 >>>>>>>>hack". >>>>>>> >>>>>>>Of course it's SRTP. It just happens to be two passes of SRTP,=20 >>>>>>>but it's >>>>>>>nonetheless SRTP. >>>>>> >>>>>>Exactly! And two passes of SRTP happen to NOT be SRTP as in: no=20 >>>>>>stock >>>>>>SRTP endpoint would do anything meaningful with them. So what you=20 >>>>>>are >>>>>>looking is to just optimize implementations, which is relevant but= =20 >>>>>>not >>>>>>the primary concern. >>>>>> >>>>>>>What PERC is adding are some additional steps between >>>>>>>each pass for HBH authentication of packets at the sender (and=20 >>>>>>>the >>>>>>>reverse at the receiver). The MDD doesn't have two steps: it=20 >>>>>>>just does >>>>>>>one normal SRTP decryption for the packet received and one SRTP >>>>>>>encryption step sending the packet. The only special requirement= =20 >>>>>>>PERC >>>>>>>introduces is that if the MDD changes either the PT field or=20 >>>>>>>sequence >>>>>>>number, the original values have to be added to the packet inside= =20 >>>>>>>an RTP >>>>>>>header extension called OHB (if not already present). >>>>>>> >>>>>>> >>>>>>>>>The problem with using a 64 bit value is that any existing SRTP >>>>>>>>>library >>>>>>>>>would have to change to associate the context that way. >>>>>>>> >>>>>>>>So just to be clear ... we are lamenting about changing an int=20 >>>>>>>>to a >>>>>>>>long? >>>>>>> >>>>>>>No, lamenting that this would not align with what RFC 3711 says=20 >>>>>>>to use >>>>>>>to identify the context. >>>>>> >>>>>>Again, 3711 applies to HBH. We are trying to reuse as much of it=20 >>>>>>for >>>>>>E2E as possible and that's admirable but it's not a reason why we >>>>>>should significantly disrupt existing implementations. >>>>>> >>>>>>>>>Further, if we >>>>>>>>>wish to break up the PERC processing into two steps, that HBH=20 >>>>>>>>>SSRC >>>>>>>>>would >>>>>>>>>have to be extracted and passed in by the application. While I >>>>>>>>>think the >>>>>>>>>intent with Double is for this to be an autonomous operation,=20 >>>>>>>>>it might >>>>>>>>>not be implemented that way for two reasons: >>>>>>>>>1) If there is a desire to do HBH FEC, the process might be to=20 >>>>>>>>>encrypt >>>>>>>>>E2E -> FEC -> HBH. So the second call to the SRTP library would= =20 >>>>>>>>>need >>>>>>>>>that HBH SSRC passed in when doing these steps in reverse to=20 >>>>>>>>>introduce >>>>>>>>>that 64-bit context ID. >>>>>>>> >>>>>>>>Em ... you'd have to explain this in a bit more detail because I= =20 >>>>>>>>fail >>>>>>>>to see how FEC is any different than regular media. As you say=20 >>>>>>>>it >>>>>>>>yourself, it all just works out properly as long as you do your=20 >>>>>>>>FEC >>>>>>>>after E2E and before HBH as that way the SFU would be able to=20 >>>>>>>>de- or >>>>>>>>re-FEC. >>>>>>> >>>>>>>Historically, there were two options for FEC. Either we do FEC=20 >>>>>>>first >>>>>>>and then SRTP, or SRTP first then FEC. The order has to match at= =20 >>>>>>>both >>>>>>>the sender and receiver. Either way, it generally makes very=20 >>>>>>>little >>>>>>>difference. >>>>>>> >>>>>>>An MDD might want to be a good citizen and reconstruct lost=20 >>>>>>>packets >>>>>>>before sending a stream to a receiver. In order to do that, the=20 >>>>>>>sender >>>>>>>will either need to do SRTP (both passes) then FEC or it could do= =20 >>>>>>>the >>>>>>>first SRTP pass (the E2E encryption pass) then FEC then SRTP for=20 >>>>>>>the >>>>>>>HBH. It really depends on what we want that FEC flow to look=20 >>>>>>>like. Do >>>>>>>we want it to be FEC over a bunch of E2E+HBH encrypted packets or= =20 >>>>>>>just >>>>>>>over the E2E packets. (The latter would be parallel to the=20 >>>>>>>current FEC >>>>>>>order of "FEC then SRTP". >>>>>>> >>>>>>>So, thinking of how this might be implemented in an SRTP library,= =20 >>>>>>>if we >>>>>>>allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when= =20 >>>>>>>the >>>>>>>application encrypts the packet, it would pass the packet into=20 >>>>>>>the SRTP >>>>>>>libtary once to encrypt HBH. >>>>>> >>>>>>You mean E2E here. >>>>>> >>>>>>> It then does whatever FEC processing it >>>>>>>wants, then it calls into the SRTP library again to encrypt the=20 >>>>>>>second >>>>>>>pass (HBH pass). It could be two entirely instances of the SRTP=20 >>>>>>>library >>>>>>>that handles each pass. On the MDD, it decrypts the flow and=20 >>>>>>>does >>>>>>>whatevever FEC magic it wants to do. There is only one SRTP=20 >>>>>>>operation >>>>>>>at the MDD, so no problem. At the receiver, it decrypts the=20 >>>>>>>packet >>>>>>>received using HBH decryption. It then does whatever FEC=20 >>>>>>>processing it >>>>>>>needs to do. Next, it would call into the SRTP library to=20 >>>>>>>decrypt for >>>>>>>E2E. If the SSRCs never change, this works fine. One could=20 >>>>>>>implement >>>>>>>this using two instances of an SRTP library today. If a single=20 >>>>>>>library >>>>>>>is used, then the only requirement is to ensure the second call=20 >>>>>>>into the >>>>>>>library does not encounter issues with the replay database (since= =20 >>>>>>>it >>>>>>>might otherwise think it's a replayed packet). In either case,=20 >>>>>>>the >>>>>>>crypto context would be looked up as per RFC 3711 using SSRC. =20 >>>>>>>If, >>>>>>>however, the SSRC value is allowed to change, then the second=20 >>>>>>>call into >>>>>>>the SRTP library (same or different instance of the library)=20 >>>>>>>would be a >>>>>>>problem since Alice and Bob both used SSRC 1. The collision is=20 >>>>>>>going to >>>>>>>prevent the library from working properly. >>>>>> >>>>>>I still fail to see how FEC changes any of this (for better or=20 >>>>>>worse). >>>>>>The problem you describe here is exactly the same with or without=20 >>>>>>FEC >>>>>>and it's what we are having the argument about. >>>>>> >>>>>>>If we take the approach of using a 64-bit identifier (in=20 >>>>>>>contradiction >>>>>>>to RFC 3711) >>>>>> >>>>>>:) ... It is NOT in contradiction with 3711 because layers of >>>>>>encryptions are not part of 3711. We simply need to set the >>>>>>expectations right for implementers. >>>>>> >>>>>>> to identify the crypto context, then we would need to pass >>>>>>>that identifier into the SRTP library when attempting to decrypt=20 >>>>>>>the >>>>>>>packet, because it could not simply discover it by looking at the= =20 >>>>>>>packet >>>>>>>(which it could do normally since the SSRC value is right there=20 >>>>>>>in the >>>>>>>packet). It would be necessary to make a call like >>>>>>>srtp_unprotect(context, packet, stream_identifiier) (where >>>>>>>stream_identifier is something that identifies the stream other=20 >>>>>>>than the >>>>>>>SSRC per 3711, like E2E_SSRC || HBH_SSRC). >>>>>>> >>>>>>>A beautiful thing about SRTP today >>>>>> >>>>>>You mean PERC here and not SRTP (even if PERC does simply apply a >>>>>>second srtp unprotect it is still not stock 3711). >>>>>> >>>>>>>is the library can operate on streams >>>>>>>without the application having to pass in such identifiers. The=20 >>>>>>>stream >>>>>>>is self-identifying. But, we lose that elegance when we modify=20 >>>>>>>the SSRC >>>>>>>in the MDD when we break the operation into two passes to handle=20 >>>>>>>this >>>>>>>FEC order. >>>>>> >>>>>>So we have an aesthetic concern because we have to change int-s to >>>>>>long-s and that's why we are having a 100 mail thread. I am=20 >>>>>>speechless. >>>>>> >>>>>>>>>2) It might be desirable to implement the PERC logic by just=20 >>>>>>>>>having a >>>>>>>>>two-step wrapper around the existing SRTP library to avoid=20 >>>>>>>>>making >>>>>>>>>changes to the core library. (I'd prefer built-in support for=20 >>>>>>>>>Double, >>>>>>>>>but I can appreciate how some might prefer to not change an=20 >>>>>>>>>otherwise >>>>>>>>>working library.) >>>>>>>> >>>>>>>>As I said, being able to reuse SRTP libraries with no change is=20 >>>>>>>>a >>>>>>>>great optimization if we get it but I really don't think the >>>>>>>>alternative is anywhere near the complexity that would justify=20 >>>>>>>>banning >>>>>>>>SSRC re-writing. >>>>>>> >>>>>>>At least we agree that it would be a good goal to find an=20 >>>>>>>approach that >>>>>>>would eliminate or minimize changes to the SRTP logic. :) >>>>>>> >>>>>>>Now to the complexity part... that's in the thread you're having=20 >>>>>>>with >>>>>>>Cullen which, as I understand, is an expression of a concern that >>>>>>>receiving endpoints are not going to properly handle multiple=20 >>>>>>>simulcast >>>>>>>streams coming toward them. >>>>>>> >>>>>>>Since I don't work for a browser vendor, I cannot speak to their=20 >>>>>>>plans. >>>>>>>I can only assume that proper handling of received simulcast=20 >>>>>>>flows would >>>>>>>be implemented per the current drafts. And if that's the case,=20 >>>>>>>then I >>>>>>>don't think changing the SSRC would be needed. If receiving=20 >>>>>>>endpoints >>>>>>>fail to do that, then you're right that this could be a problem. >>>>>> >>>>>>Let's be clear on this. There is absolutely nothing wrong or=20 >>>>>>standard >>>>>>breaking in the way browsers handle simulcast reception today.=20 >>>>>>They >>>>>>are simply not simulcast aware and the SFU hides it from them. >>>>>> >>>>>>There is no reason why that would be labelled a bad practice even=20 >>>>>>when >>>>>>RID does go through all of the IETF process. >>>>>> >>>>>>Also, the availability of this option (simulcast unaware=20 >>>>>>receivers) >>>>>>and its existence today make the motivation for RID support on the >>>>>>receiving end pretty low. It does not give you anything extra in=20 >>>>>>terms >>>>>>of functionality. There are no substantial benefits from doing it=20 >>>>>>(and >>>>>>no it doesn't allow for significantly simpler SFUs ... those would >>>>>>still have to keep 95% of their existing logic). We can decide to=20 >>>>>>make >>>>>>PERC dependent on it and hope that this would sway all browser=20 >>>>>>vendors >>>>>>... or we could also try to lower the burden on PERC adoption. >>>>>> >>>>>>Again, as stated in the beginning of this mail: it sounds like a >>>>>>compromise may lie in the option for PERC to allow an SSRC=20 >>>>>>rewriting >>>>>>mode combined with the option for endpoints to not support it. In >>>>>>other words we can have part of the PERC signalling indicate=20 >>>>>>whether >>>>>>the client and the server support these modes and whether they use >>>>>>them. This is not beautiful (by any means) but it wouldn't prevent >>>>>>either of us to do things their way. >>>>>> >>>>>>Emil >>>>>>-- https://jitsi.org >>>>> >>>>> >>>> >>>>-- >>>>https://jitsi.org >>>> >>>>_______________________________________________ >>>>Perc mailing list >>>>Perc@ietf.org >>>>https://www.ietf.org/mailman/listinfo/perc >>> >> >> >>-- >>sent from my mobile >> >>_______________________________________________ >>Perc mailing list >>Perc@ietf.org >>https://www.ietf.org/mailman/listinfo/perc >> > > > >-- >Miguel Par=C3=ADs D=C3=ADaz >------------------------------------------------------------------------ >Computer/Software engineer. >Researcher and architect in http://www.kurento.org >http://twitter.com/mparisdiaz >------------------------------------------------------------------------= --------=_MB314FC995-3571-4653-84B8-6CC9C9231C5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Miguel,
 
The current design of PERC is one where there is an E2E encryption = step using regular SRTP.  An intermediary does not have the E2E keys= and, therefore, cannot change anything about the packet.  Then, that= packet is encrypted HBH using a different key that the next hop device = will have.  Assuming the next hop device is an MDD (nor "Media Distrib= utor"), that device could have the liberty of changing the sequence numbers= and, in fact, it will be obliged to do so if it does not always forward= all of the streams (since not forwarding some streams will mean the crypto= graphic context gets out of sync).
 
So in the typical case, the MDD will change the sequence number and= might insert a new header extension to carry the original value.  = It might also change the payload type value.
 
How, as the endpoint receives a packet, it will decrypt the HBH packet= and reconstruct the E2E packet using the OHB field.  But what is ther= e?  Well, it's the original packet as created by the sending endpoint.=   Even if we change the SSRC or sequence number, the original values= are there and preserved.  So, other than out of necessity (sequence= number changed to keep crypto context in sync and PT changed to ensure = the right PT value is received as expected), I'm still not convinced that= changing the SSRC really buys us anything.  Sure, we could change = it.  We actually has space in the OHB originally to allow that. = But for what purpose?  Changing or not changing an SSRC value should= not have any affect whatsoever on the QoE.   (I'm not saying = the SSRC has no importance, but I question the need to rewrite them.)
 
I'm not sure how the other identifiers you mention might help = improve QoE.  Maybe expand on that little?
 
One important point to consider in all of this is that WebRTC = browsers MUST be PERC-aware, else they cannot participate in conferences.&n= bsp; If they're not PERC-aware, then there would have to be a middlebox = that "downgrades" for those older browsers and it can rewrite whatever it= wants, since it would be in possession of keys and would strip off= one layer of encryption to produce a legacy SRTP flow (or no SRTP at all).=  
 
Paul
 
------ Original Message ------
From: "Miguel Par=C3=ADs D=C3=ADaz" <mparisdiaz@gmail.com>
To: "Emil Ivov" <emcho@jitsi.org= >
Cc: "Eric Rescorla" <ekr@rtfm.com>; "Paul E. Jones" <paulej= @packetizer.com>; "Adam Roach" <adam@nostrum.com>; "perc@ietf.org" <perc@ietf.org>; "Cullen Jennings" <fluffy@iii.ca>
Sent: 7/20/2016 6:56:59 AM
Subject: Re: [Perc] Request for decision review
 
Hello everybody,
I understand the point of Emil because as= implementer I am worried about having hard restrictions which avoid or = hinder the implementation of features requested by the market, and this = could make PERC unusable.

So I think that firstly we should= reach consensus about= which features or uses cases must be allowed to be implemented and then= discuss the low level details taking into account that we won't can add= restrictions which avoid these features.
This may also apply to= others WGs and not only to PERC. Even having support for rid, mid, etc.= could ease the design of PERC.

Ones of the features affected with the current status are:
  1 - Video quality switching (simulcast)
  2 - Dominant Speaker switching

These features must also offer an high QoE for the users. For that,= the experience tells me that it should be performed in the SFU side. In= our current implementation:
  1 - Video quality switching (simulca= st) is performed rewriting SSRCs, seqnums and timestams
  2 - Domin= ant Speaker switching is performed rewriting SSRCs, seqnums andt timestams.= Notice that it would be consider and attack [1] when it= is the best way (easy, efficient and
with high QoE) we found to implem= ent this feature.

This is working in the WebRTC context using endpoints like Chrome or= Firefox. To implement them following current PERC status:
Could (1) be implemented without SSRCs rewriting and using RID instead= ?
I think so, but should be ensure that endpoints support that before= make SSRC immutable?
Could (2) be implemented without SSRCs rewriting and using MID instead= ? Could (2) be implemented even without adding a specific RTP stream using= idea [2]?
I think so, but should be ensure that endpoints suppo= rt that before make SSRC immutable?

These questions tell me that if endpoints does not support them, featu= res requested by the market and PERC will be incompatible :S.

Best regards!!

2016-05-26 1:12 GMT+02:00 Emil Ivov <emcho@jitsi.org>:<= BR>


On Wednesday, = 25 May 2016, Eric Rescorla <ekr@rtfm.com= > wrote:


On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <emcho@jitsi.org> wrote:


On 25.05.16 =D0= =B3. 15:20, Paul E. Jones wrote:
Emil,

You are saying = that endpoints would negotiate via signaling which SSRC
value(s) to use= before actually joining the conference?

It's awesome= how you would always attribute to me the least appealing of all possible= interpretations :).

Whether or not we negotiate SSRCs should not= be within PERC's scope. For the record this is how WebRTC works anyway = (courtesy of some of the people on this list) but the matter is completely= orthogonal to PERC.

What I was suggesting is the possibility for= PERC endpoints and MDD to negotiate whether or not they will be dealing= with a single end-to-end SSRC space, or whether they will have separate= HBH and E2E SSRC spaces.

This way you get to only implement the = single end-to-end option in your endpoints and to not support the other = one.

Does this make more sense?

That doesn't strike me as terri= bly appealing, honestly.  Between that
and the pain of dealing with= conflicting SSRCs, I might favor the
latter.  What I'd prefer most= , though, is neither and just let endpoints
do their thing.

I'd= still like to hear confirmation that receiving browsers will
definitely= be doing the right thing w.r.t. receiving simulcast streams.
Adam seeme= d to suggest Firefox will be doing the right thing (probably
before PERC= is done). What about popular browsers?

I think at this= point the answers that I've heard are for both browsers: we are not doing= this now.

As far as Firefox goes, we're not doing this now because PERC isn't= ready.
 
So you are saying that simulcast itself is not a good enough reason= to implement  receiver-side simulcast support ... but a minor= optimization to PERC is ...

Obviously I don't need to be explained the reasoning. I am= glad you have this plan.=20

I only wish we would have a clearer view of everyone's intended delive= ry dates since we are about to block PERC on them.


We're looking at it soon and plan to try to implement it pretty much= as soon as it's baked enough to do.


it's not part of webrtc 1.0.=

Is it even something that could be in WebRTC 1.0? I.e., does it requir= e changes?
How would you tell FF what group an RID corresponds to?

Emil 


 
we'd like to do it in the futur= e.

Yes.

-Ekr
 



What I'd like to avoid is= PERC having a firm dependence on this last statement and for it to only= be usable when it comes true.

Emil


Paul

------= Original Message ------
From: "Emil Ivov" <emcho@jitsi.org>= ;
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "Adam Roach" <adam@nostrum.com>; "Cullen Jennings" <= fluffy@iii.ca>;
perc@ietf.org
Sent: 5/25/2016 2:23:4= 3 PM
Subject: Re: [Perc] Request for decision review

Paul,

I have answered= your points below but we did gloss over the suggestion
I made and I = consider it important:

We can allow SSRC rewriting and make it negot= iable by signalling. This
way SFUs can state they support rewriting/immu= tability/both and
endpoints can choose to use what's available or reject= the session as
unsupported.

I believe this should address the= concerns that have been expressed so
far.

Now for the rest of= the points:

On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote:
Emil,

Since we are not enforcing a= requirement that endpoints select a
distinct SSRC per media flow, there= is a potential conflict in the
number space used E2E.
<= BR>As I have been insisting many times already: We have the option to
ma= ndate that SFUs preserve the SSRC space. That's not hard to
implement.= It's not a great option but it is a possibility.

We can also say= that whether or not SFUs do that rewrite is a feature
that has to be= signalled so clients can choose whether to support it
or not. This shou= ld address your concern.

The SFU has nothing to do with= the E2E SSRC collision problem.  When an
endpoints sends out an= RTP packet and it goes though an SFU that changes
the SSRC, there is= a HBH SSRC and an E2E SSRC.  I fully agree that the
SFU can ensure= that the HBH SSRCs do not collide, but it cannot control
the fact that= the E2E SSRCs collide.

The SFU has everytihng to do= with the E2E collision problem and it's
potential solutions. What you= describe is one way to handle things.
Another one would be to just make= SSRC conflicts obvious to senders so
that they would apply 3550 resolut= ion. That's pretty easy to implement.

The 64 bit identifier is just= a hack to work
around that problem. If the problem didn't exist, we = could use SSRC
values to look up the context as it was I intended in = SRTP.

E2E PERC is NOT SRTP. We may choose to make it= look like it is and I
see why that is appealing but not doing it is = by no means "a hack".

Of course it's SRTP.  It = just happens to be two passes of SRTP, but it's
nonetheless SRTP.

Exactly! And two passes of SRTP happen to NOT be SRTP as in:= no stock
SRTP endpoint would do anything meaningful with them. So what= you are
looking is to just optimize implementations, which is relevant= but not
the primary concern.

What PERC is adding are some= additional steps between
each pass for HBH authentication of packets= at the sender (and the
reverse at the receiver).  The MDD doesn't= have two steps: it just does
one normal SRTP decryption for the packet= received and one SRTP
encryption step sending the packet.  The = only special requirement PERC
introduces is that if the MDD changes eith= er the PT field or sequence
number, the original values have to be added= to the packet inside an RTP
header extension called OHB (if not already= present).


The problem with using a 64 = bit value is that any existing SRTP
library
would have to change to= associate the context that way.

So just to be clear= ... we are lamenting about changing an int to a
long?
<= BR>No, lamenting that this would not align with what RFC 3711 says to useto identify the context.

Again, 3711 applies to HBH.= We are trying to reuse as much of it for
E2E as possible and that's = admirable but it's not a reason why we
should significantly disrupt exis= ting implementations.

Further, if we
wish to break= up the PERC processing into two steps, that HBH SSRC
would
have to= be extracted and passed in by the application. While I
think the
int= ent with Double is for this to be an autonomous operation, it might
not= be implemented that way for two reasons:
1) If there is a desire to = do HBH FEC, the process might be to encrypt
E2E -> FEC -> HBH. = So the second call to the SRTP library would need
that HBH SSRC passed= in when doing these steps in reverse to introduce
that 64-bit context= ID.

Em ... you'd have to explain this in a bit more= detail because I fail
to see how FEC is any different than regular medi= a. As you say it
yourself, it all just works out properly as long as = you do your FEC
after E2E and before HBH as that way the SFU would be= able to de- or
re-FEC.

Historically, there were = two options for FEC.  Either we do FEC first
and then SRTP, or SRTP= first then FEC.  The order has to match at both
the sender and = receiver.  Either way, it generally makes very little
difference.
An MDD might want to be a good citizen and reconstruct lost packetsbefore sending a stream to a receiver.  In order to do that, the = sender
will either need to do SRTP (both passes) then FEC or it could= do the
first SRTP pass (the E2E encryption pass) then FEC then SRTP = for the
HBH.  It really depends on what we want that FEC flow to= look like.  Do
we want it to be FEC over a bunch of E2E+HBH encryp= ted packets or just
over the E2E packets.  (The latter would be = parallel to the current FEC
order of "FEC then SRTP".

So, thinkin= g of how this might be implemented in an SRTP library, if we
allow the= SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when the
application= encrypts the packet, it would pass the packet into the SRTP
libtary = once to encrypt HBH.

You mean E2E here.

 It then does whatever = FEC processing it
wants, then it calls into the SRTP library again to= encrypt the second
pass (HBH pass).  It could be two entirely inst= ances of the SRTP library
that handles each pass.  On the MDD, it= decrypts the flow and does
whatevever FEC magic it wants to do. = There is only one SRTP operation
at the MDD, so no problem.  At= the receiver, it decrypts the packet
received using HBH decryption. = It then does whatever FEC processing it
needs to do.  Next, it woul= d call into the SRTP library to decrypt for
E2E.  If the SSRCs neve= r change, this works fine.  One could implement
this using two inst= ances of an SRTP library today.  If a single library
is used, then= the only requirement is to ensure the second call into the
library does= not encounter issues with the replay database (since it
might otherwise= think it's a replayed packet).  In either case, the
crypto context= would be looked up as per RFC 3711 using SSRC.  If,
however, the= SSRC value is allowed to change, then the second call into
the SRTP = library (same or different instance of the library) would be a
problem= since Alice and Bob both used SSRC 1.  The collision is going to
p= revent the library from working properly.

I still fail= to see how FEC changes any of this (for better or worse).
The problem= you describe here is exactly the same with or without FEC
and it's what= we are having the argument about.

If we take the approach of usin= g a 64-bit identifier (in contradiction
to RFC 3711)
:) ... It is NOT in contradiction with 3711 because layers of
encryptio= ns are not part of 3711. We simply need to set the
expectations right= for implementers.

 to identify the crypto= context, then we would need to pass
that identifier into the SRTP libra= ry when attempting to decrypt the
packet, because it could not simply= discover it by looking at the packet
(which it could do normally since= the SSRC value is right there in the
packet).  It would be necessa= ry to make a call like
srtp_unprotect(context, packet, stream_identifiie= r) (where
stream_identifier is something that identifies the stream othe= r than the
SSRC per 3711, like E2E_SSRC || HBH_SSRC).

A beautiful= thing about SRTP today

You mean PERC here and not SRTP= (even if PERC does simply apply a
second srtp unprotect it is still = not stock 3711).

is the library can operate on= streams
without the application having to pass in such identifiers.&nbs= p; The stream
is self-identifying.  But, we lose that elegance when= we modify the SSRC
in the MDD when we break the operation into two pass= es to handle this
FEC order.

So we have an aesthetic= concern because we have to change int-s to
long-s and that's why we = are having a 100 mail thread. I am speechless.

2) It might be desirable to = implement the PERC logic by just having a
two-step wrapper around the= existing SRTP library to avoid making
changes to the core library. (I'd= prefer built-in support for Double,
but I can appreciate how some might= prefer to not change an otherwise
working library.)
As I said, being able to reuse SRTP libraries with no change is a
great= optimization if we get it but I really don't think the
alternative is= anywhere near the complexity that would justify banning
SSRC re-writing= .

At least we agree that it would be a good goal to = find an approach that
would eliminate or minimize changes to the SRTP= logic. :)

Now to the complexity part... that's in the thread you're= having with
Cullen which, as I understand, is an expression of a concer= n that
receiving endpoints are not going to properly handle multiple = simulcast
streams coming toward them.

Since I don't work for a= browser vendor, I cannot speak to their plans.
I can only assume that= proper handling of received simulcast flows would
be implemented per= the current drafts.  And if that's the case, then I
don't think= changing the SSRC would be needed.  If receiving endpoints
fail= to do that, then you're right that this could be a problem.

Let's be clear on this. There is absolutely nothing wrong or standard=
breaking in the way browsers handle simulcast reception today. They
= are simply not simulcast aware and the SFU hides it from them.

There= is no reason why that would be labelled a bad practice even when
RID= does go through all of the IETF process.

Also, the availability = of this option (simulcast unaware receivers)
and its existence today = make the motivation for RID support on the
receiving end pretty low. = It does not give you anything extra in terms
of functionality. There = are no substantial benefits from doing it (and
no it doesn't allow for= significantly simpler SFUs ... those would
still have to keep 95% of= their existing logic). We can decide to make
PERC dependent on it and= hope that this would sway all browser vendors
... or we could also try= to lower the burden on PERC adoption.

Again, as stated in the begin= ning of this mail: it sounds like a
compromise may lie in the option = for PERC to allow an SSRC rewriting
mode combined with the option for= endpoints to not support it. In
other words we can have part of the = PERC signalling indicate whether
the client and the server support these= modes and whether they use
them. This is not beautiful (by any means)= but it wouldn't prevent
either of us to do things their way.

Emi= l
-- https://jitsi.org



--
https://jit= si.org

_______________________________________________
Perc= mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo= /perc



--
sent from my mobile

_________= ______________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listi= nfo/perc




--
Miguel Par=C3=ADs D=C3=ADaz
-----------------------------= -------------------------------------------
Computer/Software engineer.<= BR>Researcher and architect in http://w= ww.kurento.org
http://twit= ter.com/mparisdiaz
-------------------------------------------------= -----------------------
--------=_MB314FC995-3571-4653-84B8-6CC9C9231C5E-- From nobody Wed Jul 20 05:49:14 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B70112D603 for ; Wed, 20 Jul 2016 05:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp4-FYIu2J-t for ; Wed, 20 Jul 2016 05:49:03 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 2447512D5F8 for ; Wed, 20 Jul 2016 05:49:03 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id o80so67440581wme.1 for ; Wed, 20 Jul 2016 05:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uSQh3IRht7+Z1d61fHVaZkP67MlbiQQmNlc1LE76FYY=; b=WnZOlkAanP5scKQ6xcU75AyhTJ3w5fHhRKK0Mk0pSyxSBQ3d/LPEH7Fs8H9yZgyXQV mt62L4XV9uosyUH8xzXxCYfJWpTtxvsWDG9+OfQ0I9J4YmtSM04D5akmsC3lBXPnLeDz tRWN7+BiuPbXIC8wJzG86x2Yjbikk0N2JeUPye9YHACGKVK2IP8NaQGLAUnoqSSKJ6CK 2AiXxWfTaLQcuz8eUImmrLauFZhdj9YhyWGWjJAEu1rEttLtgPbTiFytilc0uCSEF83T tNjTqfvYMx1LQgH85zgHECv8OoZQw+78eETy3VVe9AKjQqImsnnxdc0xEaUt/CVvJyV6 FMsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uSQh3IRht7+Z1d61fHVaZkP67MlbiQQmNlc1LE76FYY=; b=OvGsHFuWo+fSH1Pwz6X/SklOqOOBRsvxyAIDFVN4LficaF+OJdMvO1Z99o5Yrrpj26 vWA0UNZpmQgovRv+Y+xqtq9GVaAQK962JEXkDLoj1B7n6F6zHVtu6vkZa2gKk+5RE4Zk sJ8vqPRNaMH4nDJWjaEHnyqBpEBZQZg6zbY9oFxV13imuQon0hBCDe0uR2lb5oHYnshQ HV6a6sz7Ri8pvnqIM+nLjBiaItso2SAZ5UL7zk1rLzGQQYUdtJwanp2FMujYf6ylDM4E PdZCw41x0h8BRbxpt8vfEWBUzpw1Nr6WS/TdXyX3L1RHZgN1NA6IlbRNeyYykCOhP6h4 N3qw== X-Gm-Message-State: ALyK8tLD7TnJxo9a02JWciu1N8XZIrAV3VgamVK6CZx9ThL8P78VN26kbmTKNcuGhzl1WA== X-Received: by 10.194.57.197 with SMTP id k5mr1322775wjq.154.1469018941599; Wed, 20 Jul 2016 05:49:01 -0700 (PDT) Received: from [31.133.140.51] (dhcp-8c33.meeting.ietf.org. [31.133.140.51]) by smtp.gmail.com with ESMTPSA id s8sm1134475wjs.25.2016.07.20.05.49.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jul 2016 05:49:00 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-81E5CB0C-7138-40F1-8AF7-91AD8EEBEF9C Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Wed, 20 Jul 2016 14:48:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1EED1511-0EB6-45B7-B315-FE8606288BC5@gmail.com> References: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> To: =?utf-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Archived-At: Cc: Eric Rescorla , Adam Roach , Emil Ivov , "perc@ietf.org" , "Paul E. Jones" , Cullen Jennings Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:49:12 -0000 --Apple-Mail-81E5CB0C-7138-40F1-8AF7-91AD8EEBEF9C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Jul 20, 2016, at 12:56 PM, Miguel Par=C3=ADs D=C3=ADaz wrote: >=20 > These features must also offer an high QoE for the users. For that, the ex= perience tells me that it should be performed in the SFU side. > In our current implementation: > 1 - Video quality switching (simulcast) is performed by rewriting SSRCs,= seqnums and timestamps [BA] I assume you are talking about an SFU that provides a single stream per= participant to the receiver. Most existing SFU implementations operate that= way. Possible exception is SFUs supporting SVC with MRST which provide mult= iple streams and may not have to rewrite seqnums. > 2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums and= timestamps. Notice that it would be considered an attack [1] when it is the= best way (easy, efficient and=20 > with high QoE) we found to implement this feature. >=20 > This is working in the WebRTC context using endpoints like Chrome or Firef= ox. To implement them following current PERC status: > Could (1) be implemented without SSRCs rewriting and using RID instead? > I think so, but should be ensure that endpoints support that before make S= SRC immutable? > Could (2) be implemented without SSRCs rewriting and using MID instead? Co= uld (2) be implemented even without adding a specific RTP stream using idea [= 2]? > I think so, but should be ensure that endpoints support that before make S= SRC immutable? >=20 > These questions tell me that if endpoints does not support them, features r= equested by the market and PERC will be incompatible :S. >=20 > Best regards!! >=20 > Refs > [1] https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-= 7.2.4 > [2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html >=20 > 2016-05-26 1:12 GMT+02:00 Emil Ivov : >>=20 >>=20 >>> On Wednesday, 25 May 2016, Eric Rescorla wrote: >>>=20 >>>=20 >>>> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov wrote: >>>>=20 >>>>=20 >>>>> On 25.05.16 =D0=B3. 15:20, Paul E. Jones wrote: >>>>> Emil, >>>>>=20 >>>>> You are saying that endpoints would negotiate via signaling which SSRC= >>>>> value(s) to use before actually joining the conference? >>>>=20 >>>> It's awesome how you would always attribute to me the least appealing o= f all possible interpretations :). >>>>=20 >>>> Whether or not we negotiate SSRCs should not be within PERC's scope. Fo= r the record this is how WebRTC works anyway (courtesy of some of the people= on this list) but the matter is completely orthogonal to PERC. >>>>=20 >>>> What I was suggesting is the possibility for PERC endpoints and MDD to n= egotiate whether or not they will be dealing with a single end-to-end SSRC s= pace, or whether they will have separate HBH and E2E SSRC spaces. >>>>=20 >>>> This way you get to only implement the single end-to-end option in your= endpoints and to not support the other one. >>>>=20 >>>> Does this make more sense? >>>>=20 >>>>> That doesn't strike me as terribly appealing, honestly. Between that >>>>> and the pain of dealing with conflicting SSRCs, I might favor the >>>>> latter. What I'd prefer most, though, is neither and just let endpoin= ts >>>>> do their thing. >>>>>=20 >>>>> I'd still like to hear confirmation that receiving browsers will >>>>> definitely be doing the right thing w.r.t. receiving simulcast streams= . >>>>> Adam seemed to suggest Firefox will be doing the right thing (probably= >>>>> before PERC is done). What about popular browsers? >>>>=20 >>>> I think at this point the answers that I've heard are for both browsers= : we are not doing this now. >>>=20 >>> As far as Firefox goes, we're not doing this now because PERC isn't read= y. >> =20 >> So you are saying that simulcast itself is not a good enough reason to im= plement receiver-side simulcast support ... but a minor optimization to PER= C is ... >>=20 >> Obviously I don't need to be explained the reasoning. I am glad you have t= his plan. >>=20 >> I only wish we would have a clearer view of everyone's intended delivery d= ates since we are about to block PERC on them. >>=20 >>=20 >>> We're looking at it soon and plan to try to implement it pretty much as s= oon as it's baked enough to do. >>>=20 >>>=20 >>>> it's not part of webrtc 1.0. >>>=20 >>> Is it even something that could be in WebRTC 1.0? I.e., does it require c= hanges? >>=20 >> How would you tell FF what group an RID corresponds to? >>=20 >> Emil=20 >>>=20 >>>=20 >>> =20 >>>> we'd like to do it in the future. >>>=20 >>> Yes. >>>=20 >>> -Ekr >>> =20 >>>=20 >>>=20 >>>>=20 >>>> What I'd like to avoid is PERC having a firm dependence on this last st= atement and for it to only be usable when it comes true. >>>>=20 >>>> Emil >>>>=20 >>>>>=20 >>>>> Paul >>>>>=20 >>>>> ------ Original Message ------ >>>>> From: "Emil Ivov" >>>>> To: "Paul E. Jones" >>>>> Cc: "Adam Roach" ; "Cullen Jennings" = ; >>>>> perc@ietf.org >>>>> Sent: 5/25/2016 2:23:43 PM >>>>> Subject: Re: [Perc] Request for decision review >>>>>=20 >>>>>> Paul, >>>>>>=20 >>>>>> I have answered your points below but we did gloss over the suggestio= n >>>>>> I made and I consider it important: >>>>>>=20 >>>>>> We can allow SSRC rewriting and make it negotiable by signalling. Thi= s >>>>>> way SFUs can state they support rewriting/immutability/both and >>>>>> endpoints can choose to use what's available or reject the session as= >>>>>> unsupported. >>>>>>=20 >>>>>> I believe this should address the concerns that have been expressed s= o >>>>>> far. >>>>>>=20 >>>>>> Now for the rest of the points: >>>>>>=20 >>>>>>> On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote: >>>>>>> Emil, >>>>>>>=20 >>>>>>>>> Since we are not enforcing a requirement that endpoints select a >>>>>>>>> distinct SSRC per media flow, there is a potential conflict in the= >>>>>>>>> number space used E2E. >>>>>>>>=20 >>>>>>>> As I have been insisting many times already: We have the option to >>>>>>>> mandate that SFUs preserve the SSRC space. That's not hard to >>>>>>>> implement. It's not a great option but it is a possibility. >>>>>>>>=20 >>>>>>>> We can also say that whether or not SFUs do that rewrite is a featu= re >>>>>>>> that has to be signalled so clients can choose whether to support i= t >>>>>>>> or not. This should address your concern. >>>>>>>=20 >>>>>>> The SFU has nothing to do with the E2E SSRC collision problem. When= an >>>>>>> endpoints sends out an RTP packet and it goes though an SFU that cha= nges >>>>>>> the SSRC, there is a HBH SSRC and an E2E SSRC. I fully agree that t= he >>>>>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot cont= rol >>>>>>> the fact that the E2E SSRCs collide. >>>>>>=20 >>>>>> The SFU has everytihng to do with the E2E collision problem and it's >>>>>> potential solutions. What you describe is one way to handle things. >>>>>> Another one would be to just make SSRC conflicts obvious to senders s= o >>>>>> that they would apply 3550 resolution. That's pretty easy to implemen= t. >>>>>>=20 >>>>>>>>> The 64 bit identifier is just a hack to work >>>>>>>>> around that problem. If the problem didn't exist, we could use SSR= C >>>>>>>>> values to look up the context as it was I intended in SRTP. >>>>>>>>=20 >>>>>>>> E2E PERC is NOT SRTP. We may choose to make it look like it is and I= >>>>>>>> see why that is appealing but not doing it is by no means "a hack".= >>>>>>>=20 >>>>>>> Of course it's SRTP. It just happens to be two passes of SRTP, but i= t's >>>>>>> nonetheless SRTP. >>>>>>=20 >>>>>> Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock= >>>>>> SRTP endpoint would do anything meaningful with them. So what you are= >>>>>> looking is to just optimize implementations, which is relevant but no= t >>>>>> the primary concern. >>>>>>=20 >>>>>>> What PERC is adding are some additional steps between >>>>>>> each pass for HBH authentication of packets at the sender (and the >>>>>>> reverse at the receiver). The MDD doesn't have two steps: it just d= oes >>>>>>> one normal SRTP decryption for the packet received and one SRTP >>>>>>> encryption step sending the packet. The only special requirement PE= RC >>>>>>> introduces is that if the MDD changes either the PT field or sequenc= e >>>>>>> number, the original values have to be added to the packet inside an= RTP >>>>>>> header extension called OHB (if not already present). >>>>>>>=20 >>>>>>>=20 >>>>>>>>> The problem with using a 64 bit value is that any existing SRTP >>>>>>>>> library >>>>>>>>> would have to change to associate the context that way. >>>>>>>>=20 >>>>>>>> So just to be clear ... we are lamenting about changing an int to a= >>>>>>>> long? >>>>>>>=20 >>>>>>> No, lamenting that this would not align with what RFC 3711 says to u= se >>>>>>> to identify the context. >>>>>>=20 >>>>>> Again, 3711 applies to HBH. We are trying to reuse as much of it for >>>>>> E2E as possible and that's admirable but it's not a reason why we >>>>>> should significantly disrupt existing implementations. >>>>>>=20 >>>>>>>>> Further, if we >>>>>>>>> wish to break up the PERC processing into two steps, that HBH SSRC= >>>>>>>>> would >>>>>>>>> have to be extracted and passed in by the application. While I >>>>>>>>> think the >>>>>>>>> intent with Double is for this to be an autonomous operation, it m= ight >>>>>>>>> not be implemented that way for two reasons: >>>>>>>>> 1) If there is a desire to do HBH FEC, the process might be to enc= rypt >>>>>>>>> E2E -> FEC -> HBH. So the second call to the SRTP library would ne= ed >>>>>>>>> that HBH SSRC passed in when doing these steps in reverse to intro= duce >>>>>>>>> that 64-bit context ID. >>>>>>>>=20 >>>>>>>> Em ... you'd have to explain this in a bit more detail because I fa= il >>>>>>>> to see how FEC is any different than regular media. As you say it >>>>>>>> yourself, it all just works out properly as long as you do your FEC= >>>>>>>> after E2E and before HBH as that way the SFU would be able to de- o= r >>>>>>>> re-FEC. >>>>>>>=20 >>>>>>> Historically, there were two options for FEC. Either we do FEC firs= t >>>>>>> and then SRTP, or SRTP first then FEC. The order has to match at bo= th >>>>>>> the sender and receiver. Either way, it generally makes very little= >>>>>>> difference. >>>>>>>=20 >>>>>>> An MDD might want to be a good citizen and reconstruct lost packets >>>>>>> before sending a stream to a receiver. In order to do that, the sen= der >>>>>>> will either need to do SRTP (both passes) then FEC or it could do th= e >>>>>>> first SRTP pass (the E2E encryption pass) then FEC then SRTP for the= >>>>>>> HBH. It really depends on what we want that FEC flow to look like. = Do >>>>>>> we want it to be FEC over a bunch of E2E+HBH encrypted packets or ju= st >>>>>>> over the E2E packets. (The latter would be parallel to the current = FEC >>>>>>> order of "FEC then SRTP". >>>>>>>=20 >>>>>>> So, thinking of how this might be implemented in an SRTP library, if= we >>>>>>> allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when th= e >>>>>>> application encrypts the packet, it would pass the packet into the S= RTP >>>>>>> libtary once to encrypt HBH. >>>>>>=20 >>>>>> You mean E2E here. >>>>>>=20 >>>>>>> It then does whatever FEC processing it >>>>>>> wants, then it calls into the SRTP library again to encrypt the seco= nd >>>>>>> pass (HBH pass). It could be two entirely instances of the SRTP lib= rary >>>>>>> that handles each pass. On the MDD, it decrypts the flow and does >>>>>>> whatevever FEC magic it wants to do. There is only one SRTP operati= on >>>>>>> at the MDD, so no problem. At the receiver, it decrypts the packet >>>>>>> received using HBH decryption. It then does whatever FEC processing i= t >>>>>>> needs to do. Next, it would call into the SRTP library to decrypt f= or >>>>>>> E2E. If the SSRCs never change, this works fine. One could impleme= nt >>>>>>> this using two instances of an SRTP library today. If a single libr= ary >>>>>>> is used, then the only requirement is to ensure the second call into= the >>>>>>> library does not encounter issues with the replay database (since it= >>>>>>> might otherwise think it's a replayed packet). In either case, the >>>>>>> crypto context would be looked up as per RFC 3711 using SSRC. If, >>>>>>> however, the SSRC value is allowed to change, then the second call i= nto >>>>>>> the SRTP library (same or different instance of the library) would b= e a >>>>>>> problem since Alice and Bob both used SSRC 1. The collision is goin= g to >>>>>>> prevent the library from working properly. >>>>>>=20 >>>>>> I still fail to see how FEC changes any of this (for better or worse)= . >>>>>> The problem you describe here is exactly the same with or without FEC= >>>>>> and it's what we are having the argument about. >>>>>>=20 >>>>>>> If we take the approach of using a 64-bit identifier (in contradicti= on >>>>>>> to RFC 3711) >>>>>>=20 >>>>>> :) ... It is NOT in contradiction with 3711 because layers of >>>>>> encryptions are not part of 3711. We simply need to set the >>>>>> expectations right for implementers. >>>>>>=20 >>>>>>> to identify the crypto context, then we would need to pass >>>>>>> that identifier into the SRTP library when attempting to decrypt the= >>>>>>> packet, because it could not simply discover it by looking at the pa= cket >>>>>>> (which it could do normally since the SSRC value is right there in t= he >>>>>>> packet). It would be necessary to make a call like >>>>>>> srtp_unprotect(context, packet, stream_identifiier) (where >>>>>>> stream_identifier is something that identifies the stream other than= the >>>>>>> SSRC per 3711, like E2E_SSRC || HBH_SSRC). >>>>>>>=20 >>>>>>> A beautiful thing about SRTP today >>>>>>=20 >>>>>> You mean PERC here and not SRTP (even if PERC does simply apply a >>>>>> second srtp unprotect it is still not stock 3711). >>>>>>=20 >>>>>>> is the library can operate on streams >>>>>>> without the application having to pass in such identifiers. The str= eam >>>>>>> is self-identifying. But, we lose that elegance when we modify the S= SRC >>>>>>> in the MDD when we break the operation into two passes to handle thi= s >>>>>>> FEC order. >>>>>>=20 >>>>>> So we have an aesthetic concern because we have to change int-s to >>>>>> long-s and that's why we are having a 100 mail thread. I am speechles= s. >>>>>>=20 >>>>>>>>> 2) It might be desirable to implement the PERC logic by just havin= g a >>>>>>>>> two-step wrapper around the existing SRTP library to avoid making >>>>>>>>> changes to the core library. (I'd prefer built-in support for Doub= le, >>>>>>>>> but I can appreciate how some might prefer to not change an otherw= ise >>>>>>>>> working library.) >>>>>>>>=20 >>>>>>>> As I said, being able to reuse SRTP libraries with no change is a >>>>>>>> great optimization if we get it but I really don't think the >>>>>>>> alternative is anywhere near the complexity that would justify bann= ing >>>>>>>> SSRC re-writing. >>>>>>>=20 >>>>>>> At least we agree that it would be a good goal to find an approach t= hat >>>>>>> would eliminate or minimize changes to the SRTP logic. :) >>>>>>>=20 >>>>>>> Now to the complexity part... that's in the thread you're having wit= h >>>>>>> Cullen which, as I understand, is an expression of a concern that >>>>>>> receiving endpoints are not going to properly handle multiple simulc= ast >>>>>>> streams coming toward them. >>>>>>>=20 >>>>>>> Since I don't work for a browser vendor, I cannot speak to their pla= ns. >>>>>>> I can only assume that proper handling of received simulcast flows w= ould >>>>>>> be implemented per the current drafts. And if that's the case, then= I >>>>>>> don't think changing the SSRC would be needed. If receiving endpoin= ts >>>>>>> fail to do that, then you're right that this could be a problem. >>>>>>=20 >>>>>> Let's be clear on this. There is absolutely nothing wrong or standard= >>>>>> breaking in the way browsers handle simulcast reception today. They >>>>>> are simply not simulcast aware and the SFU hides it from them. >>>>>>=20 >>>>>> There is no reason why that would be labelled a bad practice even whe= n >>>>>> RID does go through all of the IETF process. >>>>>>=20 >>>>>> Also, the availability of this option (simulcast unaware receivers) >>>>>> and its existence today make the motivation for RID support on the >>>>>> receiving end pretty low. It does not give you anything extra in term= s >>>>>> of functionality. There are no substantial benefits from doing it (an= d >>>>>> no it doesn't allow for significantly simpler SFUs ... those would >>>>>> still have to keep 95% of their existing logic). We can decide to mak= e >>>>>> PERC dependent on it and hope that this would sway all browser vendor= s >>>>>> ... or we could also try to lower the burden on PERC adoption. >>>>>>=20 >>>>>> Again, as stated in the beginning of this mail: it sounds like a >>>>>> compromise may lie in the option for PERC to allow an SSRC rewriting >>>>>> mode combined with the option for endpoints to not support it. In >>>>>> other words we can have part of the PERC signalling indicate whether >>>>>> the client and the server support these modes and whether they use >>>>>> them. This is not beautiful (by any means) but it wouldn't prevent >>>>>> either of us to do things their way. >>>>>>=20 >>>>>> Emil >>>>>> -- https://jitsi.org >>>>=20 >>>> --=20 >>>> https://jitsi.org >>>>=20 >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>=20 >>=20 >> --=20 >> sent from my mobile >>=20 >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >=20 >=20 >=20 > --=20 > Miguel Par=C3=ADs D=C3=ADaz > ------------------------------------------------------------------------ > Computer/Software engineer. > Researcher and architect in http://www.kurento.org > http://twitter.com/mparisdiaz > ------------------------------------------------------------------------ > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail-81E5CB0C-7138-40F1-8AF7-91AD8EEBEF9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 20, 2016, at 12:56 P= M, Miguel Par=C3=ADs D=C3=ADaz <m= parisdiaz@gmail.com> wrote:

These features must also offer an h= igh QoE for the users. For that, the experience tells me that it should be p= erformed in the SFU side.

In our current im= plementation:
  1 - Video quality switching (simulcast) is performed= by rewriting SSRCs, seqnums and timestamps

[BA] I assume you are talking about an SFU that= provides a single stream per participant to the receiver. Most existing SFU= implementations operate that way. Possible exception is SFUs supporting SVC= with MRST which provide multiple streams and may not have to rewrite seqnum= s.

&n= bsp; 2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums a= nd timestamps. Notice that it would be considered an attack [1] when it is the best way (easy, efficient and
with h= igh QoE) we found to implement this feature.

This is= working in the WebRTC context using endpoints like Chrome or Firefox. To im= plement them following current PERC status:
Could (1) be i= mplemented without SSRCs rewriting and using RID instead?
I think so, but= should be ensure that endpoints support that before make SSRC immutable?
Could (2) be implemented without SSRCs rewriting and using MID i= nstead? Could (2) be implemented even without adding a specific RTP stream u= sing idea [2]?
I think so, but should be ensure t= hat endpoints support that before make SSRC immutable?

The= se questions tell me that if endpoints does not support them, features reque= sted by the market and PERC will be incompatible :S.

2016-05-26 1:12 GMT+02:00 Emil Ivov= <= emcho@jitsi.org>:


On Wednesday, 25 May 2016, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <emcho@jitsi.org> wrote:


On 25.05.16 =D0=B3. 15:20, Paul E. Jones wrote:
Emil,

You are saying that endpoints would negotiate via signaling which SSRC
value(s) to use before actually joining the conference?

It's awesome how you would always attribute to me the least appealing of all= possible interpretations :).

Whether or not we negotiate SSRCs should not be within PERC's scope. For the= record this is how WebRTC works anyway (courtesy of some of the people on t= his list) but the matter is completely orthogonal to PERC.

What I was suggesting is the possibility for PERC endpoints and MDD to negot= iate whether or not they will be dealing with a single end-to-end SSRC space= , or whether they will have separate HBH and E2E SSRC spaces.

This way you get to only implement the single end-to-end option in your endp= oints and to not support the other one.

Does this make more sense?

That doesn't strike me as terribly appealing, honestly.  Between that and the pain of dealing with conflicting SSRCs, I might favor the
latter.  What I'd prefer most, though, is neither and just let endpoint= s
do their thing.

I'd still like to hear confirmation that receiving browsers will
definitely be doing the right thing w.r.t. receiving simulcast streams.
Adam seemed to suggest Firefox will be doing the right thing (probably
before PERC is done). What about popular browsers?

I think at this point the answers that I've heard are for both browsers: we a= re not doing this now.

As far as Firefox goe= s, we're not doing this now because PERC isn't ready.
 
So you are saying that simulcast i= tself is not a good enough reason to implement  receiver-side simu= lcast support ... but a minor optimization to PERC is ...
Obviously I don't need to be explained the reasoning. I am glad you h= ave this plan.

I only wish we would have a clearer view o= f everyone's intended delivery dates since we are about to block PERC on the= m.


We're looking at it soon and plan to try to implement it pre= tty much as soon as it's baked enough to do.


it's not part of webrtc 1.0.

Is it even something that could be in WebRTC 1.0? I.e.,= does it require changes?

How would you tell FF what group an RID corresponds to?

Emil <= /div>


 
we'd like to= do it in the future.

Yes.
-Ekr
 



What I'd like to avoid is PERC having a firm dependence on this last stateme= nt and for it to only be usable when it comes true.

Emil


Paul

------ Original Message ------
From: "Emil Ivov" <emcho@jitsi.org>
To: "Paul E. Jones" <paulej@packetizer.com>
 Cc: "Adam Roach" <adam@nostrum.com>; "Cullen Jennings" <f= luffy@iii.ca>;
perc@ietf.org
Sent: 5/25/2016 2:23:43 PM
Subject: Re: [Perc] Request for decision review

Paul,

I have answered your points below but we did gloss over the suggestion
I made and I consider it important:

We can allow SSRC rewriting and make it negotiable by signalling. This
way SFUs can state they support rewriting/immutability/both and
endpoints can choose to use what's available or reject the session as
unsupported.

I believe this should address the concerns that have been expressed so
far.

Now for the rest of the points:

On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote:
Emil,

Since we are not enforcing a requirement that endpoints select a
distinct SSRC per media flow, there is a potential conflict in the
number space used E2E.

As I have been insisting many times already: We have the option to
mandate that SFUs preserve the SSRC space. That's not hard to
implement. It's not a great option but it is a possibility.

We can also say that whether or not SFUs do that rewrite is a feature
that has to be signalled so clients can choose whether to support it
or not. This should address your concern.

The SFU has nothing to do with the E2E SSRC collision problem.  When an=
endpoints sends out an RTP packet and it goes though an SFU that changes
= the SSRC, there is a HBH SSRC and an E2E SSRC.  I fully agree that the<= br> SFU can ensure that the HBH SSRCs do not collide, but it cannot control
the fact that the E2E SSRCs collide.

The SFU has everytihng to do with the E2E collision problem and it's
potential solutions. What you describe is one way to handle things.
Another one would be to just make SSRC conflicts obvious to senders so
that they would apply 3550 resolution. That's pretty easy to implement.

The 64 bit identifier is just a hack to work
around that problem. If the problem didn't exist, we could use SSRC
values to look up the context as it was I intended in SRTP.

E2E PERC is NOT SRTP. We may choose to make it look like it is and I
see why that is appealing but not doing it is by no means "a hack".

Of course it's SRTP.  It just happens to be two passes of SRTP, but it'= s
nonetheless SRTP.

Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock
SRTP endpoint would do anything meaningful with them. So what you are
looking is to just optimize implementations, which is relevant but not
the primary concern.

What PERC is adding are some additional steps between
each pass for HBH authentication of packets at the sender (and the
reverse at the receiver).  The MDD doesn't have two steps: it just does=
one normal SRTP decryption for the packet received and one SRTP
encryption step sending the packet.  The only special requirement PERC<= br> introduces is that if the MDD changes either the PT field or sequence
number, the original values have to be added to the packet inside an RTP
= header extension called OHB (if not already present).


The problem with using a 64 bit value is that any existing SRTP
library
would have to change to associate the context that way.

So just to be clear ... we are lamenting about changing an int to a
long?

No, lamenting that this would not align with what RFC 3711 says to use
to identify the context.

Again, 3711 applies to HBH. We are trying to reuse as much of it for
E2E as possible and that's admirable but it's not a reason why we
should significantly disrupt existing implementations.

Further, if we
wish to break up the PERC processing into two steps, that HBH SSRC
would
have to be extracted and passed in by the application. While I
think the
intent with Double is for this to be an autonomous operation, it might
not be implemented that way for two reasons:
1) If there is a desire to do HBH FEC, the process might be to encrypt
E2E -> FEC -> HBH. So the second call to the SRTP library would need that HBH SSRC passed in when doing these steps in reverse to introduce
that 64-bit context ID.

Em ... you'd have to explain this in a bit more detail because I fail
to see how FEC is any different than regular media. As you say it
yourself, it all just works out properly as long as you do your FEC
after E2E and before HBH as that way the SFU would be able to de- or
re-FEC.

Historically, there were two options for FEC.  Either we do FEC first and then SRTP, or SRTP first then FEC.  The order has to match at both<= br> the sender and receiver.  Either way, it generally makes very little difference.

An MDD might want to be a good citizen and reconstruct lost packets
before sending a stream to a receiver.  In order to do that, the sender=
will either need to do SRTP (both passes) then FEC or it could do the
first SRTP pass (the E2E encryption pass) then FEC then SRTP for the
HBH.  It really depends on what we want that FEC flow to look like.&nbs= p; Do
we want it to be FEC over a bunch of E2E+HBH encrypted packets or just
over the E2E packets.  (The latter would be parallel to the current FEC=
order of "FEC then SRTP".

So, thinking of how this might be implemented in an SRTP library, if we
allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when the
application encrypts the packet, it would pass the packet into the SRTP
libtary once to encrypt HBH.

You mean E2E here.

 It then does whatever FEC processing it
wants, then it calls into the SRTP library again to encrypt the second
pass (HBH pass).  It could be two entirely instances of the SRTP librar= y
that handles each pass.  On the MDD, it decrypts the flow and does
whatevever FEC magic it wants to do.  There is only one SRTP operation<= br> at the MDD, so no problem.  At the receiver, it decrypts the packet
= received using HBH decryption. It then does whatever FEC processing it
needs to do.  Next, it would call into the SRTP library to decrypt for<= br> E2E.  If the SSRCs never change, this works fine.  One could imple= ment
this using two instances of an SRTP library today.  If a single library=
is used, then the only requirement is to ensure the second call into the
= library does not encounter issues with the replay database (since it
might otherwise think it's a replayed packet).  In either case, the
= crypto context would be looked up as per RFC 3711 using SSRC.  If,
however, the SSRC value is allowed to change, then the second call into
the SRTP library (same or different instance of the library) would be a
problem since Alice and Bob both used SSRC 1.  The collision is going t= o
prevent the library from working properly.

I still fail to see how FEC changes any of this (for better or worse).
The problem you describe here is exactly the same with or without FEC
and it's what we are having the argument about.

If we take the approach of using a 64-bit identifier (in contradiction
to RFC 3711)

:) ... It is NOT in contradiction with 3711 because layers of
encryptions are not part of 3711. We simply need to set the
expectations right for implementers.

 to identify the crypto context, then we would need to pass
that identifier into the SRTP library when attempting to decrypt the
packet, because it could not simply discover it by looking at the packet
= (which it could do normally since the SSRC value is right there in the
packet).  It would be necessary to make a call like
srtp_unprotect(context, packet, stream_identifiier) (where
stream_identifier is something that identifies the stream other than the
= SSRC per 3711, like E2E_SSRC || HBH_SSRC).

A beautiful thing about SRTP today

You mean PERC here and not SRTP (even if PERC does simply apply a
second srtp unprotect it is still not stock 3711).

is the library can operate on streams
without the application having to pass in such identifiers.  The stream=
is self-identifying.  But, we lose that elegance when we modify the SSR= C
in the MDD when we break the operation into two passes to handle this
FEC order.

So we have an aesthetic concern because we have to change int-s to
long-s and that's why we are having a 100 mail thread. I am speechless.

2) It might be desirable to implement the PERC logic by just having a
two-step wrapper around the existing SRTP library to avoid making
changes to the core library. (I'd prefer built-in support for Double,
but I can appreciate how some might prefer to not change an otherwise
working library.)

As I said, being able to reuse SRTP libraries with no change is a
great optimization if we get it but I really don't think the
alternative is anywhere near the complexity that would justify banning
SSRC re-writing.

At least we agree that it would be a good goal to find an approach that
would eliminate or minimize changes to the SRTP logic. :)

Now to the complexity part... that's in the thread you're having with
Cullen which, as I understand, is an expression of a concern that
receiving endpoints are not going to properly handle multiple simulcast
streams coming toward them.

Since I don't work for a browser vendor, I cannot speak to their plans.
I can only assume that proper handling of received simulcast flows would
= be implemented per the current drafts.  And if that's the case, then I<= br> don't think changing the SSRC would be needed.  If receiving endpoints<= br> fail to do that, then you're right that this could be a problem.

Let's be clear on this. There is absolutely nothing wrong or standard
breaking in the way browsers handle simulcast reception today. They
are simply not simulcast aware and the SFU hides it from them.

There is no reason why that would be labelled a bad practice even when
RID does go through all of the IETF process.

Also, the availability of this option (simulcast unaware receivers)
and its existence today make the motivation for RID support on the
receiving end pretty low. It does not give you anything extra in terms
of functionality. There are no substantial benefits from doing it (and
no it doesn't allow for significantly simpler SFUs ... those would
still have to keep 95% of their existing logic). We can decide to make
PERC dependent on it and hope that this would sway all browser vendors
... or we could also try to lower the burden on PERC adoption.

Again, as stated in the beginning of this mail: it sounds like a
compromise may lie in the option for PERC to allow an SSRC rewriting
mode combined with the option for endpoints to not support it. In
other words we can have part of the PERC signalling indicate whether
the client and the server support these modes and whether they use
them. This is not beautiful (by any means) but it wouldn't prevent
either of us to do things their way.

Emil
-- https:= //jitsi.org



--
https://j= itsi.org

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


<= br>--
sent from my mobile

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




--
Miguel Par=C3= =ADs D=C3=ADaz
----------------------------------------------------------= --------------
Computer/Software engineer.
Researcher and architect in= http://www.kurento.org=
http://t= witter.com/mparisdiaz
-----------------------------------------------= -------------------------
____________________= ___________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman= /listinfo/perc
= --Apple-Mail-81E5CB0C-7138-40F1-8AF7-91AD8EEBEF9C-- From nobody Wed Jul 20 07:35:32 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C006312D834 for ; Wed, 20 Jul 2016 07:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fE4CQgkDUUN for ; Wed, 20 Jul 2016 07:35:19 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 5370212D776 for ; Wed, 20 Jul 2016 07:35:18 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id i5so71923647wmg.0 for ; Wed, 20 Jul 2016 07:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TOyPzMBOQ5ZeIj5pL5/R/e5NaZG9bR3MHWvjh5+McmI=; b=NK0BD+mTxnREg/kouqkoZ/CDQQnHnMZDMJNFWkRa9wBMrEuTMicppc2zmXzBqbycmr msr9IFsFTnBdgD8nLuJAoyI0wlaHBDQXnFu2Gx88n0qf0Op6DQnZxraquxVd5L6Nb3xY Zl9YI/CB8/GyAro/8uXachtP7qQuvGoPw8hOASH4Uw9pMNpmZ6q4d3RsnzP2fkeVd+S6 SbUq1S7U5lxpHiWCvIIRuaLOaWYxntL5fVjJh25TGt+MVLf8PnSw32vq79qlU0uw/lzC N4BC+bB+2EOxlq80YnWiraVW7ZX/dQkT8ejNva+jULYC6ngYkM14J12T+x3ejsTBMxKH K7CQ== 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; bh=TOyPzMBOQ5ZeIj5pL5/R/e5NaZG9bR3MHWvjh5+McmI=; b=KEAo4H0DZWh9je56p0z18x+F5uqohoy3hntEEdgG2ByIyW6f+OeQJvgF20QAmwvoI/ C91K8FB0oF7v7RLvCcJyt+wTcKcAUJILOF2ZWRmB3ki53T2QONECruD4SHBBtTEPEy2M g2Qr2N60A+fJttchz0R7n/4R37Dlv6C7svM1b0zTJRG+28XezqhP3nLPM8/+3loweDOL yzCapBWMMRRdisHRN8f8Ab6hMpu0gWGYz1w995awf9hS9S3fjBgWJTr5aCgi09TxezBz fU810II1MqVuPMVkn6FuI2+TnbbXC0zpHBsh4QYRIsfZfjabPBiXcC36ijUtQ/UKrMT1 TygA== X-Gm-Message-State: ALyK8tJuCgQrvwFQsWLc8atMLtDvNqNv2tQnWFWCaIFGoEeVc4XoFcNoi42FqU8LXttqgRn4TDYCNRMoLtKuYQ== X-Received: by 10.194.243.2 with SMTP id wu2mr1661533wjc.104.1469025316521; Wed, 20 Jul 2016 07:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.117.67 with HTTP; Wed, 20 Jul 2016 07:35:15 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Wed, 20 Jul 2016 16:35:15 +0200 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e013d1d622850a50538121c2f Archived-At: Cc: Adam Roach , Eric Rescorla , Emil Ivov , "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 14:35:30 -0000 --089e013d1d622850a50538121c2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Paul, we rewrite the SSRC because currently it is the way to associate a MediaStreamTrack to an RTP stream. Analysing the case of video quality switching (simulcast): - Rewriting SSRCs at the SFU side improves the QoE a lot due the switch is transparent for the endpoint which receives the RTP stream, applies t= he JitterBuffer, decrypts it, creates encoded frames, decodes frames, appli= es sync-buffer (for interstream synchronization (typically audio and video)= ) and renders the video. So the logic in the client is quite easier and smooth when switchings. - If we do NOT do that, the another possibility (I didn't found others) is negotiating with the receiver N SSRCs (each one per quality) performi= ng ON/OFF at the SFU side and doing the switching in the receiver. For doin= g that: - You have N MediaStreamTracks. - You have to detect at application layer when a MediaStreamTrack stops receiving media using getUserMedia API's events (which takes at least 500ms) - You have to detect the the new enabled MediaStreamTrack, which can take a lot of times due to JitterBuffer restarting, decoder restarting, etc. - You have to deal with audio-video synchronization that may be quite difficult. - The endpoint uses more resources (CPU and memory) - etc. - In conclusion it is a pain for the users because they see freeze video time to time (the QoE is very bad) - Rewriting timestamps is needed because there are usually some offsets between different qualities. 2016-07-20 14:34 GMT+02:00 Paul E. Jones : > Miguel, > > The current design of PERC is one where there is an E2E encryption step > using regular SRTP. An intermediary does not have the E2E keys and, > therefore, cannot change anything about the packet. Then, that packet is > encrypted HBH using a different key that the next hop device will have. > Assuming the next hop device is an MDD (nor "Media Distributor"), that > device could have the liberty of changing the sequence numbers and, in > fact, it will be obliged to do so if it does not always forward all of th= e > streams (since not forwarding some streams will mean the cryptographic > context gets out of sync). > > So in the typical case, the MDD will change the sequence number and might > insert a new header extension to carry the original value. It might also > change the payload type value. > > How, as the endpoint receives a packet, it will decrypt the HBH packet an= d > reconstruct the E2E packet using the OHB field. But what is there? Well= , > it's the original packet as created by the sending endpoint. Even if we > change the SSRC or sequence number, the original values are there and > preserved. So, other than out of necessity (sequence number changed to > keep crypto context in sync and PT changed to ensure the right PT value i= s > received as expected), I'm still not convinced that changing the SSRC > really buys us anything. Sure, we could change it. We actually has spac= e > in the OHB originally to allow that. But for what purpose? Changing or > not changing an SSRC value should not have any affect whatsoever on the > QoE. (I'm not saying the SSRC has no importance, but I question the nee= d > to rewrite them.) > > I'm not sure how the other identifiers you mention might help improve > QoE. Maybe expand on that little? > > One important point to consider in all of this is that WebRTC browsers > MUST be PERC-aware, else they cannot participate in conferences. If > they're not PERC-aware, then there would have to be a middlebox that > "downgrades" for those older browsers and it can rewrite whatever it want= s, > since it would be in possession of keys and would strip off one layer of > encryption to produce a legacy SRTP flow (or no SRTP at all). > > Paul > > ------ Original Message ------ > From: "Miguel Par=C3=ADs D=C3=ADaz" > To: "Emil Ivov" > Cc: "Eric Rescorla" ; "Paul E. Jones" ; > "Adam Roach" ; "perc@ietf.org" ; "Cullen > Jennings" > Sent: 7/20/2016 6:56:59 AM > Subject: Re: [Perc] Request for decision review > > > Hello everybody, > I understand the point of Emil because as implementer I am worried about > having hard restrictions which avoid or hinder the implementation of > features requested by the market, and this could make PERC unusable. > > So I think that firstly we should reach consensus about which features or > uses cases must be allowed to be implemented and then discuss the low lev= el > details taking into account that we won't can add restrictions which avoi= d > these features. > This may also apply to others WGs and not only to PERC. Even having > support for rid, mid, etc. could ease the design of PERC. > > Ones of the features affected with the current status are: > 1 - Video quality switching (simulcast) > 2 - Dominant Speaker switching > > These features must also offer an high QoE for the users. For that, the > experience tells me that it should be performed in the SFU side. In our > current implementation: > 1 - Video quality switching (simulcast) is performed rewriting SSRCs, > seqnums and timestams > 2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums > andt timestams. Notice that it would be consider and attack [1] > > when it is the best way (easy, efficient and > with high QoE) we found to implement this feature. > > This is working in the WebRTC context using endpoints like Chrome or > Firefox. To implement them following current PERC status: > Could (1) be implemented without SSRCs rewriting and using RID instead? > I think so, but should be ensure that endpoints support that before make > SSRC immutable? > Could (2) be implemented without SSRCs rewriting and using MID instead? > Could (2) be implemented even without adding a specific RTP stream using > idea [2] > ? > I think so, but should be ensure that endpoints support that before make > SSRC immutable? > > These questions tell me that if endpoints does not support them, features > requested by the market and PERC will be incompatible :S. > > Best regards!! > > Refs > [1] > https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2= .4 > [2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html > > 2016-05-26 1:12 GMT+02:00 Emil Ivov : > >> >> >> On Wednesday, 25 May 2016, Eric Rescorla wrote: >> >>> >>> >>> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov wrote: >>> >>>> >>>> >>>> On 25.05.16 =D0=B3. 15:20, Paul E. Jones wrote: >>>> >>>>> Emil, >>>>> >>>>> You are saying that endpoints would negotiate via signaling which SSR= C >>>>> value(s) to use before actually joining the conference? >>>>> >>>> >>>> It's awesome how you would always attribute to me the least appealing >>>> of all possible interpretations :). >>>> >>>> Whether or not we negotiate SSRCs should not be within PERC's scope. >>>> For the record this is how WebRTC works anyway (courtesy of some of th= e >>>> people on this list) but the matter is completely orthogonal to PERC. >>>> >>>> What I was suggesting is the possibility for PERC endpoints and MDD to >>>> negotiate whether or not they will be dealing with a single end-to-end= SSRC >>>> space, or whether they will have separate HBH and E2E SSRC spaces. >>>> >>>> This way you get to only implement the single end-to-end option in you= r >>>> endpoints and to not support the other one. >>>> >>>> Does this make more sense? >>>> >>>> That doesn't strike me as terribly appealing, honestly. Between that >>>>> and the pain of dealing with conflicting SSRCs, I might favor the >>>>> latter. What I'd prefer most, though, is neither and just let >>>>> endpoints >>>>> do their thing. >>>>> >>>>> I'd still like to hear confirmation that receiving browsers will >>>>> definitely be doing the right thing w.r.t. receiving simulcast stream= s. >>>>> Adam seemed to suggest Firefox will be doing the right thing (probabl= y >>>>> before PERC is done). What about popular browsers? >>>>> >>>> >>>> I think at this point the answers that I've heard are for both >>>> browsers: we are not doing this now. >>> >>> >>> As far as Firefox goes, we're not doing this now because PERC isn't >>> ready. >>> >> >> So you are saying that simulcast itself is not a good enough reason to >> implement receiver-side simulcast support ... but a minor optimization >> to PERC is ... >> >> Obviously I don't need to be explained the reasoning. I am glad you have >> this plan. >> >> I only wish we would have a clearer view of everyone's intended delivery >> dates since we are about to block PERC on them. >> >> >> We're looking at it soon and plan to try to implement it pretty much as >>> soon as it's baked enough to do. >>> >>> >>> it's not part of webrtc 1.0. >>> >>> >>> Is it even something that could be in WebRTC 1.0? I.e., does it require >>> changes? >>> >> >> How would you tell FF what group an RID corresponds to? >> >> Emil >> >>> >>> >>> >>> >>>> we'd like to do it in the future. >>>> >>> >>> Yes. >>> >>> -Ekr >>> >>> >>> >>> >>>> What I'd like to avoid is PERC having a firm dependence on this last >>>> statement and for it to only be usable when it comes true. >>>> >>>> Emil >>>> >>>> >>>>> Paul >>>>> >>>>> ------ Original Message ------ >>>>> From: "Emil Ivov" >>>>> To: "Paul E. Jones" >>>>> Cc: "Adam Roach" ; "Cullen Jennings" >>>> >; >>>>> perc@ietf.org >>>>> Sent: 5/25/2016 2:23:43 PM >>>>> Subject: Re: [Perc] Request for decision review >>>>> >>>>> Paul, >>>>>> >>>>>> I have answered your points below but we did gloss over the suggesti= on >>>>>> I made and I consider it important: >>>>>> >>>>>> We can allow SSRC rewriting and make it negotiable by signalling. Th= is >>>>>> way SFUs can state they support rewriting/immutability/both and >>>>>> endpoints can choose to use what's available or reject the session a= s >>>>>> unsupported. >>>>>> >>>>>> I believe this should address the concerns that have been expressed = so >>>>>> far. >>>>>> >>>>>> Now for the rest of the points: >>>>>> >>>>>> On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote: >>>>>> >>>>>>> Emil, >>>>>>> >>>>>>> Since we are not enforcing a requirement that endpoints select a >>>>>>>>> distinct SSRC per media flow, there is a potential conflict in th= e >>>>>>>>> number space used E2E. >>>>>>>>> >>>>>>>> >>>>>>>> As I have been insisting many times already: We have the option to >>>>>>>> mandate that SFUs preserve the SSRC space. That's not hard to >>>>>>>> implement. It's not a great option but it is a possibility. >>>>>>>> >>>>>>>> We can also say that whether or not SFUs do that rewrite is a >>>>>>>> feature >>>>>>>> that has to be signalled so clients can choose whether to support = it >>>>>>>> or not. This should address your concern. >>>>>>>> >>>>>>> >>>>>>> The SFU has nothing to do with the E2E SSRC collision problem. Whe= n >>>>>>> an >>>>>>> endpoints sends out an RTP packet and it goes though an SFU that >>>>>>> changes >>>>>>> the SSRC, there is a HBH SSRC and an E2E SSRC. I fully agree that >>>>>>> the >>>>>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot >>>>>>> control >>>>>>> the fact that the E2E SSRCs collide. >>>>>>> >>>>>> >>>>>> The SFU has everytihng to do with the E2E collision problem and it's >>>>>> potential solutions. What you describe is one way to handle things. >>>>>> Another one would be to just make SSRC conflicts obvious to senders = so >>>>>> that they would apply 3550 resolution. That's pretty easy to >>>>>> implement. >>>>>> >>>>>> The 64 bit identifier is just a hack to work >>>>>>>>> around that problem. If the problem didn't exist, we could use SS= RC >>>>>>>>> values to look up the context as it was I intended in SRTP. >>>>>>>>> >>>>>>>> >>>>>>>> E2E PERC is NOT SRTP. We may choose to make it look like it is and= I >>>>>>>> see why that is appealing but not doing it is by no means "a hack"= . >>>>>>>> >>>>>>> >>>>>>> Of course it's SRTP. It just happens to be two passes of SRTP, but >>>>>>> it's >>>>>>> nonetheless SRTP. >>>>>>> >>>>>> >>>>>> Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stoc= k >>>>>> SRTP endpoint would do anything meaningful with them. So what you ar= e >>>>>> looking is to just optimize implementations, which is relevant but n= ot >>>>>> the primary concern. >>>>>> >>>>>> What PERC is adding are some additional steps between >>>>>>> each pass for HBH authentication of packets at the sender (and the >>>>>>> reverse at the receiver). The MDD doesn't have two steps: it just >>>>>>> does >>>>>>> one normal SRTP decryption for the packet received and one SRTP >>>>>>> encryption step sending the packet. The only special requirement >>>>>>> PERC >>>>>>> introduces is that if the MDD changes either the PT field or sequen= ce >>>>>>> number, the original values have to be added to the packet inside a= n >>>>>>> RTP >>>>>>> header extension called OHB (if not already present). >>>>>>> >>>>>>> >>>>>>> The problem with using a 64 bit value is that any existing SRTP >>>>>>>>> library >>>>>>>>> would have to change to associate the context that way. >>>>>>>>> >>>>>>>> >>>>>>>> So just to be clear ... we are lamenting about changing an int to = a >>>>>>>> long? >>>>>>>> >>>>>>> >>>>>>> No, lamenting that this would not align with what RFC 3711 says to >>>>>>> use >>>>>>> to identify the context. >>>>>>> >>>>>> >>>>>> Again, 3711 applies to HBH. We are trying to reuse as much of it for >>>>>> E2E as possible and that's admirable but it's not a reason why we >>>>>> should significantly disrupt existing implementations. >>>>>> >>>>>> Further, if we >>>>>>>>> wish to break up the PERC processing into two steps, that HBH SSR= C >>>>>>>>> would >>>>>>>>> have to be extracted and passed in by the application. While I >>>>>>>>> think the >>>>>>>>> intent with Double is for this to be an autonomous operation, it >>>>>>>>> might >>>>>>>>> not be implemented that way for two reasons: >>>>>>>>> 1) If there is a desire to do HBH FEC, the process might be to >>>>>>>>> encrypt >>>>>>>>> E2E -> FEC -> HBH. So the second call to the SRTP library would >>>>>>>>> need >>>>>>>>> that HBH SSRC passed in when doing these steps in reverse to >>>>>>>>> introduce >>>>>>>>> that 64-bit context ID. >>>>>>>>> >>>>>>>> >>>>>>>> Em ... you'd have to explain this in a bit more detail because I >>>>>>>> fail >>>>>>>> to see how FEC is any different than regular media. As you say it >>>>>>>> yourself, it all just works out properly as long as you do your FE= C >>>>>>>> after E2E and before HBH as that way the SFU would be able to de- = or >>>>>>>> re-FEC. >>>>>>>> >>>>>>> >>>>>>> Historically, there were two options for FEC. Either we do FEC fir= st >>>>>>> and then SRTP, or SRTP first then FEC. The order has to match at >>>>>>> both >>>>>>> the sender and receiver. Either way, it generally makes very littl= e >>>>>>> difference. >>>>>>> >>>>>>> An MDD might want to be a good citizen and reconstruct lost packets >>>>>>> before sending a stream to a receiver. In order to do that, the >>>>>>> sender >>>>>>> will either need to do SRTP (both passes) then FEC or it could do t= he >>>>>>> first SRTP pass (the E2E encryption pass) then FEC then SRTP for th= e >>>>>>> HBH. It really depends on what we want that FEC flow to look like. >>>>>>> Do >>>>>>> we want it to be FEC over a bunch of E2E+HBH encrypted packets or >>>>>>> just >>>>>>> over the E2E packets. (The latter would be parallel to the current >>>>>>> FEC >>>>>>> order of "FEC then SRTP". >>>>>>> >>>>>>> So, thinking of how this might be implemented in an SRTP library, i= f >>>>>>> we >>>>>>> allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when t= he >>>>>>> application encrypts the packet, it would pass the packet into the >>>>>>> SRTP >>>>>>> libtary once to encrypt HBH. >>>>>>> >>>>>> >>>>>> You mean E2E here. >>>>>> >>>>>> It then does whatever FEC processing it >>>>>>> wants, then it calls into the SRTP library again to encrypt the >>>>>>> second >>>>>>> pass (HBH pass). It could be two entirely instances of the SRTP >>>>>>> library >>>>>>> that handles each pass. On the MDD, it decrypts the flow and does >>>>>>> whatevever FEC magic it wants to do. There is only one SRTP >>>>>>> operation >>>>>>> at the MDD, so no problem. At the receiver, it decrypts the packet >>>>>>> received using HBH decryption. It then does whatever FEC processing >>>>>>> it >>>>>>> needs to do. Next, it would call into the SRTP library to decrypt >>>>>>> for >>>>>>> E2E. If the SSRCs never change, this works fine. One could >>>>>>> implement >>>>>>> this using two instances of an SRTP library today. If a single >>>>>>> library >>>>>>> is used, then the only requirement is to ensure the second call int= o >>>>>>> the >>>>>>> library does not encounter issues with the replay database (since i= t >>>>>>> might otherwise think it's a replayed packet). In either case, the >>>>>>> crypto context would be looked up as per RFC 3711 using SSRC. If, >>>>>>> however, the SSRC value is allowed to change, then the second call >>>>>>> into >>>>>>> the SRTP library (same or different instance of the library) would >>>>>>> be a >>>>>>> problem since Alice and Bob both used SSRC 1. The collision is >>>>>>> going to >>>>>>> prevent the library from working properly. >>>>>>> >>>>>> >>>>>> I still fail to see how FEC changes any of this (for better or worse= ). >>>>>> The problem you describe here is exactly the same with or without FE= C >>>>>> and it's what we are having the argument about. >>>>>> >>>>>> If we take the approach of using a 64-bit identifier (in contradicti= on >>>>>>> to RFC 3711) >>>>>>> >>>>>> >>>>>> :) ... It is NOT in contradiction with 3711 because layers of >>>>>> encryptions are not part of 3711. We simply need to set the >>>>>> expectations right for implementers. >>>>>> >>>>>> to identify the crypto context, then we would need to pass >>>>>>> that identifier into the SRTP library when attempting to decrypt th= e >>>>>>> packet, because it could not simply discover it by looking at the >>>>>>> packet >>>>>>> (which it could do normally since the SSRC value is right there in >>>>>>> the >>>>>>> packet). It would be necessary to make a call like >>>>>>> srtp_unprotect(context, packet, stream_identifiier) (where >>>>>>> stream_identifier is something that identifies the stream other tha= n >>>>>>> the >>>>>>> SSRC per 3711, like E2E_SSRC || HBH_SSRC). >>>>>>> >>>>>>> A beautiful thing about SRTP today >>>>>>> >>>>>> >>>>>> You mean PERC here and not SRTP (even if PERC does simply apply a >>>>>> second srtp unprotect it is still not stock 3711). >>>>>> >>>>>> is the library can operate on streams >>>>>>> without the application having to pass in such identifiers. The >>>>>>> stream >>>>>>> is self-identifying. But, we lose that elegance when we modify the >>>>>>> SSRC >>>>>>> in the MDD when we break the operation into two passes to handle th= is >>>>>>> FEC order. >>>>>>> >>>>>> >>>>>> So we have an aesthetic concern because we have to change int-s to >>>>>> long-s and that's why we are having a 100 mail thread. I am >>>>>> speechless. >>>>>> >>>>>> 2) It might be desirable to implement the PERC logic by just having = a >>>>>>>>> two-step wrapper around the existing SRTP library to avoid making >>>>>>>>> changes to the core library. (I'd prefer built-in support for >>>>>>>>> Double, >>>>>>>>> but I can appreciate how some might prefer to not change an >>>>>>>>> otherwise >>>>>>>>> working library.) >>>>>>>>> >>>>>>>> >>>>>>>> As I said, being able to reuse SRTP libraries with no change is a >>>>>>>> great optimization if we get it but I really don't think the >>>>>>>> alternative is anywhere near the complexity that would justify >>>>>>>> banning >>>>>>>> SSRC re-writing. >>>>>>>> >>>>>>> >>>>>>> At least we agree that it would be a good goal to find an approach >>>>>>> that >>>>>>> would eliminate or minimize changes to the SRTP logic. :) >>>>>>> >>>>>>> Now to the complexity part... that's in the thread you're having wi= th >>>>>>> Cullen which, as I understand, is an expression of a concern that >>>>>>> receiving endpoints are not going to properly handle multiple >>>>>>> simulcast >>>>>>> streams coming toward them. >>>>>>> >>>>>>> Since I don't work for a browser vendor, I cannot speak to their >>>>>>> plans. >>>>>>> I can only assume that proper handling of received simulcast flows >>>>>>> would >>>>>>> be implemented per the current drafts. And if that's the case, the= n >>>>>>> I >>>>>>> don't think changing the SSRC would be needed. If receiving >>>>>>> endpoints >>>>>>> fail to do that, then you're right that this could be a problem. >>>>>>> >>>>>> >>>>>> Let's be clear on this. There is absolutely nothing wrong or standar= d >>>>>> breaking in the way browsers handle simulcast reception today. They >>>>>> are simply not simulcast aware and the SFU hides it from them. >>>>>> >>>>>> There is no reason why that would be labelled a bad practice even wh= en >>>>>> RID does go through all of the IETF process. >>>>>> >>>>>> Also, the availability of this option (simulcast unaware receivers) >>>>>> and its existence today make the motivation for RID support on the >>>>>> receiving end pretty low. It does not give you anything extra in ter= ms >>>>>> of functionality. There are no substantial benefits from doing it (a= nd >>>>>> no it doesn't allow for significantly simpler SFUs ... those would >>>>>> still have to keep 95% of their existing logic). We can decide to ma= ke >>>>>> PERC dependent on it and hope that this would sway all browser vendo= rs >>>>>> ... or we could also try to lower the burden on PERC adoption. >>>>>> >>>>>> Again, as stated in the beginning of this mail: it sounds like a >>>>>> compromise may lie in the option for PERC to allow an SSRC rewriting >>>>>> mode combined with the option for endpoints to not support it. In >>>>>> other words we can have part of the PERC signalling indicate whether >>>>>> the client and the server support these modes and whether they use >>>>>> them. This is not beautiful (by any means) but it wouldn't prevent >>>>>> either of us to do things their way. >>>>>> >>>>>> Emil >>>>>> -- https://jitsi.org >>>>>> >>>>> >>>>> >>>>> >>>> -- >>>> https://jitsi.org >>>> >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>> >>> >> >> -- >> sent from my mobile >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> > > > -- > Miguel Par=C3=ADs D=C3=ADaz > ------------------------------------------------------------------------ > Computer/Software engineer. > Researcher and architect in http://www.kurento.org > http://twitter.com/mparisdiaz > ------------------------------------------------------------------------ > > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --089e013d1d622850a50538121c2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Paul,
we rewrite the SSRC because= currently it is the way to associate a MediaStreamTrack to an RTP stream.<= br>
Analysing the case of video quality switching (simulcast)= :
  • Rewriting SSRCs at the SFU side improves the QoE a = lot due the switch is transparent for the endpoint which receives the RTP s= tream, applies the JitterBuffer, decrypts it, creates encoded frames, decod= es frames, applies sync-buffer (for interstream synchronization (typically = audio and video)) and renders the video. So the logic in the client is quit= e easier and smooth when switchings.
  • If we do NOT do that, the another=20 possibility (I didn't found others) is negotiating with the receiver N= =20 SSRCs (each one per quality) performing ON/OFF at the SFU side and doing the switching in the receiver. For doing that:
    • You have N Medi= aStreamTracks.
    • You have to detect at application layer when a MediaStreamTrack stops=20 receiving media using getUserMedia API's events (which takes at least= =20 500ms)
    • You have to detect the the new enabled MediaStreamTrack,=20 which can take a lot of times due to JitterBuffer restarting, decoder=20 restarting, etc.
    • You have to deal with audio-video synchronization = that may be quite difficult.
    • The endpoint uses more resources (CPU = and memory)
    • etc.
    • In conclusion it is a pain for the users b= ecause they see freeze video time to time (the QoE is very bad)
    • Rewriting timestamps is needed because there are usually some of= fsets between different qualities.

2016-07-20 14:34 GMT+02= :00 Paul E. Jones <paulej@packetizer.com>:
Miguel,
=C2=A0
The current design of PERC is one where there is an E2E encryption ste= p using regular SRTP.=C2=A0 An intermediary does not have the E2E keys and,= therefore, cannot change anything about the packet.=C2=A0 Then, that packe= t is encrypted HBH using a different key that the next hop device will have= .=C2=A0 Assuming the next hop device is an MDD (nor "Media Distributor= "), that device could have the liberty of changing the sequence number= s and, in fact, it will be obliged to do so if it does not always forward a= ll of the streams (since not forwarding some streams will mean the cryptogr= aphic context gets out of sync).
=C2=A0
So in the typical case, the MDD will change the sequence number and mi= ght insert a new header extension to carry the original value.=C2=A0 It mig= ht also change the payload type value.
=C2=A0
How, as the endpoint receives a packet, it will decrypt the HBH packet= and reconstruct the E2E packet using the OHB field.=C2=A0 But what is ther= e?=C2=A0 Well, it's the original packet as created by the sending endpo= int.=C2=A0 Even if we change the SSRC or sequence number, the original valu= es are there and preserved.=C2=A0 So, other than out of necessity (sequence= number changed to keep crypto context in sync and PT changed to ensure the= right PT value is received as expected), I'm still not convinced that = changing the SSRC really buys us anything.=C2=A0 Sure, we could change it.= =C2=A0 We actually has space in the OHB originally to allow that.=C2=A0 But= for what purpose?=C2=A0 Changing or not changing an SSRC value should not = have any affect whatsoever on the QoE.=C2=A0=C2=A0 (I'm not saying the = SSRC has no importance, but I question the need to rewrite them.)
=C2=A0
I'm not sure how the other identifiers you mention might=C2=A0help= improve QoE.=C2=A0 Maybe expand on that little?
=C2=A0
One important point to consider in all of this=C2=A0is that WebRTC bro= wsers MUST be PERC-aware, else they cannot participate in conferences.=C2= =A0 If they're not PERC-aware, then there would have to be a middlebox = that "downgrades" for those older browsers and it can rewrite wha= tever it wants, since it would be in=C2=A0possession of keys and would stri= p off one layer of encryption to produce a legacy SRTP flow (or no SRTP at = all).=C2=A0
=C2=A0
Paul
=C2=A0
------ Original Message ------
From: "Miguel Par=C3=ADs D=C3=ADaz&= quot; <mparisd= iaz@gmail.com>
To: "Emil Ivov" <emcho@jitsi.org>
Cc: "Eric Rescorla" <ekr@rtfm.com>; "Paul E. Jones" <paulej@packetizer.com>; "Adam Roach" <adam@nostrum.com>; "perc@ietf.org" <perc@ietf.org>; "Cullen Jennings"= ; <fluffy@iii.ca&= gt;
Sent: 7/20/2016 6:56:59 AM
Subject: Re: [Perc] Request for decision review
=C2=A0
Hello everybody,
I understand the point of Emil because as im= plementer I am worried about having hard restrictions which avoid or hinder= the implementation of features requested by the market, and this could mak= e PERC unusable.

So I think that firstly we should reach consensus about which features or uses ca= ses must be allowed to be implemented and then discuss the low level detail= s taking into account that we won't can add restrictions which avoid th= ese features.
This may also apply to others WGs and not only to PE= RC. Even having support for rid, mid, etc. could ease the design of PERC.

Ones of the features affected with the current status are:
=C2=A0 1 - Video quality switching (simulcast)
=C2=A0 2 - Dominant Speaker switching

These features must also offer an high QoE for the users. For that, th= e experience tells me that it should be performed in the SFU side. In our c= urrent implementation:
=C2=A0 1 - Video quality switching (simulcast) is= performed rewriting SSRCs, seqnums and timestams
=C2=A0 2 - Dominant Sp= eaker switching is performed rewriting SSRCs, seqnums andt timestams. Notic= e that it would be consider and attack [1] when it is the best way (easy, efficient and
with high QoE) we found= to implement this feature.

This is working in the WebRTC context using endpoints like Chrome or F= irefox. To implement them following current PERC status:

2016-05-26 1:12 GMT+02:00 Emil Ivov <emcho@jitsi.= org>:


On Wednesda= y, 25 May 2016, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <emcho@jitsi.org> wrote:


On 25.05.16= =D0=B3. 15:20, Paul E. Jones wrote:
Emil,

You are sayi= ng that endpoints would negotiate via signaling which SSRC
value(s) to u= se before actually joining the conference?

It's awe= some how you would always attribute to me the least appealing of all possib= le interpretations :).

Whether or not we negotiate SSRCs should not = be within PERC's scope. For the record this is how WebRTC works anyway = (courtesy of some of the people on this list) but the matter is completely = orthogonal to PERC.

What I was suggesting is the possibility for PER= C endpoints and MDD to negotiate whether or not they will be dealing with a= single end-to-end SSRC space, or whether they will have separate HBH and E= 2E SSRC spaces.

This way you get to only implement the single end-to= -end option in your endpoints and to not support the other one.

Does= this make more sense?

That doesn't strike m= e as terribly appealing, honestly.=C2=A0 Between that
and the pain of de= aling with conflicting SSRCs, I might favor the
latter.=C2=A0 What I'= ;d prefer most, though, is neither and just let endpoints
do their thing= .

I'd still like to hear confirmation that receiving browsers wi= ll
definitely be doing the right thing w.r.t. receiving simulcast stream= s.
Adam seemed to suggest Firefox will be doing the right thing (probabl= y
before PERC is done). What about popular browsers?
I think at this point the answers that I've heard are for both browser= s: we are not doing this now.

As far as Firefox goes, we're not doing this now because PERC isn&= #39;t ready.
=C2=A0
So you are saying that simulcast itself is not a good enough reason to= implement=C2=A0=C2=A0receiver-side simulcast support ... but a minor optim= ization to=C2=A0PERC is ...

Obviously I don't need to be explained the reasoning. I = am glad you have this plan.=20

I only wish we would have a clearer view of everyone's intended de= livery dates since we are about to block PERC on them.


We're looking at it soon and plan to try to implement it pretty mu= ch as soon as it's baked enough to do.


it's not part of webr= tc 1.0.

Is it even something that could be in WebRTC 1.0? I.e., does it requir= e changes?
How would you tell FF what group an RID corresponds to?

Emil=C2=A0


=C2=A0
we'd like to do it in= the future.

Yes.

-Ekr
=C2=A0



What I'd like to = avoid is PERC having a firm dependence on this last statement and for it to= only be usable when it comes true.

Emil


Paul

---= --- Original Message ------
From: "Emil Ivov" <emcho@jit= si.org>
To: "Paul E. Jones" <paulej@packetizer.co= m>
Cc: "Adam Roach" <adam@nostrum.co= m>; "Cullen Jennings" <fluffy@iii.ca>;
= perc@ietf.org
Sent: 5/25/2016 2:23:43 PM
Subject: Re: [Perc] Requ= est for decision review
Paul,

I have answe= red your points below but we did gloss over the suggestion
I made and I = consider it important:

We can allow SSRC rewriting and make it negot= iable by signalling. This
way SFUs can state they support rewriting/immu= tability/both and
endpoints can choose to use what's available or re= ject the session as
unsupported.

I believe this should address th= e concerns that have been expressed so
far.

Now for the rest of t= he points:

On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote:
Emil,

Since we are not enforcin= g a requirement that endpoints select a
distinct SSRC per media flow, th= ere is a potential conflict in the
number space used E2E.

As I have been insisting many times already: We have the option tomandate that SFUs preserve the SSRC space. That's not hard to
imple= ment. It's not a great option but it is a possibility.

We can al= so say that whether or not SFUs do that rewrite is a feature
that has to= be signalled so clients can choose whether to support it
or not. This s= hould address your concern.

The SFU has nothing to do w= ith the E2E SSRC collision problem.=C2=A0 When an
endpoints sends out an= RTP packet and it goes though an SFU that changes
the SSRC, there is a = HBH SSRC and an E2E SSRC.=C2=A0 I fully agree that the
SFU can ensure th= at the HBH SSRCs do not collide, but it cannot control
the fact that the= E2E SSRCs collide.

The SFU has everytihng to do with t= he E2E collision problem and it's
potential solutions. What you desc= ribe is one way to handle things.
Another one would be to just make SSRC= conflicts obvious to senders so
that they would apply 3550 resolution. = That's pretty easy to implement.

The 64 bit identifier is = just a hack to work
around that problem. If the problem didn't exist= , we could use SSRC
values to look up the context as it was I intended i= n SRTP.

E2E PERC is NOT SRTP. We may choose to make it = look like it is and I
see why that is appealing but not doing it is by n= o means "a hack".

Of course it's SRTP.=C2= =A0 It just happens to be two passes of SRTP, but it's
nonetheless S= RTP.

Exactly! And two passes of SRTP happen to NOT be S= RTP as in: no stock
SRTP endpoint would do anything meaningful with them= . So what you are
looking is to just optimize implementations, which is = relevant but not
the primary concern.

What PERC is adding are s= ome additional steps between
each pass for HBH authentication of packets= at the sender (and the
reverse at the receiver).=C2=A0 The MDD doesn= 9;t have two steps: it just does
one normal SRTP decryption for the pack= et received and one SRTP
encryption step sending the packet.=C2=A0 The o= nly special requirement PERC
introduces is that if the MDD changes eithe= r the PT field or sequence
number, the original values have to be added = to the packet inside an RTP
header extension called OHB (if not already = present).


The problem with using a = 64 bit value is that any existing SRTP
library
would have to change t= o associate the context that way.

So just to be clear .= .. we are lamenting about changing an int to a
long?
No, lamenting that this would not align with what RFC 3711 says to use
= to identify the context.

Again, 3711 applies to HBH. We= are trying to reuse as much of it for
E2E as possible and that's ad= mirable but it's not a reason why we
should significantly disrupt ex= isting implementations.

Further, if we
wish to= break up the PERC processing into two steps, that HBH SSRC
would
hav= e to be extracted and passed in by the application. While I
think theintent with Double is for this to be an autonomous operation, it might
= not be implemented that way for two reasons:
1) If there is a desire to = do HBH FEC, the process might be to encrypt
E2E -> FEC -> HBH. So = the second call to the SRTP library would need
that HBH SSRC passed in w= hen doing these steps in reverse to introduce
that 64-bit context ID.

Em ... you'd have to explain this in a bit more detai= l because I fail
to see how FEC is any different than regular media. As = you say it
yourself, it all just works out properly as long as you do yo= ur FEC
after E2E and before HBH as that way the SFU would be able to de-= or
re-FEC.

Historically, there were two options for= FEC.=C2=A0 Either we do FEC first
and then SRTP, or SRTP first then FEC= .=C2=A0 The order has to match at both
the sender and receiver.=C2=A0 Ei= ther way, it generally makes very little
difference.

An MDD might= want to be a good citizen and reconstruct lost packets
before sending a= stream to a receiver.=C2=A0 In order to do that, the sender
will either= need to do SRTP (both passes) then FEC or it could do the
first SRTP pa= ss (the E2E encryption pass) then FEC then SRTP for the
HBH.=C2=A0 It re= ally depends on what we want that FEC flow to look like.=C2=A0 Do
we wan= t it to be FEC over a bunch of E2E+HBH encrypted packets or just
over th= e E2E packets.=C2=A0 (The latter would be parallel to the current FEC
or= der of "FEC then SRTP".

So, thinking of how this might be = implemented in an SRTP library, if we
allow the SRTP(E2E)+FEC+SRTP(HBH) = option for FEC order, then when the
application encrypts the packet, it = would pass the packet into the SRTP
libtary once to encrypt HBH.

You mean E2E here.

=C2=A0It then does whatev= er FEC processing it
wants, then it calls into the SRTP library again to= encrypt the second
pass (HBH pass).=C2=A0 It could be two entirely inst= ances of the SRTP library
that handles each pass.=C2=A0 On the MDD, it d= ecrypts the flow and does
whatevever FEC magic it wants to do.=C2=A0 The= re is only one SRTP operation
at the MDD, so no problem.=C2=A0 At the re= ceiver, it decrypts the packet
received using HBH decryption. It then do= es whatever FEC processing it
needs to do.=C2=A0 Next, it would call int= o the SRTP library to decrypt for
E2E.=C2=A0 If the SSRCs never change, = this works fine.=C2=A0 One could implement
this using two instances of a= n SRTP library today.=C2=A0 If a single library
is used, then the only r= equirement is to ensure the second call into the
library does not encoun= ter issues with the replay database (since it
might otherwise think it&#= 39;s a replayed packet).=C2=A0 In either case, the
crypto context would = be looked up as per RFC 3711 using SSRC.=C2=A0 If,
however, the SSRC val= ue is allowed to change, then the second call into
the SRTP library (sam= e or different instance of the library) would be a
problem since Alice a= nd Bob both used SSRC 1.=C2=A0 The collision is going to
prevent the lib= rary from working properly.

I still fail to see how FEC= changes any of this (for better or worse).
The problem you describe her= e is exactly the same with or without FEC
and it's what we are havin= g the argument about.

If we take the approach o= f using a 64-bit identifier (in contradiction
to RFC 3711)

:) ... It is NOT in contradiction with 3711 because layers of
enc= ryptions are not part of 3711. We simply need to set the
expectations ri= ght for implementers.

=C2=A0to identify the cry= pto context, then we would need to pass
that identifier into the SRTP li= brary when attempting to decrypt the
packet, because it could not simply= discover it by looking at the packet
(which it could do normally since = the SSRC value is right there in the
packet).=C2=A0 It would be necessar= y to make a call like
srtp_unprotect(context, packet, stream_identifiier= ) (where
stream_identifier is something that identifies the stream other= than the
SSRC per 3711, like E2E_SSRC || HBH_SSRC).

A beautiful = thing about SRTP today

You mean PERC here and not SRTP = (even if PERC does simply apply a
second srtp unprotect it is still not = stock 3711).

is the library can operat= e on streams
without the application having to pass in such identifiers.= =C2=A0 The stream
is self-identifying.=C2=A0 But, we lose that elegance = when we modify the SSRC
in the MDD when we break the operation into two = passes to handle this
FEC order.

So we have an aesth= etic concern because we have to change int-s to
long-s and that's wh= y we are having a 100 mail thread. I am speechless.

2) It might be desirable = to implement the PERC logic by just having a
two-step wrapper around the= existing SRTP library to avoid making
changes to the core library. (I&#= 39;d prefer built-in support for Double,
but I can appreciate how some m= ight prefer to not change an otherwise
working library.)

As I said, being able to reuse SRTP libraries with no change is a
g= reat optimization if we get it but I really don't think the
alternat= ive is anywhere near the complexity that would justify banning
SSRC re-w= riting.

At least we agree that it would be a good goal = to find an approach that
would eliminate or minimize changes to the SRTP= logic. :)

Now to the complexity part... that's in the thread yo= u're having with
Cullen which, as I understand, is an expression of = a concern that
receiving endpoints are not going to properly handle mult= iple simulcast
streams coming toward them.

Since I don't work= for a browser vendor, I cannot speak to their plans.
I can only assume = that proper handling of received simulcast flows would
be implemented pe= r the current drafts.=C2=A0 And if that's the case, then I
don't= think changing the SSRC would be needed.=C2=A0 If receiving endpoints
f= ail to do that, then you're right that this could be a problem.

Let's be clear on this. There is absolutely nothing wrong = or standard
breaking in the way browsers handle simulcast reception toda= y. They
are simply not simulcast aware and the SFU hides it from them.
There is no reason why that would be labelled a bad practice even whe= n
RID does go through all of the IETF process.

Also, the availabi= lity of this option (simulcast unaware receivers)
and its existence toda= y make the motivation for RID support on the
receiving end pretty low. I= t does not give you anything extra in terms
of functionality. There are = no substantial benefits from doing it (and
no it doesn't allow for s= ignificantly simpler SFUs ... those would
still have to keep 95% of thei= r existing logic). We can decide to make
PERC dependent on it and hope t= hat this would sway all browser vendors
... or we could also try to lowe= r the burden on PERC adoption.

Again, as stated in the beginning of = this mail: it sounds like a
compromise may lie in the option for PERC to= allow an SSRC rewriting
mode combined with the option for endpoints to = not support it. In
other words we can have part of the PERC signalling i= ndicate whether
the client and the server support these modes and whethe= r they use
them. This is not beautiful (by any means) but it wouldn'= t prevent
either of us to do things their way.

Emil
-- https://jitsi.= org



--
https://jitsi.org

_____________________________________= __________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc



--
sent from my mobile

____________________= ___________________________
Perc mailing list
Perc@ietf.org
https://w= ww.ietf.org/mailman/listinfo/perc




--
Miguel Par=C3=ADs D=C3=ADaz
---------------------------= ---------------------------------------------
Computer/Software engineer= .
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz
-----------= -------------------------------------------------------------



--
Miguel Par=C3=ADs D=C3=ADaz
--------------= ----------------------------------------------------------
Computer/Soft= ware engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz------------------------------------------------------------------------

--089e013d1d622850a50538121c2f-- From nobody Wed Jul 20 08:08:43 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA43812D8C1 for ; Wed, 20 Jul 2016 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sObswKoiCjVw for ; Wed, 20 Jul 2016 08:08:35 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 B22D712D8F7 for ; Wed, 20 Jul 2016 08:08:27 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id r9so48087665ywg.0 for ; Wed, 20 Jul 2016 08:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JYePxHYzKwM81xlxAAgxg1y5Se1pUeNvlje8fBjbzRw=; b=h9Lb/jgtx8lOAkzG0fCOqZcfC8/qAPXd9V4F6LPpZSYvAHs3U0cWwjkHY+9PSbsc8k JKSjrAqYYFZ80CcA5Bgas8p/0jH7DiaQa19aK/eJ3alA9NnVcJK3GfDnCviccMzaYqZ1 kARaN48cmEFPDiq9o+MIhKfqUAEKrUCpCxcfAVXIddfuuztnVrxW7bw3kHWRE3Ma73kc 2gCmhwAQDchdvatdPq7lEpfcKBwuqtbZJ8DNzvaBDZ7UF8aIguTSLFiO7sPUSbsvz9te CLAiQVz/s4Vu7+0xBU4HCPyJJShrp5a6xpNGSxLSHxRMMYChrdUV7rL9zUVV8akFYdyq Wn9g== 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-transfer-encoding; bh=JYePxHYzKwM81xlxAAgxg1y5Se1pUeNvlje8fBjbzRw=; b=Tn7jYEG+KgKHdDDZF6PF7sgjoNmGmuvWly+Fc25jnEwcbBGZ22SfdldyKeYrUBu1c0 bahvO43KlYsgMst7rym7XIhjgpz1ZDF6nFqbTUbLI+PX7+J9Mcm7UCG+3eD0jCn3rSIY ggLcPqMo9pKfXgkkKQxUOJxrxq6HB8BtYgqD+O2caiUzPv52FefHo1ALsw7FAzP0WjiW N/lQ5nSFUQOWmYJXKFXhBmmkUt/UfYkx3sUyE1fXscpmVVsh3aBExYV23mBF9bjU41ro jXpHoWQI/dWmCMpuYKBHp2ek3hGlQghWb7oB4oU0GJD/YrwGXhirH030OB8LLeY6FWZS /MwA== X-Gm-Message-State: ALyK8tJbPl5/5zqkq+3R69Q24+7E0ssOuzE6xK+Gs2SSPbmA8vTC+1tYUj++OMtujCj6oQ== X-Received: by 10.129.177.129 with SMTP id p123mr29405719ywh.109.1469027306716; Wed, 20 Jul 2016 08:08:26 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com. [209.85.161.179]) by smtp.gmail.com with ESMTPSA id l5sm1163624ywl.24.2016.07.20.08.08.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 08:08:26 -0700 (PDT) Received: by mail-yw0-f179.google.com with SMTP id r9so48087011ywg.0 for ; Wed, 20 Jul 2016 08:08:26 -0700 (PDT) X-Received: by 10.13.213.19 with SMTP id x19mr33528046ywd.226.1469027305298; Wed, 20 Jul 2016 08:08:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.17.204 with HTTP; Wed, 20 Jul 2016 08:08:05 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Wed, 20 Jul 2016 17:08:05 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Paul E. Jones" , Eric Rescorla , Adam Roach , "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:08:42 -0000 It is probably worth reminding there IS a middle ground that allows PERC to function with both SSRC rewriting and use of RID. We simply need to convey the original SSRC to the receiver and have PERC code use that for verification. That's all. We've been through this before. The only meaningful argument against this is Paul's: "The code wouldn't be as pretty as I want it to be because PERC would no longer be implementable as a double standard SRTP unprotect". As a result we are going toward something incompatible with most popular SFU implementations, mandating support for receiver-side RID-based simulcast that NO ONE implements today, that will not be part of WebRTC 1.0 and that is not even fully specified on the IETF. Chairs, ADs, ... please, please, please, let's get back to a state of sanit= y. Emil On Wed, Jul 20, 2016 at 4:35 PM, Miguel Par=C3=ADs D=C3=ADaz wrote: > Hello Paul, > we rewrite the SSRC because currently it is the way to associate a > MediaStreamTrack to an RTP stream. > > Analysing the case of video quality switching (simulcast): > > Rewriting SSRCs at the SFU side improves the QoE a lot due the switch is > transparent for the endpoint which receives the RTP stream, applies the > JitterBuffer, decrypts it, creates encoded frames, decodes frames, applie= s > sync-buffer (for interstream synchronization (typically audio and video)) > and renders the video. So the logic in the client is quite easier and smo= oth > when switchings. > > If we do NOT do that, the another possibility (I didn't found others) is > negotiating with the receiver N SSRCs (each one per quality) performing > ON/OFF at the SFU side and doing the switching in the receiver. For doing > that: > > You have N MediaStreamTracks. > You have to detect at application layer when a MediaStreamTrack stops > receiving media using getUserMedia API's events (which takes at least 500= ms) > You have to detect the the new enabled MediaStreamTrack, which can take a > lot of times due to JitterBuffer restarting, decoder restarting, etc. > You have to deal with audio-video synchronization that may be quite > difficult. > The endpoint uses more resources (CPU and memory) > etc. > In conclusion it is a pain for the users because they see freeze video ti= me > to time (the QoE is very bad) > > Rewriting timestamps is needed because there are usually some offsets > between different qualities. > > > 2016-07-20 14:34 GMT+02:00 Paul E. Jones : >> >> Miguel, >> >> The current design of PERC is one where there is an E2E encryption step >> using regular SRTP. An intermediary does not have the E2E keys and, >> therefore, cannot change anything about the packet. Then, that packet i= s >> encrypted HBH using a different key that the next hop device will have. >> Assuming the next hop device is an MDD (nor "Media Distributor"), that >> device could have the liberty of changing the sequence numbers and, in f= act, >> it will be obliged to do so if it does not always forward all of the str= eams >> (since not forwarding some streams will mean the cryptographic context g= ets >> out of sync). >> >> So in the typical case, the MDD will change the sequence number and migh= t >> insert a new header extension to carry the original value. It might als= o >> change the payload type value. >> >> How, as the endpoint receives a packet, it will decrypt the HBH packet a= nd >> reconstruct the E2E packet using the OHB field. But what is there? Wel= l, >> it's the original packet as created by the sending endpoint. Even if we >> change the SSRC or sequence number, the original values are there and >> preserved. So, other than out of necessity (sequence number changed to = keep >> crypto context in sync and PT changed to ensure the right PT value is >> received as expected), I'm still not convinced that changing the SSRC re= ally >> buys us anything. Sure, we could change it. We actually has space in t= he >> OHB originally to allow that. But for what purpose? Changing or not >> changing an SSRC value should not have any affect whatsoever on the QoE. >> (I'm not saying the SSRC has no importance, but I question the need to >> rewrite them.) >> >> I'm not sure how the other identifiers you mention might help improve Qo= E. >> Maybe expand on that little? >> >> One important point to consider in all of this is that WebRTC browsers >> MUST be PERC-aware, else they cannot participate in conferences. If the= y're >> not PERC-aware, then there would have to be a middlebox that "downgrades= " >> for those older browsers and it can rewrite whatever it wants, since it >> would be in possession of keys and would strip off one layer of encrypti= on >> to produce a legacy SRTP flow (or no SRTP at all). >> >> Paul >> >> ------ Original Message ------ >> From: "Miguel Par=C3=ADs D=C3=ADaz" >> To: "Emil Ivov" >> Cc: "Eric Rescorla" ; "Paul E. Jones" >> ; "Adam Roach" ; "perc@ietf.org= " >> ; "Cullen Jennings" >> Sent: 7/20/2016 6:56:59 AM >> Subject: Re: [Perc] Request for decision review >> >> >> Hello everybody, >> I understand the point of Emil because as implementer I am worried about >> having hard restrictions which avoid or hinder the implementation of >> features requested by the market, and this could make PERC unusable. >> >> So I think that firstly we should reach consensus about which features o= r >> uses cases must be allowed to be implemented and then discuss the low le= vel >> details taking into account that we won't can add restrictions which avo= id >> these features. >> This may also apply to others WGs and not only to PERC. Even having >> support for rid, mid, etc. could ease the design of PERC. >> >> Ones of the features affected with the current status are: >> 1 - Video quality switching (simulcast) >> 2 - Dominant Speaker switching >> >> These features must also offer an high QoE for the users. For that, the >> experience tells me that it should be performed in the SFU side. In our >> current implementation: >> 1 - Video quality switching (simulcast) is performed rewriting SSRCs, >> seqnums and timestams >> 2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums >> andt timestams. Notice that it would be consider and attack [1] when it = is >> the best way (easy, efficient and >> with high QoE) we found to implement this feature. >> >> This is working in the WebRTC context using endpoints like Chrome or >> Firefox. To implement them following current PERC status: >> Could (1) be implemented without SSRCs rewriting and using RID instead? >> I think so, but should be ensure that endpoints support that before make >> SSRC immutable? >> Could (2) be implemented without SSRCs rewriting and using MID instead? >> Could (2) be implemented even without adding a specific RTP stream using >> idea [2]? >> I think so, but should be ensure that endpoints support that before make >> SSRC immutable? >> >> These questions tell me that if endpoints does not support them, feature= s >> requested by the market and PERC will be incompatible :S. >> >> Best regards!! >> >> Refs >> [1] >> https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.= 2.4 >> [2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html >> >> 2016-05-26 1:12 GMT+02:00 Emil Ivov : >>> >>> >>> >>> On Wednesday, 25 May 2016, Eric Rescorla wrote: >>>> >>>> >>>> >>>> On Wed, May 25, 2016 at 1:43 PM, Emil Ivov wrote: >>>>> >>>>> >>>>> >>>>> On 25.05.16 =D0=B3. 15:20, Paul E. Jones wrote: >>>>>> >>>>>> Emil, >>>>>> >>>>>> You are saying that endpoints would negotiate via signaling which SS= RC >>>>>> value(s) to use before actually joining the conference? >>>>> >>>>> >>>>> It's awesome how you would always attribute to me the least appealing >>>>> of all possible interpretations :). >>>>> >>>>> Whether or not we negotiate SSRCs should not be within PERC's scope. >>>>> For the record this is how WebRTC works anyway (courtesy of some of t= he >>>>> people on this list) but the matter is completely orthogonal to PERC. >>>>> >>>>> What I was suggesting is the possibility for PERC endpoints and MDD t= o >>>>> negotiate whether or not they will be dealing with a single end-to-en= d SSRC >>>>> space, or whether they will have separate HBH and E2E SSRC spaces. >>>>> >>>>> This way you get to only implement the single end-to-end option in yo= ur >>>>> endpoints and to not support the other one. >>>>> >>>>> Does this make more sense? >>>>> >>>>>> That doesn't strike me as terribly appealing, honestly. Between tha= t >>>>>> and the pain of dealing with conflicting SSRCs, I might favor the >>>>>> latter. What I'd prefer most, though, is neither and just let >>>>>> endpoints >>>>>> do their thing. >>>>>> >>>>>> I'd still like to hear confirmation that receiving browsers will >>>>>> definitely be doing the right thing w.r.t. receiving simulcast >>>>>> streams. >>>>>> Adam seemed to suggest Firefox will be doing the right thing (probab= ly >>>>>> before PERC is done). What about popular browsers? >>>>> >>>>> >>>>> I think at this point the answers that I've heard are for both >>>>> browsers: we are not doing this now. >>>> >>>> >>>> As far as Firefox goes, we're not doing this now because PERC isn't >>>> ready. >>> >>> >>> So you are saying that simulcast itself is not a good enough reason to >>> implement receiver-side simulcast support ... but a minor optimization= to >>> PERC is ... >>> >>> Obviously I don't need to be explained the reasoning. I am glad you hav= e >>> this plan. >>> >>> I only wish we would have a clearer view of everyone's intended deliver= y >>> dates since we are about to block PERC on them. >>> >>> >>>> We're looking at it soon and plan to try to implement it pretty much a= s >>>> soon as it's baked enough to do. >>>> >>>> >>>>> it's not part of webrtc 1.0. >>>> >>>> >>>> Is it even something that could be in WebRTC 1.0? I.e., does it requir= e >>>> changes? >>> >>> >>> How would you tell FF what group an RID corresponds to? >>> >>> Emil >>>> >>>> >>>> >>>> >>>>> >>>>> we'd like to do it in the future. >>>> >>>> >>>> Yes. >>>> >>>> -Ekr >>>> >>>> >>>> >>>>> >>>>> What I'd like to avoid is PERC having a firm dependence on this last >>>>> statement and for it to only be usable when it comes true. >>>>> >>>>> Emil >>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> ------ Original Message ------ >>>>>> From: "Emil Ivov" >>>>>> To: "Paul E. Jones" >>>>>> Cc: "Adam Roach" ; "Cullen Jennings" >>>>>> ; >>>>>> perc@ietf.org >>>>>> Sent: 5/25/2016 2:23:43 PM >>>>>> Subject: Re: [Perc] Request for decision review >>>>>> >>>>>>> Paul, >>>>>>> >>>>>>> I have answered your points below but we did gloss over the >>>>>>> suggestion >>>>>>> I made and I consider it important: >>>>>>> >>>>>>> We can allow SSRC rewriting and make it negotiable by signalling. >>>>>>> This >>>>>>> way SFUs can state they support rewriting/immutability/both and >>>>>>> endpoints can choose to use what's available or reject the session = as >>>>>>> unsupported. >>>>>>> >>>>>>> I believe this should address the concerns that have been expressed >>>>>>> so >>>>>>> far. >>>>>>> >>>>>>> Now for the rest of the points: >>>>>>> >>>>>>> On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote: >>>>>>>> >>>>>>>> Emil, >>>>>>>> >>>>>>>>>> Since we are not enforcing a requirement that endpoints select a >>>>>>>>>> distinct SSRC per media flow, there is a potential conflict in t= he >>>>>>>>>> number space used E2E. >>>>>>>>> >>>>>>>>> >>>>>>>>> As I have been insisting many times already: We have the option t= o >>>>>>>>> mandate that SFUs preserve the SSRC space. That's not hard to >>>>>>>>> implement. It's not a great option but it is a possibility. >>>>>>>>> >>>>>>>>> We can also say that whether or not SFUs do that rewrite is a >>>>>>>>> feature >>>>>>>>> that has to be signalled so clients can choose whether to support >>>>>>>>> it >>>>>>>>> or not. This should address your concern. >>>>>>>> >>>>>>>> >>>>>>>> The SFU has nothing to do with the E2E SSRC collision problem. Wh= en >>>>>>>> an >>>>>>>> endpoints sends out an RTP packet and it goes though an SFU that >>>>>>>> changes >>>>>>>> the SSRC, there is a HBH SSRC and an E2E SSRC. I fully agree that >>>>>>>> the >>>>>>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot >>>>>>>> control >>>>>>>> the fact that the E2E SSRCs collide. >>>>>>> >>>>>>> >>>>>>> The SFU has everytihng to do with the E2E collision problem and it'= s >>>>>>> potential solutions. What you describe is one way to handle things. >>>>>>> Another one would be to just make SSRC conflicts obvious to senders >>>>>>> so >>>>>>> that they would apply 3550 resolution. That's pretty easy to >>>>>>> implement. >>>>>>> >>>>>>>>>> The 64 bit identifier is just a hack to work >>>>>>>>>> around that problem. If the problem didn't exist, we could use >>>>>>>>>> SSRC >>>>>>>>>> values to look up the context as it was I intended in SRTP. >>>>>>>>> >>>>>>>>> >>>>>>>>> E2E PERC is NOT SRTP. We may choose to make it look like it is an= d >>>>>>>>> I >>>>>>>>> see why that is appealing but not doing it is by no means "a hack= ". >>>>>>>> >>>>>>>> >>>>>>>> Of course it's SRTP. It just happens to be two passes of SRTP, bu= t >>>>>>>> it's >>>>>>>> nonetheless SRTP. >>>>>>> >>>>>>> >>>>>>> Exactly! And two passes of SRTP happen to NOT be SRTP as in: no sto= ck >>>>>>> SRTP endpoint would do anything meaningful with them. So what you a= re >>>>>>> looking is to just optimize implementations, which is relevant but >>>>>>> not >>>>>>> the primary concern. >>>>>>> >>>>>>>> What PERC is adding are some additional steps between >>>>>>>> each pass for HBH authentication of packets at the sender (and the >>>>>>>> reverse at the receiver). The MDD doesn't have two steps: it just >>>>>>>> does >>>>>>>> one normal SRTP decryption for the packet received and one SRTP >>>>>>>> encryption step sending the packet. The only special requirement >>>>>>>> PERC >>>>>>>> introduces is that if the MDD changes either the PT field or >>>>>>>> sequence >>>>>>>> number, the original values have to be added to the packet inside = an >>>>>>>> RTP >>>>>>>> header extension called OHB (if not already present). >>>>>>>> >>>>>>>> >>>>>>>>>> The problem with using a 64 bit value is that any existing SRTP >>>>>>>>>> library >>>>>>>>>> would have to change to associate the context that way. >>>>>>>>> >>>>>>>>> >>>>>>>>> So just to be clear ... we are lamenting about changing an int to= a >>>>>>>>> long? >>>>>>>> >>>>>>>> >>>>>>>> No, lamenting that this would not align with what RFC 3711 says to >>>>>>>> use >>>>>>>> to identify the context. >>>>>>> >>>>>>> >>>>>>> Again, 3711 applies to HBH. We are trying to reuse as much of it fo= r >>>>>>> E2E as possible and that's admirable but it's not a reason why we >>>>>>> should significantly disrupt existing implementations. >>>>>>> >>>>>>>>>> Further, if we >>>>>>>>>> wish to break up the PERC processing into two steps, that HBH SS= RC >>>>>>>>>> would >>>>>>>>>> have to be extracted and passed in by the application. While I >>>>>>>>>> think the >>>>>>>>>> intent with Double is for this to be an autonomous operation, it >>>>>>>>>> might >>>>>>>>>> not be implemented that way for two reasons: >>>>>>>>>> 1) If there is a desire to do HBH FEC, the process might be to >>>>>>>>>> encrypt >>>>>>>>>> E2E -> FEC -> HBH. So the second call to the SRTP library would >>>>>>>>>> need >>>>>>>>>> that HBH SSRC passed in when doing these steps in reverse to >>>>>>>>>> introduce >>>>>>>>>> that 64-bit context ID. >>>>>>>>> >>>>>>>>> >>>>>>>>> Em ... you'd have to explain this in a bit more detail because I >>>>>>>>> fail >>>>>>>>> to see how FEC is any different than regular media. As you say it >>>>>>>>> yourself, it all just works out properly as long as you do your F= EC >>>>>>>>> after E2E and before HBH as that way the SFU would be able to de- >>>>>>>>> or >>>>>>>>> re-FEC. >>>>>>>> >>>>>>>> >>>>>>>> Historically, there were two options for FEC. Either we do FEC >>>>>>>> first >>>>>>>> and then SRTP, or SRTP first then FEC. The order has to match at >>>>>>>> both >>>>>>>> the sender and receiver. Either way, it generally makes very litt= le >>>>>>>> difference. >>>>>>>> >>>>>>>> An MDD might want to be a good citizen and reconstruct lost packet= s >>>>>>>> before sending a stream to a receiver. In order to do that, the >>>>>>>> sender >>>>>>>> will either need to do SRTP (both passes) then FEC or it could do >>>>>>>> the >>>>>>>> first SRTP pass (the E2E encryption pass) then FEC then SRTP for t= he >>>>>>>> HBH. It really depends on what we want that FEC flow to look like= . >>>>>>>> Do >>>>>>>> we want it to be FEC over a bunch of E2E+HBH encrypted packets or >>>>>>>> just >>>>>>>> over the E2E packets. (The latter would be parallel to the curren= t >>>>>>>> FEC >>>>>>>> order of "FEC then SRTP". >>>>>>>> >>>>>>>> So, thinking of how this might be implemented in an SRTP library, = if >>>>>>>> we >>>>>>>> allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when >>>>>>>> the >>>>>>>> application encrypts the packet, it would pass the packet into the >>>>>>>> SRTP >>>>>>>> libtary once to encrypt HBH. >>>>>>> >>>>>>> >>>>>>> You mean E2E here. >>>>>>> >>>>>>>> It then does whatever FEC processing it >>>>>>>> wants, then it calls into the SRTP library again to encrypt the >>>>>>>> second >>>>>>>> pass (HBH pass). It could be two entirely instances of the SRTP >>>>>>>> library >>>>>>>> that handles each pass. On the MDD, it decrypts the flow and does >>>>>>>> whatevever FEC magic it wants to do. There is only one SRTP >>>>>>>> operation >>>>>>>> at the MDD, so no problem. At the receiver, it decrypts the packe= t >>>>>>>> received using HBH decryption. It then does whatever FEC processin= g >>>>>>>> it >>>>>>>> needs to do. Next, it would call into the SRTP library to decrypt >>>>>>>> for >>>>>>>> E2E. If the SSRCs never change, this works fine. One could >>>>>>>> implement >>>>>>>> this using two instances of an SRTP library today. If a single >>>>>>>> library >>>>>>>> is used, then the only requirement is to ensure the second call in= to >>>>>>>> the >>>>>>>> library does not encounter issues with the replay database (since = it >>>>>>>> might otherwise think it's a replayed packet). In either case, th= e >>>>>>>> crypto context would be looked up as per RFC 3711 using SSRC. If, >>>>>>>> however, the SSRC value is allowed to change, then the second call >>>>>>>> into >>>>>>>> the SRTP library (same or different instance of the library) would >>>>>>>> be a >>>>>>>> problem since Alice and Bob both used SSRC 1. The collision is >>>>>>>> going to >>>>>>>> prevent the library from working properly. >>>>>>> >>>>>>> >>>>>>> I still fail to see how FEC changes any of this (for better or >>>>>>> worse). >>>>>>> The problem you describe here is exactly the same with or without F= EC >>>>>>> and it's what we are having the argument about. >>>>>>> >>>>>>>> If we take the approach of using a 64-bit identifier (in >>>>>>>> contradiction >>>>>>>> to RFC 3711) >>>>>>> >>>>>>> >>>>>>> :) ... It is NOT in contradiction with 3711 because layers of >>>>>>> encryptions are not part of 3711. We simply need to set the >>>>>>> expectations right for implementers. >>>>>>> >>>>>>>> to identify the crypto context, then we would need to pass >>>>>>>> that identifier into the SRTP library when attempting to decrypt t= he >>>>>>>> packet, because it could not simply discover it by looking at the >>>>>>>> packet >>>>>>>> (which it could do normally since the SSRC value is right there in >>>>>>>> the >>>>>>>> packet). It would be necessary to make a call like >>>>>>>> srtp_unprotect(context, packet, stream_identifiier) (where >>>>>>>> stream_identifier is something that identifies the stream other th= an >>>>>>>> the >>>>>>>> SSRC per 3711, like E2E_SSRC || HBH_SSRC). >>>>>>>> >>>>>>>> A beautiful thing about SRTP today >>>>>>> >>>>>>> >>>>>>> You mean PERC here and not SRTP (even if PERC does simply apply a >>>>>>> second srtp unprotect it is still not stock 3711). >>>>>>> >>>>>>>> is the library can operate on streams >>>>>>>> without the application having to pass in such identifiers. The >>>>>>>> stream >>>>>>>> is self-identifying. But, we lose that elegance when we modify th= e >>>>>>>> SSRC >>>>>>>> in the MDD when we break the operation into two passes to handle >>>>>>>> this >>>>>>>> FEC order. >>>>>>> >>>>>>> >>>>>>> So we have an aesthetic concern because we have to change int-s to >>>>>>> long-s and that's why we are having a 100 mail thread. I am >>>>>>> speechless. >>>>>>> >>>>>>>>>> 2) It might be desirable to implement the PERC logic by just >>>>>>>>>> having a >>>>>>>>>> two-step wrapper around the existing SRTP library to avoid makin= g >>>>>>>>>> changes to the core library. (I'd prefer built-in support for >>>>>>>>>> Double, >>>>>>>>>> but I can appreciate how some might prefer to not change an >>>>>>>>>> otherwise >>>>>>>>>> working library.) >>>>>>>>> >>>>>>>>> >>>>>>>>> As I said, being able to reuse SRTP libraries with no change is a >>>>>>>>> great optimization if we get it but I really don't think the >>>>>>>>> alternative is anywhere near the complexity that would justify >>>>>>>>> banning >>>>>>>>> SSRC re-writing. >>>>>>>> >>>>>>>> >>>>>>>> At least we agree that it would be a good goal to find an approach >>>>>>>> that >>>>>>>> would eliminate or minimize changes to the SRTP logic. :) >>>>>>>> >>>>>>>> Now to the complexity part... that's in the thread you're having >>>>>>>> with >>>>>>>> Cullen which, as I understand, is an expression of a concern that >>>>>>>> receiving endpoints are not going to properly handle multiple >>>>>>>> simulcast >>>>>>>> streams coming toward them. >>>>>>>> >>>>>>>> Since I don't work for a browser vendor, I cannot speak to their >>>>>>>> plans. >>>>>>>> I can only assume that proper handling of received simulcast flows >>>>>>>> would >>>>>>>> be implemented per the current drafts. And if that's the case, th= en >>>>>>>> I >>>>>>>> don't think changing the SSRC would be needed. If receiving >>>>>>>> endpoints >>>>>>>> fail to do that, then you're right that this could be a problem. >>>>>>> >>>>>>> >>>>>>> Let's be clear on this. There is absolutely nothing wrong or standa= rd >>>>>>> breaking in the way browsers handle simulcast reception today. They >>>>>>> are simply not simulcast aware and the SFU hides it from them. >>>>>>> >>>>>>> There is no reason why that would be labelled a bad practice even >>>>>>> when >>>>>>> RID does go through all of the IETF process. >>>>>>> >>>>>>> Also, the availability of this option (simulcast unaware receivers) >>>>>>> and its existence today make the motivation for RID support on the >>>>>>> receiving end pretty low. It does not give you anything extra in >>>>>>> terms >>>>>>> of functionality. There are no substantial benefits from doing it >>>>>>> (and >>>>>>> no it doesn't allow for significantly simpler SFUs ... those would >>>>>>> still have to keep 95% of their existing logic). We can decide to >>>>>>> make >>>>>>> PERC dependent on it and hope that this would sway all browser >>>>>>> vendors >>>>>>> ... or we could also try to lower the burden on PERC adoption. >>>>>>> >>>>>>> Again, as stated in the beginning of this mail: it sounds like a >>>>>>> compromise may lie in the option for PERC to allow an SSRC rewritin= g >>>>>>> mode combined with the option for endpoints to not support it. In >>>>>>> other words we can have part of the PERC signalling indicate whethe= r >>>>>>> the client and the server support these modes and whether they use >>>>>>> them. This is not beautiful (by any means) but it wouldn't prevent >>>>>>> either of us to do things their way. >>>>>>> >>>>>>> Emil >>>>>>> -- https://jitsi.org >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> https://jitsi.org >>>>> >>>>> _______________________________________________ >>>>> Perc mailing list >>>>> Perc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>>> >>> >>> >>> -- >>> sent from my mobile >>> >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >> >> >> >> -- >> Miguel Par=C3=ADs D=C3=ADaz >> ------------------------------------------------------------------------ >> Computer/Software engineer. >> Researcher and architect in http://www.kurento.org >> http://twitter.com/mparisdiaz >> ------------------------------------------------------------------------ > > > > > -- > Miguel Par=C3=ADs D=C3=ADaz > ------------------------------------------------------------------------ > Computer/Software engineer. > Researcher and architect in http://www.kurento.org > http://twitter.com/mparisdiaz > ------------------------------------------------------------------------ > --=20 https://jitsi.org From nobody Wed Jul 20 08:11:25 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B618A12D8C1 for ; Wed, 20 Jul 2016 08:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPj27VaPAaoJ for ; Wed, 20 Jul 2016 08:11:04 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 6A81D12D815 for ; Wed, 20 Jul 2016 08:11:04 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id o80so73753470wme.1 for ; Wed, 20 Jul 2016 08:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xV3rZ3gC8wPWgb9jhDgGAQ3ReOrhCYlDjgHX8Z2ZI2w=; b=yOdGwBf/nFbsHX/wZTUoKDKUavRC+etFR8P7n84W61kxFO8vy0FOMUJ0aziLlsWAko fx/68YVqf7NDXiBVHnRVc2NHvlorKoMpp60qyDM6qYfSzwECpnelPkQ/FaRHf59rs3ZT iz0qLQe5+w+Xec0c1RJLRvxshoJZc6MXWAewsjzQIEt6JXyQx5AH3fD6tYStSK4ry94M JVCnXlZmQ6d0fq4xPWG5AcblW7oOGUxarz8+88STgRRn6EoozKjYYVqe1etmpBx09H5b p0zWWLNkxwzb+w4wY/SsfM8ery61/W6ITVzY50g/uwTXikMneV2bMwItuz1xzj1gApYG 7vIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xV3rZ3gC8wPWgb9jhDgGAQ3ReOrhCYlDjgHX8Z2ZI2w=; b=Ll/aDWLE/rkemHraX7EN3jTnInfgXdmW03WwdjE4WrZ6PtNhbOJK10DHZdA40eiHX6 L4GbMNtoBhBfxqG3UAZuM15+9KBTwqwKf87sv8+7AUNiz4sVZ92iwR2pYte+XSM0aHQz 6KqlXWzZjOiwmzuX2Ve26wsmA543ZqAG+rcH/fHvPjDvqwgMFmY6DeeN3t8JveOqQGu/ IfQa2tT4Fuv9Zw+sm4mjOR3sm/JUG2HLj9y+RGlL93oua+ueh30rQI0urKddLvxQ9sZu 4DPy/RO8yt36Vr9fMQvS3A3kVPn7s1G8G2+qLRefgFmyeN12rn8crhR4eBRmoiQAbJ3r bbPg== X-Gm-Message-State: ALyK8tITnQJhT4NepjRU8iCt3ZyEry7RVoKrmmMTwghOcFdBAyKwHKRMss9AE25G2owfnQ== X-Received: by 10.28.25.135 with SMTP id 129mr11352871wmz.59.1469027462964; Wed, 20 Jul 2016 08:11:02 -0700 (PDT) Received: from [10.24.253.149] ([46.189.28.89]) by smtp.gmail.com with ESMTPSA id b130sm31984474wmg.3.2016.07.20.08.11.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jul 2016 08:11:02 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-8C2C538A-D55F-43F9-8DCF-81FED131E316 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13F69) In-Reply-To: Date: Wed, 20 Jul 2016 17:11:01 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: =?utf-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Archived-At: Cc: Eric Rescorla , Adam Roach , Emil Ivov , "perc@ietf.org" , "Paul E. Jones" , Cullen Jennings Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:11:10 -0000 --Apple-Mail-8C2C538A-D55F-43F9-8DCF-81FED131E316 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Jul 20, 2016, at 16:35, Miguel Par=C3=ADs D=C3=ADaz wrote: > If we do NOT do that, the another possibility (I didn't found others) is n= egotiating with the receiver N SSRCs (each one per quality) performing ON/OFF= at the SFU side and doing the switching in the receiver. For doing that: > You have N MediaStreamTracks. > You have to detect at application layer when a MediaStreamTrack stops rece= iving media using getUserMedia API's events (which takes at least 500ms) [BA] I do not believe those events provide a useful way to support reception= of simulcast in WebRTC 1.0. That is why simulcast reception is not supporte= d. In ORTC it is supported (2 implementations) but experience shows that withou= t an explicit switching indication (like PAUSED or SEI layer drop) it is qui= te difficult to perform well in the face of reordering. Without a drop indic= ation or RFC 6051 support, a single stream approach typically works much bet= ter.=20= --Apple-Mail-8C2C538A-D55F-43F9-8DCF-81FED131E316 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jul 20, 2016, at 16:35, M= iguel Par=C3=ADs D=C3=ADaz <mpari= sdiaz@gmail.com> wrote:
  • If we do NOT do that,= the another=20 possibility (I didn't found others) is negotiating with the receiver N=20 SSRCs (each one per quality) performing ON/OFF at the SFU side and doing the switching in the receiver. For doing that:
    • You have N Media= StreamTracks.
    • You have to detect at application layer when a MediaStreamTrack stops=20 receiving media using getUserMedia API's events (which takes at least=20 500ms)
[BA] I do not believe tho= se events provide a useful way to support reception of simulcast in WebRTC 1= .0. That is why simulcast reception is not supported.

In ORTC it is supported (2 implementations) but experience shows that wit= hout an explicit switching indication (like PAUSED or SEI layer drop) it is q= uite difficult to perform well in the face of reordering. Without a drop ind= ication or RFC 6051 support, a single stream approach typically works much b= etter. = --Apple-Mail-8C2C538A-D55F-43F9-8DCF-81FED131E316-- From nobody Thu Jul 21 02:05:08 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA3A12DC3D for ; Thu, 21 Jul 2016 02:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5kRI65oIrVW for ; Thu, 21 Jul 2016 02:04:55 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 2471A12DC24 for ; Thu, 21 Jul 2016 02:04:55 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id f93so55804404lfi.2 for ; Thu, 21 Jul 2016 02:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=k/C9tGBk3LqcZv6Y5xg7N8052r8ptngf9vQuuiDVqXc=; b=guvwR9oITngvx6cIsmlhAi5SBi2miEQ8c6jIucFAjdiouFV1oGwiPdL1fXIvspEiRI B66O3T5B8+bT0TqP4PoJwFzmcx5f7ZoZlojlzw4MplhkFp15NF/V918bcV/OEN/0zhGm cudP2zyKcJVnsWXhcbXkLZjtewM1anBouknTJ9K8sdtiqULyOszHF+e8sy9JTJcMpfXM svPhqdZejc26OzLN+JQIzxTOrRhcS8CeO63ObBxdfpahHmUYDN1oR+BpZBRVAi+amjOI wNPMwdUWicIyKbiwsiawTU7zknc/ZkTDrEfzKRLpYJyhZgRkXvkc/EvYbF2calgEcSAW Y48Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=k/C9tGBk3LqcZv6Y5xg7N8052r8ptngf9vQuuiDVqXc=; b=SO/IYotNDxmD2kKCPJEvAisg3/Yl95ybH7f85Y2PGZjzcN1GIRcNnvSzH7R73v/3GG CQ8v4Ozj+ktDCdm9E2/FInStNJNK0bRKGyMsRHFQDlCIshmwgAR7gPO7D8/EyCapjvKA k+AGHu2YcLyOp549N2GYx1VYelwNhLNUClr4QOe6SPInzUHr6t9H268Iw3FPZ02KdFVB xtmsqYEgLLWKA3xzavtuE1IkXtqv9Vl7TQ9waeFD7N11lv1doK9hfMPZ8J0RTWrd18/7 LUwXNOEPg4Nlgr8mu6tBthnPM/7QpvQTletbMuvnmwlJhl+hYlJDyBgwUJNB8nNjjqbk cFew== X-Gm-Message-State: ALyK8tIJaSfhFX+HdevYq5r95qNS8NmXEVmw6CdV9/tLWofW5Vz/MW/OJrnRL+SKgBv5Qg== X-Received: by 10.25.169.213 with SMTP id s204mr12020996lfe.57.1469091893344; Thu, 21 Jul 2016 02:04:53 -0700 (PDT) Received: from RoniPC ([2001:67c:370:160:c1e8:32b0:c7b2:252b]) by smtp.gmail.com with ESMTPSA id 90sm1385521lfs.7.2016.07.21.02.04.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 02:04:52 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , References: In-Reply-To: Date: Thu, 21 Jul 2016 12:04:50 +0300 Message-ID: <00ba01d1e32e$f0b9bc40$d22d34c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7aEbfowG3EBQRTHYrvP4Sk7/xeKDPjHqw Content-Language: he Archived-At: Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 09:05:07 -0000 Hi, The framework document defines the MD as "Media Distributor (MD): An RTP middlebox that is not allowed to to have access to E2E encryption keys. It may operate according to any of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] per the constraints defined by the PERC system, which includes, but not limited to, having no access to RTP media unencrypted and having limits on what RTP header field it can alter." If we do not allow changing SSRC by the middle box then as far as I can see this means that only Topo-PtP-Translator from RFC7667 is applicable for PERC and not any other topology Roni Even > -----Original Message----- > From: Perc [mailto:perc-bounces@ietf.org] On Behalf Of Emil Ivov > Sent: Monday, May 16, 2016 10:43 PM > To: perc@ietf.org > Subject: [Perc] Request for decision review > > Hey all, > > The parallel thread that we had going on the subject might have become too > hairy so I assume not everyone is following, so I am spinning off this one: > > I would officially like to ask the PERC WG to review the decision for > immutable SSRCs. > > At this point, after the many conversations on the topic, it sounds like no one > would really have a problem with SSRCs being mutable. We also have at least > some (if not many) implementers ranting that lacking the possibility to > change SSRCs would make things *very* complicated for them. > > So all in all it sounds like we'd have a net positive if we reviewed that > decision. > > Could we please do that? > > Emil > > -- > https://jitsi.org > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Thu Jul 21 05:42:50 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB9A12B059 for ; Thu, 21 Jul 2016 05:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP3WXdJLk0kQ for ; Thu, 21 Jul 2016 05:42:45 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F94112B00E for ; Thu, 21 Jul 2016 05:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2078; q=dns/txt; s=iport; t=1469104636; x=1470314236; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Y5OHj13301J98cHS4RjBGS7Ifcb+UhznPr2ibLO9T4U=; b=Kop/yLM+CVfR9Y5l6dHmu2ZzA4N+MGy8ppvjvtzjm1Ugq6KjZq6ur3Is 6kkkstiC2Rk6d7FFqq5W0UipPq8uyU0tTNN1bDfVeIiuc2ad4CBt+i6dj xUs1gC7LuZY1yRQ3Ph1KWbn4dSXDOfoThePvDNVHnIh4xlYBNHYfqnEoQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAgBOwZBX/4kNJK1dgz9WfAa4XoF7I?= =?us-ascii?q?oV4AhyBETgUAQEBAQEBAWUnhFwBAQUdBhFRBAIBCBoCJgICAjAVEAIEARqIKA6?= =?us-ascii?q?vFo1pAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUphE2BIoJ6BwEBgxyCWgWZJ?= =?us-ascii?q?gGOY4FzjU5vhXGJQAEeNoILHIFMbgGGCQ8XH38BAQE?= X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="299061118" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Jul 2016 12:37:15 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u6LCbFim019299 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 12:37:15 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 07:37:14 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 07:37:14 -0500 From: "David Benham (dbenham)" To: "ron.even.tlv@gmail.com" , "perc@ietf.org" Thread-Topic: [Perc] Request for decision review Thread-Index: AQHR4pkQTIdp+V/CSEONQm5zFzjYpqAiyx7A Date: Thu, 21 Jul 2016 12:37:14 +0000 Message-ID: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.86.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:42:49 -0000 RGVzcGl0ZSBnaXZpbmcgYW4gYWRkaXRpb25hbCBhbnN3ZXIgYmVsb3csIEkgYW0gYWxzbyBjYWxs aW5nIGZvciArMXMgZnJvbSB0aGlzIGxpc3QgaW4gZmF2b3Igb2YgLi4uDQogICBhKSBub3QgZG8g dGhpcyBtYXBwaW5nIHRvIDc2NjcgdG9wb2xvZ2llcyBub3cgd2hpbGUgc3RpbGwgc28gbXVjaCBt b3JlIFBFUkMgZGVzaWduIHdvcmsgdG8gZG8NCiAgICAgICAgICBhbmQNCiAgIGIpIGRvIHRoaXMg bWFwcGluZyB0byA3NjY3IHRvcG9sb2dpZXMgb24gdGhlIEFWVC1Db3JlIG1haWwgbGlzdCBhbmQv b3IgKGpvaW50KSBhZ2VuZGEgdGltZSBpbiBmdXR1cmUgaWYgbmVlZGVkDQoNCg0KDQpTZWxlY3Rp dmUgRm9yd2FyZGluZyBNaWRkbGVib3ggKHNlY3QgMy43IG9mIFJGQzc2NjcpIGFjY29tbW9kYXRl cyBlaXRoZXIgU1NSQyB0ZXJtaW5hdGlvbi9yZXdyaXRlcyAoc2VwYXJhdGUgc3BhY2UpIG9yIFNT UkMgbm9uLXRlcm1pbmF0aW9uL25vLXJld3JpdGUgKGNvbW1vbiBzcGFjZSkuDQoNCkkgY2hlY2tl ZCB3aXRoIE1hZ251cyBvdmVyIGEgeWVhciBhZ28gdGhhdCBpbmRlZWQgU1NSQyB0ZXJtaW5hdGlv bi9yZXdyaXRlcyB3YXMgbm90IHRoZSBvbmx5IG1vZGUgZm9yIDMuNyBTRk0ncy4NCkhlIGRpZCBz b21lIHJld29yZGluZyB0byBzZWN0IDMuNyBtYWtlIHRoYXQgKG1pbGRseSkgY2xlYXJlciBhZnRl ciBvdXIgZXhjaGFuZ2UuDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2F2 dC9jdXJyZW50L21zZzE2Njk5Lmh0bWwNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvYXZ0L2N1cnJlbnQvbXNnMTY3MDAuaHRtbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpUaGUgZnJhbWV3b3JrIGRvY3VtZW50IGRlZmluZXMgdGhlIE1EIGFzDQoiTWVkaWEg RGlzdHJpYnV0b3IgKE1EKTogQW4gUlRQIG1pZGRsZWJveCB0aGF0IGlzIG5vdCBhbGxvd2VkIHRv IHRvDQogICBoYXZlIGFjY2VzcyB0byBFMkUgZW5jcnlwdGlvbiBrZXlzLiAgSXQgbWF5IG9wZXJh dGUgYWNjb3JkaW5nIHRvIGFueQ0KICAgb2YgdGhlIFJUUCB0b3BvbG9naWVzIFtJLUQuaWV0Zi1h dnRjb3JlLXJ0cC10b3BvbG9naWVzLXVwZGF0ZV0gcGVyDQogICB0aGUgY29uc3RyYWludHMgZGVm aW5lZCBieSB0aGUgUEVSQyBzeXN0ZW0sIHdoaWNoIGluY2x1ZGVzLCBidXQgbm90DQogICBsaW1p dGVkIHRvLCBoYXZpbmcgbm8gYWNjZXNzIHRvIFJUUCBtZWRpYSB1bmVuY3J5cHRlZCBhbmQgaGF2 aW5nDQogICBsaW1pdHMgb24gd2hhdCBSVFAgaGVhZGVyIGZpZWxkIGl0IGNhbiBhbHRlci4iDQoN CklmIHdlIGRvIG5vdCBhbGxvdyBjaGFuZ2luZyBTU1JDIGJ5IHRoZSBtaWRkbGUgYm94IHRoZW4g YXMgZmFyIGFzIEkgY2FuIHNlZQ0KdGhpcyBtZWFucyB0aGF0IG9ubHkgVG9wby1QdFAtVHJhbnNs YXRvciBmcm9tIFJGQzc2NjcgaXMgYXBwbGljYWJsZSBmb3IgUEVSQw0KYW5kIG5vdCBhbnkgb3Ro ZXIgdG9wb2xvZ3kNCg0KUm9uaSBFdmVuDQoNCg0KDQoNCg0K From nobody Thu Jul 21 05:45:21 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5612D5B5 for ; Thu, 21 Jul 2016 05:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCIwVWSbJkd4 for ; Thu, 21 Jul 2016 05:45:11 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 142B712DA20 for ; Thu, 21 Jul 2016 05:45:08 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id b199so60973454lfe.0 for ; Thu, 21 Jul 2016 05:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Xa9jO5tThlm33PawcLO0mrQcyQJcGDsI4wUwa/YVxVs=; b=qoMWV2Dn3gTIT+jZp6t37KmiqH9+5v7PTaZQ6ZXszqEAmYaeDHJ2FqAIoMUlxzvl7B XrHBRiXw6XH3QAgIkr5aY7aLSxXg7GFsUa3baGEcG2WH3imwvP4uZApLRol8NlsAZC8z SmCQCappp5Jo/2x3EEf3raYLw4SPE1hJGaa8U67u0VWtL+5xThl6MjP7e6fs2blVI1+X DtakzJeYJND8KUqqClomLW55URZsdnRcHJd7vXASDsu9KcsDdbCSZ076j/ziganoL/pk sKztD3kdQOcuv+UfodaKCtUIPFADvuWxeyExoqvBcA37hsF2Fqe0gCroUkf0R7Vj+ukk HEcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Xa9jO5tThlm33PawcLO0mrQcyQJcGDsI4wUwa/YVxVs=; b=NvGiRUCFWfNmN7VHj7UVZ35tdYoMTK6fh96I/cwyfVALbkinZqQ+w0CXijazJL4WgC Azb0Ydaxn89ou9cy+4OY70UjZJp9s+xtGe5Mt0aNNjJt3pWAG4Scj5Lo+KV4Dqy0QVcO Fyo/23dq/B6akvAPQjF9qEk231Gn6X7LX+1+3IoxIx9SzDh1e4FqITYoWPgshA9z90OD a3UzOrlrK84swjqePWBt/RxKExApzugTHNvz1ShdU+7J99Wt44g6bwoExWoBn2gG8I/h ycKN0MdtCFe/27+h37+IS8z5rweD4FQqCJ+TC1oOiDjlrlLypbAPkkhPIGNPjxM2QM5l s2Jg== X-Gm-Message-State: ALyK8tKRCA0rgDJEeSnhjsC/+w3FRZpMJrHbPS9bkNXvi23OiIeVrrxKX6ZjGJ+PnhciBQ== X-Received: by 10.46.5.5 with SMTP id 5mr23662754ljf.9.1469105106196; Thu, 21 Jul 2016 05:45:06 -0700 (PDT) Received: from RoniPC ([2001:67c:370:160:c1e8:32b0:c7b2:252b]) by smtp.gmail.com with ESMTPSA id c125sm1737860lfe.10.2016.07.21.05.45.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 05:45:04 -0700 (PDT) From: "Roni Even" To: "'David Benham \(dbenham\)'" , References: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> In-Reply-To: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> Date: Thu, 21 Jul 2016 15:45:03 +0300 Message-ID: <010801d1e34d$b3bab640$1b3022c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNScl5U2jL3LzFW4U4u2OfzoV0JowKMCgTMAlnbDmgCTM3egALxaCNRnNCUHiA= Content-Language: he Archived-At: Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 12:45:19 -0000 Hi, What confuses me is that the framework document reference RFC7667 but = does not say what is the PEWRC topology at all. So we are trying to = define a solution to an undefined topology. This should be a PERC issue, = not AVTcore, this is why PERC was formed As for SFM it can have one RTP session to all participants but I assume = it will still need some way to indicate the mapping of incoming streams = to outgoing stream from the SFM otherwise the receiver does not know if = there is one or multiple RTP sessions. This is what Emil suggested for = identifying if SSRC are mutable or not. Roni > -----Original Message----- > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > Sent: Thursday, July 21, 2016 3:37 PM > To: ron.even.tlv@gmail.com; perc@ietf.org > Subject: RE: [Perc] Request for decision review >=20 > Despite giving an additional answer below, I am also calling for +1s = from this > list in favor of ... > a) not do this mapping to 7667 topologies now while still so much = more > PERC design work to do > and > b) do this mapping to 7667 topologies on the AVT-Core mail list = and/or > (joint) agenda time in future if needed >=20 >=20 >=20 > Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommodates = either > SSRC termination/rewrites (separate space) or SSRC non-termination/no- > rewrite (common space). >=20 > I checked with Magnus over a year ago that indeed SSRC > termination/rewrites was not the only mode for 3.7 SFM's. > He did some rewording to sect 3.7 make that (mildly) clearer after our > exchange. > https://www.ietf.org/mail-archive/web/avt/current/msg16699.html > https://www.ietf.org/mail-archive/web/avt/current/msg16700.html >=20 >=20 > -----Original Message----- > The framework document defines the MD as "Media Distributor (MD): An > RTP middlebox that is not allowed to to > have access to E2E encryption keys. It may operate according to = any > of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] per > the constraints defined by the PERC system, which includes, but not > limited to, having no access to RTP media unencrypted and having > limits on what RTP header field it can alter." >=20 > If we do not allow changing SSRC by the middle box then as far as I = can see > this means that only Topo-PtP-Translator from RFC7667 is applicable = for > PERC and not any other topology >=20 > Roni Even >=20 >=20 >=20 >=20 From nobody Thu Jul 21 06:01:47 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F4312D827 for ; Thu, 21 Jul 2016 06:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlgdaf6csjx4 for ; Thu, 21 Jul 2016 06:01:41 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63ADF12D5FB for ; Thu, 21 Jul 2016 06:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3856; q=dns/txt; s=iport; t=1469106091; x=1470315691; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XkANeFQIupJVwiNPM4wWn+mLggV/mhqZfVtihR9kEEk=; b=BaWEnxcmfWdWfUr4bNUqXsBepDYVDsFHwHXePCZFJ7uiK5sIwggZs4DK AeeKNaMUn3b4oygdJJJoRRZS3zh9e78zRztVtzq1lBmJC9qUkgjUlFPLg pK1v9nONdg7u+Bq23TUI28+B4mZ2JpaXehC76yDzShd6f/5DGvF7iipcO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgC1xpBX/49dJa1dgz9WfAasRIwcg?= =?us-ascii?q?XsihXgCHIEROBQBAQEBAQEBZSeEXAEBBR0GEVEEAgEIDgMEAQEDAiMDAgICHxE?= =?us-ascii?q?UAQgIAgQBEggTh3sDFw6vIYlWDYQJAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBA?= =?us-ascii?q?YUphE2BIoEhgVkHAQGDHIJaBZhyNAGMRoIdgXONTm+FcYFGh3oBHjaCCxyBTG4?= =?us-ascii?q?BhgkPFx9/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="298714594" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 13:01:30 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u6LD1U5B004176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 13:01:30 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 08:01:29 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 08:01:29 -0500 From: "David Benham (dbenham)" To: Roni Even , "perc@ietf.org" Thread-Topic: [Perc] Request for decision review Thread-Index: AQHR4pkQTIdp+V/CSEONQm5zFzjYpqAiyx7AgABe6ID//61OgA== Date: Thu, 21 Jul 2016 13:01:29 +0000 Message-ID: References: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> <010801d1e34d$b3bab640$1b3022c0$@gmail.com> In-Reply-To: <010801d1e34d$b3bab640$1b3022c0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.86.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:01:45 -0000 TmVlZCB0byBzdGFydCBhbiBSRkM3NjY3YmlzIHRvIGVsYWJvcmF0ZSBmdXJ0aGVyIG9uIGhvdyBh biBTRk0gd29ya3MgaW4gU1NSQyBub24tdGVybWluYXRpb24vbm8tcmV3cml0ZSAoY29tbW9uIHNw YWNlKSBjYXNlPw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb25pIEV2 ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKdWx5 IDIxLCAyMDE2IDU6NDUgQU0NClRvOiBEYXZpZCBCZW5oYW0gKGRiZW5oYW0pIDxkYmVuaGFtQGNp c2NvLmNvbT47IHBlcmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbUGVyY10gUmVxdWVzdCBmb3Ig ZGVjaXNpb24gcmV2aWV3DQpJbXBvcnRhbmNlOiBIaWdoDQoNCkhpLA0KV2hhdCBjb25mdXNlcyBt ZSBpcyB0aGF0IHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQgcmVmZXJlbmNlIFJGQzc2NjcgYnV0IGRv ZXMgbm90IHNheSB3aGF0IGlzIHRoZSBQRVdSQyB0b3BvbG9neSBhdCBhbGwuIFNvIHdlIGFyZSB0 cnlpbmcgdG8gZGVmaW5lIGEgc29sdXRpb24gdG8gYW4gdW5kZWZpbmVkIHRvcG9sb2d5LiBUaGlz IHNob3VsZCBiZSBhIFBFUkMgaXNzdWUsIG5vdCBBVlRjb3JlLCB0aGlzIGlzIHdoeSBQRVJDIHdh cyBmb3JtZWQNCg0KQXMgZm9yIFNGTSBpdCBjYW4gaGF2ZSBvbmUgUlRQIHNlc3Npb24gdG8gYWxs IHBhcnRpY2lwYW50cyBidXQgSSBhc3N1bWUgaXQgd2lsbCBzdGlsbCBuZWVkIHNvbWUgd2F5IHRv IGluZGljYXRlIHRoZSBtYXBwaW5nIG9mIGluY29taW5nIHN0cmVhbXMgdG8gb3V0Z29pbmcgc3Ry ZWFtIGZyb20gdGhlIFNGTSBvdGhlcndpc2UgdGhlIHJlY2VpdmVyIGRvZXMgbm90IGtub3cgaWYg dGhlcmUgaXMgb25lIG9yIG11bHRpcGxlIFJUUCBzZXNzaW9ucy4gVGhpcyBpcyB3aGF0IEVtaWwg c3VnZ2VzdGVkIGZvciBpZGVudGlmeWluZyBpZiBTU1JDIGFyZSBtdXRhYmxlIG9yIG5vdC4NCg0K Um9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhdmlkIEJlbmhh bSAoZGJlbmhhbSkgW21haWx0bzpkYmVuaGFtQGNpc2NvLmNvbV0NCj4gU2VudDogVGh1cnNkYXks IEp1bHkgMjEsIDIwMTYgMzozNyBQTQ0KPiBUbzogcm9uLmV2ZW4udGx2QGdtYWlsLmNvbTsgcGVy Y0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW1BlcmNdIFJlcXVlc3QgZm9yIGRlY2lzaW9uIHJl dmlldw0KPiANCj4gRGVzcGl0ZSBnaXZpbmcgYW4gYWRkaXRpb25hbCBhbnN3ZXIgYmVsb3csIEkg YW0gYWxzbyBjYWxsaW5nIGZvciArMXMgZnJvbSB0aGlzDQo+IGxpc3QgaW4gZmF2b3Igb2YgLi4u DQo+ICAgIGEpIG5vdCBkbyB0aGlzIG1hcHBpbmcgdG8gNzY2NyB0b3BvbG9naWVzIG5vdyB3aGls ZSBzdGlsbCBzbyBtdWNoIG1vcmUNCj4gUEVSQyBkZXNpZ24gd29yayB0byBkbw0KPiAgICAgICAg ICAgYW5kDQo+ICAgIGIpIGRvIHRoaXMgbWFwcGluZyB0byA3NjY3IHRvcG9sb2dpZXMgb24gdGhl IEFWVC1Db3JlIG1haWwgbGlzdCBhbmQvb3INCj4gKGpvaW50KSBhZ2VuZGEgdGltZSBpbiBmdXR1 cmUgaWYgbmVlZGVkDQo+IA0KPiANCj4gDQo+IFNlbGVjdGl2ZSBGb3J3YXJkaW5nIE1pZGRsZWJv eCAoc2VjdCAzLjcgb2YgUkZDNzY2NykgYWNjb21tb2RhdGVzIGVpdGhlcg0KPiBTU1JDIHRlcm1p bmF0aW9uL3Jld3JpdGVzIChzZXBhcmF0ZSBzcGFjZSkgb3IgU1NSQyBub24tdGVybWluYXRpb24v bm8tDQo+IHJld3JpdGUgKGNvbW1vbiBzcGFjZSkuDQo+IA0KPiBJIGNoZWNrZWQgd2l0aCBNYWdu dXMgb3ZlciBhIHllYXIgYWdvIHRoYXQgaW5kZWVkIFNTUkMNCj4gdGVybWluYXRpb24vcmV3cml0 ZXMgd2FzIG5vdCB0aGUgb25seSBtb2RlIGZvciAzLjcgU0ZNJ3MuDQo+IEhlIGRpZCBzb21lIHJl d29yZGluZyB0byBzZWN0IDMuNyBtYWtlIHRoYXQgKG1pbGRseSkgY2xlYXJlciBhZnRlciBvdXIN Cj4gZXhjaGFuZ2UuDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXZ0 L2N1cnJlbnQvbXNnMTY2OTkuaHRtbA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2F2dC9jdXJyZW50L21zZzE2NzAwLmh0bWwNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBUaGUgZnJhbWV3b3JrIGRvY3VtZW50IGRlZmluZXMgdGhlIE1EIGFz ICJNZWRpYSBEaXN0cmlidXRvciAoTUQpOiBBbg0KPiBSVFAgbWlkZGxlYm94IHRoYXQgaXMgbm90 IGFsbG93ZWQgdG8gdG8NCj4gICAgaGF2ZSBhY2Nlc3MgdG8gRTJFIGVuY3J5cHRpb24ga2V5cy4g IEl0IG1heSBvcGVyYXRlIGFjY29yZGluZyB0byBhbnkNCj4gICAgb2YgdGhlIFJUUCB0b3BvbG9n aWVzIFtJLUQuaWV0Zi1hdnRjb3JlLXJ0cC10b3BvbG9naWVzLXVwZGF0ZV0gcGVyDQo+ICAgIHRo ZSBjb25zdHJhaW50cyBkZWZpbmVkIGJ5IHRoZSBQRVJDIHN5c3RlbSwgd2hpY2ggaW5jbHVkZXMs IGJ1dCBub3QNCj4gICAgbGltaXRlZCB0bywgaGF2aW5nIG5vIGFjY2VzcyB0byBSVFAgbWVkaWEg dW5lbmNyeXB0ZWQgYW5kIGhhdmluZw0KPiAgICBsaW1pdHMgb24gd2hhdCBSVFAgaGVhZGVyIGZp ZWxkIGl0IGNhbiBhbHRlci4iDQo+IA0KPiBJZiB3ZSBkbyBub3QgYWxsb3cgY2hhbmdpbmcgU1NS QyBieSB0aGUgbWlkZGxlIGJveCB0aGVuIGFzIGZhciBhcyBJIGNhbiBzZWUNCj4gdGhpcyBtZWFu cyB0aGF0IG9ubHkgVG9wby1QdFAtVHJhbnNsYXRvciBmcm9tIFJGQzc2NjcgaXMgYXBwbGljYWJs ZSBmb3INCj4gUEVSQyBhbmQgbm90IGFueSBvdGhlciB0b3BvbG9neQ0KPiANCj4gUm9uaSBFdmVu DQo+IA0KPiANCj4gDQo+IA0KDQoNCg== From nobody Thu Jul 21 06:12:20 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D047912D187 for ; Thu, 21 Jul 2016 06:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_q-4xxhmEah for ; Thu, 21 Jul 2016 06:12:15 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 C78BC12B04D for ; Thu, 21 Jul 2016 06:12:13 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id f93so61586276lfi.2 for ; Thu, 21 Jul 2016 06:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=fA/5M65X/1X13ZsoZG9ndK2EZIoR11+D3ipYUNvqdGo=; b=trZ2WuWoK6mEAzj9XtFFOQDd2l9G86nCLquTxcn5eEpCOtAstlwk6IDTxpz6HpiFHX nXX6M33aMxmsWpz4OblRsQZBHJ7OmaH40Hd6TxlNTGyeKYT4hoQ9HLMQBS3KWuTH4+8q rYAjbK13tKKGhWSrNglkkdU6WrjKLzHXQlvbsbLq6xID+UrUIMsMcJDs9t9RvEoq9QZ4 W2Mi7Xc8n4QQfaTvOfE9LMV9e8ScEahWN06J92p6Vxah/Sb60ZZU2FzEK5r3KAEPbp4v xLpE1HRbLbAw2LAwWHIvwFRnTStGaT+aGlfTm8WeLrylXS5GmbtKOHAM5RTAuJOFR0ez yvog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=fA/5M65X/1X13ZsoZG9ndK2EZIoR11+D3ipYUNvqdGo=; b=ioJ+9BCSPjH3668hBLwvZvDPEEzTMcQ4VuGN5R0QZCCAq7IWcn9PwnsRMM+nnpcwLt 6ov5TxVtZTGwIglDJ2p02y0BuMvf4TJiUsLhV4wu2PSt2D/j62pupKKmdXLZbCAb0CgG YnoiSp+SNG326HoUM0wD25f5MT/wDdBE3+crYM5fBiQtzeJklKyH97jwvV20Q4XB1var Ba+Yot0lLtu5x+Gcmi15YUmRGwuaGL2iIaqcnJrFHI2OtTEKgrAk6BnCj/oCmLTy9k64 Ro7fMGxZD1wukJ/pDvqUNsguVUhDKOOfnyzmLdPjTnsIRjzlYbRzzsop4qi9Fzj5MVDM suZA== X-Gm-Message-State: ALyK8tKPccbOEuYi58G+Z3y+jbGwlLmKWrlN5jVidW6sgYsRMO6AWYBHma3KQH85AltY+g== X-Received: by 10.25.134.65 with SMTP id i62mr21814873lfd.128.1469106731912; Thu, 21 Jul 2016 06:12:11 -0700 (PDT) Received: from RoniPC (dhcp-a330.meeting.ietf.org. [31.133.163.48]) by smtp.gmail.com with ESMTPSA id 196sm1807888ljf.5.2016.07.21.06.12.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 06:12:10 -0700 (PDT) From: "Roni Even" To: "'David Benham \(dbenham\)'" , References: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> <010801d1e34d$b3bab640$1b3022c0$@gmail.com> In-Reply-To: Date: Thu, 21 Jul 2016 16:12:08 +0300 Message-ID: <011a01d1e351$7cca1690$765e43b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNScl5U2jL3LzFW4U4u2OfzoV0JowKMCgTMAlnbDmgCTM3egALxaCNRAm0AoT8By/j55pyu1H9Q Content-Language: he Archived-At: Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:12:18 -0000 You do not need to change RFC7667 since to know if it is a SSRC = terminating or not is not an RTP issue, it may be signaling issue and = this is not AVTcore charter. The PERC framework document must have clear text about what is in MD. It = is too vague now in order to see if the solution addresses the specified = MD. The framework is the only architecture document Roni > -----Original Message----- > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > Sent: Thursday, July 21, 2016 4:01 PM > To: Roni Even; perc@ietf.org > Subject: RE: [Perc] Request for decision review >=20 > Need to start an RFC7667bis to elaborate further on how an SFM works = in > SSRC non-termination/no-rewrite (common space) case? >=20 >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Thursday, July 21, 2016 5:45 AM > To: David Benham (dbenham) ; perc@ietf.org > Subject: RE: [Perc] Request for decision review > Importance: High >=20 > Hi, > What confuses me is that the framework document reference RFC7667 but > does not say what is the PEWRC topology at all. So we are trying to = define a > solution to an undefined topology. This should be a PERC issue, not = AVTcore, > this is why PERC was formed >=20 > As for SFM it can have one RTP session to all participants but I = assume it will > still need some way to indicate the mapping of incoming streams to = outgoing > stream from the SFM otherwise the receiver does not know if there is = one or > multiple RTP sessions. This is what Emil suggested for identifying if = SSRC are > mutable or not. >=20 > Roni >=20 > > -----Original Message----- > > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > > Sent: Thursday, July 21, 2016 3:37 PM > > To: ron.even.tlv@gmail.com; perc@ietf.org > > Subject: RE: [Perc] Request for decision review > > > > Despite giving an additional answer below, I am also calling for +1s > > from this list in favor of ... > > a) not do this mapping to 7667 topologies now while still so much > > more PERC design work to do > > and > > b) do this mapping to 7667 topologies on the AVT-Core mail list > > and/or > > (joint) agenda time in future if needed > > > > > > > > Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommodates > > either SSRC termination/rewrites (separate space) or SSRC > > non-termination/no- rewrite (common space). > > > > I checked with Magnus over a year ago that indeed SSRC > > termination/rewrites was not the only mode for 3.7 SFM's. > > He did some rewording to sect 3.7 make that (mildly) clearer after = our > > exchange. > > https://www.ietf.org/mail-archive/web/avt/current/msg16699.html > > https://www.ietf.org/mail-archive/web/avt/current/msg16700.html > > > > > > -----Original Message----- > > The framework document defines the MD as "Media Distributor (MD): An > > RTP middlebox that is not allowed to to > > have access to E2E encryption keys. It may operate according to = any > > of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] = per > > the constraints defined by the PERC system, which includes, but = not > > limited to, having no access to RTP media unencrypted and having > > limits on what RTP header field it can alter." > > > > If we do not allow changing SSRC by the middle box then as far as I > > can see this means that only Topo-PtP-Translator from RFC7667 is > > applicable for PERC and not any other topology > > > > Roni Even > > > > > > > > >=20 From nobody Thu Jul 21 06:19:50 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E6112D533 for ; Thu, 21 Jul 2016 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDKDAiQeXsPx for ; Thu, 21 Jul 2016 06:19:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC9312D1EA for ; Thu, 21 Jul 2016 06:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5592; q=dns/txt; s=iport; t=1469107187; x=1470316787; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=efrzdgA2obW87NlfZGMznlmldFurEUF6RjGaM4GoWqE=; b=G1Se1ENAa5+yF4+i46aXF0Lcw5sOPF7E06gYDqABuHOqUItZTzwPhD2a iKERgxa1A0VElPtmWJV/1pYVj+IbtXNruKkSYlAlSDzmfcuYSFke//PLb PavdhKp+XD6vCJcedC/qtVhUHONKKyqHuLBgD1dTnSbjZWchylJaBYoJB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgCYy5BX/5xdJa1dgz9WfAasRIwcg?= =?us-ascii?q?XsihXgCHIEROBQBAQEBAQEBZSeEXAEBBR0GEVEEAgEIDgMBAwEBAwIjAwICAh8?= =?us-ascii?q?RFAECBggCBAESCBOHewMXDq8eiVgNhAkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXB?= =?us-ascii?q?YEBhSmETYEigSGBWQcBAYMcgloFmHI0AYkQgzaCHYFzjU5vhXGBRod6AR42ggs?= =?us-ascii?q?cgUxuAYYJDxcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="128378940" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 13:19:46 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6LDJk4i026641 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Jul 2016 13:19:46 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 21 Jul 2016 08:19:45 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1210.000; Thu, 21 Jul 2016 08:19:45 -0500 From: "David Benham (dbenham)" To: Roni Even , "perc@ietf.org" Thread-Topic: [Perc] Request for decision review Thread-Index: AQHR4pkQTIdp+V/CSEONQm5zFzjYpqAiyx7AgABe6ID//61OgIAAWkMA//+tRLA= Date: Thu, 21 Jul 2016 13:19:45 +0000 Message-ID: <1d739f5752614680aff37477c8a6f5b7@XCH-RCD-020.cisco.com> References: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> <010801d1e34d$b3bab640$1b3022c0$@gmail.com> <011a01d1e351$7cca1690$765e43b0$@gmail.com> In-Reply-To: <011a01d1e351$7cca1690$765e43b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.86.44] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:19:49 -0000 U291bmRzIGxpa2Uga25vd2luZyBpZiBhbiBTRk0gaXMgYSBTU1JDIHRlcm1pbmF0aW5nIG9yIG5v dCBpcyBhbHJlYWR5IGFuIGlzc3VlIC4uLiBwZXJoYXBzIHNvbWV0aGluZyBpbiBzaWduYWxpbmcv UlRDUC4gICANClNlZW1zIGluY29tcGxldGUgaW50ZXJvcCBmb3IgZXhpc3RpbmcgUkZDNzY2NyBh ZG9wdGVycyBiZWZvcmUgdGhpcyBQRVJDIGRpc2N1c3Npb24gY2FtZSBhbG9uZy4NCg0KV2h5IGRp ZG4ndCBBVlQgQ29yZSBhbHJlYWR5IGFzayBmb3IgdGhpcyBmcm9tIGFub3RoZXIgV0c/ICAgDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb24u ZXZlbi50bHZAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKdWx5IDIxLCAyMDE2IDY6MTIg QU0NClRvOiBEYXZpZCBCZW5oYW0gKGRiZW5oYW0pIDxkYmVuaGFtQGNpc2NvLmNvbT47IHBlcmNA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbUGVyY10gUmVxdWVzdCBmb3IgZGVjaXNpb24gcmV2aWV3 DQpJbXBvcnRhbmNlOiBIaWdoDQoNCllvdSBkbyBub3QgbmVlZCB0byBjaGFuZ2UgUkZDNzY2NyBz aW5jZSB0byBrbm93IGlmIGl0IGlzIGEgU1NSQyB0ZXJtaW5hdGluZyBvciBub3QgaXMgbm90IGFu IFJUUCBpc3N1ZSwgaXQgbWF5IGJlIHNpZ25hbGluZyBpc3N1ZSBhbmQgdGhpcyBpcyBub3QgQVZU Y29yZSBjaGFydGVyLg0KVGhlIFBFUkMgZnJhbWV3b3JrIGRvY3VtZW50IG11c3QgaGF2ZSBjbGVh ciB0ZXh0IGFib3V0IHdoYXQgaXMgaW4gTUQuIEl0IGlzIHRvbyB2YWd1ZSBub3cgaW4gb3JkZXIg dG8gc2VlIGlmIHRoZSBzb2x1dGlvbiBhZGRyZXNzZXMgdGhlIHNwZWNpZmllZCBNRC4NClRoZSBm cmFtZXdvcmsgaXMgdGhlIG9ubHkgYXJjaGl0ZWN0dXJlIGRvY3VtZW50DQpSb25pDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGF2aWQgQmVuaGFtIChkYmVuaGFtKSBb bWFpbHRvOmRiZW5oYW1AY2lzY28uY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAyMSwgMjAx NiA0OjAxIFBNDQo+IFRvOiBSb25pIEV2ZW47IHBlcmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6 IFtQZXJjXSBSZXF1ZXN0IGZvciBkZWNpc2lvbiByZXZpZXcNCj4gDQo+IE5lZWQgdG8gc3RhcnQg YW4gUkZDNzY2N2JpcyB0byBlbGFib3JhdGUgZnVydGhlciBvbiBob3cgYW4gU0ZNIHdvcmtzIGlu DQo+IFNTUkMgbm9uLXRlcm1pbmF0aW9uL25vLXJld3JpdGUgKGNvbW1vbiBzcGFjZSkgY2FzZT8N Cj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSb25pIEV2ZW4g W21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAy MSwgMjAxNiA1OjQ1IEFNDQo+IFRvOiBEYXZpZCBCZW5oYW0gKGRiZW5oYW0pIDxkYmVuaGFtQGNp c2NvLmNvbT47IHBlcmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtQZXJjXSBSZXF1ZXN0IGZv ciBkZWNpc2lvbiByZXZpZXcNCj4gSW1wb3J0YW5jZTogSGlnaA0KPiANCj4gSGksDQo+IFdoYXQg Y29uZnVzZXMgbWUgaXMgdGhhdCB0aGUgZnJhbWV3b3JrIGRvY3VtZW50IHJlZmVyZW5jZSBSRkM3 NjY3IGJ1dA0KPiBkb2VzIG5vdCBzYXkgd2hhdCBpcyB0aGUgUEVXUkMgdG9wb2xvZ3kgYXQgYWxs LiBTbyB3ZSBhcmUgdHJ5aW5nIHRvIGRlZmluZSBhDQo+IHNvbHV0aW9uIHRvIGFuIHVuZGVmaW5l ZCB0b3BvbG9neS4gVGhpcyBzaG91bGQgYmUgYSBQRVJDIGlzc3VlLCBub3QgQVZUY29yZSwNCj4g dGhpcyBpcyB3aHkgUEVSQyB3YXMgZm9ybWVkDQo+IA0KPiBBcyBmb3IgU0ZNIGl0IGNhbiBoYXZl IG9uZSBSVFAgc2Vzc2lvbiB0byBhbGwgcGFydGljaXBhbnRzIGJ1dCBJIGFzc3VtZSBpdCB3aWxs DQo+IHN0aWxsIG5lZWQgc29tZSB3YXkgdG8gaW5kaWNhdGUgdGhlIG1hcHBpbmcgb2YgaW5jb21p bmcgc3RyZWFtcyB0byBvdXRnb2luZw0KPiBzdHJlYW0gZnJvbSB0aGUgU0ZNIG90aGVyd2lzZSB0 aGUgcmVjZWl2ZXIgZG9lcyBub3Qga25vdyBpZiB0aGVyZSBpcyBvbmUgb3INCj4gbXVsdGlwbGUg UlRQIHNlc3Npb25zLiBUaGlzIGlzIHdoYXQgRW1pbCBzdWdnZXN0ZWQgZm9yIGlkZW50aWZ5aW5n IGlmIFNTUkMgYXJlDQo+IG11dGFibGUgb3Igbm90Lg0KPiANCj4gUm9uaQ0KPiANCj4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERhdmlkIEJlbmhhbSAoZGJlbmhhbSkg W21haWx0bzpkYmVuaGFtQGNpc2NvLmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAyMSwg MjAxNiAzOjM3IFBNDQo+ID4gVG86IHJvbi5ldmVuLnRsdkBnbWFpbC5jb207IHBlcmNAaWV0Zi5v cmcNCj4gPiBTdWJqZWN0OiBSRTogW1BlcmNdIFJlcXVlc3QgZm9yIGRlY2lzaW9uIHJldmlldw0K PiA+DQo+ID4gRGVzcGl0ZSBnaXZpbmcgYW4gYWRkaXRpb25hbCBhbnN3ZXIgYmVsb3csIEkgYW0g YWxzbyBjYWxsaW5nIGZvciArMXMNCj4gPiBmcm9tIHRoaXMgbGlzdCBpbiBmYXZvciBvZiAuLi4N Cj4gPiAgICBhKSBub3QgZG8gdGhpcyBtYXBwaW5nIHRvIDc2NjcgdG9wb2xvZ2llcyBub3cgd2hp bGUgc3RpbGwgc28gbXVjaA0KPiA+IG1vcmUgUEVSQyBkZXNpZ24gd29yayB0byBkbw0KPiA+ICAg ICAgICAgICBhbmQNCj4gPiAgICBiKSBkbyB0aGlzIG1hcHBpbmcgdG8gNzY2NyB0b3BvbG9naWVz IG9uIHRoZSBBVlQtQ29yZSBtYWlsIGxpc3QNCj4gPiBhbmQvb3INCj4gPiAoam9pbnQpIGFnZW5k YSB0aW1lIGluIGZ1dHVyZSBpZiBuZWVkZWQNCj4gPg0KPiA+DQo+ID4NCj4gPiBTZWxlY3RpdmUg Rm9yd2FyZGluZyBNaWRkbGVib3ggKHNlY3QgMy43IG9mIFJGQzc2NjcpIGFjY29tbW9kYXRlcw0K PiA+IGVpdGhlciBTU1JDIHRlcm1pbmF0aW9uL3Jld3JpdGVzIChzZXBhcmF0ZSBzcGFjZSkgb3Ig U1NSQw0KPiA+IG5vbi10ZXJtaW5hdGlvbi9uby0gcmV3cml0ZSAoY29tbW9uIHNwYWNlKS4NCj4g Pg0KPiA+IEkgY2hlY2tlZCB3aXRoIE1hZ251cyBvdmVyIGEgeWVhciBhZ28gdGhhdCBpbmRlZWQg U1NSQw0KPiA+IHRlcm1pbmF0aW9uL3Jld3JpdGVzIHdhcyBub3QgdGhlIG9ubHkgbW9kZSBmb3Ig My43IFNGTSdzLg0KPiA+IEhlIGRpZCBzb21lIHJld29yZGluZyB0byBzZWN0IDMuNyBtYWtlIHRo YXQgKG1pbGRseSkgY2xlYXJlciBhZnRlciBvdXINCj4gPiBleGNoYW5nZS4NCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2F2dC9jdXJyZW50L21zZzE2Njk5Lmh0bWwN Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2F2dC9jdXJyZW50L21z ZzE2NzAwLmh0bWwNCj4gPg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiBUaGUgZnJhbWV3b3JrIGRvY3VtZW50IGRlZmluZXMgdGhlIE1EIGFzICJNZWRpYSBEaXN0cmli dXRvciAoTUQpOiBBbg0KPiA+IFJUUCBtaWRkbGVib3ggdGhhdCBpcyBub3QgYWxsb3dlZCB0byB0 bw0KPiA+ICAgIGhhdmUgYWNjZXNzIHRvIEUyRSBlbmNyeXB0aW9uIGtleXMuICBJdCBtYXkgb3Bl cmF0ZSBhY2NvcmRpbmcgdG8gYW55DQo+ID4gICAgb2YgdGhlIFJUUCB0b3BvbG9naWVzIFtJLUQu aWV0Zi1hdnRjb3JlLXJ0cC10b3BvbG9naWVzLXVwZGF0ZV0gcGVyDQo+ID4gICAgdGhlIGNvbnN0 cmFpbnRzIGRlZmluZWQgYnkgdGhlIFBFUkMgc3lzdGVtLCB3aGljaCBpbmNsdWRlcywgYnV0IG5v dA0KPiA+ICAgIGxpbWl0ZWQgdG8sIGhhdmluZyBubyBhY2Nlc3MgdG8gUlRQIG1lZGlhIHVuZW5j cnlwdGVkIGFuZCBoYXZpbmcNCj4gPiAgICBsaW1pdHMgb24gd2hhdCBSVFAgaGVhZGVyIGZpZWxk IGl0IGNhbiBhbHRlci4iDQo+ID4NCj4gPiBJZiB3ZSBkbyBub3QgYWxsb3cgY2hhbmdpbmcgU1NS QyBieSB0aGUgbWlkZGxlIGJveCB0aGVuIGFzIGZhciBhcyBJDQo+ID4gY2FuIHNlZSB0aGlzIG1l YW5zIHRoYXQgb25seSBUb3BvLVB0UC1UcmFuc2xhdG9yIGZyb20gUkZDNzY2NyBpcw0KPiA+IGFw cGxpY2FibGUgZm9yIFBFUkMgYW5kIG5vdCBhbnkgb3RoZXIgdG9wb2xvZ3kNCj4gPg0KPiA+IFJv bmkgRXZlbg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+IA0KDQoNCg== From nobody Thu Jul 21 06:46:40 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C705712D159 for ; Thu, 21 Jul 2016 06:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtFUJL-V07dr for ; Thu, 21 Jul 2016 06:46:35 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 47B9512D50B for ; Thu, 21 Jul 2016 06:46:34 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id g62so62398150lfe.3 for ; Thu, 21 Jul 2016 06:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=5lqcxgX4Z1/Wm0EPhIDab/H4RbZhn64zMn/62DolO9w=; b=g7BlfwU3PlYr9n8WCUBiigqPaxIMLb/vddFRzIDBTrr5v6mhwu6JJss3ZpFC8dPaKf +mBYliduznjChqvp8cf38SZ0reaHeurlDhx4QaYGkndbZPz9pMEqGxGv40VdRGlUmYco YcUxGPXxKGIAJ0iCFY+fxb3ecgSQRA+54VD1fVtfgtMXgdl5G8ZedEIh2knIfqE/ccUe BOqv1Ll03v6W+FxmTh0FhuHP0KFwNE38ZyrKs8iIZBo6S+poGMgcnPTbw0X0KHW8bRUJ TV/YROBe2wk0PS6b9jPWzE+EQB1ovVJHuaQCTA7ZAfTv6nBAtOVxrbOE27cFb5YUKUkN 1PVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=5lqcxgX4Z1/Wm0EPhIDab/H4RbZhn64zMn/62DolO9w=; b=I0Xe8tKYNv7YigdtQwW4veAisXkFQkPOGQ+uzLUbZpgNRN1cO8IVjIK89jrACnYsf1 YF5wVAcR5m8+ZJqUM4pnBP7upK6R7C6ggVh4EsPyZlhE/VaUlgx0YUhz+X6GvMoboyO0 5bnW5K1nFRtYJzMeJ/1BHPPmWbZziJ1Lt7A1PbnppeXl/dtpxhhiVurnX19iXoHxfURS C88z+cp6I/nFfoK/JC7LaJFz6BIKRYN8Jh5ZjYfXOjySuAPQm0XiUHgyYU4exPsn3hN5 RQFgJS3sxbdueaY69374ZVyM7mHhu8ij9nOUomeSbyfFZwE1kmOSQ0yi5PVQqb8aAWL+ Q+bA== X-Gm-Message-State: ALyK8tKn74bLMk+3Ljz/nBygSYv5S9LStRxKagnbSc0TzFANAg978mTSP0Flap9VIXjqOw== X-Received: by 10.25.196.19 with SMTP id u19mr24985662lff.77.1469108792432; Thu, 21 Jul 2016 06:46:32 -0700 (PDT) Received: from RoniPC (dhcp-a330.meeting.ietf.org. [31.133.163.48]) by smtp.gmail.com with ESMTPSA id s87sm1831525lfg.46.2016.07.21.06.46.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jul 2016 06:46:31 -0700 (PDT) From: "Roni Even" To: "'David Benham \(dbenham\)'" , References: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> <010801d1e34d$b3bab640$1b3022c0$@gmail.com> <011a01d1e351$7cca1690$765e43b0$@gmail.com> <1d739f5752614680aff37477c8a6f5b7@XCH-RCD-020.cisco.com> In-Reply-To: <1d739f5752614680aff37477c8a6f5b7@XCH-RCD-020.cisco.com> Date: Thu, 21 Jul 2016 16:46:29 +0300 Message-ID: <015901d1e356$48f0faa0$dad2efe0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNScl5U2jL3LzFW4U4u2OfzoV0JowKMCgTMAlnbDmgCTM3egALxaCNRAm0AoT8By/j55gFXKYM8AhGWwzyck5brsA== Content-Language: he Archived-At: Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:46:39 -0000 Again, RFC7667 describes RTP level entities not how you signal = functionality of the application on top of it. Using single or multiple = RTP sessions in an implementation if both can be used in an RTP topology = is not AVT topic. As for PERC, I am not arguing for changing or not changing SSRC in the = MD. I am arguing that the PERC topology need to be clear. Having a solution and then having the architecture is one way to design = solutions (not my preferred mode) but it MUST also include the = architecture and the framework definition of MD must reflect it. The text for MD should be changed if SSRC cannot be overwritten to say = that only the TOPO-PtP-translator and single session SFM are supported = when signaling PERC support. Roni > -----Original Message----- > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > Sent: Thursday, July 21, 2016 4:20 PM > To: Roni Even; perc@ietf.org > Subject: RE: [Perc] Request for decision review >=20 > Sounds like knowing if an SFM is a SSRC terminating or not is already = an issue > ... perhaps something in signaling/RTCP. > Seems incomplete interop for existing RFC7667 adopters before this = PERC > discussion came along. >=20 > Why didn't AVT Core already ask for this from another WG? >=20 > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Thursday, July 21, 2016 6:12 AM > To: David Benham (dbenham) ; perc@ietf.org > Subject: RE: [Perc] Request for decision review > Importance: High >=20 > You do not need to change RFC7667 since to know if it is a SSRC = terminating > or not is not an RTP issue, it may be signaling issue and this is not = AVTcore > charter. > The PERC framework document must have clear text about what is in MD. = It > is too vague now in order to see if the solution addresses the = specified MD. > The framework is the only architecture document Roni >=20 > > -----Original Message----- > > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > > Sent: Thursday, July 21, 2016 4:01 PM > > To: Roni Even; perc@ietf.org > > Subject: RE: [Perc] Request for decision review > > > > Need to start an RFC7667bis to elaborate further on how an SFM works > > in SSRC non-termination/no-rewrite (common space) case? > > > > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Thursday, July 21, 2016 5:45 AM > > To: David Benham (dbenham) ; perc@ietf.org > > Subject: RE: [Perc] Request for decision review > > Importance: High > > > > Hi, > > What confuses me is that the framework document reference RFC7667 = but > > does not say what is the PEWRC topology at all. So we are trying to > > define a solution to an undefined topology. This should be a PERC > > issue, not AVTcore, this is why PERC was formed > > > > As for SFM it can have one RTP session to all participants but I > > assume it will still need some way to indicate the mapping of = incoming > > streams to outgoing stream from the SFM otherwise the receiver does > > not know if there is one or multiple RTP sessions. This is what Emil > > suggested for identifying if SSRC are mutable or not. > > > > Roni > > > > > -----Original Message----- > > > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > > > Sent: Thursday, July 21, 2016 3:37 PM > > > To: ron.even.tlv@gmail.com; perc@ietf.org > > > Subject: RE: [Perc] Request for decision review > > > > > > Despite giving an additional answer below, I am also calling for = +1s > > > from this list in favor of ... > > > a) not do this mapping to 7667 topologies now while still so = much > > > more PERC design work to do > > > and > > > b) do this mapping to 7667 topologies on the AVT-Core mail list > > > and/or > > > (joint) agenda time in future if needed > > > > > > > > > > > > Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommodates > > > either SSRC termination/rewrites (separate space) or SSRC > > > non-termination/no- rewrite (common space). > > > > > > I checked with Magnus over a year ago that indeed SSRC > > > termination/rewrites was not the only mode for 3.7 SFM's. > > > He did some rewording to sect 3.7 make that (mildly) clearer after > > > our exchange. > > > https://www.ietf.org/mail-archive/web/avt/current/msg16699.html > > > https://www.ietf.org/mail-archive/web/avt/current/msg16700.html > > > > > > > > > -----Original Message----- > > > The framework document defines the MD as "Media Distributor (MD): = An > > > RTP middlebox that is not allowed to to > > > have access to E2E encryption keys. It may operate according = to any > > > of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] = per > > > the constraints defined by the PERC system, which includes, but = not > > > limited to, having no access to RTP media unencrypted and = having > > > limits on what RTP header field it can alter." > > > > > > If we do not allow changing SSRC by the middle box then as far as = I > > > can see this means that only Topo-PtP-Translator from RFC7667 is > > > applicable for PERC and not any other topology > > > > > > Roni Even > > > > > > > > > > > > > > >=20 From nobody Fri Jul 22 00:07:04 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3765512D918 for ; Fri, 22 Jul 2016 00:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97T6BeivQNqa for ; Fri, 22 Jul 2016 00:07:00 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 9F19912D755 for ; Fri, 22 Jul 2016 00:07:00 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u134so95332261ywg.3 for ; Fri, 22 Jul 2016 00:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KEV6u+0uIjTsG6qDThYSSULKn2N4HEwqgP4cyksq6XE=; b=VosF3cbRX0WR7Ba6ZV+EEEiCOZoZ8Jbend1/4zzET+TB48nQ8KhzdtmhyZbE3rAPxz p6MhpjlHDXRJcXSgBgj2dg/Pq1iIlHYNuPgKNWzJ86zQo2BHCY7RZEgNl7BKsCmqk5Tk 8aNHhN+h8sHeE6o7mPwboNDkfHuQ7tSrqhFmiqbE7oC3FzzaA+WpndZQa2P44lHV1LZH hR8TvzerUfM3dVzoTd6VJxE1zmHKEnPXf1NZhD9GciVMRt9lv7Hqk/fe23yDf1xU+HxF PPP1xKbGB6N4LPRpr0AVN21w4HG+WVEYYYeN3pVarxAu9TESmloGL8A2Kb8TxXn7Imti FSEg== 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; bh=KEV6u+0uIjTsG6qDThYSSULKn2N4HEwqgP4cyksq6XE=; b=Tg1qRqrja2jgS0pB1gjdsqiqGtL3nohW00Wm6KqnfFVK1itMjG1HWODDNoMhZICtFr oWWYNwNetYYyNIjaJGYvH206czqg19IZPb/8N1ed8pC7pOk3WGjlosSgJN3qVH4tuJnx 255qxx5oGPwu43pfIYms9aegh9dNKb7xot3SjhYuMQS6ZDcS1o7EzbanZ8l74RKyUK+L iS1LIuTnvxsT+X3f7QCn4qt+0Iz/birb3MMJcQt9EcQ9urGbMNL+Obyg0H+Pwy09/pD2 4X3KMTK0XdYYLkCBOzfuQARI1nOZpbDrgRPUNygkSK5B98cBASNLUMA3Qqv5RJmX03mH AQYQ== X-Gm-Message-State: AEkoousMeCR8Tyd0GVz654AeJL6B3zYQgoqUW6kTuEtvvJyvUR6O7MW8NfD6l9J3tPmb+MLLuhSC9N48jpJHog== X-Received: by 10.129.39.200 with SMTP id n191mr1955913ywn.16.1469171219798; Fri, 22 Jul 2016 00:06:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Fri, 22 Jul 2016 00:06:20 -0700 (PDT) In-Reply-To: <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> From: Eric Rescorla Date: Fri, 22 Jul 2016 09:06:20 +0200 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a1141826aabce6e05383414a0 Archived-At: Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:07:03 -0000 --001a1141826aabce6e05383414a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rather than inventing something new, I'd like to suggest that we just define a web services interface from the KMF to the MDD. As soon as you're not on the same path as the DTLS messages, then you lose the benefits of the implicit binding between the DTLS messages and the control messages, and then this just becomes a straight-up question of what's the easiest way to build a control channel between machine A and machine B. And I think at this point we have a fair amount of experience that the natural thing to do here is HTTPS (cf. ACME) -Ekr On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings wrote: > > So agree that snag kills the current plan. > > Running a webrtc data channel looks like the most hideously complicated > thing we could do. How about we just use a TLS connection made from the > KMF to the MDD? I don=E2=80=99t think the head of line issue or the putti= ng the MDD > behind a NAT are practical enough use cases to justify the complexity. > > > > > > On Jul 16, 2016, at 4:39 AM, Adam Roach wrote: > > > > Mozilla has started looking into implementation of a PERC KMF, and have > run into a bit of a snag with the tunnel protocol. Right now, the current > tunnel i-d plans on using the reliability of the underlying TLS handshake > (client hello/server hello/finished/finished) to ensure that required > information is exchanged between the KMF and the MDD. > > > > Unfortunately, this won't work. The *reason* it won't work is that TLS > 1.3 (which we'll certainly want to support) performs a three-way handshak= e > instead of a four-way handshake. So the message that we planned to use to > send the HBH key from the KMF to the MDD simply doesn't exist. > > > > This means that we'll need some additional reliability mechanism. > > > > We can roll our own -- but (as SIP taught us) that's not an awesome > thing to do -- or we can re-use something that already works. As we worke= d > through how best to do this, something relatively simple presented itself= . > If we use a stack similar to what we're using for WebRTC > (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: > > > > * ICE gives us the keepalives we need to maintain NAT and firewall > > pinholes > > * ICE provides a means for finding which of UDP or TCP will work > > through the firewall > > * SCTP provides reliability for exchanging messages pertaining to > > supported ciphersuites and hop-by-hop keys > > * SCTP provides multiple channels that can be used to carry multiple > > DTLS associations > > > > Basically, this means we move away from a custom binary protocol for th= e > tunnel and re-use existing designs. It's easier to specify, and (at least= , > for the architectures we've been considering) much easier to implement. > It's worth noting that the MDD would only need to support ice-lite, > assuming it's deployed on a publicly-routable address. > > > > > > +------+------+------+------+ > > | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here > > +------+------+------+------+ > > | SCTP | <- Provides control channel reliability, > channel IDs > > +---------------------------+ > > | DTLS | <- DTLS here is the KMF <-> MDD connecti= on > > +---------------------------+ > > | ICE | <- Provides keepalives, firewall travers= al > > +---------------------------+ > > | UDP or TCP | > > +---------------------------+ > > > > > > I know it's kind of a step back from the tunnel protocol we've been > designing at so far, but it looks a lot cleaner, and allows for re-use of > already debugged components that will largely exist in implementations (o= r > that can be trivially sourced from commercially-friendly open source > projects). Overall -- and in addition to the other advantages -- I think > this will be easier to specify and easier to implement. > > > > /a > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a1141826aabce6e05383414a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Rather than inventing something new, I'd like to sugge= st that we just define a web services interface from the KMF to the MDD. As= soon as you're not on the same path as the DTLS messages, then you los= e the benefits of the implicit binding between the DTLS messages and the co= ntrol messages, and then this just becomes a straight-up question of what&#= 39;s the easiest way to build a control channel between machine A and =C2= =A0machine B. And I think at this point we have a fair amount of experience= that the natural thing to do here is HTTPS (cf. ACME)

-= Ekr


On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings <fluffy@iii.ca> wrote:

So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated thi= ng we could do.=C2=A0 How about we just use a TLS connection made from the = KMF to the MDD? I don=E2=80=99t think the head of line issue or the putting= the MDD behind a NAT are practical enough use cases to justify the complex= ity.




> On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com> wrote:
>
> Mozilla has started looking into implementation of a PERC KMF, and hav= e run into a bit of a snag with the tunnel protocol. Right now, the current= tunnel i-d plans on using the reliability of the underlying TLS handshake = (client hello/server hello/finished/finished) to ensure that required infor= mation is exchanged between the KMF and the MDD.
>
> Unfortunately, this won't work. The *reason* it won't work is = that TLS 1.3 (which we'll certainly want to support) performs a three-w= ay handshake instead of a four-way handshake. So the message that we planne= d to use to send the HBH key from the KMF to the MDD simply doesn't exi= st.
>
> This means that we'll need some additional reliability mechanism.<= br> >
> We can roll our own -- but (as SIP taught us) that's not an awesom= e thing to do -- or we can re-use something that already works. As we worke= d through how best to do this, something relatively simple presented itself= . If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/I= CE/UDP), we can kill several birds with one stone:
>
> * ICE gives us the keepalives we need to maintain NAT and firewall
>=C2=A0 =C2=A0pinholes
> * ICE provides a means for finding which of UDP or TCP will work
>=C2=A0 =C2=A0through the firewall
> * SCTP provides reliability for exchanging messages pertaining to
>=C2=A0 =C2=A0supported ciphersuites and hop-by-hop keys
> * SCTP provides multiple channels that can be used to carry multiple >=C2=A0 =C2=A0DTLS associations
>
> Basically, this means we move away from a custom binary protocol for t= he tunnel and re-use existing designs. It's easier to specify, and (at = least, for the architectures we've been considering) much easier to imp= lement. It's worth noting that the MDD would only need to support ice-l= ite, assuming it's deployed on a publicly-routable address.
>
>
> +------+------+------+------+
> | Ctrl | DTLS | DTLS | DTLS |=C2=A0 <- DTLS for DTLS-SRTP terminate= s here
> +------+------+------+------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SCTP=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 <- Provides control channel reliability, chann= el IDs
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DTLS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 <- DTLS here is the KMF <-> MDD connecti= on
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 <- Provides keepalives, firewall travers= al
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP or TCP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
> +---------------------------+
>
>
> I know it's kind of a step back from the tunnel protocol we've= been designing at so far, but it looks a lot cleaner, and allows for re-us= e of already debugged components that will largely exist in implementations= (or that can be trivially sourced from commercially-friendly open source p= rojects). Overall -- and in addition to the other advantages -- I think thi= s will be easier to specify and easier to implement.
>
> /a
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc

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

--001a1141826aabce6e05383414a0-- From nobody Fri Jul 22 00:19:18 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A0B12D678 for ; Fri, 22 Jul 2016 00:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rlTlRM_dgkb6 for ; Fri, 22 Jul 2016 00:19:14 -0700 (PDT) Received: from smtp117.iad3a.emailsrvr.com (smtp117.iad3a.emailsrvr.com [173.203.187.117]) (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 EF7FB12D6B8 for ; Fri, 22 Jul 2016 00:19:13 -0700 (PDT) Received: from smtp7.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0FBDA4017F; Fri, 22 Jul 2016 03:19:13 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5AC8B40108; Fri, 22 Jul 2016 03:19:12 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from surfer-172-29-42-53-hotspot.internet-for-guests.com ([UNAVAILABLE]. [62.214.2.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Fri, 22 Jul 2016 03:19:13 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_198BBE73-A4C6-4AD7-B779-18F20C2AD5E0" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Fri, 22 Jul 2016 09:19:12 +0200 Message-Id: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 07:19:16 -0000 --Apple-Mail=_198BBE73-A4C6-4AD7-B779-18F20C2AD5E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 how would you imaging the message that are initiated from Media = Distributor to the Key Distributor gong ? Websockets ? > On Jul 22, 2016, at 9:06 AM, Eric Rescorla wrote: >=20 > Rather than inventing something new, I'd like to suggest that we just = define a web services interface from the KMF to the MDD. As soon as = you're not on the same path as the DTLS messages, then you lose the = benefits of the implicit binding between the DTLS messages and the = control messages, and then this just becomes a straight-up question of = what's the easiest way to build a control channel between machine A and = machine B. And I think at this point we have a fair amount of experience = that the natural thing to do here is HTTPS (cf. ACME) >=20 > -Ekr >=20 >=20 > On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings > wrote: >=20 > So agree that snag kills the current plan. >=20 > Running a webrtc data channel looks like the most hideously = complicated thing we could do. How about we just use a TLS connection = made from the KMF to the MDD? I don=E2=80=99t think the head of line = issue or the putting the MDD behind a NAT are practical enough use cases = to justify the complexity. >=20 >=20 >=20 >=20 > > On Jul 16, 2016, at 4:39 AM, Adam Roach > wrote: > > > > Mozilla has started looking into implementation of a PERC KMF, and = have run into a bit of a snag with the tunnel protocol. Right now, the = current tunnel i-d plans on using the reliability of the underlying TLS = handshake (client hello/server hello/finished/finished) to ensure that = required information is exchanged between the KMF and the MDD. > > > > Unfortunately, this won't work. The *reason* it won't work is that = TLS 1.3 (which we'll certainly want to support) performs a three-way = handshake instead of a four-way handshake. So the message that we = planned to use to send the HBH key from the KMF to the MDD simply = doesn't exist. > > > > This means that we'll need some additional reliability mechanism. > > > > We can roll our own -- but (as SIP taught us) that's not an awesome = thing to do -- or we can re-use something that already works. As we = worked through how best to do this, something relatively simple = presented itself. If we use a stack similar to what we're using for = WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: > > > > * ICE gives us the keepalives we need to maintain NAT and firewall > > pinholes > > * ICE provides a means for finding which of UDP or TCP will work > > through the firewall > > * SCTP provides reliability for exchanging messages pertaining to > > supported ciphersuites and hop-by-hop keys > > * SCTP provides multiple channels that can be used to carry multiple > > DTLS associations > > > > Basically, this means we move away from a custom binary protocol for = the tunnel and re-use existing designs. It's easier to specify, and (at = least, for the architectures we've been considering) much easier to = implement. It's worth noting that the MDD would only need to support = ice-lite, assuming it's deployed on a publicly-routable address. > > > > > > +------+------+------+------+ > > | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here > > +------+------+------+------+ > > | SCTP | <- Provides control channel = reliability, channel IDs > > +---------------------------+ > > | DTLS | <- DTLS here is the KMF <-> MDD = connection > > +---------------------------+ > > | ICE | <- Provides keepalives, firewall = traversal > > +---------------------------+ > > | UDP or TCP | > > +---------------------------+ > > > > > > I know it's kind of a step back from the tunnel protocol we've been = designing at so far, but it looks a lot cleaner, and allows for re-use = of already debugged components that will largely exist in = implementations (or that can be trivially sourced from = commercially-friendly open source projects). Overall -- and in addition = to the other advantages -- I think this will be easier to specify and = easier to implement. > > > > /a > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc = >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_198BBE73-A4C6-4AD7-B779-18F20C2AD5E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

how = would you imaging the message that are initiated from Media Distributor = to the Key Distributor gong ? Websockets ?



On = Jul 22, 2016, at 9:06 AM, Eric Rescorla <ekr@rtfm.com> = wrote:

Rather than inventing something new, I'd like to = suggest that we just define a web services interface from the KMF to the = MDD. As soon as you're not on the same path as the DTLS messages, then = you lose the benefits of the implicit binding between the DTLS messages = and the control messages, and then this just becomes a straight-up = question of what's the easiest way to build a control channel between = machine A and  machine B. And I think at this point we have a fair = amount of experience that the natural thing to do here is HTTPS (cf. = ACME)

-Ekr


On Mon, Jul 18, 2016 at 2:02 PM, = Cullen Jennings <fluffy@iii.ca> wrote:

So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated = thing we could do.  How about we just use a TLS connection made = from the KMF to the MDD? I don=E2=80=99t think the head of line issue or = the putting the MDD behind a NAT are practical enough use cases to = justify the complexity.




> On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com> = wrote:
>
> Mozilla has started looking into implementation of a PERC KMF, and = have run into a bit of a snag with the tunnel protocol. Right now, the = current tunnel i-d plans on using the reliability of the underlying TLS = handshake (client hello/server hello/finished/finished) to ensure that = required information is exchanged between the KMF and the MDD.
>
> Unfortunately, this won't work. The *reason* it won't work is that = TLS 1.3 (which we'll certainly want to support) performs a three-way = handshake instead of a four-way handshake. So the message that we = planned to use to send the HBH key from the KMF to the MDD simply = doesn't exist.
>
> This means that we'll need some additional reliability = mechanism.
>
> We can roll our own -- but (as SIP taught us) that's not an awesome = thing to do -- or we can re-use something that already works. As we = worked through how best to do this, something relatively simple = presented itself. If we use a stack similar to what we're using for = WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone:
>
> * ICE gives us the keepalives we need to maintain NAT and = firewall
>   pinholes
> * ICE provides a means for finding which of UDP or TCP will work
>   through the firewall
> * SCTP provides reliability for exchanging messages pertaining = to
>   supported ciphersuites and hop-by-hop keys
= > * SCTP provides multiple channels that can be used to carry = multiple
>   DTLS associations
>
> Basically, this means we move away from a custom binary protocol = for the tunnel and re-use existing designs. It's easier to specify, and = (at least, for the architectures we've been considering) much easier to = implement. It's worth noting that the MDD would only need to support = ice-lite, assuming it's deployed on a publicly-routable address.
>
>
> +------+------+------+------+
> | Ctrl | DTLS | DTLS | DTLS |  <- DTLS for DTLS-SRTP = terminates here
> +------+------+------+------+
> |           SCTP      =       |  <- Provides control channel reliability, = channel IDs
> +---------------------------+
> |           DTLS      =       |  <- DTLS here is the KMF <-> MDD = connection
> +---------------------------+
> |           ICE      =        |  <- Provides keepalives, firewall = traversal
> +---------------------------+
> |        UDP or TCP        =  |
> +---------------------------+
>
>
> I know it's kind of a step back from the tunnel protocol we've been = designing at so far, but it looks a lot cleaner, and allows for re-use = of already debugged components that will largely exist in = implementations (or that can be trivially sourced from = commercially-friendly open source projects). Overall -- and in addition = to the other advantages -- I think this will be easier to specify and = easier to implement.
>
> /a
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc

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

_______________________________________________
Perc = mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

= --Apple-Mail=_198BBE73-A4C6-4AD7-B779-18F20C2AD5E0-- From nobody Fri Jul 22 01:09:09 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE5A12D642 for ; Fri, 22 Jul 2016 01:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_YNyUAIkbjV for ; Fri, 22 Jul 2016 01:09:05 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BA412D5EB for ; Fri, 22 Jul 2016 01:09:05 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u134so96372777ywg.3 for ; Fri, 22 Jul 2016 01:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bTyGtO85NPX1tE++NVZ3sQC9J11/G6JyEid+IbGKgWE=; b=RAVDbtRTmO4erCtxmzEuAdzn/rlk1suJf8489CNsWf/OHxa+h1WvAF8EGg/+YjwAqw DR0Iexho9/0VjS2PNcgINOwe7gjOnJgtoGjqZk53+H9bxuvWvrVWJAgWJ7mPNERL/jXg tZywrj1KWEKpMzNwEDgeAORq655g0PrAZm5r0XQIpH0mBok7PMstVRiKkKh/Z5VeCkTy IyGmoCqEnsWxcNAHWz9LJTC2YipRHy+FGfapUoQFkNi+/mLTdQJwCRSkjGlExmICNLle UbR2BbMZAaUQyKeuO07jQP1NayKm40w7zySSzbixzyeKciK4AfBu+Exx/YVXOxVoQOOh VfvQ== 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; bh=bTyGtO85NPX1tE++NVZ3sQC9J11/G6JyEid+IbGKgWE=; b=mZdKlWl/YLu83uqcllhCwlZc1HZLYrGY7dMMwpG5VX4WLtrZillEpyffoRPAFrfFIu QrBDDX//8tPWM5x0nfQOmmViHOAjmob888xcao5RwV0b77cwGELYpq+82lCS2tqsIsRz NNZnLhMalKgw/+ujLpFcQrRomDodsl505Cq1nqp5odfoC2rLr5JMKSny+dI73xEw7cBe gxhX/sP6mqe+Fxz/0BiIn4v2STVlTtRWku8oV5O9Y5oLUacpWzafHY5JNeBawXAm6YIY n2w+aHgpJyVMVVOiJpmoSizd53vPiuy/M2eAeg+8Dnk7Oah/4CqZ4GrmQG96DEuGb3Dp yK+g== X-Gm-Message-State: AEkooutaEzBx6idiHl0mgDDUPhXfZHZn9D+4gf8eiaxYxA6FRUoMujJNkNm+YzYNlsuDMdk3t2Nn6XW8bQ/uhQ== X-Received: by 10.37.126.1 with SMTP id z1mr1868129ybc.57.1469174944546; Fri, 22 Jul 2016 01:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Fri, 22 Jul 2016 01:08:25 -0700 (PDT) In-Reply-To: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> From: Eric Rescorla Date: Fri, 22 Jul 2016 10:08:25 +0200 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114e1a46aefec9053834f2c4 Archived-At: Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:09:08 -0000 --001a114e1a46aefec9053834f2c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 22, 2016 at 9:19 AM, Cullen Jennings wrote: > > how would you imaging the message that are initiated from Media > Distributor to the Key Distributor gong ? Websockets ? > I think there are two choices: 1. Have two channels, one of which is (D)TLS and one of which is HTTPS. Note that if it's DTLS you need some sort of ICE-type story on the DTLS channel. 2. Have everything over HTTPS, in which case it's WebSockets. -Ekr > > > On Jul 22, 2016, at 9:06 AM, Eric Rescorla wrote: > > Rather than inventing something new, I'd like to suggest that we just > define a web services interface from the KMF to the MDD. As soon as you'r= e > not on the same path as the DTLS messages, then you lose the benefits of > the implicit binding between the DTLS messages and the control messages, > and then this just becomes a straight-up question of what's the easiest w= ay > to build a control channel between machine A and machine B. And I think = at > this point we have a fair amount of experience that the natural thing to = do > here is HTTPS (cf. ACME) > > -Ekr > > > On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings wrote: > >> >> So agree that snag kills the current plan. >> >> Running a webrtc data channel looks like the most hideously complicated >> thing we could do. How about we just use a TLS connection made from the >> KMF to the MDD? I don=E2=80=99t think the head of line issue or the putt= ing the MDD >> behind a NAT are practical enough use cases to justify the complexity. >> >> >> >> >> > On Jul 16, 2016, at 4:39 AM, Adam Roach wrote: >> > >> > Mozilla has started looking into implementation of a PERC KMF, and hav= e >> run into a bit of a snag with the tunnel protocol. Right now, the curren= t >> tunnel i-d plans on using the reliability of the underlying TLS handshak= e >> (client hello/server hello/finished/finished) to ensure that required >> information is exchanged between the KMF and the MDD. >> > >> > Unfortunately, this won't work. The *reason* it won't work is that TLS >> 1.3 (which we'll certainly want to support) performs a three-way handsha= ke >> instead of a four-way handshake. So the message that we planned to use t= o >> send the HBH key from the KMF to the MDD simply doesn't exist. >> > >> > This means that we'll need some additional reliability mechanism. >> > >> > We can roll our own -- but (as SIP taught us) that's not an awesome >> thing to do -- or we can re-use something that already works. As we work= ed >> through how best to do this, something relatively simple presented itsel= f. >> If we use a stack similar to what we're using for WebRTC >> (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >> > >> > * ICE gives us the keepalives we need to maintain NAT and firewall >> > pinholes >> > * ICE provides a means for finding which of UDP or TCP will work >> > through the firewall >> > * SCTP provides reliability for exchanging messages pertaining to >> > supported ciphersuites and hop-by-hop keys >> > * SCTP provides multiple channels that can be used to carry multiple >> > DTLS associations >> > >> > Basically, this means we move away from a custom binary protocol for >> the tunnel and re-use existing designs. It's easier to specify, and (at >> least, for the architectures we've been considering) much easier to >> implement. It's worth noting that the MDD would only need to support >> ice-lite, assuming it's deployed on a publicly-routable address. >> > >> > >> > +------+------+------+------+ >> > | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here >> > +------+------+------+------+ >> > | SCTP | <- Provides control channel reliability= , >> channel IDs >> > +---------------------------+ >> > | DTLS | <- DTLS here is the KMF <-> MDD >> connection >> > +---------------------------+ >> > | ICE | <- Provides keepalives, firewall >> traversal >> > +---------------------------+ >> > | UDP or TCP | >> > +---------------------------+ >> > >> > >> > I know it's kind of a step back from the tunnel protocol we've been >> designing at so far, but it looks a lot cleaner, and allows for re-use o= f >> already debugged components that will largely exist in implementations (= or >> that can be trivially sourced from commercially-friendly open source >> projects). Overall -- and in addition to the other advantages -- I think >> this will be easier to specify and easier to implement. >> > >> > /a >> > >> > _______________________________________________ >> > Perc mailing list >> > Perc@ietf.org >> > https://www.ietf.org/mailman/listinfo/perc >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > > --001a114e1a46aefec9053834f2c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jul 22, 2016 at 9:19 AM, Cullen Jennings <= fluffy@iii.ca> wrote:

how would you imaging the message that are initi= ated from Media Distributor to the Key Distributor gong ? Websockets ?

I think there are two choices:

1. Have two channels, one of which is (D)TLS and one o= f which is HTTPS. Note that if it's DTLS you need some sort of ICE-type= story on the DTLS channel.
2. Have everything over HTTPS, in whi= ch case it's WebSockets.

-Ekr




On Jul 22, 2016, at 9:06 AM, Eric Rescorla <ekr@rtfm.com> wrote:

<= div>
Rather than inventing something new, I'd like to s= uggest that we just define a web services interface from the KMF to the MDD= . As soon as you're not on the same path as the DTLS messages, then you= lose the benefits of the implicit binding between the DTLS messages and th= e control messages, and then this just becomes a straight-up question of wh= at's the easiest way to build a control channel between machine A and = =C2=A0machine B. And I think at this point we have a fair amount of experie= nce that the natural thing to do here is HTTPS (cf. ACME)

-Ekr


On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings <fluffy@iii.= ca> wrote:

So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated thi= ng we could do.=C2=A0 How about we just use a TLS connection made from the = KMF to the MDD? I don=E2=80=99t think the head of line issue or the putting= the MDD behind a NAT are practical enough use cases to justify the complex= ity.




> On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com> wrote:
>
> Mozilla has started looking into implementation of a PERC KMF, and hav= e run into a bit of a snag with the tunnel protocol. Right now, the current= tunnel i-d plans on using the reliability of the underlying TLS handshake = (client hello/server hello/finished/finished) to ensure that required infor= mation is exchanged between the KMF and the MDD.
>
> Unfortunately, this won't work. The *reason* it won't work is = that TLS 1.3 (which we'll certainly want to support) performs a three-w= ay handshake instead of a four-way handshake. So the message that we planne= d to use to send the HBH key from the KMF to the MDD simply doesn't exi= st.
>
> This means that we'll need some additional reliability mechanism.<= br> >
> We can roll our own -- but (as SIP taught us) that's not an awesom= e thing to do -- or we can re-use something that already works. As we worke= d through how best to do this, something relatively simple presented itself= . If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/I= CE/UDP), we can kill several birds with one stone:
>
> * ICE gives us the keepalives we need to maintain NAT and firewall
>=C2=A0 =C2=A0pinholes
> * ICE provides a means for finding which of UDP or TCP will work
>=C2=A0 =C2=A0through the firewall
> * SCTP provides reliability for exchanging messages pertaining to
>=C2=A0 =C2=A0supported ciphersuites and hop-by-hop keys
> * SCTP provides multiple channels that can be used to carry multiple >=C2=A0 =C2=A0DTLS associations
>
> Basically, this means we move away from a custom binary protocol for t= he tunnel and re-use existing designs. It's easier to specify, and (at = least, for the architectures we've been considering) much easier to imp= lement. It's worth noting that the MDD would only need to support ice-l= ite, assuming it's deployed on a publicly-routable address.
>
>
> +------+------+------+------+
> | Ctrl | DTLS | DTLS | DTLS |=C2=A0 <- DTLS for DTLS-SRTP terminate= s here
> +------+------+------+------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SCTP=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 <- Provides control channel reliability, chann= el IDs
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DTLS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 <- DTLS here is the KMF <-> MDD connecti= on
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 <- Provides keepalives, firewall travers= al
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP or TCP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
> +---------------------------+
>
>
> I know it's kind of a step back from the tunnel protocol we've= been designing at so far, but it looks a lot cleaner, and allows for re-us= e of already debugged components that will largely exist in implementations= (or that can be trivially sourced from commercially-friendly open source p= rojects). Overall -- and in addition to the other advantages -- I think thi= s will be easier to specify and easier to implement.
>
> /a
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc

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

_______________________________________________
Perc mailing list
Perc@ietf.org
https://= www.ietf.org/mailman/listinfo/perc


--001a114e1a46aefec9053834f2c4-- From nobody Fri Jul 22 01:11:03 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7F212D5EB for ; Fri, 22 Jul 2016 01:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoraStCfx3Ii for ; Fri, 22 Jul 2016 01:10:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 5B23212D630 for ; Fri, 22 Jul 2016 01:10:48 -0700 (PDT) Received: from [IPv6:2607:fb90:81a:6875:0:1a:4647:301] ([172.56.6.34]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u6M8AgNo023989 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 04:10:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1469175047; bh=WDSFn5e3uGVF1+ZUCBRuJ2c5LWZSXiEJGHIqeR0Dwhc=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=b7o3J4gYwoL/cHriJn3moHRTMnGtT5nU/+GNmw4rCpT+wqgg0VIut9VCQ+gohbGIY Pu0nr+pkD4DOLMc897i9z3NLTh9UyApTdqpf2OONB7tuZDaAxgfKAIKvr99MTuXl9O NEly2kRoZtvtqQ7o2foMvP4m5UhInYzkRB1Hv84g= User-Agent: K-9 Mail for Android In-Reply-To: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----23LGBJJ4X214XRARALGH2TZ7A5S2X3" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Fri, 22 Jul 2016 10:10:37 +0200 To: Eric Rescorla , Cullen Jennings Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Fri, 22 Jul 2016 04:10:47 -0400 (EDT) Archived-At: Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:11:01 -0000 ------23LGBJJ4X214XRARALGH2TZ7A5S2X3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I think all proposals keep the MDD in the path. pj -------- Original Message -------- From: Eric Rescorla Sent: July 22, 2016 9:06:20 AM GMT+02:00 To: Cullen Jennings Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach Rather than inventing something new, I'd like to suggest that we just define a web services interface from the KMF to the MDD. As soon as you're not on the same path as the DTLS messages, then you lose the benefits of the implicit binding between the DTLS messages and the control messages, and then this just becomes a straight-up question of what's the easiest way to build a control channel between machine A and machine B. And I think at this point we have a fair amount of experience that the natural thing to do here is HTTPS (cf. ACME) -Ekr On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings wrote: > > So agree that snag kills the current plan. > > Running a webrtc data channel looks like the most hideously complicated > thing we could do. How about we just use a TLS connection made from the > KMF to the MDD? I don’t think the head of line issue or the putting the MDD > behind a NAT are practical enough use cases to justify the complexity. > > > > > > On Jul 16, 2016, at 4:39 AM, Adam Roach wrote: > > > > Mozilla has started looking into implementation of a PERC KMF, and have > run into a bit of a snag with the tunnel protocol. Right now, the current > tunnel i-d plans on using the reliability of the underlying TLS handshake > (client hello/server hello/finished/finished) to ensure that required > information is exchanged between the KMF and the MDD. > > > > Unfortunately, this won't work. The *reason* it won't work is that TLS > 1.3 (which we'll certainly want to support) performs a three-way handshake > instead of a four-way handshake. So the message that we planned to use to > send the HBH key from the KMF to the MDD simply doesn't exist. > > > > This means that we'll need some additional reliability mechanism. > > > > We can roll our own -- but (as SIP taught us) that's not an awesome > thing to do -- or we can re-use something that already works. As we worked > through how best to do this, something relatively simple presented itself. > If we use a stack similar to what we're using for WebRTC > (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: > > > > * ICE gives us the keepalives we need to maintain NAT and firewall > > pinholes > > * ICE provides a means for finding which of UDP or TCP will work > > through the firewall > > * SCTP provides reliability for exchanging messages pertaining to > > supported ciphersuites and hop-by-hop keys > > * SCTP provides multiple channels that can be used to carry multiple > > DTLS associations > > > > Basically, this means we move away from a custom binary protocol for the > tunnel and re-use existing designs. It's easier to specify, and (at least, > for the architectures we've been considering) much easier to implement. > It's worth noting that the MDD would only need to support ice-lite, > assuming it's deployed on a publicly-routable address. > > > > > > +------+------+------+------+ > > | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here > > +------+------+------+------+ > > | SCTP | <- Provides control channel reliability, > channel IDs > > +---------------------------+ > > | DTLS | <- DTLS here is the KMF <-> MDD connection > > +---------------------------+ > > | ICE | <- Provides keepalives, firewall traversal > > +---------------------------+ > > | UDP or TCP | > > +---------------------------+ > > > > > > I know it's kind of a step back from the tunnel protocol we've been > designing at so far, but it looks a lot cleaner, and allows for re-use of > already debugged components that will largely exist in implementations (or > that can be trivially sourced from commercially-friendly open source > projects). Overall -- and in addition to the other advantages -- I think > this will be easier to specify and easier to implement. > > > > /a > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > ------------------------------------------------------------------------ _______________________________________________ Perc mailing list Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc ------23LGBJJ4X214XRARALGH2TZ7A5S2X3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think all proposals keep the MDD in the path.

pj

From: Eric Rescorla <ekr@rtfm.com>
Sent: July 22, 2016 9:06:20 AM GMT+02:00
To: Cullen Jennings <fluffy@iii.ca>
Cc: Adam Roach <adam@nostrum.com>, "perc@ietf.org" <perc@ietf.org>
Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach

Rather than inventing something new, I'd like to suggest that we just define a web services interface from the KMF to the MDD. As soon as you're not on the same path as the DTLS messages, then you lose the benefits of the implicit binding between the DTLS messages and the control messages, and then this just becomes a straight-up question of what's the easiest way to build a control channel between machine A and  machine B. And I think at this point we have a fair amount of experience that the natural thing to do here is HTTPS (cf. ACME)

-Ekr


On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings <fluffy@iii.ca> wrote:

So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated thing we could do.  How about we just use a TLS connection made from the KMF to the MDD? I don’t think the head of line issue or the putting the MDD behind a NAT are practical enough use cases to justify the complexity.




> On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com> wrote:
>
> Mozilla has started looking into implementation of a PERC KMF, and have run into a bit of a snag with the tunnel protocol. Right now, the current tunnel i-d plans on using the reliability of the underlying TLS handshake (client hello/server hello/finished/finished) to ensure that required information is exchanged between the KMF and the MDD.
>
> Unfortunately, this won't work. The *reason* it won't work is that TLS 1.3 (which we'll certainly want to support) performs a three-way handshake instead of a four-way handshake. So the message that we planned to use to send the HBH key from the KMF to the MDD simply doesn't exist.
>
> This means that we'll need some additional reliability mechanism.
>
> We can roll our own -- but (as SIP taught us) that's not an awesome thing to do -- or we can re-use something that already works. As we worked through how best to do this, something relatively simple presented itself. If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone:
>
> * ICE gives us the keepalives we need to maintain NAT and firewall
>   pinholes
> * ICE provides a means for finding which of UDP or TCP will work
>   through the firewall
> * SCTP provides reliability for exchanging messages pertaining to
>   supported ciphersuites and hop-by-hop keys
> * SCTP provides multiple channels that can be used to carry multiple
>   DTLS associations
>
> Basically, this means we move away from a custom binary protocol for the tunnel and re-use existing designs. It's easier to specify, and (at least, for the architectures we've been considering) much easier to implement. It's worth noting that the MDD would only need to support ice-lite, assuming it's deployed on a publicly-routable address.
>
>
> +------+------+------+------+
> | Ctrl | DTLS | DTLS | DTLS |  <- DTLS for DTLS-SRTP terminates here
> +------+------+------+------+
> |           SCTP            |  <- Provides control channel reliability, channel IDs
> +---------------------------+
> |           DTLS            |  <- DTLS here is the KMF <-> MDD connection
> +---------------------------+
> |           ICE             |  <- Provides keepalives, firewall traversal
> +---------------------------+
> |        UDP or TCP         |
> +---------------------------+
>
>
> I know it's kind of a step back from the tunnel protocol we've been designing at so far, but it looks a lot cleaner, and allows for re-use of already debugged components that will largely exist in implementations (or that can be trivially sourced from commercially-friendly open source projects). Overall -- and in addition to the other advantages -- I think this will be easier to specify and easier to implement.
>
> /a
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc

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


Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
------23LGBJJ4X214XRARALGH2TZ7A5S2X3-- From nobody Fri Jul 22 01:28:06 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDCF12D672 for ; Fri, 22 Jul 2016 01:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V-03iwf3cKj for ; Fri, 22 Jul 2016 01:28:01 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 0793912D1A4 for ; Fri, 22 Jul 2016 01:28:00 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id z8so75451927ywa.1 for ; Fri, 22 Jul 2016 01:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DgrIU+NPyj5JID5Vhu2wpwAIeGUdunTRCH8wyBUQ4Jo=; b=OSP6XavfNnr9DMvv3HiWeOwxaqVDYux3hnz7T/cDrtgZozwV3rUXOgBv1dimzqRiOO hBNt2wgNxMMkeZQHD9XAqK2Fu83tZ6/1zTqo3whZYjody61IV0UFZEOFqgvz2I0xUIjx f0ytZkKbrv7bO25pipq2Tok4nMfwgQX3YH1bDHpT11XihQz+9ITMRz66pn946mbxMHtw fieZbQSTKvcBZ2q0MaYPxMiLCKOmbM70vcKoBHUsrWfeqea1zaBgV7Bbb9WUnuZiTL8I 43ZnNfS3xYEb2Le6Azp6r693lksDwDHOJiNeTiP/jbv4aSF0rJTUQ/xkSrN6tI1ZZIeI EFlw== 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; bh=DgrIU+NPyj5JID5Vhu2wpwAIeGUdunTRCH8wyBUQ4Jo=; b=bupXpZy5P2+P4qoDxlu59bDS6IBMQEb0qd7+uTW4Ops0lyFGsoZrwKIPDaoW3vJFX+ hKd/QycNtZxpWHd+t1XckfGihyNXVoTH7K97JOe2PFZ0ILSPiFUupxt3Dfei0wFPKMvz RJWeEjc/DT+yjIFie+YnHTSpqNT655hgXVB8f8j5ecOrNO4YnbSdo4AKG/O+k4p8PAWe 9w/2LBpL7e8pg8Jm5ioiPFBbHPB4PBWAleBMbqrQxkFva5GdGiQ5DFC7OpWya+hijDw5 Oj3exNygwOYbpuDqF/37CpM4pXH8p5xXvZRwCnvihnj20IDrwJjUmiqeiYrWQOJ4ra7I u+5w== X-Gm-Message-State: AEkoouungLvRubwyaUoxI5QRqT8a+3Vg5yLUCSbyB/JzG6PIoio4ORowH1avhAjp7NEmhZ+SfxFnliSoxZTzjw== X-Received: by 10.37.97.78 with SMTP id v75mr1826218ybb.146.1469176079731; Fri, 22 Jul 2016 01:27:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.152.13 with HTTP; Fri, 22 Jul 2016 01:27:20 -0700 (PDT) In-Reply-To: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> From: Eric Rescorla Date: Fri, 22 Jul 2016 10:27:20 +0200 Message-ID: To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a1142e0105883170538353660 Archived-At: Cc: Adam Roach , "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:28:05 -0000 --001a1142e0105883170538353660 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, at least one design is to have two parallel connections, one DTLS and one HTTPS -Ekr On Fri, Jul 22, 2016 at 10:10 AM, Paul E. Jones wrote: > I think all proposals keep the MDD in the path. > > pj > > ------------------------------ > *From:* Eric Rescorla > *Sent:* July 22, 2016 9:06:20 AM GMT+02:00 > *To:* Cullen Jennings > *Cc:* Adam Roach , "perc@ietf.org" > *Subject:* Re: [Perc] KMF/MDD interface: thoughts on a new approach > > Rather than inventing something new, I'd like to suggest that we just > define a web services interface from the KMF to the MDD. As soon as you'r= e > not on the same path as the DTLS messages, then you lose the benefits of > the implicit binding between the DTLS messages and the control messages, > and then this just becomes a straight-up question of what's the easiest w= ay > to build a control channel between machine A and machine B. And I think = at > this point we have a fair amount of experience that the natural thing to = do > here is HTTPS (cf. ACME) > > -Ekr > > > On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings wrote: > >> >> So agree that snag kills the current plan. >> >> Running a webrtc data channel looks like the most hideously complicated >> thing we could do. How about we just use a TLS connection made from the >> KMF to the MDD? I don=E2=80=99t think the head of line issue or the putt= ing the MDD >> behind a NAT are practical enough use cases to justify the complexity. >> >> >> >> >> > On Jul 16, 2016, at 4:39 AM, Adam Roach wrote: >> > >> > Mozilla has started looking into implementation of a PERC KMF, and hav= e >> run into a bit of a snag with the tunnel protocol. Right now, the curren= t >> tunnel i-d plans on using the reliability of the underlying TLS handshak= e >> (client hello/server hello/finished/finished) to ensure that required >> information is exchanged between the KMF and the MDD. >> > >> > Unfortunately, this won't work. The *reason* it won't work is that TLS >> 1.3 (which we'll certainly want to support) performs a three-way handsha= ke >> instead of a four-way handshake. So the message that we planned to use t= o >> send the HBH key from the KMF to the MDD simply doesn't exist. >> > >> > This means that we'll need some additional reliability mechanism. >> > >> > We can roll our own -- but (as SIP taught us) that's not an awesome >> thing to do -- or we can re-use something that already works. As we work= ed >> through how best to do this, something relatively simple presented itsel= f. >> If we use a stack similar to what we're using for WebRTC >> (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >> > >> > * ICE gives us the keepalives we need to maintain NAT and firewall >> > pinholes >> > * ICE provides a means for finding which of UDP or TCP will work >> > through the firewall >> > * SCTP provides reliability for exchanging messages pertaining to >> > supported ciphersuites and hop-by-hop keys >> > * SCTP provides multiple channels that can be used to carry multiple >> > DTLS associations >> > >> > Basically, this means we move away from a custom binary protocol for >> the tunnel and re-use existing designs. It's easier to specify, and (at >> least, for the architectures we've been considering) much easier to >> implement. It's worth noting that the MDD would only need to support >> ice-lite, assuming it's deployed on a publicly-routable address. >> > >> > >> > +------+------+------+------+ >> > | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here >> > +------+------+------+------+ >> > | SCTP | <- Provides control channel reliability= , >> channel IDs >> > +---------------------------+ >> > | DTLS | <- DTLS here is the KMF <-> MDD >> connection >> > +---------------------------+ >> > | ICE | <- Provides keepalives, firewall >> traversal >> > +---------------------------+ >> > | UDP or TCP | >> > +---------------------------+ >> > >> > >> > I know it's kind of a step back from the tunnel protocol we've been >> designing at so far, but it looks a lot cleaner, and allows for re-use o= f >> already debugged components that will largely exist in implementations (= or >> that can be trivially sourced from commercially-friendly open source >> projects). Overall -- and in addition to the other advantages -- I think >> this will be easier to specify and easier to implement. >> > >> > /a >> > >> > _______________________________________________ >> > Perc mailing list >> > Perc@ietf.org >> > https://www.ietf.org/mailman/listinfo/perc >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > > ------------------------------ > > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --001a1142e0105883170538353660 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, at least one design is to have two parallel connecti= ons, one DTLS and one HTTPS

-Ekr


On Fri, Jul 22, 2016 = at 10:10 AM, Paul E. Jones <paulej@packetizer.com> wrote= :
I think all proposals keep the MDD= in the path.

pj

From: Eric Rescorla <ekr@rtfm.com>
Sent: July 22, 2016 9:06:20 AM GMT+02:00
To: Cullen Jennings <fluffy@iii.ca>
Cc: Adam Roach <adam@nostrum.com>, "perc@ietf.org" <perc@ietf.org>
Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach

Rather than inventing something new, I'd like to sugge= st that we just define a web services interface from the KMF to the MDD. As= soon as you're not on the same path as the DTLS messages, then you los= e the benefits of the implicit binding between the DTLS messages and the co= ntrol messages, and then this just becomes a straight-up question of what&#= 39;s the easiest way to build a control channel between machine A and =C2= =A0machine B. And I think at this point we have a fair amount of experience= that the natural thing to do here is HTTPS (cf. ACME)

-= Ekr


On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings <fluffy@iii.ca> wrote:

So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated thi= ng we could do.=C2=A0 How about we just use a TLS connection made from the = KMF to the MDD? I don=E2=80=99t think the head of line issue or the putting= the MDD behind a NAT are practical enough use cases to justify the complex= ity.




> On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com> wrote:
>
> Mozilla has started looking into implementation of a PERC KMF, and hav= e run into a bit of a snag with the tunnel protocol. Right now, the current= tunnel i-d plans on using the reliability of the underlying TLS handshake = (client hello/server hello/finished/finished) to ensure that required infor= mation is exchanged between the KMF and the MDD.
>
> Unfortunately, this won't work. The *reason* it won't work is = that TLS 1.3 (which we'll certainly want to support) performs a three-w= ay handshake instead of a four-way handshake. So the message that we planne= d to use to send the HBH key from the KMF to the MDD simply doesn't exi= st.
>
> This means that we'll need some additional reliability mechanism.<= br> >
> We can roll our own -- but (as SIP taught us) that's not an awesom= e thing to do -- or we can re-use something that already works. As we worke= d through how best to do this, something relatively simple presented itself= . If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/I= CE/UDP), we can kill several birds with one stone:
>
> * ICE gives us the keepalives we need to maintain NAT and firewall
>=C2=A0 =C2=A0pinholes
> * ICE provides a means for finding which of UDP or TCP will work
>=C2=A0 =C2=A0through the firewall
> * SCTP provides reliability for exchanging messages pertaining to
>=C2=A0 =C2=A0supported ciphersuites and hop-by-hop keys
> * SCTP provides multiple channels that can be used to carry multiple >=C2=A0 =C2=A0DTLS associations
>
> Basically, this means we move away from a custom binary protocol for t= he tunnel and re-use existing designs. It's easier to specify, and (at = least, for the architectures we've been considering) much easier to imp= lement. It's worth noting that the MDD would only need to support ice-l= ite, assuming it's deployed on a publicly-routable address.
>
>
> +------+------+------+------+
> | Ctrl | DTLS | DTLS | DTLS |=C2=A0 <- DTLS for DTLS-SRTP terminate= s here
> +------+------+------+------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SCTP=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 <- Provides control channel reliability, chann= el IDs
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DTLS=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 <- DTLS here is the KMF <-> MDD connecti= on
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 <- Provides keepalives, firewall travers= al
> +---------------------------+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP or TCP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
> +---------------------------+
>
>
> I know it's kind of a step back from the tunnel protocol we've= been designing at so far, but it looks a lot cleaner, and allows for re-us= e of already debugged components that will largely exist in implementations= (or that can be trivially sourced from commercially-friendly open source p= rojects). Overall -- and in addition to the other advantages -- I think thi= s will be easier to specify and easier to implement.
>
> /a
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc

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

Perc@ietf.org
https://www.ietf.org/mailman/listinfo/pe= rc


= --001a1142e0105883170538353660-- From nobody Fri Jul 22 01:32:23 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B944412DA42 for ; Fri, 22 Jul 2016 01:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM-qIKEFAP_m for ; Fri, 22 Jul 2016 01:32:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 EB40712DA24 for ; Fri, 22 Jul 2016 01:32:18 -0700 (PDT) Received: from [IPv6:2607:fb90:81a:6875:0:1a:4647:301] ([172.56.6.34]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u6M8WCP0025362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2016 04:32:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1469176337; bh=Ks6tdCD3/4idYH52LCYS0IU+qMbyP4nAgMg5ah9pqzE=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=St0XS4JvX+7hsgAYXATkLY7b8szCe9zBY3XPyr52SuGOcJWjm1bw6fUM6sbnac2ku y510s5gRbFvOzqomJv/LpZLEPvRtU5bYvgKn8fSRDcnd44oTBwblIFUKEceWuUJe9M 0I1/nhUIVjtvC+Fo6t5rIV8x/ILhZE8IQ3x/PqKc= User-Agent: K-9 Mail for Android In-Reply-To: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YBZU3N4V284HWBN2MB05JDM8YLQ53O" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Fri, 22 Jul 2016 10:32:07 +0200 To: Eric Rescorla Message-ID: <6009B824-78B4-43C5-876F-234F64D1704D@packetizer.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Fri, 22 Jul 2016 04:32:17 -0400 (EDT) Archived-At: Cc: Adam Roach , "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 08:32:22 -0000 ------YBZU3N4V284HWBN2MB05JDM8YLQ53O Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 We've not had that proposal until today. We did discuss having a HTTPS connection long ago, but people preferred DTLS-SRTP and bundling MDD interface with that. Paul -------- Original Message -------- From: Eric Rescorla Sent: July 22, 2016 10:27:20 AM GMT+02:00 To: "Paul E. Jones" Cc: Cullen Jennings , Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach Well, at least one design is to have two parallel connections, one DTLS and one HTTPS -Ekr On Fri, Jul 22, 2016 at 10:10 AM, Paul E. Jones wrote: > I think all proposals keep the MDD in the path. > > pj > > ------------------------------ > *From:* Eric Rescorla > *Sent:* July 22, 2016 9:06:20 AM GMT+02:00 > *To:* Cullen Jennings > *Cc:* Adam Roach , "perc@ietf.org" > *Subject:* Re: [Perc] KMF/MDD interface: thoughts on a new approach > > Rather than inventing something new, I'd like to suggest that we just > define a web services interface from the KMF to the MDD. As soon as you're > not on the same path as the DTLS messages, then you lose the benefits of > the implicit binding between the DTLS messages and the control messages, > and then this just becomes a straight-up question of what's the easiest way > to build a control channel between machine A and machine B. And I think at > this point we have a fair amount of experience that the natural thing to do > here is HTTPS (cf. ACME) > > -Ekr > > > On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings wrote: > >> >> So agree that snag kills the current plan. >> >> Running a webrtc data channel looks like the most hideously complicated >> thing we could do. How about we just use a TLS connection made from the >> KMF to the MDD? I don’t think the head of line issue or the putting the MDD >> behind a NAT are practical enough use cases to justify the complexity. >> >> >> >> >> > On Jul 16, 2016, at 4:39 AM, Adam Roach wrote: >> > >> > Mozilla has started looking into implementation of a PERC KMF, and have >> run into a bit of a snag with the tunnel protocol. Right now, the current >> tunnel i-d plans on using the reliability of the underlying TLS handshake >> (client hello/server hello/finished/finished) to ensure that required >> information is exchanged between the KMF and the MDD. >> > >> > Unfortunately, this won't work. The *reason* it won't work is that TLS >> 1.3 (which we'll certainly want to support) performs a three-way handshake >> instead of a four-way handshake. So the message that we planned to use to >> send the HBH key from the KMF to the MDD simply doesn't exist. >> > >> > This means that we'll need some additional reliability mechanism. >> > >> > We can roll our own -- but (as SIP taught us) that's not an awesome >> thing to do -- or we can re-use something that already works. As we worked >> through how best to do this, something relatively simple presented itself. >> If we use a stack similar to what we're using for WebRTC >> (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >> > >> > * ICE gives us the keepalives we need to maintain NAT and firewall >> > pinholes >> > * ICE provides a means for finding which of UDP or TCP will work >> > through the firewall >> > * SCTP provides reliability for exchanging messages pertaining to >> > supported ciphersuites and hop-by-hop keys >> > * SCTP provides multiple channels that can be used to carry multiple >> > DTLS associations >> > >> > Basically, this means we move away from a custom binary protocol for >> the tunnel and re-use existing designs. It's easier to specify, and (at >> least, for the architectures we've been considering) much easier to >> implement. It's worth noting that the MDD would only need to support >> ice-lite, assuming it's deployed on a publicly-routable address. >> > >> > >> > +------+------+------+------+ >> > | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here >> > +------+------+------+------+ >> > | SCTP | <- Provides control channel reliability, >> channel IDs >> > +---------------------------+ >> > | DTLS | <- DTLS here is the KMF <-> MDD >> connection >> > +---------------------------+ >> > | ICE | <- Provides keepalives, firewall >> traversal >> > +---------------------------+ >> > | UDP or TCP | >> > +---------------------------+ >> > >> > >> > I know it's kind of a step back from the tunnel protocol we've been >> designing at so far, but it looks a lot cleaner, and allows for re-use of >> already debugged components that will largely exist in implementations (or >> that can be trivially sourced from commercially-friendly open source >> projects). Overall -- and in addition to the other advantages -- I think >> this will be easier to specify and easier to implement. >> > >> > /a >> > >> > _______________________________________________ >> > Perc mailing list >> > Perc@ietf.org >> > https://www.ietf.org/mailman/listinfo/perc >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > > ------------------------------ > > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > ------YBZU3N4V284HWBN2MB05JDM8YLQ53O Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit We've not had that proposal until today. We did discuss having a HTTPS connection long ago, but people preferred DTLS-SRTP and bundling MDD interface with that.

Paul

From: Eric Rescorla <ekr@rtfm.com>
Sent: July 22, 2016 10:27:20 AM GMT+02:00
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Cullen Jennings <fluffy@iii.ca>, Adam Roach <adam@nostrum.com>, "perc@ietf.org" <perc@ietf.org>
Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach

Well, at least one design is to have two parallel connections, one DTLS and one HTTPS

-Ekr


On Fri, Jul 22, 2016 at 10:10 AM, Paul E. Jones <paulej@packetizer.com> wrote:
I think all proposals keep the MDD in the path.

pj

From: Eric Rescorla <ekr@rtfm.com>
Sent: July 22, 2016 9:06:20 AM GMT+02:00
To: Cullen Jennings <fluffy@iii.ca>
Cc: Adam Roach <adam@nostrum.com>, "perc@ietf.org" <perc@ietf.org>
Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach

Rather than inventing something new, I'd like to suggest that we just define a web services interface from the KMF to the MDD. As soon as you're not on the same path as the DTLS messages, then you lose the benefits of the implicit binding between the DTLS messages and the control messages, and then this just becomes a straight-up question of what's the easiest way to build a control channel between machine A and  machine B. And I think at this point we have a fair amount of experience that the natural thing to do here is HTTPS (cf. ACME)

-Ekr


On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings <fluffy@iii.ca> wrote:

So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated thing we could do.  How about we just use a TLS connection made from the KMF to the MDD? I don’t think the head of line issue or the putting the MDD behind a NAT are practical enough use cases to justify the complexity.




> On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com> wrote:
>
> Mozilla has started looking into implementation of a PERC KMF, and have run into a bit of a snag with the tunnel protocol. Right now, the current tunnel i-d plans on using the reliability of the underlying TLS handshake (client hello/server hello/finished/finished) to ensure that required information is exchanged between the KMF and the MDD.
>
> Unfortunately, this won't work. The *reason* it won't work is that TLS 1.3 (which we'll certainly want to support) performs a three-way handshake instead of a four-way handshake. So the message that we planned to use to send the HBH key from the KMF to the MDD simply doesn't exist.
>
> This means that we'll need some additional reliability mechanism.
>
> We can roll our own -- but (as SIP taught us) that's not an awesome thing to do -- or we can re-use something that already works. As we worked through how best to do this, something relatively simple presented itself. If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone:
>
> * ICE gives us the keepalives we need to maintain NAT and firewall
>   pinholes
> * ICE provides a means for finding which of UDP or TCP will work
>   through the firewall
> * SCTP provides reliability for exchanging messages pertaining to
>   supported ciphersuites and hop-by-hop keys
> * SCTP provides multiple channels that can be used to carry multiple
>   DTLS associations
>
> Basically, this means we move away from a custom binary protocol for the tunnel and re-use existing designs. It's easier to specify, and (at least, for the architectures we've been considering) much easier to implement. It's worth noting that the MDD would only need to support ice-lite, assuming it's deployed on a publicly-routable address.
>
>
> +------+------+------+------+
> | Ctrl | DTLS | DTLS | DTLS |  <- DTLS for DTLS-SRTP terminates here
> +------+------+------+------+
> |           SCTP            |  <- Provides control channel reliability, channel IDs
> +---------------------------+
> |           DTLS            |  <- DTLS here is the KMF <-> MDD connection
> +---------------------------+
> |           ICE             |  <- Provides keepalives, firewall traversal
> +---------------------------+
> |        UDP or TCP         |
> +---------------------------+
>
>
> I know it's kind of a step back from the tunnel protocol we've been designing at so far, but it looks a lot cleaner, and allows for re-use of already debugged components that will largely exist in implementations (or that can be trivially sourced from commercially-friendly open source projects). Overall -- and in addition to the other advantages -- I think this will be easier to specify and easier to implement.
>
> /a
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc

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


Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

------YBZU3N4V284HWBN2MB05JDM8YLQ53O-- From nobody Fri Jul 22 02:09:45 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC94E12DAC1 for ; Fri, 22 Jul 2016 02:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi6Vvw0r_vrj for ; Fri, 22 Jul 2016 02:09:41 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3414B12DA87 for ; Fri, 22 Jul 2016 02:09:41 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id i5so57135346wmg.0 for ; Fri, 22 Jul 2016 02:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fjAB0d7U9GXZUeGhkaWnAQuhEiVINjRKnf4ArHk2IV8=; b=0BW4anvlQGnqjhxiw2R1ugi+E0TBlgntGdMRDw/mf7VrvPybimBzZD9B7L+hoT80Vs Nb2f3PX3T+mRDj6MiXBOTp/OUA95+TYI4XxV/VOlqjfmvu2F0vok4fKjqtgsBVkLMaBp y7kEkA8mIkHCmF/0uIZGUM4fe2w8tLtvCZ5Bl/93NPA7B99zwfZMFg98dLxuTpyQah9W XjVGrUm1L7BDMmS4MCmp0/h+NyXz29yxuPeZKya9wUROs79CH9N0zoM6nGGXGrWS+Yz/ WE4PSQGZUozkiMqYlwJAL2Ex8dhC72T4O+d9161tks5+g2fnxFGDIjjurJeX5//DWkAj IQAg== 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; bh=fjAB0d7U9GXZUeGhkaWnAQuhEiVINjRKnf4ArHk2IV8=; b=HMBlEAHQDxzmZajVHnJz15D4rXE2EBmNgW2E6QiUhSSeRL0z5vdMjlxJX9vcy0k5oU GB+lkvGP19SdzA62B0C2uf+/Q+utaJgOTW3xYk3xsPTyeqYjWJAywXmVufyWEM4r8hHW j12JugLltkNUl9KDYblowK/udmvVsJ8YJhgcUoTKL/TZW/TVb+PguOHofEg3Z9R1IJnY Iy9yhLAADKP6rsg1evLWjyn8YWzqcz7xgco+Z5L1SiheJoyWsvQdYb/CVtr0poRH3WZO 147+krxTaFTYhE2HM/pXN6NR6AvTtNsEjiaFOGiaaxrNqP4/efTIRkUfWNiUAxgB2k+S Yo3w== X-Gm-Message-State: AEkooutukY6ncETlv12d92W66JxiKpmGZ6BCYeQVAGPpKrzwyDvSexE9maE4XeWkahavfoxx2CbicFB2ipyXfQ== X-Received: by 10.28.18.11 with SMTP id 11mr3879966wms.11.1469178579682; Fri, 22 Jul 2016 02:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.117.67 with HTTP; Fri, 22 Jul 2016 02:09:38 -0700 (PDT) In-Reply-To: <015901d1e356$48f0faa0$dad2efe0$@gmail.com> References: <1438e12c7f864d83b5a05c8471400524@XCH-RCD-020.cisco.com> <010801d1e34d$b3bab640$1b3022c0$@gmail.com> <011a01d1e351$7cca1690$765e43b0$@gmail.com> <1d739f5752614680aff37477c8a6f5b7@XCH-RCD-020.cisco.com> <015901d1e356$48f0faa0$dad2efe0$@gmail.com> From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Fri, 22 Jul 2016 11:09:38 +0200 Message-ID: To: Roni Even Content-Type: multipart/alternative; boundary=001a114697225a8c14053835cbf4 Archived-At: Cc: "David Benham \(dbenham\)" , perc@ietf.org Subject: Re: [Perc] Request for decision review X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:09:43 -0000 --001a114697225a8c14053835cbf4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We should take into account that when a MediaStreamTrack will be associated to an RTP stream using MID RTP Header Extension instead of the SSRC, PERC should allow rewrite this header. The purpose is the same that allow rewriting SSRC nowadays. 2016-07-21 15:46 GMT+02:00 Roni Even : > Again, RFC7667 describes RTP level entities not how you signal > functionality of the application on top of it. Using single or multiple R= TP > sessions in an implementation if both can be used in an RTP topology is > not AVT topic. > > > As for PERC, I am not arguing for changing or not changing SSRC in the MD= . > I am arguing that the PERC topology need to be clear. > Having a solution and then having the architecture is one way to design > solutions (not my preferred mode) but it MUST also include the architectu= re > and the framework definition of MD must reflect it. > > The text for MD should be changed if SSRC cannot be overwritten to say > that only the TOPO-PtP-translator and single session SFM are supported wh= en > signaling PERC support. > > > > Roni > > > -----Original Message----- > > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > > Sent: Thursday, July 21, 2016 4:20 PM > > To: Roni Even; perc@ietf.org > > Subject: RE: [Perc] Request for decision review > > > > Sounds like knowing if an SFM is a SSRC terminating or not is already a= n > issue > > ... perhaps something in signaling/RTCP. > > Seems incomplete interop for existing RFC7667 adopters before this PERC > > discussion came along. > > > > Why didn't AVT Core already ask for this from another WG? > > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Thursday, July 21, 2016 6:12 AM > > To: David Benham (dbenham) ; perc@ietf.org > > Subject: RE: [Perc] Request for decision review > > Importance: High > > > > You do not need to change RFC7667 since to know if it is a SSRC > terminating > > or not is not an RTP issue, it may be signaling issue and this is not > AVTcore > > charter. > > The PERC framework document must have clear text about what is in MD. I= t > > is too vague now in order to see if the solution addresses the specifie= d > MD. > > The framework is the only architecture document Roni > > > > > -----Original Message----- > > > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > > > Sent: Thursday, July 21, 2016 4:01 PM > > > To: Roni Even; perc@ietf.org > > > Subject: RE: [Perc] Request for decision review > > > > > > Need to start an RFC7667bis to elaborate further on how an SFM works > > > in SSRC non-termination/no-rewrite (common space) case? > > > > > > > > > -----Original Message----- > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > > Sent: Thursday, July 21, 2016 5:45 AM > > > To: David Benham (dbenham) ; perc@ietf.org > > > Subject: RE: [Perc] Request for decision review > > > Importance: High > > > > > > Hi, > > > What confuses me is that the framework document reference RFC7667 but > > > does not say what is the PEWRC topology at all. So we are trying to > > > define a solution to an undefined topology. This should be a PERC > > > issue, not AVTcore, this is why PERC was formed > > > > > > As for SFM it can have one RTP session to all participants but I > > > assume it will still need some way to indicate the mapping of incomin= g > > > streams to outgoing stream from the SFM otherwise the receiver does > > > not know if there is one or multiple RTP sessions. This is what Emil > > > suggested for identifying if SSRC are mutable or not. > > > > > > Roni > > > > > > > -----Original Message----- > > > > From: David Benham (dbenham) [mailto:dbenham@cisco.com] > > > > Sent: Thursday, July 21, 2016 3:37 PM > > > > To: ron.even.tlv@gmail.com; perc@ietf.org > > > > Subject: RE: [Perc] Request for decision review > > > > > > > > Despite giving an additional answer below, I am also calling for +1= s > > > > from this list in favor of ... > > > > a) not do this mapping to 7667 topologies now while still so muc= h > > > > more PERC design work to do > > > > and > > > > b) do this mapping to 7667 topologies on the AVT-Core mail list > > > > and/or > > > > (joint) agenda time in future if needed > > > > > > > > > > > > > > > > Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommodates > > > > either SSRC termination/rewrites (separate space) or SSRC > > > > non-termination/no- rewrite (common space). > > > > > > > > I checked with Magnus over a year ago that indeed SSRC > > > > termination/rewrites was not the only mode for 3.7 SFM's. > > > > He did some rewording to sect 3.7 make that (mildly) clearer after > > > > our exchange. > > > > https://www.ietf.org/mail-archive/web/avt/current/msg16699.html > > > > https://www.ietf.org/mail-archive/web/avt/current/msg16700.html > > > > > > > > > > > > -----Original Message----- > > > > The framework document defines the MD as "Media Distributor (MD): A= n > > > > RTP middlebox that is not allowed to to > > > > have access to E2E encryption keys. It may operate according to > any > > > > of the RTP topologies [I-D.ietf-avtcore-rtp-topologies-update] p= er > > > > the constraints defined by the PERC system, which includes, but > not > > > > limited to, having no access to RTP media unencrypted and having > > > > limits on what RTP header field it can alter." > > > > > > > > If we do not allow changing SSRC by the middle box then as far as I > > > > can see this means that only Topo-PtP-Translator from RFC7667 is > > > > applicable for PERC and not any other topology > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a114697225a8c14053835cbf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We should take into account that when a MediaStreamTr= ack will be associated to an RTP stream using MID RTP Header Extension inst= ead of the SSRC, PERC should allow rewrite this header.
The purpos= e is the same that allow rewriting SSRC nowadays.

2016-07-21 15:46 GMT+02:00 Roni E= ven <ron.even.tlv@gmail.com>:
Again, RFC7667 describes RTP level entities not how you signal fu= nctionality of the application on top of it. Using single or multiple RTP s= essions in an implementation if both can be used in an RTP topology=C2=A0 i= s not AVT topic.


As for PERC, I am not arguing for changing or not changing SSRC in the MD. = I am arguing that the PERC topology need to be clear.
Having a solution and then having the architecture is one way to design sol= utions (not my preferred mode) but it MUST also include the architecture an= d the framework definition of MD must reflect it.

The text for MD should be changed if SSRC cannot be overwritten to say that= only the TOPO-PtP-translator and single session SFM are supported when sig= naling PERC support.



Roni

> -----Original Message-----
> From: David Benham (dbenham) [mailto:dbenham@cisco.com]
> Sent: Thursday, July 21= , 2016 4:20 PM
> To: Roni Even; perc@ietf.org
> Subject: RE: [Perc] Request for decision review
>
> Sounds like knowing if an SFM is a SSRC terminating or not is already = an issue
> ... perhaps something in signaling/RTCP.
> Seems incomplete interop for existing RFC7667 adopters before this PER= C
> discussion came along.
>
> Why didn't AVT Core already ask for this from another WG?
>
> -----Original Message-----
> From: Roni Even [mailto:ron.= even.tlv@gmail.com]
> Sent: Thursday, July 21, 2016 6:12 AM
> To: David Benham (dbenham) <db= enham@cisco.com>; perc@ietf.org=
> Subject: RE: [Perc] Request for decision review
> Importance: High
>
> You do not need to change RFC7667 since to know if it is a SSRC termin= ating
> or not is not an RTP issue, it may be signaling issue and this is not = AVTcore
> charter.
> The PERC framework document must have clear text about what is in MD. = It
> is too vague now in order to see if the solution addresses the specifi= ed MD.
> The framework is the only architecture document Roni
>
> > -----Original Message-----
> > From: David Benham (dbenham) [mailto:dbenham@cisco.com]
> > Sent: Thursday, July 21, 2016 4:01 PM
> > To: Roni Even; perc@ietf.org=
> > Subject: RE: [Perc] Request for decision review
> >
> > Need to start an RFC7667bis to elaborate further on how an SFM wo= rks
> > in SSRC non-termination/no-rewrite (common space) case?
> >
> >
> > -----Original Message-----
> > From: Roni Even [mailto:ron.even.tlv@gmail.com]
> > Sent: Thursday, July 21, 2016 5:45 AM
> > To: David Benham (dbenham) <dbenham@cisco.com>; perc@ietf.or= g
> > Subject: RE: [Perc] Request for decision review
> > Importance: High
> >
> > Hi,
> > What confuses me is that the framework document reference RFC7667= but
> > does not say what is the PEWRC topology at all. So we are trying = to
> > define a solution to an undefined topology. This should be a PERC=
> > issue, not AVTcore, this is why PERC was formed
> >
> > As for SFM it can have one RTP session to all participants but I<= br> > > assume it will still need some way to indicate the mapping of inc= oming
> > streams to outgoing stream from the SFM otherwise the receiver do= es
> > not know if there is one or multiple RTP sessions. This is what E= mil
> > suggested for identifying if SSRC are mutable or not.
> >
> > Roni
> >
> > > -----Original Message-----
> > > From: David Benham (dbenham) [mailto:dbenham@cisco.com]
> > > Sent: Thursday, July 21, 2016 3:37 PM
> > > To: ron.even.tlv@g= mail.com; perc@ietf.org
> > > Subject: RE: [Perc] Request for decision review
> > >
> > > Despite giving an additional answer below, I am also calling= for +1s
> > > from this list in favor of ...
> > >=C2=A0 =C2=A0 a) not do this mapping to 7667 topologies now w= hile still so much
> > > more PERC design work to do
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and
> > >=C2=A0 =C2=A0 b) do this mapping to 7667 topologies on the AV= T-Core mail list
> > > and/or
> > > (joint) agenda time in future if needed
> > >
> > >
> > >
> > > Selective Forwarding Middlebox (sect 3.7 of RFC7667) accommo= dates
> > > either SSRC termination/rewrites (separate space) or SSRC > > > non-termination/no- rewrite (common space).
> > >
> > > I checked with Magnus over a year ago that indeed SSRC
> > > termination/rewrites was not the only mode for 3.7 SFM's= .
> > > He did some rewording to sect 3.7 make that (mildly) clearer= after
> > > our exchange.
> > > https://www.ietf.org/m= ail-archive/web/avt/current/msg16699.html
> > > https://www.ietf.org/m= ail-archive/web/avt/current/msg16700.html
> > >
> > >
> > > -----Original Message-----
> > > The framework document defines the MD as "Media Distrib= utor (MD): An
> > > RTP middlebox that is not allowed to to
> > >=C2=A0 =C2=A0 have access to E2E encryption keys.=C2=A0 It ma= y operate according to any
> > >=C2=A0 =C2=A0 of the RTP topologies [I-D.ietf-avtcore-rtp-top= ologies-update] per
> > >=C2=A0 =C2=A0 the constraints defined by the PERC system, whi= ch includes, but not
> > >=C2=A0 =C2=A0 limited to, having no access to RTP media unenc= rypted and having
> > >=C2=A0 =C2=A0 limits on what RTP header field it can alter.&q= uot;
> > >
> > > If we do not allow changing SSRC by the middle box then as f= ar as I
> > > can see this means that only Topo-PtP-Translator from RFC766= 7 is
> > > applicable for PERC and not any other topology
> > >
> > > Roni Even
> > >
> > >
> > >
> > >
> >
>


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



--
Mi= guel Par=C3=ADs D=C3=ADaz
----------------------------------------------= --------------------------
Computer/Software engineer.
Researcher and= architect in http://w= ww.kurento.org
http://twitter.com/mparisdiaz
-------------------------------= -----------------------------------------
--001a114697225a8c14053835cbf4--