From nobody Mon May 2 13:01:49 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 C02B112D626 for ; Mon, 2 May 2016 13:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 ZkpOuT3eynbh for ; Mon, 2 May 2016 13:01:46 -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 75CF212D623 for ; Mon, 2 May 2016 13:01:46 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u42K1j5c017973 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 2 May 2016 15:01:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "perc@ietf.org" From: Adam Roach Message-ID: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> Date: Mon, 2 May 2016 15:01:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Perc] PERC and DataChannels 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, 02 May 2016 20:01:48 -0000 One of the things that came up on the call last week was what to do with DTLS data received at the KMS; this would include WebRTC datachannels. After considering this quite a bit (and discussing it with Cullen on Friday), I'm pretty certain that the answer, from a PERC perspective, is that we don't want to specify setting up any kind of data communications along that path. So, for example, an attempt to negotiate a datachannel in a webrtc context would fail. If anyone thinks this is going in the wrong direction, please speak up. /a From nobody Mon May 2 17:43:16 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 9297412D6C6 for ; Mon, 2 May 2016 17:43:14 -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 rf5bBZ6-S-3e for ; Mon, 2 May 2016 17:43:13 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 21FDA12D6C2 for ; Mon, 2 May 2016 17:43:13 -0700 (PDT) Received: by mail-ig0-x230.google.com with SMTP id bi2so101528282igb.0 for ; Mon, 02 May 2016 17:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SMz4tm3ww8wUvK5vFsJoH5udcVF0lVF8RKZQFBo2koc=; b=M16EYOhp83STFhcNlSQ/yXWnM5jq6jf3Ctd2qibnV0GDPPUTDGWTCP6oeGnj6Q34/B ASEZvr2IqrDU2y6/7CRF4Bt4LNN072QXy8Vcx/s+sFNbr22XjqdNSbljf9H3a8/6TZGc BQhVJfFPfzAmE1qCYauwyC3HI1NsnxdQ4LflKFtab3cGAp/N0vw36sJ1hAT/dldQdAkz lNCtLEbfLVspl+b3t2LxVlLG7bbZ9E+Gm7sVfvL+Az7jVJAvjPNI8XgqS/IVv6vl5Qnu OJ3ukUSP2jm+uNE1A50psmrn8PAQMV7TlId4PoPXxCCtpB380TsekD3Ark6M+kl+XX04 RslQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SMz4tm3ww8wUvK5vFsJoH5udcVF0lVF8RKZQFBo2koc=; b=FH0sH38cBVOD1YoKI6tdzOcuwaGcMWSmqnijCnpt3s2M34489dOzPlOPghKD1zbyBD nAhER9XYrig2rEw5JMvrZ4QAXcbRillWmLie299e2cQpy+YlOa3+fxR2f8+UaeRWY8Br 9vOTH3y10dmP/1ERwx/8E1a0XK7qFw+urKEyk+CbZME/5cTv7AcBBJFAL0YPKxlQSVKB 99dvNQR4caKmALnEmYIO8w705XQfh5YsPjBvNVLr4kiHyCSR0qZQPmMsx7Y9ZWoWz32T Cf+HoQP1X6k3u277IajNbKkRQsn0YqDAt85Or3SThpxNY5NM0SuerPFpQV8lizbiofsF 18HA== X-Gm-Message-State: AOPr4FVDGjV86mPDbLbYsNudIvpiByIxmlJGAApkO2aNbANqUlKa1YAaTC+uEFNeFgSIWsPSkkr8Zx5nfE+51Q== MIME-Version: 1.0 X-Received: by 10.50.33.81 with SMTP id p17mr5888583igi.58.1462236192492; Mon, 02 May 2016 17:43:12 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Mon, 2 May 2016 17:43:12 -0700 (PDT) In-Reply-To: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> References: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> Date: Tue, 3 May 2016 10:43:12 +1000 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] PERC and DataChannels 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: Tue, 03 May 2016 00:43:14 -0000 On 3 May 2016 at 06:01, Adam Roach wrote: > After considering this quite a bit (and discussing it with Cullen on > Friday), I'm pretty certain that the answer, from a PERC perspective, is > that we don't want to specify setting up any kind of data communications > along that path. So, for example, an attempt to negotiate a datachannel in a > webrtc context would fail. Would this be an outright prohibition (MUST NOT) or just a "don't do that, it doesn't make sense"? From nobody Mon May 2 22:44:24 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 E955C12B03B for ; Mon, 2 May 2016 22:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 Fs78IDeZKRP9 for ; Mon, 2 May 2016 22:44:20 -0700 (PDT) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 83E8A12B035 for ; Mon, 2 May 2016 22:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=F45vRslVZYBZUhfMOikGhK7Jcns8mtim/8oSahDyV7E=; b=FAe7a1kG4fCvXHwqwp2UAYziqC DrMRbt8SkvNW7xsuty7X5TGbTwbRrjtLxMWlBIWfAKIH6FqiIjzQHw308mNXMq0kcitmDn2K5WcoX sYlbw3FV2bXG8TiUFG5uZ0mmuCLN3WoYipHULWSEXjmHMu29cr7pLGR3qVg/cu2wq6bd3YcK/xqyq y1IFhjoYaG6FGizg2hFie1wUXHeNsEPiHi1It9H1hvFAJ2yzmUnnAELOLvSxSXf1bX7IT38A+8Dqm JUcDws98LqvCQQY9Ud+PzWQc7MAiv7tya5g5NKRNmuxm6Okb3azqxjzTPPFvL8ERa8YWvsJCnWEnC VkBQiGtg==; Received: from ppp118-209-32-134.lns20.mel4.internode.on.net ([118.209.32.134]:50466 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1axT85-003ZDW-JG for perc@ietf.org; Tue, 03 May 2016 15:44:17 +1000 To: perc@ietf.org References: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> From: Christian Groves Message-ID: Date: Tue, 3 May 2016 15:44:13 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Perc] PERC and DataChannels 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: Tue, 03 May 2016 05:44:23 -0000 How would CLUE fit into this equation? Do we say for CLUE that a 2nd DTLS association for the data channel would need to be established with the MDD? Basically if an endpoint wants to use data channels it can't multiplex it on the same DTLS association as PERC. I do agree it doesn't make sense to send CLUE to the KMF. Regards, Christian On 3/05/2016 6:01 AM, Adam Roach wrote: > One of the things that came up on the call last week was what to do > with DTLS data received at the KMS; this would include WebRTC > datachannels. > > After considering this quite a bit (and discussing it with Cullen on > Friday), I'm pretty certain that the answer, from a PERC perspective, > is that we don't want to specify setting up any kind of data > communications along that path. So, for example, an attempt to > negotiate a datachannel in a webrtc context would fail. > > If anyone thinks this is going in the wrong direction, please speak up. > > /a > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > From nobody Wed May 4 07:43: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 4774112D515 for ; Wed, 4 May 2016 07:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 YC56l56kDOxg for ; Wed, 4 May 2016 07:43:05 -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 BFBEB12D6CB for ; Wed, 4 May 2016 07:42:30 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u44EgQYP000777 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 May 2016 09:42:27 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Martin Thomson References: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> From: Adam Roach Message-ID: <5dc1fb8a-fcaa-0470-ea05-d9d7fad3b61f@nostrum.com> Date: Wed, 4 May 2016 09:42:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] PERC and DataChannels 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, 04 May 2016 14:43:07 -0000 On 5/2/16 19:43, Martin Thomson wrote: > On 3 May 2016 at 06:01, Adam Roach wrote: >> After considering this quite a bit (and discussing it with Cullen on >> Friday), I'm pretty certain that the answer, from a PERC perspective, is >> that we don't want to specify setting up any kind of data communications >> along that path. So, for example, an attempt to negotiate a datachannel in a >> webrtc context would fail. > Would this be an outright prohibition (MUST NOT) or just a "don't do > that, it doesn't make sense"? I was thinking the latter: just including guidance that this can't be expected to work in the general case, and a suggestion that a full-mesh setup for data is more sensible. /a From nobody Wed May 4 07:59:37 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 9D5DA12D1E2 for ; Wed, 4 May 2016 07:59:36 -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 yW7lh1o6Ko2h for ; Wed, 4 May 2016 07:59:34 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 49CF312B03E for ; Wed, 4 May 2016 07:59:33 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id f89so56491351ioi.0 for ; Wed, 04 May 2016 07:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=liStwaZxPY1yP2V5C0r9Cz+bOdm5BgI6050CgMIhcnc=; b=Ss8zPfttVCiQ+VQfdPGbU4fnQAoFrXRoTWU/lPfH9g9Hw2wFxFaCuIiFMvnlCOBIf+ DzPVOBreknfLeYIXxNQjZUjG+lSSsASJZedOxNEf/IU5LYz02ydEvJQihNiDfGGgDsuM 7NB+EYSlvinA8gZM30958wUJS6zx9MoULhDIoMGrjrJIKMql/LnTg0Q9ttzJpLkJqAGH 9SptYrCggDm1aZa5+VIitnTNgPMHdx5jo7vrBhsl7MrzaIigbUXhWyCbZ3WfAqJg/o0e z8HvoJT2o8VFfhbeSjyxtm7whBADlcu2/2pCtopHrGy3Tp0P+vQ21V76GdW5HXp4FEDf Xw4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=liStwaZxPY1yP2V5C0r9Cz+bOdm5BgI6050CgMIhcnc=; b=SE4zX0tDHrOJYh3iPBELEzxtRsBA9BYrk+YVhgk3fRDXz635b8T+nUVXMUIErD38Bp S9/wIynzLxfwKx/lMizJxBtPH3Mq1/2fypQxmDsvgqF4X8w0RXaCoM73MBfD754rRDXm PJa+/0dS8gGSqNacuz85SHdGUDtFp5Jbqm7gfxA5cpXg5KYdThoyYxDMcw4nc0iZkfJ/ 1FdL/7d9Tc7yzPasn5EXCNj7i1Fw0s4WtaLWsFyGj1CO0KLtRI5tnlnI6Wm9bzv4Gtna LkfJfl7425sjbi4jF1GvbSeDQ+wxxH8aoRgxeFnV3g7vI7I7T4dDgBclMctCZcdgwvUX tD6A== X-Gm-Message-State: AOPr4FVYK0kU1lObL1eGvcuBeTbLRGL4pfc/bzKpivMmPsu2HFrHnjGvlxvoTMm3RaH89osS2DsL01p2xEC+ww== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr11752154ioe.190.1462373972557; Wed, 04 May 2016 07:59:32 -0700 (PDT) Received: by 10.36.43.82 with HTTP; Wed, 4 May 2016 07:59:32 -0700 (PDT) In-Reply-To: <5dc1fb8a-fcaa-0470-ea05-d9d7fad3b61f@nostrum.com> References: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> <5dc1fb8a-fcaa-0470-ea05-d9d7fad3b61f@nostrum.com> Date: Thu, 5 May 2016 00:59:32 +1000 Message-ID: From: Martin Thomson To: Adam Roach Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] PERC and DataChannels 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, 04 May 2016 14:59:36 -0000 On 5 May 2016 at 00:42, Adam Roach wrote: > I was thinking the latter: just including guidance that this can't be > expected to work in the general case, and a suggestion that a full-mesh > setup for data is more sensible. I would be careful with that. Rather you should say that PERC is designed for media, not data. Suggesting a full mesh just invites the crazy. From nobody Wed May 4 10:58:19 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 8DC8F12D970 for ; Wed, 4 May 2016 10:58:17 -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=ipv-sx.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 n22Y9dGhPjaM for ; Wed, 4 May 2016 10:58:15 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 559A612D57A for ; Wed, 4 May 2016 10:58:15 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g133so96777266ywb.2 for ; Wed, 04 May 2016 10:58:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QwzOKdI7fezBLX9DjQHjmuAHqwWtBQf0lFkxm6/Yj2o=; b=h85B7X+cOc8BwU+Y+KGPXAl+X3B7VmAuTq6UwLkEhfc/0syxbrCuJdNJclhavf6CTQ UBWhuhZy8cgLFoCjwEOTFd5iVcpS118zdIWPJx3njmiCBrFx6pXjEKz5WHAaojEZ3QuU gSwzq7bQuoWt5LDLMMi7QPg636aTZD4vi0RMdcX3Ozn2qRmJe8VGnYvvYydvuWw0tpuO larnF49g81lcXeFlLkW8vGS9Ukwzg/TjBkvJRDoVRkGVwUMBK6in21mUUUCB6QpHCD0d 6i272GI9ve2zdu6wy4oVl2hxmMSGTmN6/qxVFuShWQvHkfWv/U5HjbRLtwEIwX6+kVW5 mCAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QwzOKdI7fezBLX9DjQHjmuAHqwWtBQf0lFkxm6/Yj2o=; b=JgmcIYDjHJV3TmNcIp3tt1GaHrn/RsZlFq6Sxn4KNHYEDpKs1m01FX9jHh+m/i1L0b eTDso/AmjrCDDBlpCEwyimICxiMNQC7MaW/4v3SQcrjqYm6+ahvQevN0ZJ5RJMvBuoF7 aanGAXF7Dd+NrlZdVhgKKqhh/+3J05ONUmMEKA5f0/8PVqBVJ8sxFp5nmyzVRL24T9F+ VtOgkEsIcgE+KHODaIxQNqgYJQNgJfvl9UgoPzrE5jjPVj/ZhToGVv9KPaed8HuKEgjr XjzKoKgmWtCczbePavc7axqFv4qwc/xyZmm2cmlkBGjxrlE3LVBfkRvoLcM314oIkD6v wxXQ== X-Gm-Message-State: AOPr4FUhnT93bdX0XbcnR3LWBIO5z+rUPvkOGAkqzK4SkxCx8vtVLx5dV4L0ciEy7xAleYHabEuBauqRSZFaTQ== MIME-Version: 1.0 X-Received: by 10.176.2.65 with SMTP id 59mr6579965uas.16.1462384694485; Wed, 04 May 2016 10:58:14 -0700 (PDT) Received: by 10.31.141.74 with HTTP; Wed, 4 May 2016 10:58:14 -0700 (PDT) In-Reply-To: References: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> <5dc1fb8a-fcaa-0470-ea05-d9d7fad3b61f@nostrum.com> Date: Wed, 4 May 2016 13:58:14 -0400 Message-ID: From: Richard Barnes To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113c01d03dfb0f053207f827 Archived-At: Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] PERC and DataChannels 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, 04 May 2016 17:58:18 -0000 --001a113c01d03dfb0f053207f827 Content-Type: text/plain; charset=UTF-8 On Wed, May 4, 2016 at 10:59 AM, Martin Thomson wrote: > On 5 May 2016 at 00:42, Adam Roach wrote: > > I was thinking the latter: just including guidance that this can't be > > expected to work in the general case, and a suggestion that a full-mesh > > setup for data is more sensible. > > I would be careful with that. Rather you should say that PERC is > designed for media, not data. Suggesting a full mesh just invites the > crazy. > I would phrase this yet differently. In principle, you could probably make something like EKT and -double work for DataChannels; we just haven't. (And won't. I think it's pretty clearly out of scope of the current charter.) That doesn't mean you can't use them, it just means that you're stuck with the pre-PERC privilege levels: You're part of the DTLS association or you're not. You can send additional DTLS packets to the KMF and have it do something with them, or you can make a DataChannel to the MDD, but you can't have the KMF synchronize the keys or allow the MDD to decrypt/modify anything. --Richard > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a113c01d03dfb0f053207f827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 4, 2016 at 10:59 AM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 5 May 2016 at 00:42, Adam Roach <adam@nostrum.com> wrote:
> I was thinking the latter: just including guidance that this can't= be
> expected to work in the general case, and a suggestion that a full-mes= h
> setup for data is more sensible.

I would be careful with that.=C2=A0 Rather you should say that PERC = is
designed for media, not data.=C2=A0 Suggesting a full mesh just invites the=
crazy.

I would phrase this yet differen= tly.=C2=A0 In principle, you could probably make something like EKT and -do= uble work for DataChannels; we just haven't.=C2=A0 (And won't.=C2= =A0 I think it's pretty clearly out of scope of the current charter.)
That doesn't mean you can't use them, it just mean= s that you're stuck with the pre-PERC privilege levels: You're part= of the DTLS association or you're not.=C2=A0 You can send additional D= TLS packets to the KMF and have it do something with them, or you can make = a DataChannel to the MDD, but you can't have the KMF synchronize the ke= ys or allow the MDD to decrypt/modify anything.

--Richard

=C2=A0

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

--001a113c01d03dfb0f053207f827-- From nobody Mon May 9 15:42:56 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 3C75212D0CE; Mon, 9 May 2016 15:42:52 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509224252.18300.3907.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 15:42:52 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-double-00.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: Mon, 09 May 2016 22:42:52 -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-00.txt Pages : 12 Date : 2016-05-09 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-00 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 Mon May 9 16:38:48 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 388301200A0; Mon, 9 May 2016 16:38:46 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509233846.18341.33145.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 16:38:46 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-00.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: Mon, 09 May 2016 23:38:46 -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-00.txt Pages : 18 Date : 2016-05-09 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-00 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 Tue May 10 08:35:17 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 AE4CA12D6D4 for ; Tue, 10 May 2016 08:35:15 -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 UUIKjXsaJncx for ; Tue, 10 May 2016 08:35:13 -0700 (PDT) Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DD512D72E for ; Tue, 10 May 2016 08:34:50 -0700 (PDT) Received: from smtp17.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DFC7C18045E for ; Tue, 10 May 2016 11:34:46 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp17.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9D1C5180159 for ; Tue, 10 May 2016 11:34:46 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 10 May 2016 11:34:46 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> Date: Tue, 10 May 2016 09:34:49 -0600 To: perc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [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: Tue, 10 May 2016 15:35:16 -0000 Normally I view names as a bit of a bike shed issue but lately I have = been spending a bunch of time explaining PERC to folks and I have been = finding the current names sort of confusing to new people. I'd like to = start a thread to come up with some new names for existing things ... inner and outer - people are never sure which is inner and which is = outer. I'd propose just using hop-by-hop and end-to-end=20 MDD - change to "Media Switch" or "Switch".=20 KMF - change to "Key Server" or "Key Manger" Endpoint - keep as "Endpoint" I'd like to move away from acronyms as much as possible - they just add = confusion.=20 Now that the OHB has become just a PT or Seq# change or both, it might = be good to think about simpler way of describing this.=20 EKT Field - use this to describe the place that any type of EKT message = get carried=20 Long EKT Field - change to Encrypted Key message. This message simply = caries the encrypted form of the SRTP Master Key and calling it EKT Long = Field in a protocol called EKT that is negotiated in TLS by including = ekt in the handshake is not very enlightening.=20 Short EKT Field - change to Empty message. This message caries nothing = and simply is there to indicate that no other EKT message is attached to = this packet.=20 Thoughts on better names? Folks OK with the proposed changes ? From nobody Tue May 10 08:42:55 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 31B6A12B054 for ; Tue, 10 May 2016 08:42:54 -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 91tVtFPIso9F for ; Tue, 10 May 2016 08:42:51 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 88DD712D1E9 for ; Tue, 10 May 2016 08:42:49 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id j74so15600002ywg.1 for ; Tue, 10 May 2016 08:42:49 -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; bh=BVsOFS3ijAOqGXjKUL07Snmk21tmG+/+jkSj9eQ45fI=; b=xwRsSmaBDWtoDQ8ewLHODRw69E+C3sZXaLaZcmH5Du8lXTvAkrBWHNBsiZRrmbrGF7 HeX/bNTa0aYqGb38wni42k7u1dTLPSr4gZREwoMQrMWE68QjBp6Uz1AiKjsljT2cm0tM m6AUKIFc7i2HJ7vbMKVxMC5ywk0ocqTFMsoDxTUbPKnOEujUPB6WXQIFsrtDTuMzDyWB j8L0b7YbyY5LKFOJD+vijnC8R4AhA7tLod/RHFSjPatBqxN8Rr+fplKAuptP0OZExrPE 5xtsBcbZUlx8I+wJ3qJcWct/Ocnin5bsVB0HNNXmReTHcgqMEQbezAjnpNidZ4JiVl3E LtPQ== 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=BVsOFS3ijAOqGXjKUL07Snmk21tmG+/+jkSj9eQ45fI=; b=XQaisK+08IRhEo3Ulm2tnF5R6UhFVQr/SCknTZsXUEbadhzXgkG8skzDD3s5DQZbqK jC2HE37ryM/x6ErHKbNglIR/NMXoPm15kYKq0YL3ZSZYkELrprVwmJxvdpDBL0Tt1wMT WFD9eXpjGhOPxh4TvR1Pk+SbZAHm6SdDyVabUj1pB8VJ6qpGJ7xPdriI+7/Glgjxygw6 LjlDHrNhnTldzsU9HmMGcqLaTIQiuiIU8yIx3cugNt7qYcp1YwPzWk2PJy6Wd+oMmPdd xSnW3joE4abecUcFqbn9dFd+A6ApZIrclUO0XYdvUmY4rju+A9GPRsUQ0E9GJLysSVu6 r87w== X-Gm-Message-State: AOPr4FViKhQ4rOH+oTHFWLbJsYnfElPdRknFIuXvJFu6ZZZRrg+78FCKS21tMbSWoKqmWA== X-Received: by 10.129.70.134 with SMTP id t128mr22277040ywa.208.1462894968811; Tue, 10 May 2016 08:42:48 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com. [209.85.161.182]) by smtp.gmail.com with ESMTPSA id g190sm1389624ywb.27.2016.05.10.08.42.48 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 08:42:48 -0700 (PDT) Received: by mail-yw0-f182.google.com with SMTP id o66so17382749ywc.3 for ; Tue, 10 May 2016 08:42:48 -0700 (PDT) X-Received: by 10.37.208.211 with SMTP id h202mr4298220ybg.63.1462894968224; Tue, 10 May 2016 08:42:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.6.138 with HTTP; Tue, 10 May 2016 08:42:28 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Tue, 10 May 2016 10:42:28 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 10 May 2016 15:42:54 -0000 Hey all, I was trying to get myself updated on PERC's status and stumbled upon these. Specifically, I was very surprised to find out that SSRCs have again become immutable ... There was abundant feedback on this list from implementers stating this would make PERC particularly inconvenient to support by today's SFUs. Could someone please tell me how I am completely misreading everything and that it's all a misunderstanding on my side? Thanks, Emil On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes wrote: > Hey all, > > Please find below the chairs' notes from the design team call we had on Monday. > > --Richard > > > PERC Design Team Call #3 > > # Chairs introduction > > * Future calls will follow Virtual Interim process > * This call is focused on figuring out what capabilities the MDD needs > to modify header fields > > > # Discussion of Header Fields > > Summary of conclusions on call: > > Field Can be modified? Send original? > V No --- > X Yes Maybe (see extn) > M No --- > PT Yes Yes > SEQ Yes Yes > Timestamp No --- > SSRC No --- > CSRC/CC No --- > Extension Yes TBD > > --- > > V - MDD MUST NOT change > > P - MDD MUST NOT change > > X - MDD needs to be able to change > -- Original value may be necessary for E2E integrity-protected extns > > M - MDD MUST NOT change > -- M is used to signal to endpoints to reset jitter buffers > -- ... but it's tied to SSRC, so switching SSRC could be the signal > -- Might need to document how this relates to SSRC / source indication > > PT - MDD needs to be able to change > -- MDD can always trash the conference > -- needs changing to match PTs across individual sessions > -- Security considerations about malicious PT changes > -- No immediate need for the original value at the receiver > -- ... but we should keep the option open > > SEQ - MDD needs to be able to change > > -- For, e.g., consistent loss detection with stream on/off behavior > > -- Different from network attacker b/c long silences are normal > > -- Replay attacks might need extra mechanism > > -- e.g., authenticated ROC in EKT > > -- Delay attack might be better handled with timestamp / RTCP > > -- Original value needed at the endpoint > > > Timestamp - MDD MUST NOT change > > -- MDD might want to change if MSM are used > > -- No MSM , no need to fudge the timespatmp > > -- When changed needs to preserve the original value > > -- No need to change if SSRC is immutable > > > SSRC - MDD MUST NOT change > > -- Splicing attack - needs source to be verified ? > > -- Need higher level layer to ensure SSRCs are end to end > authenticated somehow [[ or otherwise have the right properties ]] > > -- Might need to come back and make it mutable later > > -- Need to better express to the list why this design is simpler (Magnus/Adam) > > -- Might be making some topologies incompatible with this decision > > -- ... and we should be explicit about this > > > CSRC - MDD MUST NOT change > > -- ... and by implication, CSRC Count (CC) > > > Header Extensions > > -- ID values behave similar to PT (signaling based assignment) > > -- ... so MDD might need to align them > > -- Needs more discussion of how > > -- RFC5450 > > -- MDD MUST NOT change > > -- Not used widely today and might not be in future (ref RMCAT ) > > -- RFC6051 > > -- MDD MUST NOT change, might need more discussions > > -- no timestamp rewriting implies no changing of this value > > -- Tied to E2E RTCP decision > > -- RFC6464 > > -- removing or not removing might not matter > > -- b/w might force to remove but having it allows end-point to verify > the authenticity of source reporting its audio level > > -- RFC6465 > > -- MDD MUST NOT Modify > > -- Encrypted or not ( needs more discussion for all the audio > levels). Use HBH as the baseline to drive these discussions. > > -- CVO > > -- MUST NOT MODIFY > > -- [[ Ran out of time here ]] > > > Path Forward: > > -- Work through existing extensions to see what capabilities are needed > > -- Write protocol mechanism for capabilities, handling guidlines per header > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc -- https://jitsi.org From nobody Tue May 10 08:53:39 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 D59D312D518 for ; Tue, 10 May 2016 08:53:37 -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 W85IOnCaFt6S for ; Tue, 10 May 2016 08:53:34 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 8EAE812D506 for ; Tue, 10 May 2016 08:53:34 -0700 (PDT) Received: by mail-pa0-x22f.google.com with SMTP id iv1so6938712pac.2 for ; Tue, 10 May 2016 08:53:34 -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=yP3kFB4ZvS7+65gPGpSkSoDUOZJCI1Rzivq3QzUL+q8=; b=FO1XacckB1jfts/guFnWJbLt2X94oiH8JgshzNRQlovx8xBzIFPNEPAj6t7hZQl5ay qOmVQdpOf3pzAdfWMN40lQXRxCPe5qGj8Rf5F+pkNPTnaxv9jhChHUEHuBfaxTZY7fTK qpCoJqX0yIV2mEZmSoH85WKFknjw+VzMmC+fqI44dFhaEJm8cMkZwTp2/VhsgFC76oYn 2TreSuV9spYGzFpmFHjAp/1T7U2qLXocc5VMaAwNTpdUcNAY8PGvtIMuatYsVpyFBwLg UQx5+7UHzzZ0wOnjfkSyCQ3mTdPsGmPfXTA++J5iKdRROgjkgjEMuXtQ5kDHxGlKZs+g kadQ== 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=yP3kFB4ZvS7+65gPGpSkSoDUOZJCI1Rzivq3QzUL+q8=; b=F/o4FsdjqHJmbAW46Sgx+vYuBRs9I1UqkoSHi6/kyZuwNXc1haH36O4YsxMauTSy5W YESWf5DDjdtKZz35FTc0S6PIH5ZFPq5jALOZI5mA9cS9OxyEODqKbgYtJ/4G+lgOP1PN f93xis3isuZTLRCBzLv4fshIKY4/3W9xma2qgqLO+KBSVx0mvGI66aqcbOEC5LxSX0kj caNPI9c2HuVHELNcLFrAvQQVj5AI8fm2eoo2djZk5vxsAddDUPekycDIRuqaxGnV3uGT BJT36q90WaUNsqpqGIFU+XASXHx4YEEuBGWMSAe63kt7gs/kuX2L2CWxZT9w8D7LxTV7 0RRw== X-Gm-Message-State: AOPr4FUMErvEyx78tfe4UHZAqj7PEzux4b/pCv416ske2k7t1hi5O3R0wRxjNFlOITvpnA== X-Received: by 10.66.55.101 with SMTP id r5mr59666908pap.146.1462895614207; Tue, 10 May 2016 08:53:34 -0700 (PDT) Received: from [10.15.40.80] (mobile-166-176-186-225.mycingular.net. [166.176.186.225]) by smtp.gmail.com with ESMTPSA id kh2sm5522348pad.9.2016.05.10.08.53.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 08:53:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Tue, 10 May 2016 08:53:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4B472660-F05C-4A0F-A5B9-629322214B13@gmail.com> References: To: Emil Ivov Archived-At: Cc: Richard Barnes , perc@ietf.org Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 10 May 2016 15:53:38 -0000 Inconvenient is an understatement. Even the most basic SFU scenarios (like s= imulcast) require SSRC modification.=20 > On May 10, 2016, at 8:42 AM, Emil Ivov wrote: >=20 > Hey all, >=20 > I was trying to get myself updated on PERC's status and stumbled upon > these. Specifically, I was very surprised to find out that SSRCs have > again become immutable ... >=20 > There was abundant feedback on this list from implementers stating > this would make PERC particularly inconvenient to support by today's > SFUs. >=20 > Could someone please tell me how I am completely misreading everything > and that it's all a misunderstanding on my side? >=20 > Thanks, > Emil >=20 >=20 >> On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes wrote: >> Hey all, >>=20 >> Please find below the chairs' notes from the design team call we had on M= onday. >>=20 >> --Richard >>=20 >>=20 >> PERC Design Team Call #3 >>=20 >> # Chairs introduction >>=20 >> * Future calls will follow Virtual Interim process >> * This call is focused on figuring out what capabilities the MDD needs >> to modify header fields >>=20 >>=20 >> # Discussion of Header Fields >>=20 >> Summary of conclusions on call: >>=20 >> Field Can be modified? Send original? >> V No --- >> X Yes Maybe (see extn) >> M No --- >> PT Yes Yes >> SEQ Yes Yes >> Timestamp No --- >> SSRC No --- >> CSRC/CC No --- >> Extension Yes TBD >>=20 >> --- >>=20 >> V - MDD MUST NOT change >>=20 >> P - MDD MUST NOT change >>=20 >> X - MDD needs to be able to change >> -- Original value may be necessary for E2E integrity-protected extns >>=20 >> M - MDD MUST NOT change >> -- M is used to signal to endpoints to reset jitter buffers >> -- ... but it's tied to SSRC, so switching SSRC could be the signal >> -- Might need to document how this relates to SSRC / source indication= >>=20 >> PT - MDD needs to be able to change >> -- MDD can always trash the conference >> -- needs changing to match PTs across individual sessions >> -- Security considerations about malicious PT changes >> -- No immediate need for the original value at the receiver >> -- ... but we should keep the option open >>=20 >> SEQ - MDD needs to be able to change >>=20 >> -- For, e.g., consistent loss detection with stream on/off behavior >>=20 >> -- Different from network attacker b/c long silences are normal >>=20 >> -- Replay attacks might need extra mechanism >>=20 >> -- e.g., authenticated ROC in EKT >>=20 >> -- Delay attack might be better handled with timestamp / RTCP >>=20 >> -- Original value needed at the endpoint >>=20 >>=20 >> Timestamp - MDD MUST NOT change >>=20 >> -- MDD might want to change if MSM are used >>=20 >> -- No MSM , no need to fudge the timespatmp >>=20 >> -- When changed needs to preserve the original value >>=20 >> -- No need to change if SSRC is immutable >>=20 >>=20 >> SSRC - MDD MUST NOT change >>=20 >> -- Splicing attack - needs source to be verified ? >>=20 >> -- Need higher level layer to ensure SSRCs are end to end >> authenticated somehow [[ or otherwise have the right properties ]] >>=20 >> -- Might need to come back and make it mutable later >>=20 >> -- Need to better express to the list why this design is simpler (Magnus/= Adam) >>=20 >> -- Might be making some topologies incompatible with this decision >>=20 >> -- ... and we should be explicit about this >>=20 >>=20 >> CSRC - MDD MUST NOT change >>=20 >> -- ... and by implication, CSRC Count (CC) >>=20 >>=20 >> Header Extensions >>=20 >> -- ID values behave similar to PT (signaling based assignment) >>=20 >> -- ... so MDD might need to align them >>=20 >> -- Needs more discussion of how >>=20 >> -- RFC5450 >>=20 >> -- MDD MUST NOT change >>=20 >> -- Not used widely today and might not be in future (ref RMCAT ) >>=20 >> -- RFC6051 >>=20 >> -- MDD MUST NOT change, might need more discussions >>=20 >> -- no timestamp rewriting implies no changing of this value >>=20 >> -- Tied to E2E RTCP decision >>=20 >> -- RFC6464 >>=20 >> -- removing or not removing might not matter >>=20 >> -- b/w might force to remove but having it allows end-point to verify >> the authenticity of source reporting its audio level >>=20 >> -- RFC6465 >>=20 >> -- MDD MUST NOT Modify >>=20 >> -- Encrypted or not ( needs more discussion for all the audio >> levels). Use HBH as the baseline to drive these discussions. >>=20 >> -- CVO >>=20 >> -- MUST NOT MODIFY >>=20 >> -- [[ Ran out of time here ]] >>=20 >>=20 >> Path Forward: >>=20 >> -- Work through existing extensions to see what capabilities are needed >>=20 >> -- Write protocol mechanism for capabilities, handling guidlines per head= er >>=20 >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >=20 >=20 >=20 > --=20 > https://jitsi.org >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Tue May 10 09:02:36 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 8765212D518 for ; Tue, 10 May 2016 09:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 p5HPtv-GAHOV for ; Tue, 10 May 2016 09:02:33 -0700 (PDT) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1730C12D506 for ; Tue, 10 May 2016 09:02:11 -0700 (PDT) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 51845380158; Tue, 10 May 2016 12:02:08 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A1935380171; Tue, 10 May 2016 12:02:07 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 10 May 2016 12:02:08 -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: Date: Tue, 10 May 2016 10:02:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> References: To: Emil Ivov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , perc@ietf.org Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 10 May 2016 16:02:35 -0000 Yes, that topic was extensively discussed on the calls. One of the issue = was questions on how RTCP would work. Other issues were along lines of = how receiver would know what key to use. There was also the splicing = attack. It's worth noting that endpoints can change SSRC at along the = way, it's just the MDD that can not change them.=20 > On May 10, 2016, at 9:42 AM, Emil Ivov wrote: >=20 > Hey all, >=20 > I was trying to get myself updated on PERC's status and stumbled upon > these. Specifically, I was very surprised to find out that SSRCs have > again become immutable ... >=20 > There was abundant feedback on this list from implementers stating > this would make PERC particularly inconvenient to support by today's > SFUs. >=20 > Could someone please tell me how I am completely misreading everything > and that it's all a misunderstanding on my side? >=20 > Thanks, > Emil >=20 >=20 > On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes wrote: >> Hey all, >>=20 >> Please find below the chairs' notes from the design team call we had = on Monday. >>=20 >> --Richard >>=20 >>=20 >> PERC Design Team Call #3 >>=20 >> # Chairs introduction >>=20 >> * Future calls will follow Virtual Interim process >> * This call is focused on figuring out what capabilities the MDD = needs >> to modify header fields >>=20 >>=20 >> # Discussion of Header Fields >>=20 >> Summary of conclusions on call: >>=20 >> Field Can be modified? Send original? >> V No --- >> X Yes Maybe (see extn) >> M No --- >> PT Yes Yes >> SEQ Yes Yes >> Timestamp No --- >> SSRC No --- >> CSRC/CC No --- >> Extension Yes TBD >>=20 >> --- >>=20 >> V - MDD MUST NOT change >>=20 >> P - MDD MUST NOT change >>=20 >> X - MDD needs to be able to change >> -- Original value may be necessary for E2E integrity-protected = extns >>=20 >> M - MDD MUST NOT change >> -- M is used to signal to endpoints to reset jitter buffers >> -- ... but it's tied to SSRC, so switching SSRC could be the = signal >> -- Might need to document how this relates to SSRC / source = indication >>=20 >> PT - MDD needs to be able to change >> -- MDD can always trash the conference >> -- needs changing to match PTs across individual sessions >> -- Security considerations about malicious PT changes >> -- No immediate need for the original value at the receiver >> -- ... but we should keep the option open >>=20 >> SEQ - MDD needs to be able to change >>=20 >> -- For, e.g., consistent loss detection with stream on/off behavior >>=20 >> -- Different from network attacker b/c long silences are normal >>=20 >> -- Replay attacks might need extra mechanism >>=20 >> -- e.g., authenticated ROC in EKT >>=20 >> -- Delay attack might be better handled with timestamp / RTCP >>=20 >> -- Original value needed at the endpoint >>=20 >>=20 >> Timestamp - MDD MUST NOT change >>=20 >> -- MDD might want to change if MSM are used >>=20 >> -- No MSM , no need to fudge the timespatmp >>=20 >> -- When changed needs to preserve the original value >>=20 >> -- No need to change if SSRC is immutable >>=20 >>=20 >> SSRC - MDD MUST NOT change >>=20 >> -- Splicing attack - needs source to be verified ? >>=20 >> -- Need higher level layer to ensure SSRCs are end to end >> authenticated somehow [[ or otherwise have the right properties ]] >>=20 >> -- Might need to come back and make it mutable later >>=20 >> -- Need to better express to the list why this design is simpler = (Magnus/Adam) >>=20 >> -- Might be making some topologies incompatible with this decision >>=20 >> -- ... and we should be explicit about this >>=20 >>=20 >> CSRC - MDD MUST NOT change >>=20 >> -- ... and by implication, CSRC Count (CC) >>=20 >>=20 >> Header Extensions >>=20 >> -- ID values behave similar to PT (signaling based assignment) >>=20 >> -- ... so MDD might need to align them >>=20 >> -- Needs more discussion of how >>=20 >> -- RFC5450 >>=20 >> -- MDD MUST NOT change >>=20 >> -- Not used widely today and might not be in future (ref RMCAT ) >>=20 >> -- RFC6051 >>=20 >> -- MDD MUST NOT change, might need more discussions >>=20 >> -- no timestamp rewriting implies no changing of this value >>=20 >> -- Tied to E2E RTCP decision >>=20 >> -- RFC6464 >>=20 >> -- removing or not removing might not matter >>=20 >> -- b/w might force to remove but having it allows end-point to verify >> the authenticity of source reporting its audio level >>=20 >> -- RFC6465 >>=20 >> -- MDD MUST NOT Modify >>=20 >> -- Encrypted or not ( needs more discussion for all the audio >> levels). Use HBH as the baseline to drive these discussions. >>=20 >> -- CVO >>=20 >> -- MUST NOT MODIFY >>=20 >> -- [[ Ran out of time here ]] >>=20 >>=20 >> Path Forward: >>=20 >> -- Work through existing extensions to see what capabilities are = needed >>=20 >> -- Write protocol mechanism for capabilities, handling guidlines per = header >>=20 >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >=20 >=20 >=20 > --=20 > https://jitsi.org >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Tue May 10 09:12:27 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 DB07012D714 for ; Tue, 10 May 2016 09:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.517 X-Spam-Level: X-Spam-Status: No, score=-115.517 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=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 Z9uMp5w2Fg5G for ; Tue, 10 May 2016 09:12:23 -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 3364512D703 for ; Tue, 10 May 2016 09:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=762; q=dns/txt; s=iport; t=1462896743; x=1464106343; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S5w0R6odGjGAnEfjJGum+nWsTaxVU0IHIPAMH0V7I14=; b=gLp7tg9sgo+izXRC/EqsfJ6Ig5KKO61oQThcYEK5J+FYhgv7V6xMFPfh Sbio8z45wys/7LIbnggFvotj8DJJbYPyU/BKLHQnxZ3kNIAJHgthDZbgP malvjaDCdFqnrY4wCCGM0RzGoqL4OATzQhmv3vJfqh/K+TGNSpZ05cMGS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAgCtBzJX/5NdJa1dgziBUgatSYlWg?= =?us-ascii?q?g8BDYF2hhACgTQ4FAEBAQEBAQFlJ4RBAQEBAwE6PwULAgEIGB4QIRElAgQOBYg?= =?us-ascii?q?VAwsItCENhCcBAQEBAQEBAQEBAQEBAQEBAQEBAQEViBYIgk6CQ4F8gyuCLgEEl?= =?us-ascii?q?3YxAYwkgXmPGYdch2MBHgEBQoNrbogLfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,604,1454976000"; d="scan'208";a="270314522" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2016 16:12:22 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4AGCMkx005093 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 May 2016 16:12:22 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 May 2016 12:12:21 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Tue, 10 May 2016 12:12:21 -0400 From: "Cullen Jennings (fluffy)" To: Martin Thomson Thread-Topic: [Perc] PERC and DataChannels Thread-Index: AQHRqta7W2enNc8nIUed0YAi/l7qGQ== Date: Tue, 10 May 2016 16:12:21 +0000 Message-ID: <7DD7CA35-CE5D-4591-9E8F-D93CF12900B4@cisco.com> References: <7ecbe328-fe31-43d5-d245-eeb84248da43@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F47504AC1205741985FB27D9D13923B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] PERC and DataChannels 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: Tue, 10 May 2016 16:12:25 -0000 > On May 2, 2016, at 6:43 PM, Martin Thomson wro= te: >=20 > On 3 May 2016 at 06:01, Adam Roach wrote: >> After considering this quite a bit (and discussing it with Cullen on >> Friday), I'm pretty certain that the answer, from a PERC perspective, is >> that we don't want to specify setting up any kind of data communications >> along that path. So, for example, an attempt to negotiate a datachannel = in a >> webrtc context would fail. >=20 > Would this be an outright prohibition (MUST NOT) or just a "don't do > that, it doesn't make sense"? I think it would be more just not defined by PERC and don't expect this to = work or do anything in particularly unless something else extended it= From nobody Tue May 10 12:21:58 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 3FE2512D87F for ; Tue, 10 May 2016 12:21:56 -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 I2sq9YPuFcFQ for ; Tue, 10 May 2016 12:21:54 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 162A612D87D for ; Tue, 10 May 2016 12:21:54 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id j74so21894170ywg.1 for ; Tue, 10 May 2016 12:21:54 -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=cdDEXIkkPHB9j2mHNeRZu6Vt7ZmmGS9kHt139eU+OHE=; b=JuaIQvWmJ8CRYwq+ukkBZirpFqNkSfSYJxwpKTbV1pb8oJgP8dBkdCR/RwWv4ri1B3 HJnnZadsWGa1kby/JhXGNqi1WQ/YcwmHmFZSOjKzP1QYhRMILgcgAlmWU5fWLjRx1Wa9 elX492ctXx64qvdymvdmHXPtMfs8zCtSUctO8NvTXrZKsqAv7hNc0um0UGBj8CHWxdvX PNpsYOjljE0hEVf7D+E0uAhqupu9BiV4FyNarHgKrftEOE2liOwuVjbObxb4LR/86Nnh 3kw9isv2dZRx7JYzJliIYzqiF3dgFf3MtaX9BIB9/wPc2ZYT2Fm/f46tC666jSm28KCS kUZQ== 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=cdDEXIkkPHB9j2mHNeRZu6Vt7ZmmGS9kHt139eU+OHE=; b=DWJJudRGNFM2gSiywAaTv4luU7b9n33JjuWzrsNdPK8g4Gvt9WHYX77Euz3J/luVGb i+ADfmKxTHRWdduhWEcVDDpGUD8ooW+Ez3+qyiWgaMJmg4vKsxlqyluhCg+6ADn4ZQBr nn97u6T1zQReMB1jTLmLwkCTBk+OZaJ89z2zlsvoOx2KCE4AxHASKQokppxKJLMmQQvk WxjT5xaC6udajYyfIGxbb4R7KrsLCy+iaSSskTwQV0OeYvEqGLwvs5eWf+yeWwLQUfz1 7eqC2YVYQYrnOovikppss92CyqKcLTkvHm2HjQwLNEKu0uRadW5gnPiB/PcJOVsv7e14 PtDw== X-Gm-Message-State: AOPr4FWa81lP+4XShtcTqpmg2lcVkNu+v5/OUNzYPpSe8gtjkMvE81Pl+61ASvjhZw5XuQ== X-Received: by 10.13.233.68 with SMTP id s65mr23113670ywe.96.1462908113337; Tue, 10 May 2016 12:21:53 -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 o75sm1942480ywd.7.2016.05.10.12.21.52 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 12:21:53 -0700 (PDT) Received: by mail-yw0-f179.google.com with SMTP id t10so24498874ywa.0 for ; Tue, 10 May 2016 12:21:52 -0700 (PDT) X-Received: by 10.129.82.140 with SMTP id g134mr26147717ywb.27.1462908112566; Tue, 10 May 2016 12:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.6.138 with HTTP; Tue, 10 May 2016 12:21:33 -0700 (PDT) In-Reply-To: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> From: Emil Ivov Date: Tue, 10 May 2016 14:21:33 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Richard Barnes , perc@ietf.org Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 10 May 2016 19:21:56 -0000 I don't get it. PERC is the new thing and I assume adoption is, at least to some extent, an objective for the WG. If PERC needs an identifier with constraints that are incompatible with common practices, then PERC should simply define a new id with the behaviour, color, shape and smell that please PERC. It would then add that to RTP and RTCP and do whatever it pleases with it. It can be a copy of the original SSRC, it could only look like it or it could be something entirely different, whatever works. The point is: PERC should take the real world into account because the opposite is likely not going to work in PERC's favor. Has that option been considered and rejected? Are the reasons recorded anywhere or can we discuss them here? Emil On Tue, May 10, 2016 at 11:02 AM, Cullen Jennings wrote: > > Yes, that topic was extensively discussed on the calls. One of the issue = was questions on how RTCP would work. Other issues were along lines of how = receiver would know what key to use. There was also the splicing attack. It= 's worth noting that endpoints can change SSRC at along the way, it's just = the MDD that can not change them. > >> On May 10, 2016, at 9:42 AM, Emil Ivov wrote: >> >> Hey all, >> >> I was trying to get myself updated on PERC's status and stumbled upon >> these. Specifically, I was very surprised to find out that SSRCs have >> again become immutable ... >> >> There was abundant feedback on this list from implementers stating >> this would make PERC particularly inconvenient to support by today's >> SFUs. >> >> Could someone please tell me how I am completely misreading everything >> and that it's all a misunderstanding on my side? >> >> Thanks, >> Emil >> >> >> On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes wrote: >>> Hey all, >>> >>> Please find below the chairs' notes from the design team call we had on= Monday. >>> >>> --Richard >>> >>> >>> PERC Design Team Call #3 >>> >>> # Chairs introduction >>> >>> * Future calls will follow Virtual Interim process >>> * This call is focused on figuring out what capabilities the MDD needs >>> to modify header fields >>> >>> >>> # Discussion of Header Fields >>> >>> Summary of conclusions on call: >>> >>> Field Can be modified? Send original? >>> V No --- >>> X Yes Maybe (see extn) >>> M No --- >>> PT Yes Yes >>> SEQ Yes Yes >>> Timestamp No --- >>> SSRC No --- >>> CSRC/CC No --- >>> Extension Yes TBD >>> >>> --- >>> >>> V - MDD MUST NOT change >>> >>> P - MDD MUST NOT change >>> >>> X - MDD needs to be able to change >>> -- Original value may be necessary for E2E integrity-protected extns >>> >>> M - MDD MUST NOT change >>> -- M is used to signal to endpoints to reset jitter buffers >>> -- ... but it's tied to SSRC, so switching SSRC could be the signal >>> -- Might need to document how this relates to SSRC / source indicati= on >>> >>> PT - MDD needs to be able to change >>> -- MDD can always trash the conference >>> -- needs changing to match PTs across individual sessions >>> -- Security considerations about malicious PT changes >>> -- No immediate need for the original value at the receiver >>> -- ... but we should keep the option open >>> >>> SEQ - MDD needs to be able to change >>> >>> -- For, e.g., consistent loss detection with stream on/off behavior >>> >>> -- Different from network attacker b/c long silences are normal >>> >>> -- Replay attacks might need extra mechanism >>> >>> -- e.g., authenticated ROC in EKT >>> >>> -- Delay attack might be better handled with timestamp / RTCP >>> >>> -- Original value needed at the endpoint >>> >>> >>> Timestamp - MDD MUST NOT change >>> >>> -- MDD might want to change if MSM are used >>> >>> -- No MSM , no need to fudge the timespatmp >>> >>> -- When changed needs to preserve the original value >>> >>> -- No need to change if SSRC is immutable >>> >>> >>> SSRC - MDD MUST NOT change >>> >>> -- Splicing attack - needs source to be verified ? >>> >>> -- Need higher level layer to ensure SSRCs are end to end >>> authenticated somehow [[ or otherwise have the right properties ]] >>> >>> -- Might need to come back and make it mutable later >>> >>> -- Need to better express to the list why this design is simpler (Magnu= s/Adam) >>> >>> -- Might be making some topologies incompatible with this decision >>> >>> -- ... and we should be explicit about this >>> >>> >>> CSRC - MDD MUST NOT change >>> >>> -- ... and by implication, CSRC Count (CC) >>> >>> >>> Header Extensions >>> >>> -- ID values behave similar to PT (signaling based assignment) >>> >>> -- ... so MDD might need to align them >>> >>> -- Needs more discussion of how >>> >>> -- RFC5450 >>> >>> -- MDD MUST NOT change >>> >>> -- Not used widely today and might not be in future (ref RMCAT ) >>> >>> -- RFC6051 >>> >>> -- MDD MUST NOT change, might need more discussions >>> >>> -- no timestamp rewriting implies no changing of this value >>> >>> -- Tied to E2E RTCP decision >>> >>> -- RFC6464 >>> >>> -- removing or not removing might not matter >>> >>> -- b/w might force to remove but having it allows end-point to verify >>> the authenticity of source reporting its audio level >>> >>> -- RFC6465 >>> >>> -- MDD MUST NOT Modify >>> >>> -- Encrypted or not ( needs more discussion for all the audio >>> levels). Use HBH as the baseline to drive these discussions. >>> >>> -- CVO >>> >>> -- MUST NOT MODIFY >>> >>> -- [[ Ran out of time here ]] >>> >>> >>> Path Forward: >>> >>> -- Work through existing extensions to see what capabilities are needed >>> >>> -- Write protocol mechanism for capabilities, handling guidlines per he= ader >>> >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >> >> >> >> -- >> https://jitsi.org >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc > --=20 https://jitsi.org From nobody Tue May 10 12:49:35 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 27A6F12D8A2 for ; Tue, 10 May 2016 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kurento.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 LHdVhq2D4tN3 for ; Tue, 10 May 2016 12:49:30 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E30EA12D58F for ; Tue, 10 May 2016 12:49:29 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id n129so192782742wmn.1 for ; Tue, 10 May 2016 12:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurento.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Qk7DEkNbfoCUeEgFGOu0ebXALo6q92c7IBQfAtpz/yg=; b=bOXK3HhnXGeuAT92AW6za5zOHZq+jDQPa57TEdas2tfzcpLDLSHJM9CWv4sjZN6vyt jko7zMQXt+qgGz2oj2fb7cnmvZYOFrbTM7akGhoPY7kY+rrLxUXKnOx4TmwMAm9UMfkh n5FKtdXwRdtkpgZuYbm9xutN6SHiF4YkONp9Q= 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=Qk7DEkNbfoCUeEgFGOu0ebXALo6q92c7IBQfAtpz/yg=; b=KWTrii1ibKNKy3l2kZxLPJwjZhpAKfOeVCSlgxMdeqK29N/QvgFfs7dpSHJ/rN65d0 gy6eB0lohcMzpr5HmNiQjkr1BOtjNB6ejCT3GHc8lxi1rpBEQHU2sol0UF4s8QV9LQ4p iddVZBB142yagiGND2fpFX3g2VsdD7KEUAv8smGUNsyZC2RHn+ICP9aB466nRHTi332C lDy/Eu7mTrxWfBm31CmhjJCpAYMhYyDA31AG+q4kCPYqni33us4PZ0z3LZCdlR3rjK/u 0om4/2TqPRx7PMzNP1IEPjp5T1nWFxvlK0dnIlQqB/P90O8xPUy8B2uPchg5GwIWcVCn AxtQ== X-Gm-Message-State: AOPr4FX9PI13U89Wg6/TrSbrj5JCeO7gHVsH1uAw+s16sXaNbPVWzAfCJjjejNv8iS2DXQ== X-Received: by 10.28.102.8 with SMTP id a8mr19437478wmc.54.1462909768372; Tue, 10 May 2016 12:49:28 -0700 (PDT) Received: from [192.168.1.36] (65.red-2-137-39.dynamicip.rima-tde.net. [2.137.39.65]) by smtp.gmail.com with ESMTPSA id a207sm4671093wma.8.2016.05.10.12.49.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 May 2016 12:49:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luis Lopez In-Reply-To: Date: Tue, 10 May 2016 21:49:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> To: Emil Ivov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , perc@ietf.org, Cullen Jennings Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 10 May 2016 19:49:33 -0000 Hi, I already provided my vision as an SFU implementor some months ago but I = would like to stress it again: I=E2=80=99m with Emil. Avoiding SSRC = re-writing will significantly decrease the impact of PERC in the = implementors community as we=E2=80=99ll need to drop in the trash most = of our previous code and mechanism for managing lots of features = including simulcast, voice-power-based switching and many others. = Probably I=E2=80=99m missing something, but the arguments I=E2=80=99ve = seen in favor of inmutable SSRCs do not, IMO, justify a decision with = such relevant implications in implementations. Best regards. L. > El 10 may 2016, a las 21:21, Emil Ivov escribi=C3=B3: >=20 > I don't get it. PERC is the new thing and I assume adoption is, at > least to some extent, an objective for the WG. >=20 > If PERC needs an identifier with constraints that are incompatible > with common practices, then PERC should simply define a new id with > the behaviour, color, shape and smell that please PERC. It would then > add that to RTP and RTCP and do whatever it pleases with it. It can be > a copy of the original SSRC, it could only look like it or it could be > something entirely different, whatever works. >=20 > The point is: PERC should take the real world into account because the > opposite is likely not going to work in PERC's favor. >=20 > Has that option been considered and rejected? Are the reasons recorded > anywhere or can we discuss them here? >=20 > Emil >=20 > On Tue, May 10, 2016 at 11:02 AM, Cullen Jennings = wrote: >>=20 >> Yes, that topic was extensively discussed on the calls. One of the = issue was questions on how RTCP would work. Other issues were along = lines of how receiver would know what key to use. There was also the = splicing attack. It's worth noting that endpoints can change SSRC at = along the way, it's just the MDD that can not change them. >>=20 >>> On May 10, 2016, at 9:42 AM, Emil Ivov wrote: >>>=20 >>> Hey all, >>>=20 >>> I was trying to get myself updated on PERC's status and stumbled = upon >>> these. Specifically, I was very surprised to find out that SSRCs = have >>> again become immutable ... >>>=20 >>> There was abundant feedback on this list from implementers stating >>> this would make PERC particularly inconvenient to support by today's >>> SFUs. >>>=20 >>> Could someone please tell me how I am completely misreading = everything >>> and that it's all a misunderstanding on my side? >>>=20 >>> Thanks, >>> Emil >>>=20 >>>=20 >>> On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes wrote: >>>> Hey all, >>>>=20 >>>> Please find below the chairs' notes from the design team call we = had on Monday. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>> PERC Design Team Call #3 >>>>=20 >>>> # Chairs introduction >>>>=20 >>>> * Future calls will follow Virtual Interim process >>>> * This call is focused on figuring out what capabilities the MDD = needs >>>> to modify header fields >>>>=20 >>>>=20 >>>> # Discussion of Header Fields >>>>=20 >>>> Summary of conclusions on call: >>>>=20 >>>> Field Can be modified? Send original? >>>> V No --- >>>> X Yes Maybe (see extn) >>>> M No --- >>>> PT Yes Yes >>>> SEQ Yes Yes >>>> Timestamp No --- >>>> SSRC No --- >>>> CSRC/CC No --- >>>> Extension Yes TBD >>>>=20 >>>> --- >>>>=20 >>>> V - MDD MUST NOT change >>>>=20 >>>> P - MDD MUST NOT change >>>>=20 >>>> X - MDD needs to be able to change >>>> -- Original value may be necessary for E2E integrity-protected = extns >>>>=20 >>>> M - MDD MUST NOT change >>>> -- M is used to signal to endpoints to reset jitter buffers >>>> -- ... but it's tied to SSRC, so switching SSRC could be the = signal >>>> -- Might need to document how this relates to SSRC / source = indication >>>>=20 >>>> PT - MDD needs to be able to change >>>> -- MDD can always trash the conference >>>> -- needs changing to match PTs across individual sessions >>>> -- Security considerations about malicious PT changes >>>> -- No immediate need for the original value at the receiver >>>> -- ... but we should keep the option open >>>>=20 >>>> SEQ - MDD needs to be able to change >>>>=20 >>>> -- For, e.g., consistent loss detection with stream on/off behavior >>>>=20 >>>> -- Different from network attacker b/c long silences are normal >>>>=20 >>>> -- Replay attacks might need extra mechanism >>>>=20 >>>> -- e.g., authenticated ROC in EKT >>>>=20 >>>> -- Delay attack might be better handled with timestamp / RTCP >>>>=20 >>>> -- Original value needed at the endpoint >>>>=20 >>>>=20 >>>> Timestamp - MDD MUST NOT change >>>>=20 >>>> -- MDD might want to change if MSM are used >>>>=20 >>>> -- No MSM , no need to fudge the timespatmp >>>>=20 >>>> -- When changed needs to preserve the original value >>>>=20 >>>> -- No need to change if SSRC is immutable >>>>=20 >>>>=20 >>>> SSRC - MDD MUST NOT change >>>>=20 >>>> -- Splicing attack - needs source to be verified ? >>>>=20 >>>> -- Need higher level layer to ensure SSRCs are end to end >>>> authenticated somehow [[ or otherwise have the right properties ]] >>>>=20 >>>> -- Might need to come back and make it mutable later >>>>=20 >>>> -- Need to better express to the list why this design is simpler = (Magnus/Adam) >>>>=20 >>>> -- Might be making some topologies incompatible with this decision >>>>=20 >>>> -- ... and we should be explicit about this >>>>=20 >>>>=20 >>>> CSRC - MDD MUST NOT change >>>>=20 >>>> -- ... and by implication, CSRC Count (CC) >>>>=20 >>>>=20 >>>> Header Extensions >>>>=20 >>>> -- ID values behave similar to PT (signaling based assignment) >>>>=20 >>>> -- ... so MDD might need to align them >>>>=20 >>>> -- Needs more discussion of how >>>>=20 >>>> -- RFC5450 >>>>=20 >>>> -- MDD MUST NOT change >>>>=20 >>>> -- Not used widely today and might not be in future (ref RMCAT ) >>>>=20 >>>> -- RFC6051 >>>>=20 >>>> -- MDD MUST NOT change, might need more discussions >>>>=20 >>>> -- no timestamp rewriting implies no changing of this value >>>>=20 >>>> -- Tied to E2E RTCP decision >>>>=20 >>>> -- RFC6464 >>>>=20 >>>> -- removing or not removing might not matter >>>>=20 >>>> -- b/w might force to remove but having it allows end-point to = verify >>>> the authenticity of source reporting its audio level >>>>=20 >>>> -- RFC6465 >>>>=20 >>>> -- MDD MUST NOT Modify >>>>=20 >>>> -- Encrypted or not ( needs more discussion for all the audio >>>> levels). Use HBH as the baseline to drive these discussions. >>>>=20 >>>> -- CVO >>>>=20 >>>> -- MUST NOT MODIFY >>>>=20 >>>> -- [[ Ran out of time here ]] >>>>=20 >>>>=20 >>>> Path Forward: >>>>=20 >>>> -- Work through existing extensions to see what capabilities are = needed >>>>=20 >>>> -- Write protocol mechanism for capabilities, handling guidlines = per header >>>>=20 >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>=20 >>>=20 >>>=20 >>> -- >>> https://jitsi.org >>>=20 >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>=20 >=20 >=20 >=20 > --=20 > https://jitsi.org >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Tue May 10 16:04: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 60B9912D136 for ; Tue, 10 May 2016 16:04:05 -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 ttpCBlZs3ln4 for ; Tue, 10 May 2016 16:04:03 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EDE12D0C5 for ; Tue, 10 May 2016 16:04:02 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id iv1so10269026pac.2 for ; Tue, 10 May 2016 16:04:02 -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=XZl1Fvk3wbabKSwjPij0wlbJWj1FPlmUlgOghH0QAP0=; b=jeYMYPdtWZppKXdinkUuxlbyUCTDTr5tYt2wxI851Qol7ajdB19L2RE1BgdeXs02b8 CN2Me9+p8J5ZXrysh3qMAtF9vUWA0WcTrjIhrFRoGFCup1RVldSE74i+imUs8VPfuzp5 87TOHqad8qF1FjKw6yzSPxepXCYnnPzLwF2rbZUAvvqeHluLYrQPYH7gLn9Mcq4OSW13 PJPLXBaoSt2KUGf3YcoHiRXV/ciIIfnrWuN1CfFFsXecErHmqjJBKZmBNvP9h3z+PTKg C19SAMWUj2E0vaFXUItsRwri+vMJkXhIlSRt7lelFduI8IwEI+t0/Ap32QoJc2XaGlDx NcwA== 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=XZl1Fvk3wbabKSwjPij0wlbJWj1FPlmUlgOghH0QAP0=; b=i8lkkzlirDsiiCUrve7q0qSixYmgWBtZjTU/NOxWjFxbsaFKFJK6N1VaCdewYksXBr i9+t0SqEdJmNlkQGskr1bvhMlw0GJRMuckinpyBmLWXYR0L7jHs36UOWTRW5FdCwxTWg dXHWd6JB5PfSS6rqtaZdJjspDzeCc0GgZBZInx00TCOIcjAPnVeOyZZJf7g5vZF5xpvd IyomtA3zsOcBRvaWSLGtY10XAwQyURk/pnnCCheHcBLhQtIxvT4HU73rs8YMqNzUmM41 7SXpfjevDsgshIbO4my27rh18nP7GpI6f+TV6HqhAMxtJ8Oppg32BYfhsNAQGaFIk/JA dm7w== X-Gm-Message-State: AOPr4FUnIjgI8je9Gp4MohnIIOEt7NuhdcW85OKT4W6/RL3vUO7tYFIRBiQPMoFbf5NMTQ== X-Received: by 10.66.172.10 with SMTP id ay10mr197046pac.36.1462921442522; Tue, 10 May 2016 16:04:02 -0700 (PDT) Received: from [10.15.40.80] (mobile-166-176-186-225.mycingular.net. [166.176.186.225]) by smtp.gmail.com with ESMTPSA id g70sm6975320pfb.7.2016.05.10.16.04.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 16:04:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E238) In-Reply-To: <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> Date: Tue, 10 May 2016 16:04:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> To: Luis Lopez Archived-At: Cc: Richard Barnes , Emil Ivov , perc@ietf.org, Cullen Jennings Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 10 May 2016 23:04:05 -0000 I agree. Without SSRC rewriting PERC does not apply to any real world confer= encing scenarios.=20 But since the proposed key management scheme has similar security properties= to SRTP/SDES, that might be just as well. > On May 10, 2016, at 12:49 PM, Luis Lopez wrote: >=20 > Hi, >=20 > I already provided my vision as an SFU implementor some months ago but I w= ould like to stress it again: I=E2=80=99m with Emil. Avoiding SSRC re-writin= g will significantly decrease the impact of PERC in the implementors communi= ty as we=E2=80=99ll need to drop in the trash most of our previous code and m= echanism for managing lots of features including simulcast, voice-power-base= d switching and many others. Probably I=E2=80=99m missing something, but the= arguments I=E2=80=99ve seen in favor of inmutable SSRCs do not, IMO, justif= y a decision with such relevant implications in implementations. >=20 > Best regards. >=20 > L. >=20 >> El 10 may 2016, a las 21:21, Emil Ivov escribi=C3=B3: >>=20 >> I don't get it. PERC is the new thing and I assume adoption is, at >> least to some extent, an objective for the WG. >>=20 >> If PERC needs an identifier with constraints that are incompatible >> with common practices, then PERC should simply define a new id with >> the behaviour, color, shape and smell that please PERC. It would then >> add that to RTP and RTCP and do whatever it pleases with it. It can be >> a copy of the original SSRC, it could only look like it or it could be >> something entirely different, whatever works. >>=20 >> The point is: PERC should take the real world into account because the >> opposite is likely not going to work in PERC's favor. >>=20 >> Has that option been considered and rejected? Are the reasons recorded >> anywhere or can we discuss them here? >>=20 >> Emil >>=20 >>> On Tue, May 10, 2016 at 11:02 AM, Cullen Jennings wrote:= >>>=20 >>> Yes, that topic was extensively discussed on the calls. One of the issue= was questions on how RTCP would work. Other issues were along lines of how r= eceiver would know what key to use. There was also the splicing attack. It's= worth noting that endpoints can change SSRC at along the way, it's just the= MDD that can not change them. >>>=20 >>>> On May 10, 2016, at 9:42 AM, Emil Ivov wrote: >>>>=20 >>>> Hey all, >>>>=20 >>>> I was trying to get myself updated on PERC's status and stumbled upon >>>> these. Specifically, I was very surprised to find out that SSRCs have >>>> again become immutable ... >>>>=20 >>>> There was abundant feedback on this list from implementers stating >>>> this would make PERC particularly inconvenient to support by today's >>>> SFUs. >>>>=20 >>>> Could someone please tell me how I am completely misreading everything >>>> and that it's all a misunderstanding on my side? >>>>=20 >>>> Thanks, >>>> Emil >>>>=20 >>>>=20 >>>>> On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes wrote: >>>>> Hey all, >>>>>=20 >>>>> Please find below the chairs' notes from the design team call we had o= n Monday. >>>>>=20 >>>>> --Richard >>>>>=20 >>>>>=20 >>>>> PERC Design Team Call #3 >>>>>=20 >>>>> # Chairs introduction >>>>>=20 >>>>> * Future calls will follow Virtual Interim process >>>>> * This call is focused on figuring out what capabilities the MDD needs= >>>>> to modify header fields >>>>>=20 >>>>>=20 >>>>> # Discussion of Header Fields >>>>>=20 >>>>> Summary of conclusions on call: >>>>>=20 >>>>> Field Can be modified? Send original? >>>>> V No --- >>>>> X Yes Maybe (see extn) >>>>> M No --- >>>>> PT Yes Yes >>>>> SEQ Yes Yes >>>>> Timestamp No --- >>>>> SSRC No --- >>>>> CSRC/CC No --- >>>>> Extension Yes TBD >>>>>=20 >>>>> --- >>>>>=20 >>>>> V - MDD MUST NOT change >>>>>=20 >>>>> P - MDD MUST NOT change >>>>>=20 >>>>> X - MDD needs to be able to change >>>>> -- Original value may be necessary for E2E integrity-protected extns >>>>>=20 >>>>> M - MDD MUST NOT change >>>>> -- M is used to signal to endpoints to reset jitter buffers >>>>> -- ... but it's tied to SSRC, so switching SSRC could be the signal >>>>> -- Might need to document how this relates to SSRC / source indicatio= n >>>>>=20 >>>>> PT - MDD needs to be able to change >>>>> -- MDD can always trash the conference >>>>> -- needs changing to match PTs across individual sessions >>>>> -- Security considerations about malicious PT changes >>>>> -- No immediate need for the original value at the receiver >>>>> -- ... but we should keep the option open >>>>>=20 >>>>> SEQ - MDD needs to be able to change >>>>>=20 >>>>> -- For, e.g., consistent loss detection with stream on/off behavior >>>>>=20 >>>>> -- Different from network attacker b/c long silences are normal >>>>>=20 >>>>> -- Replay attacks might need extra mechanism >>>>>=20 >>>>> -- e.g., authenticated ROC in EKT >>>>>=20 >>>>> -- Delay attack might be better handled with timestamp / RTCP >>>>>=20 >>>>> -- Original value needed at the endpoint >>>>>=20 >>>>>=20 >>>>> Timestamp - MDD MUST NOT change >>>>>=20 >>>>> -- MDD might want to change if MSM are used >>>>>=20 >>>>> -- No MSM , no need to fudge the timespatmp >>>>>=20 >>>>> -- When changed needs to preserve the original value >>>>>=20 >>>>> -- No need to change if SSRC is immutable >>>>>=20 >>>>>=20 >>>>> SSRC - MDD MUST NOT change >>>>>=20 >>>>> -- Splicing attack - needs source to be verified ? >>>>>=20 >>>>> -- Need higher level layer to ensure SSRCs are end to end >>>>> authenticated somehow [[ or otherwise have the right properties ]] >>>>>=20 >>>>> -- Might need to come back and make it mutable later >>>>>=20 >>>>> -- Need to better express to the list why this design is simpler (Magn= us/Adam) >>>>>=20 >>>>> -- Might be making some topologies incompatible with this decision >>>>>=20 >>>>> -- ... and we should be explicit about this >>>>>=20 >>>>>=20 >>>>> CSRC - MDD MUST NOT change >>>>>=20 >>>>> -- ... and by implication, CSRC Count (CC) >>>>>=20 >>>>>=20 >>>>> Header Extensions >>>>>=20 >>>>> -- ID values behave similar to PT (signaling based assignment) >>>>>=20 >>>>> -- ... so MDD might need to align them >>>>>=20 >>>>> -- Needs more discussion of how >>>>>=20 >>>>> -- RFC5450 >>>>>=20 >>>>> -- MDD MUST NOT change >>>>>=20 >>>>> -- Not used widely today and might not be in future (ref RMCAT ) >>>>>=20 >>>>> -- RFC6051 >>>>>=20 >>>>> -- MDD MUST NOT change, might need more discussions >>>>>=20 >>>>> -- no timestamp rewriting implies no changing of this value >>>>>=20 >>>>> -- Tied to E2E RTCP decision >>>>>=20 >>>>> -- RFC6464 >>>>>=20 >>>>> -- removing or not removing might not matter >>>>>=20 >>>>> -- b/w might force to remove but having it allows end-point to verify >>>>> the authenticity of source reporting its audio level >>>>>=20 >>>>> -- RFC6465 >>>>>=20 >>>>> -- MDD MUST NOT Modify >>>>>=20 >>>>> -- Encrypted or not ( needs more discussion for all the audio >>>>> levels). Use HBH as the baseline to drive these discussions. >>>>>=20 >>>>> -- CVO >>>>>=20 >>>>> -- MUST NOT MODIFY >>>>>=20 >>>>> -- [[ Ran out of time here ]] >>>>>=20 >>>>>=20 >>>>> Path Forward: >>>>>=20 >>>>> -- Work through existing extensions to see what capabilities are neede= d >>>>>=20 >>>>> -- Write protocol mechanism for capabilities, handling guidlines per h= eader >>>>>=20 >>>>> _______________________________________________ >>>>> Perc mailing list >>>>> Perc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perc >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> https://jitsi.org >>>>=20 >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>=20 >>=20 >>=20 >> --=20 >> https://jitsi.org >>=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 From nobody Tue May 10 22:07:38 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 E3FA512D628 for ; Tue, 10 May 2016 22:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 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=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 Af4vkqpby9Xs for ; Tue, 10 May 2016 22:07:35 -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 7024F12D615 for ; Tue, 10 May 2016 22:07:35 -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 u4B57Xdk025084 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2016 01:07:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1462943254; bh=O5hdbdA0nxvKdRDrZ0ODR35qr4BZZln5vGChFoEKYAQ=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=ks64EMYnrzqcTJ/rqiL+LgT5q2+vN+qzRPjcMmUYwCUIfUJn+clIrNJnD4n5LCSG0 LrQg9ZnmtWBZAMgmumBBLF5apzKgHIO/gEOxPjz7Ig212hakS0hTdEes53C2fOFpjQ nQlh1qcjfWlHsAnA9y8F0aqidyBhFIJYNXh4vtL0= From: "Paul E. Jones" To: "Cullen Jennings" , perc@ietf.org Date: Wed, 11 May 2016 05:07:42 +0000 Message-Id: In-Reply-To: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 11 May 2016 01:07:34 -0400 (EDT) Archived-At: Subject: Re: [Perc] Names, Names, Names 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, 11 May 2016 05:07:37 -0000 Cullen, >inner and outer - people are never sure which is inner and which is=20 >outer. I'd propose just using hop-by-hop and end-to-end Agreed. >MDD - change to "Media Switch" or "Switch". Switching Conference Server is the original term we used, I think. I=20 have no strong preference on this one. >KMF - change to "Key Server" or "Key Manger" I avoided the word "Key Server" to make it clear it's not just a=20 "server", but a functional element within the system. The term "key=20 manager" might be better given this function might be inside a browser. >I'd like to move away from acronyms as much as possible - they just add= =20 >confusion. Oh, I won't argue with this one at all. >Now that the OHB has become just a PT or Seq# change or both, it might=20 >be good to think about simpler way of describing this. We can review that text, but OHB doesn't suggest a complex structure. =20 It could be the "original header field value extension" (avoiding=20 acronyms). >EKT Field - use this to describe the place that any type of EKT message= =20 >get carried > >Long EKT Field - change to Encrypted Key message. This message simply=20 >caries the encrypted form of the SRTP Master Key and calling it EKT=20 >Long Field in a protocol called EKT that is negotiated in TLS by=20 >including ekt in the handshake is not very enlightening. > >Short EKT Field - change to Empty message. This message caries nothing= =20 >and simply is there to indicate that no other EKT message is attached=20 >to this packet. I think changing this to "encrypted" and "empty" are confusing. =20 Previously, this thing was called the "EKT Tag". The current terms are= =20 "Full EKT Field" or "Short EKT Field". If that's too confusing, perhaps= =20 we just try to find a way to drop the full/short delineation, just call=20 it the EKT Tag/Field? Personally, I like the short/full description=20 since there is concrete syntax that goes with it. The alternatives you=20 suggest make it sound like different messages (versus field elements). Paul From nobody Tue May 10 22:48: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 A2B4212D0E6 for ; Tue, 10 May 2016 22:48: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 lq1mDh3I-mAG for ; Tue, 10 May 2016 22:48:04 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 5A08C12B01A for ; Tue, 10 May 2016 22:48:04 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g133so33191517ywb.2 for ; Tue, 10 May 2016 22:48:04 -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=DaSaET9tj+KTg0AwaBKj/yXy6IIpE89Nm1Wesn4909o=; b=RIhP8xsjlKvoM6sOpeEmxDPn2OJUbGkiMDfj/tr/OwThGqfC+96eGuAhkcgDGaPfUh 3jz1HZovK89Duk3/7A/eVrZ8OIcz2o0sKHhF+VfJtJZDLHhYCT0NLUjme0yOxXJuVI0i dgaGp+9aR0HxAzeUP+ZHP87OcQ8+f/PVwtHjCdBoG8eCqU8XWsxfJam7605EDwhjZn4z mjrlku7sCaWtSppV7Gf63N155R8XVwReIVprkgA2CsP6VCxV1h+ZVYr1Zf7cyYjbau0S 5Jfj7zxOpEBExnKiQB4GWr/m0z5THABLei4cbKtH8tIlOEJkKwOr08N7rgFEdC4KtHUN FomA== 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=DaSaET9tj+KTg0AwaBKj/yXy6IIpE89Nm1Wesn4909o=; b=W6qg53bJpt6nBB2CMMSGwbt6gzzJs+SZt/629CvO8XSfVsKlV+9LbR/KxGM0uGChpZ GCS5RB/yB+3mv8WflncrQa6MF6cEO9SjtHwOxvZy7+Nzzg2alsmdYJTV/RW46zfn3+km 7D12HZ7eRUh0GDhD/KCXW1ujrP4/5KkqXmMeVZ13QECtYU8fu+Qzd1urNvoW9lc/bh4y tTWt+SzzboYr0DFJ/8vCxaDa3MsWyeP+HbzMWpIzxHTeahtGCDSy/Y4UrfduVjIXb3YI qVYeQsWwf2HPiaDD3t0m6Rt+lWjrJsiF0RMKWRP+Rt/tT7TRIdf45XfcuywZwvPEnBJC CI8g== X-Gm-Message-State: AOPr4FUvYsn4MOG+xoazg39ZXfeYHQUKZrvsbLqxn3Ds2n6v9HLi4LAZWjtfrJ6PILnMLtM38LKa8NvR4D3T0A== X-Received: by 10.129.4.151 with SMTP id 145mr696368ywe.44.1462945683411; Tue, 10 May 2016 22:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Tue, 10 May 2016 22:47:24 -0700 (PDT) In-Reply-To: References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> From: Eric Rescorla Date: Wed, 11 May 2016 07:47:24 +0200 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a113f3160c9428f05328a952a Archived-At: Cc: Richard Barnes , Luis Lopez , Emil Ivov , perc@ietf.org, Cullen Jennings Subject: Re: [Perc] Minutes from Design Team call #3 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, 11 May 2016 05:48:07 -0000 --001a113f3160c9428f05328a952a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, May 11, 2016 at 1:04 AM, Bernard Aboba wrote: > I agree. Without SSRC rewriting PERC does not apply to any real world > conferencing scenarios. > > But since the proposed key management scheme has similar security > properties to SRTP/SDES, that might be just as well. > Hmm... Unless I've badly misanalyzed it, this is not correct. While the scheme does permit one side to dictate the keys, they are not available to a passive signaling server. What have I misunderstood? -Ekr > > On May 10, 2016, at 12:49 PM, Luis Lopez wrote: > > > > Hi, > > > > I already provided my vision as an SFU implementor some months ago but = I > would like to stress it again: I=E2=80=99m with Emil. Avoiding SSRC re-wr= iting will > significantly decrease the impact of PERC in the implementors community a= s > we=E2=80=99ll need to drop in the trash most of our previous code and mec= hanism for > managing lots of features including simulcast, voice-power-based switchin= g > and many others. Probably I=E2=80=99m missing something, but the argument= s I=E2=80=99ve > seen in favor of inmutable SSRCs do not, IMO, justify a decision with suc= h > relevant implications in implementations. > > > > Best regards. > > > > L. > > > >> El 10 may 2016, a las 21:21, Emil Ivov escribi=C3=B3= : > >> > >> I don't get it. PERC is the new thing and I assume adoption is, at > >> least to some extent, an objective for the WG. > >> > >> If PERC needs an identifier with constraints that are incompatible > >> with common practices, then PERC should simply define a new id with > >> the behaviour, color, shape and smell that please PERC. It would then > >> add that to RTP and RTCP and do whatever it pleases with it. It can be > >> a copy of the original SSRC, it could only look like it or it could be > >> something entirely different, whatever works. > >> > >> The point is: PERC should take the real world into account because the > >> opposite is likely not going to work in PERC's favor. > >> > >> Has that option been considered and rejected? Are the reasons recorded > >> anywhere or can we discuss them here? > >> > >> Emil > >> > >>> On Tue, May 10, 2016 at 11:02 AM, Cullen Jennings > wrote: > >>> > >>> Yes, that topic was extensively discussed on the calls. One of the > issue was questions on how RTCP would work. Other issues were along lines > of how receiver would know what key to use. There was also the splicing > attack. It's worth noting that endpoints can change SSRC at along the way= , > it's just the MDD that can not change them. > >>> > >>>> On May 10, 2016, at 9:42 AM, Emil Ivov wrote: > >>>> > >>>> Hey all, > >>>> > >>>> I was trying to get myself updated on PERC's status and stumbled upo= n > >>>> these. Specifically, I was very surprised to find out that SSRCs hav= e > >>>> again become immutable ... > >>>> > >>>> There was abundant feedback on this list from implementers stating > >>>> this would make PERC particularly inconvenient to support by today's > >>>> SFUs. > >>>> > >>>> Could someone please tell me how I am completely misreading everythi= ng > >>>> and that it's all a misunderstanding on my side? > >>>> > >>>> Thanks, > >>>> Emil > >>>> > >>>> > >>>>> On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes wrote: > >>>>> Hey all, > >>>>> > >>>>> Please find below the chairs' notes from the design team call we ha= d > on Monday. > >>>>> > >>>>> --Richard > >>>>> > >>>>> > >>>>> PERC Design Team Call #3 > >>>>> > >>>>> # Chairs introduction > >>>>> > >>>>> * Future calls will follow Virtual Interim process > >>>>> * This call is focused on figuring out what capabilities the MDD > needs > >>>>> to modify header fields > >>>>> > >>>>> > >>>>> # Discussion of Header Fields > >>>>> > >>>>> Summary of conclusions on call: > >>>>> > >>>>> Field Can be modified? Send original? > >>>>> V No --- > >>>>> X Yes Maybe (see extn) > >>>>> M No --- > >>>>> PT Yes Yes > >>>>> SEQ Yes Yes > >>>>> Timestamp No --- > >>>>> SSRC No --- > >>>>> CSRC/CC No --- > >>>>> Extension Yes TBD > >>>>> > >>>>> --- > >>>>> > >>>>> V - MDD MUST NOT change > >>>>> > >>>>> P - MDD MUST NOT change > >>>>> > >>>>> X - MDD needs to be able to change > >>>>> -- Original value may be necessary for E2E integrity-protected ext= ns > >>>>> > >>>>> M - MDD MUST NOT change > >>>>> -- M is used to signal to endpoints to reset jitter buffers > >>>>> -- ... but it's tied to SSRC, so switching SSRC could be the signa= l > >>>>> -- Might need to document how this relates to SSRC / source > indication > >>>>> > >>>>> PT - MDD needs to be able to change > >>>>> -- MDD can always trash the conference > >>>>> -- needs changing to match PTs across individual sessions > >>>>> -- Security considerations about malicious PT changes > >>>>> -- No immediate need for the original value at the receiver > >>>>> -- ... but we should keep the option open > >>>>> > >>>>> SEQ - MDD needs to be able to change > >>>>> > >>>>> -- For, e.g., consistent loss detection with stream on/off behavior > >>>>> > >>>>> -- Different from network attacker b/c long silences are normal > >>>>> > >>>>> -- Replay attacks might need extra mechanism > >>>>> > >>>>> -- e.g., authenticated ROC in EKT > >>>>> > >>>>> -- Delay attack might be better handled with timestamp / RTCP > >>>>> > >>>>> -- Original value needed at the endpoint > >>>>> > >>>>> > >>>>> Timestamp - MDD MUST NOT change > >>>>> > >>>>> -- MDD might want to change if MSM are used > >>>>> > >>>>> -- No MSM , no need to fudge the timespatmp > >>>>> > >>>>> -- When changed needs to preserve the original value > >>>>> > >>>>> -- No need to change if SSRC is immutable > >>>>> > >>>>> > >>>>> SSRC - MDD MUST NOT change > >>>>> > >>>>> -- Splicing attack - needs source to be verified ? > >>>>> > >>>>> -- Need higher level layer to ensure SSRCs are end to end > >>>>> authenticated somehow [[ or otherwise have the right properties ]] > >>>>> > >>>>> -- Might need to come back and make it mutable later > >>>>> > >>>>> -- Need to better express to the list why this design is simpler > (Magnus/Adam) > >>>>> > >>>>> -- Might be making some topologies incompatible with this decision > >>>>> > >>>>> -- ... and we should be explicit about this > >>>>> > >>>>> > >>>>> CSRC - MDD MUST NOT change > >>>>> > >>>>> -- ... and by implication, CSRC Count (CC) > >>>>> > >>>>> > >>>>> Header Extensions > >>>>> > >>>>> -- ID values behave similar to PT (signaling based assignment) > >>>>> > >>>>> -- ... so MDD might need to align them > >>>>> > >>>>> -- Needs more discussion of how > >>>>> > >>>>> -- RFC5450 > >>>>> > >>>>> -- MDD MUST NOT change > >>>>> > >>>>> -- Not used widely today and might not be in future (ref RMCAT ) > >>>>> > >>>>> -- RFC6051 > >>>>> > >>>>> -- MDD MUST NOT change, might need more discussions > >>>>> > >>>>> -- no timestamp rewriting implies no changing of this value > >>>>> > >>>>> -- Tied to E2E RTCP decision > >>>>> > >>>>> -- RFC6464 > >>>>> > >>>>> -- removing or not removing might not matter > >>>>> > >>>>> -- b/w might force to remove but having it allows end-point to veri= fy > >>>>> the authenticity of source reporting its audio level > >>>>> > >>>>> -- RFC6465 > >>>>> > >>>>> -- MDD MUST NOT Modify > >>>>> > >>>>> -- Encrypted or not ( needs more discussion for all the audio > >>>>> levels). Use HBH as the baseline to drive these discussions. > >>>>> > >>>>> -- CVO > >>>>> > >>>>> -- MUST NOT MODIFY > >>>>> > >>>>> -- [[ Ran out of time here ]] > >>>>> > >>>>> > >>>>> Path Forward: > >>>>> > >>>>> -- Work through existing extensions to see what capabilities are > needed > >>>>> > >>>>> -- Write protocol mechanism for capabilities, handling guidlines pe= r > header > >>>>> > >>>>> _______________________________________________ > >>>>> Perc mailing list > >>>>> Perc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/perc > >>>> > >>>> > >>>> > >>>> -- > >>>> https://jitsi.org > >>>> > >>>> _______________________________________________ > >>>> Perc mailing list > >>>> Perc@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/perc > >> > >> > >> > >> -- > >> https://jitsi.org > >> > >> _______________________________________________ > >> 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 > --001a113f3160c9428f05328a952a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 11, 2016 at 1:04 AM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:
I agree. Wi= thout SSRC rewriting PERC does not apply to any real world conferencing sce= narios.

But since the proposed key management scheme has similar security propertie= s to SRTP/SDES, that might be just as well.

=
Hmm... Unless I've badly misanalyzed it, this is not correct. Whil= e the scheme does permit one side to dictate the keys, they are not availab= le to
a passive signaling server. What have I misunderstood?

-Ekr


> On May 10, 2016, at 12:49 PM, Luis Lopez <lulop@kurento.com> wrote:
>
> Hi,
>
> I already provided my vision as an SFU implementor some months ago but= I would like to stress it again: I=E2=80=99m with Emil. Avoiding SSRC re-w= riting will significantly decrease the impact of PERC in the implementors c= ommunity as we=E2=80=99ll need to drop in the trash most of our previous co= de and mechanism for managing lots of features including simulcast, voice-p= ower-based switching and many others. Probably I=E2=80=99m missing somethin= g, but the arguments I=E2=80=99ve seen in favor of inmutable SSRCs do not, = IMO, justify a decision with such relevant implications in implementations.=
>
> Best regards.
>
> L.
>
>> El 10 may 2016, a las 21:21, Emil Ivov <emcho@jitsi.org> escribi=C3=B3:
>>
>> I don't get it. PERC is the new thing and I assume adoption is= , at
>> least to some extent, an objective for the WG.
>>
>> If PERC needs an identifier with constraints that are incompatible=
>> with common practices, then PERC should simply define a new id wit= h
>> the behaviour, color, shape and smell that please PERC. It would t= hen
>> add that to RTP and RTCP and do whatever it pleases with it. It ca= n be
>> a copy of the original SSRC, it could only look like it or it coul= d be
>> something entirely different, whatever works.
>>
>> The point is: PERC should take the real world into account because= the
>> opposite is likely not going to work in PERC's favor.
>>
>> Has that option been considered and rejected? Are the reasons reco= rded
>> anywhere or can we discuss them here?
>>
>> Emil
>>
>>> On Tue, May 10, 2016 at 11:02 AM, Cullen Jennings <fluffy@iii.ca> wrote:
>>>
>>> Yes, that topic was extensively discussed on the calls. One of= the issue was questions on how RTCP would work. Other issues were along li= nes of how receiver would know what key to use. There was also the splicing= attack. It's worth noting that endpoints can change SSRC at along the = way, it's just the MDD that can not change them.
>>>
>>>> On May 10, 2016, at 9:42 AM, Emil Ivov <emcho@jitsi.org> wrote:
>>>>
>>>> Hey all,
>>>>
>>>> I was trying to get myself updated on PERC's status an= d stumbled upon
>>>> these. Specifically, I was very surprised to find out that= SSRCs have
>>>> again become immutable ...
>>>>
>>>> There was abundant feedback on this list from implementers= stating
>>>> this would make PERC particularly inconvenient to support = by today's
>>>> SFUs.
>>>>
>>>> Could someone please tell me how I am completely misreadin= g everything
>>>> and that it's all a misunderstanding on my side?
>>>>
>>>> Thanks,
>>>> Emil
>>>>
>>>>
>>>>> On Wed, Dec 2, 2015 at 5:36 PM, Richard Barnes <rlb= @ipv.sx> wrote:
>>>>> Hey all,
>>>>>
>>>>> Please find below the chairs' notes from the desig= n team call we had on Monday.
>>>>>
>>>>> --Richard
>>>>>
>>>>>
>>>>> PERC Design Team Call #3
>>>>>
>>>>> # Chairs introduction
>>>>>
>>>>> * Future calls will follow Virtual Interim process
>>>>> * This call is focused on figuring out what capabiliti= es the MDD needs
>>>>> to modify header fields
>>>>>
>>>>>
>>>>> # Discussion of Header Fields
>>>>>
>>>>> Summary of conclusions on call:
>>>>>
>>>>> Field=C2=A0 =C2=A0 =C2=A0 =C2=A0Can be modified?=C2=A0= =C2=A0 Send original?
>>>>> V=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0No=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-= --
>>>>> X=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Yes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Maybe (see extn)
>>>>> M=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0No=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-= --
>>>>> PT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes
>>>>> SEQ=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes
>>>>> Timestamp=C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
>>>>> SSRC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 No=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
>>>>> CSRC/CC=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0No=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0---
>>>>> Extension=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TBD
>>>>>
>>>>> ---
>>>>>
>>>>> V - MDD MUST NOT change
>>>>>
>>>>> P - MDD MUST NOT change
>>>>>
>>>>> X - MDD needs to be able to change
>>>>>=C2=A0 -- Original value may be necessary for E2E integ= rity-protected extns
>>>>>
>>>>> M - MDD MUST NOT change
>>>>>=C2=A0 -- M is used to signal to endpoints to reset jit= ter buffers
>>>>>=C2=A0 -- ... but it's tied to SSRC, so switching S= SRC could be the signal
>>>>>=C2=A0 -- Might need to document how this relates to SS= RC / source indication
>>>>>
>>>>> PT - MDD needs to be able to change
>>>>> -- MDD can always trash the conference
>>>>> -- needs changing to match PTs across individual sessi= ons
>>>>> -- Security considerations about malicious PT changes<= br> >>>>> -- No immediate need for the original value at the rec= eiver
>>>>> -- ... but we should keep the option open
>>>>>
>>>>> SEQ - MDD needs to be able to change
>>>>>
>>>>> -- For, e.g., consistent loss detection with stream on= /off behavior
>>>>>
>>>>> -- Different from network attacker b/c long silences a= re normal
>>>>>
>>>>> -- Replay attacks might need extra mechanism
>>>>>
>>>>> -- e.g., authenticated ROC in EKT
>>>>>
>>>>> -- Delay attack might be better handled with timestamp= / RTCP
>>>>>
>>>>> -- Original value needed at the endpoint
>>>>>
>>>>>
>>>>> Timestamp - MDD MUST NOT change
>>>>>
>>>>> -- MDD might want to change if MSM are used
>>>>>
>>>>> -- No MSM , no need to fudge the timespatmp
>>>>>
>>>>> -- When changed needs to preserve the original value >>>>>
>>>>> -- No need to change if SSRC is immutable
>>>>>
>>>>>
>>>>> SSRC - MDD MUST NOT change
>>>>>
>>>>> -- Splicing attack - needs source to be verified ?
>>>>>
>>>>> -- Need higher level layer to ensure SSRCs are end to = end
>>>>> authenticated somehow [[ or otherwise have the right p= roperties ]]
>>>>>
>>>>> -- Might need to come back and make it mutable later >>>>>
>>>>> -- Need to better express to the list why this design = is simpler (Magnus/Adam)
>>>>>
>>>>> -- Might be making some topologies incompatible with t= his decision
>>>>>
>>>>> -- ... and we should be explicit about this
>>>>>
>>>>>
>>>>> CSRC - MDD MUST NOT change
>>>>>
>>>>> -- ... and by implication, CSRC Count (CC)
>>>>>
>>>>>
>>>>> Header Extensions
>>>>>
>>>>> -- ID values behave similar to PT (signaling based ass= ignment)
>>>>>
>>>>> -- ... so MDD might need to align them
>>>>>
>>>>> -- Needs more discussion of how
>>>>>
>>>>> -- RFC5450
>>>>>
>>>>> -- MDD MUST NOT change
>>>>>
>>>>> -- Not used widely today and might not be in future (r= ef RMCAT )
>>>>>
>>>>> -- RFC6051
>>>>>
>>>>> -- MDD MUST NOT change, might need more discussions >>>>>
>>>>> -- no timestamp rewriting implies no changing of this = value
>>>>>
>>>>> -- Tied to E2E RTCP decision
>>>>>
>>>>> -- RFC6464
>>>>>
>>>>> -- removing or not removing might not matter
>>>>>
>>>>> -- b/w might force to remove but having it allows end-= point to verify
>>>>> the authenticity of source reporting its audio level >>>>>
>>>>> --=C2=A0 RFC6465
>>>>>
>>>>> -- MDD MUST NOT Modify
>>>>>
>>>>> --=C2=A0 Encrypted or not ( needs more discussion for = all the audio
>>>>> levels). Use HBH as the baseline to drive these discus= sions.
>>>>>
>>>>> -- CVO
>>>>>
>>>>> -- MUST NOT MODIFY
>>>>>
>>>>> -- [[ Ran out of time here ]]
>>>>>
>>>>>
>>>>> Path Forward:
>>>>>
>>>>> -- Work through existing extensions to see what capabi= lities are needed
>>>>>
>>>>> -- Write protocol mechanism for capabilities, handling= guidlines per header
>>>>>
>>>>> _______________________________________________
>>>>> Perc mailing list
>>>>> Perc@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo= /perc
>>>>
>>>>
>>>>
>>>> --
>>>> https://jitsi.org
>>>>
>>>> _______________________________________________
>>>> Perc mailing list
>>>> Perc@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/per= c
>>
>>
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> 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

--001a113f3160c9428f05328a952a-- From nobody Wed May 11 00:52:55 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 57C5F12B029 for ; Wed, 11 May 2016 00:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 IzIVDYE-B_yD for ; Wed, 11 May 2016 00:52:51 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 86BF112B04F for ; Wed, 11 May 2016 00:52:51 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id c189so16341689pfb.3 for ; Wed, 11 May 2016 00:52:51 -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=npyiH8gH2jaXEwnQp+f+J1rCZr0m4HBik2ndk5ENMFc=; b=kPRhqM8hTMQVvlxXsoNT+kaRmCmBheYeSnL4GxloIFTXhZaL1Hyi85imbkrs3HdVnx hLyGrgU24aPBm2S/F7ZOSq0ENFZjpixJEl0jgRqa5Kx7cAA2BWEq4MJmK1noFi8WV3Fn iLh1ZqtWy7IZDm9tDoju5BQI8akBURa5sMAMPHlIP0Md9PfS+vRnDIz83NgH3UGzANGY 0EegyCt40nBHCs5iCNRdn5rNdsNYKIG2cIjOf7WJreMFiWOsi3DPD87V6zIr4FBZ4w94 oGeS3F8nTMKDqPhboQyqYndfGSov6UWTFxsVnNuJZF+JB0XWWT5pykrumAAL/Hr9hmrM gRtQ== 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=npyiH8gH2jaXEwnQp+f+J1rCZr0m4HBik2ndk5ENMFc=; b=hNZ4d41c6rjNDZR+2dAy8Oyxz02VG6K8ymB7Dg4fQ1vCRjQgjZSXzlTBtkQ3tPvTme Wmsz0GBXzJWOb8YlO0t6mZ1QENY7Kza7lZ3dOzhwi/SF+uLY4MmEFmN6YEuAN4lwWB9o RM4S0osZICnHFdmfUr0AR40yw4/5EmRxWOfSpKvohIP8cjb4fbmowNT35eOVV0Ji0Yv0 yjYOlDIsIMJgQa7B+/aVHsBP1+aZ0v/2Pzfpaz9gGgTmzqHV18Bco+hbvk7+O4F9ozSe bzCEfxha/aV8mnpbp5gI/q4ZC2bVsM5I7snjURdNCZPZKXLCF7wf46RJ2+qx6XxW0orb bs2Q== X-Gm-Message-State: AOPr4FXmu9qyXf7HO0lG97GGulWR1snCJV9g7UMRfFqxrSgu1XMSrpbOzCTj/gKWbHNywg== X-Received: by 10.98.41.70 with SMTP id p67mr2663316pfp.93.1462953171138; Wed, 11 May 2016 00:52:51 -0700 (PDT) Received: from [10.15.40.80] (mobile-166-176-186-225.mycingular.net. [166.176.186.225]) by smtp.gmail.com with ESMTPSA id h1sm9725993pfh.49.2016.05.11.00.52.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 00:52:50 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7147A4EE-3985-41D9-8B70-E97AEF2F95BF Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 11 May 2016 00:52:48 -0700 Content-Transfer-Encoding: 7bit Message-Id: <16FDAB1B-EEB6-48F0-98B7-A1554CED229B@gmail.com> References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> To: Eric Rescorla Archived-At: Cc: Richard Barnes , Luis Lopez , Emil Ivov , perc@ietf.org, Cullen Jennings Subject: Re: [Perc] Minutes from Design Team call #3 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, 11 May 2016 07:52:53 -0000 --Apple-Mail-7147A4EE-3985-41D9-8B70-E97AEF2F95BF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On May 10, 2016, at 10:47 PM, Eric Rescorla wrote: >=20 >> On Wed, May 11, 2016 at 1:04 AM, Bernard Aboba w= rote: >> I agree. Without SSRC rewriting PERC does not apply to any real world con= ferencing scenarios. >>=20 >> But since the proposed key management scheme has similar security propert= ies to SRTP/SDES, that might be just as well. >=20 > Hmm... Unless I've badly misanalyzed it, this is not correct. While the sc= heme does permit one side to dictate the keys, they are not available to > a passive signaling server. What have I misunderstood? [BA] The proposed hop by hop key sharing between the KMF and MDD is not more= secure than an SRTP/SDES exchange between the same parties, since in both c= ases a key that was formerly known only by 2 parties with DTLS/STTP is now p= ossessed by 3 parties instead.=20 This enables governments to request hop-by-hop keying material from endpoint= s, the KMF or MDD owners rather than merely from the endpoints and MDD, crea= ting more risk particularly when the KMF and MDD are located in different co= untries. Also, since the KMF possesses e2e keys both the KMF and endpoint ow= ners are now potential targets for key disclosure requests. While PERC is f= ocusing on media confidentiality, in surveillance scenarios meta-data disclo= sure is as valuable as decrypting media - and PERC could increase those risk= s. For small groups an e2e key exchange would be preferred so that e2e keys wer= e held only in endpoints which neither a KMF nor MDD could possess. It also= would be preferred for endpoint - MDD hop-by-hop keys to be known only by t= hose parties.=20= --Apple-Mail-7147A4EE-3985-41D9-8B70-E97AEF2F95BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On May 10, 2016, at 10:47 P= M, Eric Rescorla <ekr@rtfm.com> wr= ote:

On Wed, May 11, 2016 at 1:04 A= M, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I agree. Without SSRC rewriting PERC does not app= ly to any real world conferencing scenarios.

But since the proposed key management scheme has similar security properties= to SRTP/SDES, that might be just as well.

Hmm... Unless I've badly misanalyzed it, this is not correct. While the s= cheme does permit one side to dictate the keys, they are not available to
a passive signaling server. What have I misunderstood?

[BA] The proposed hop by hop key sharing between the K= MF and MDD is not more secure than an SRTP/SDES exchange between the same pa= rties, since in both cases a key that was formerly known only by 2 parties w= ith DTLS/STTP is now possessed by 3 parties instead. 

This enables governments to request hop-by-hop keying material from e= ndpoints, the KMF or MDD owners rather than merely from the endpoints and MD= D, creating more risk particularly when the KMF and MDD are located in diffe= rent countries. Also, since the KMF possesses e2e keys both the KMF and endp= oint owners are now potential targets for key disclosure requests.  Whi= le PERC is focusing on media confidentiality, in surveillance scenarios meta= -data disclosure is as valuable as decrypting media - and PERC could increas= e those risks.

For small groups an e2e key exchange= would be preferred so that e2e keys were held only in endpoints which neith= er a KMF nor MDD could possess.  It also would be preferred for endpoin= t - MDD hop-by-hop keys to be known only by those parties. 
= --Apple-Mail-7147A4EE-3985-41D9-8B70-E97AEF2F95BF-- From nobody Wed May 11 01:07:52 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 3C2F712D5DA for ; Wed, 11 May 2016 01:07:51 -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 0wW-Z_NluTSZ for ; Wed, 11 May 2016 01:07:49 -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 84D7A12B063 for ; Wed, 11 May 2016 01:07:49 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t10so40017206ywa.0 for ; Wed, 11 May 2016 01:07:49 -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=Fhx/L0kx7ITVDYeEcziXsqKnwISbEde4OxhGXJMltfc=; b=d5tCwpUmqLKjAyg1cuMYOA7idfC1ssrLbri/5JSdp/av31mM024j7qjcUpZesi5xTm NT6pdgcL39/tLLOSRlwPYWWZutk2Zg9tNjHn0RzHfgUZYqiO/DeNR45KoaY1orCTkVeU zUQcmOKtlEcKymOKwIWfhk+6ObWFi3+E+a+YEMU88R8xkQoxvc6EOnm/8pTTCwXgZDIF FtaEGpwl9nY2IbtIeqKllBOcu+4WQoOrzopeCYeXCmqCgs3ly9OrBAdwiy0tyj8tqLC/ OS3izIXc3Om2Am20uU4em21Z17a1Ag3z9t2PKjJqgz17dypsXTjK+rQL3skt4NX8DoHQ RLOw== 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=Fhx/L0kx7ITVDYeEcziXsqKnwISbEde4OxhGXJMltfc=; b=P+ZB8FzW2+Uprr9D3n8yc3MVcF+kIsoSPorymSU0SnEj7q6ykW0JVXW+mljqTefaKd ANAXGO6WyqLbcVbNDf45P7NsJXsZ7k8CNhWcnGFd3EMZWnaMm92IWA6ApNzdhG4Zc+cP x5ZjUJ6SaLWkmgdoTUXb2trJHJavlJsQiZgvPk/Y7Nd0fJEhGUyXgyB3SB2isjBbDoBk 01qejgGjemlXn+NeS7RGsO3wU4aIBpQoUVMty8npaBPX0Xx5OeEqjuNE43ml+44TdW6c wqHdES8BDkKsA0NdPETWrhntl3Dw7F7CK2AQv05+v+eKA8kxoTb5oTjmh3+k8TYut49M 9lww== X-Gm-Message-State: AOPr4FX3b8gxiuGo57LHxt7kYSYW4wBQ7oGDK9DjpxCJ7lB0XmlIzdxGxtcCX+4OQ8HwXLJJIziMmS9hglZNJQ== X-Received: by 10.129.51.140 with SMTP id z134mr797958ywz.322.1462954068725; Wed, 11 May 2016 01:07:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Wed, 11 May 2016 01:07:09 -0700 (PDT) In-Reply-To: <16FDAB1B-EEB6-48F0-98B7-A1554CED229B@gmail.com> References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> <16FDAB1B-EEB6-48F0-98B7-A1554CED229B@gmail.com> From: Eric Rescorla Date: Wed, 11 May 2016 10:07:09 +0200 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=001a1140746e96feba05328c89e2 Archived-At: Cc: Richard Barnes , Luis Lopez , Emil Ivov , perc@ietf.org, Cullen Jennings Subject: Re: [Perc] Minutes from Design Team call #3 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, 11 May 2016 08:07:51 -0000 --001a1140746e96feba05328c89e2 Content-Type: text/plain; charset=UTF-8 On Wed, May 11, 2016 at 9:52 AM, Bernard Aboba wrote: > On May 10, 2016, at 10:47 PM, Eric Rescorla wrote: > > On Wed, May 11, 2016 at 1:04 AM, Bernard Aboba > wrote: > >> I agree. Without SSRC rewriting PERC does not apply to any real world >> conferencing scenarios. >> >> But since the proposed key management scheme has similar security >> properties to SRTP/SDES, that might be just as well. >> > > Hmm... Unless I've badly misanalyzed it, this is not correct. While the > scheme does permit one side to dictate the keys, they are not available to > a passive signaling server. What have I misunderstood? > > > [BA] The proposed hop by hop key sharing between the KMF and MDD is not > more secure than an SRTP/SDES exchange between the same parties, since in > both cases a key that was formerly known only by 2 parties with DTLS/STTP > is now possessed by 3 parties instead. > But the hop-by-hop keys are not sufficient to recover the communications traffic. Only the end-to-end keys are sufficient for that. That's the point of the design. It's true that the KMF has the keys and that's one of the reasons why it's desirable to have one of the endpoints be the KMF. This enables governments to request hop-by-hop keying material from > endpoints, the KMF or MDD owners rather than merely from the endpoints and > MDD, creating more risk particularly when the KMF and MDD are located in > different countries. > But again, the hop-by-hop keys are not very useful For small groups an e2e key exchange would be preferred so that e2e keys > were held only in endpoints which neither a KMF nor MDD could possess. > Yes, I agree. Unfortunately, this is a much larger change to the protocols and endpoints. In any case, I don't think the security properties are comparable to SDES. -Ekr > It also would be preferred for endpoint - MDD hop-by-hop keys to be known > only by those parties. > --001a1140746e96feba05328c89e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, May 11, 2016 at 9:52 AM, Bernard Aboba <bernard.aboba@gm= ail.com> wrote:
On May 10, 2016, at 10:47 PM, Eric Rescorla &l= t;ekr@rtfm.com> wr= ote:

On Wed, May 11, 2016 at 1:04= AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I agree. Without SSRC rewriting PERC does n= ot apply to any real world conferencing scenarios.

But since the proposed key management scheme has similar security propertie= s to SRTP/SDES, that might be just as well.

=
Hmm... Unless I've badly misanalyzed it, this is not correct. Whil= e the scheme does permit one side to dictate the keys, they are not availab= le to
a passive signaling server. What have I misunderstood?

[BA] The proposed hop by hop key sharing betwe= en the KMF and MDD is not more secure than an SRTP/SDES exchange between th= e same parties, since in both cases a key that was formerly known only by 2= parties with DTLS/STTP is now possessed by 3 parties instead.=C2=A0
<= /div>

But the hop-by-hop keys are not suffi= cient to recover the communications traffic. Only the end-to-end keys are s= ufficient for that. That's the point of the design. It's true that = the KMF has the keys and that's one of the reasons why it's desirab= le to have one of the endpoints be the KMF.


This enables gove= rnments to request hop-by-hop keying material from endpoints, the KMF or MD= D owners rather than merely from the endpoints and MDD, creating more risk = particularly when the KMF and MDD are located in different countries.
=

But again, the hop-by-hop keys are n= ot very useful


For small groups an e2e key exchange would be = preferred so that e2e keys were held only in endpoints which neither a KMF = nor MDD could possess.

Yes, I = agree. Unfortunately, this is a much larger change to the protocols and end= points.

In any case, I don't think the securit= y properties are comparable to SDES.

-Ekr
=C2=A0
=C2=A0I= t also would be preferred for endpoint - MDD hop-by-hop keys to be known on= ly by those parties.=C2=A0

--001a1140746e96feba05328c89e2-- From nobody Wed May 11 02:08:57 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 D78BD12D62D for ; Wed, 11 May 2016 02:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 ggtTB0wH9Ieh for ; Wed, 11 May 2016 02:08:54 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 E2C8512D57C for ; Wed, 11 May 2016 02:08:53 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id g133so36604144ywb.2 for ; Wed, 11 May 2016 02:08:53 -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:date:message-id:subject:from:to :cc; bh=NxrzuKbiQbEXVn8I81NpiIkDqVqVaAUqYQp5oNBOm/A=; b=Vmj+M3qRjXWTGeS47C/3ekdub13n3+WvgtQ9rg9LIbr6Zgeli+34Nlq3/zf3lV0BoY uEYgY/oYvNu+lT+0gu3u8aB9TDamUICMziPsvR0Ympimvg1OriChC2USu0qq9ewrirou 6V3no9xAnKFLxLzQeyWzY12qPAgO/2nBOK9qQrls3pMY9oCLNkjeiM3j2H4UO/7g06WL f3HOns9KYwiA5I8BlVMAcC43euZq5UXAmSJFgwRtyWSWyfqzLJJPH038Ac+kIGC2ddD4 Ea8oZ2DsCM4d39MPqX4BOf2UUv93cxndPpF4dtHWp4G5j9AwB8IZ9WptjX7VhjmL29il Ocsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NxrzuKbiQbEXVn8I81NpiIkDqVqVaAUqYQp5oNBOm/A=; b=B8R3V5OReWZC24tjRQYrx51xz+hL3n9nLtAfFnOf4EfqwT0avJczZ/4DhF1c71gcIP C0jCIdIHkhartjlIWT7ZQ9VCDezD4NgUg6Xd116xA0ttqK5NYZnuZu0TgBa2OMRdzkQv YRYllQJ3IuWaLHR0WFhYNuIuLpAaCeAaBEHRx+yoJFdoWYUfjPqlXRIAzf1OVqjUbARU KmBd9JBxE9HK+OS4EMr/K2BymwDXOtsrZexOMQpcDYnKnfyvqNwkodDf+b1v9n99pJrM 4Ojit8m55KkIrLZ7HPJa/Mrd5t3hHG3cFZusZT0DdM0HkUMM0o9sraA7tTqHb+lwul5O zG/w== X-Gm-Message-State: AOPr4FVwfP/6GZkpw7SvG22dERMNv/Z0aCB7/x+r2cd39LPd2YhqJpzy08YmfiRo4c2HEw== X-Received: by 10.129.4.216 with SMTP id 207mr1061956ywe.184.1462957729872; Wed, 11 May 2016 02:08:49 -0700 (PDT) Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com. [209.85.161.169]) by smtp.gmail.com with ESMTPSA id d68sm3626190ywe.53.2016.05.11.02.08.49 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 02:08:49 -0700 (PDT) Received: by mail-yw0-f169.google.com with SMTP id t10so41246431ywa.0 for ; Wed, 11 May 2016 02:08:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.251.4 with SMTP id l4mr1010440ywf.265.1462957728919; Wed, 11 May 2016 02:08:48 -0700 (PDT) Received: by 10.83.6.138 with HTTP; Wed, 11 May 2016 02:08:48 -0700 (PDT) In-Reply-To: References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> Date: Wed, 11 May 2016 04:08:48 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=94eb2c07e55cc1287b05328d631f Archived-At: Cc: "perc@ietf.org" , Cullen Jennings 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, 11 May 2016 09:08:56 -0000 --94eb2c07e55cc1287b05328d631f Content-Type: text/plain; charset=UTF-8 On Wednesday, 11 May 2016, Paul E. Jones wrote. > > > MDD - change to "Media Switch" or "Switch". >> > > Switching Conference Server is the original term we used, I think. I have > no strong preference on this one. Why is it again that we are not using SFU here? Emil -- sent from my mobile --94eb2c07e55cc1287b05328d631f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, 11 May 2016, Paul E. Jones <paulej@packetizer.com> wrote.
MDD - change to "Media Switch" or "Switch".

Switching Conference Server is the original term we used, I think. I have n= o strong preference on this one.

Why is it = again that we are not using SFU here?=C2=A0

Emil

--
sent from my mobile
--94eb2c07e55cc1287b05328d631f-- From nobody Wed May 11 09:24:11 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 B0B9912B02C for ; Wed, 11 May 2016 09:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no 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 1sFZFtR6AZlz for ; Wed, 11 May 2016 09:24:09 -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 72CC612D1D2 for ; Wed, 11 May 2016 09:24:09 -0700 (PDT) Received: from [IPv6:2607:fb90:405c:35f8:0:f:4aae:f701] ([172.58.169.197]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4BGO6Ww002286 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2016 12:24:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1462983848; bh=DPGlPLxFaiDfcb6nxOBdTZs39lCzk9SD0IR8WAT16N0=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=r2ZBSNEBHvRC9yHf67mttR/TLniyaUQuvRQCawX/AB4D8gFdjwmKeOq24Ar1c5qGT VNLKAMYZqzxJarg86mH2pDe9nGU76+2ai9W77N82b7qLK/RL7zJAr9MoovYlOrnQcs vNFvtISZVD119sVDSAhQFpmOQu/xpDUUVMi+xpWI= User-Agent: K-9 Mail for Android In-Reply-To: References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----6FWEH05UOM9FNRJOOZR958YPQ6UMB7" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Wed, 11 May 2016 12:24:09 -0400 To: Emil Ivov Message-ID: <86ECB699-B5DB-40F4-832F-1F39CC2EF291@packetizer.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 11 May 2016 12:24:08 -0400 (EDT) Archived-At: Cc: "perc@ietf.org" , Cullen Jennings 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, 11 May 2016 16:24:10 -0000 ------6FWEH05UOM9FNRJOOZR958YPQ6UMB7 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 The topologies draft moved away from SFU to SFM. Still, not sure it perfectly represents what were doing with PERC, because we are introducing a two-step process where a security association exists HBH and E2E. We had some dialog before that we might need to define a new topological function or amend a current definition. I don't think we're at the point where we can do that, yet. Paul -------- Original Message -------- From: Emil Ivov Sent: May 11, 2016 5:08:48 AM EDT To: "Paul E. Jones" Cc: Cullen Jennings , "perc@ietf.org" Subject: Re: [Perc] Names, Names, Names On Wednesday, 11 May 2016, Paul E. Jones wrote. > > > MDD - change to "Media Switch" or "Switch". >> > > Switching Conference Server is the original term we used, I think. I have > no strong preference on this one. Why is it again that we are not using SFU here? Emil -- sent from my mobile ------6FWEH05UOM9FNRJOOZR958YPQ6UMB7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The topologies draft moved away from SFU to SFM. Still, not sure it perfectly represents what were doing with PERC, because we are introducing a two-step process where a security association exists HBH and E2E.

We had some dialog before that we might need to define a new topological function or amend a current definition. I don't think we're at the point where we can do that, yet.

Paul

From: Emil Ivov <emcho@jitsi.org>
Sent: May 11, 2016 5:08:48 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Cullen Jennings <fluffy@iii.ca>, "perc@ietf.org" <perc@ietf.org>
Subject: Re: [Perc] Names, Names, Names



On Wednesday, 11 May 2016, Paul E. Jones <paulej@packetizer.com> wrote.

MDD - change to "Media Switch" or "Switch".

Switching Conference Server is the original term we used, I think. I have no strong preference on this one.

Why is it again that we are not using SFU here? 

Emil

------6FWEH05UOM9FNRJOOZR958YPQ6UMB7-- From nobody Wed May 11 13:45: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 90E1412D7BD for ; Wed, 11 May 2016 13:45:44 -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 ITuB0cSWVvVJ for ; Wed, 11 May 2016 13:45:43 -0700 (PDT) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF08E12D53F for ; Wed, 11 May 2016 13:45:42 -0700 (PDT) Received: from smtp29.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp29.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D93463805DA; Wed, 11 May 2016 16:45:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 58E2C380456; Wed, 11 May 2016 16:45:39 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Wed, 11 May 2016 16:45:39 -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: Date: Wed, 11 May 2016 14:45:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> To: Emil Ivov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Paul Jones , "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, 11 May 2016 20:45:44 -0000 > 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 >=20 > Emil >=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? From nobody Wed May 11 13:50:11 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 0AA6C12D5C4 for ; Wed, 11 May 2016 13:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.89 X-Spam-Level: X-Spam-Status: No, score=-101.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01, USER_IN_WHITELIST=-100] 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 KDqjItj6Xtjv for ; Wed, 11 May 2016 13:50:09 -0700 (PDT) Received: from mail.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D132012D514 for ; Wed, 11 May 2016 13:50:09 -0700 (PDT) Received: from localhost (ronin.smetech.net [209.135.209.5]) by mail.smetech.net (Postfix) with ESMTP id 9B842F2401F; Wed, 11 May 2016 16:50:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from mail.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id HPX6hJiPPu6X; Wed, 11 May 2016 16:33:20 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.smetech.net (Postfix) with ESMTP id 3F575F24013; Wed, 11 May 2016 16:50:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> Date: Wed, 11 May 2016 16:50:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.1878.6) 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, 11 May 2016 20:50:11 -0000 > 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 From nobody Wed May 11 13:50:56 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 C134C12D5C4 for ; Wed, 11 May 2016 13:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 liMzYfeJ1Hrh for ; Wed, 11 May 2016 13:50:52 -0700 (PDT) Received: from smtp133.dfw.emailsrvr.com (smtp133.dfw.emailsrvr.com [67.192.241.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8AC112D50B for ; Wed, 11 May 2016 13:50:52 -0700 (PDT) Received: from smtp29.relay.dfw1a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp29.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id F328A180CF1; Wed, 11 May 2016 16:50:51 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp29.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A8E51180CAB; Wed, 11 May 2016 16:50:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Wed, 11 May 2016 16:50:51 -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: Date: Wed, 11 May 2016 14:50:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Jones 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: Wed, 11 May 2016 20:50:54 -0000 > On May 10, 2016, at 11:07 PM, Paul E. Jones = wrote: >=20 > Cullen, >=20 >> inner and outer - people are never sure which is inner and which is = outer. I'd propose just using hop-by-hop and end-to-end > Agreed. >=20 >=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 >> KMF - change to "Key Server" or "Key Manger" >=20 > I avoided the word "Key Server" to make it clear it's not just a = "server", but a functional element within the system. The term "key = manager" might be better given this function might be inside a browser. +1=20 >=20 >> I'd like to move away from acronyms as much as possible - they just = add confusion. >=20 > Oh, I won't argue with this one at all. >=20 >> Now that the OHB has become just a PT or Seq# change or both, it = might be good to think about simpler way of describing this. >=20 > We can review that text, but OHB doesn't suggest a complex structure. = It could be the "original header field value extension" (avoiding = acronyms). >=20 >> EKT Field - use this to describe the place that any type of EKT = message get carried >>=20 >> Long EKT Field - change to Encrypted Key message. This message simply = caries the encrypted form of the SRTP Master Key and calling it EKT Long = Field in a protocol called EKT that is negotiated in TLS by including = ekt in the handshake is not very enlightening. >>=20 >> Short EKT Field - change to Empty message. This message caries = nothing and simply is there to indicate that no other EKT message is = attached to this packet. >=20 > I think changing this to "encrypted" and "empty" are confusing. = Previously, this thing was called the "EKT Tag". The current terms are = "Full EKT Field" or "Short EKT Field". If that's too confusing, perhaps = we just try to find a way to drop the full/short delineation, just call = it the EKT Tag/Field? Personally, I like the short/full description = since there is concrete syntax that goes with it. The alternatives you = suggest make it sound like different messages (versus field elements). OK ... back to the drawing boards on this..=20 We need something that helps capture what the purpose and content is of = the full message so when you see it on a call flow, it inspires the = right thought.=20 DItto for short We need something that describes the whole set of things so both the = short and long are instances of this thing.=20 =20 >=20 > Paul >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Wed May 11 13:56:30 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 16F7512D5F4 for ; Wed, 11 May 2016 13:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 HaV6Uyb73yuw for ; Wed, 11 May 2016 13:56:28 -0700 (PDT) Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9733712D5EA for ; Wed, 11 May 2016 13:56:28 -0700 (PDT) Received: from smtp4.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B8D9F2803E4; Wed, 11 May 2016 16:56:25 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id EBEF72804F2; Wed, 11 May 2016 16:56:24 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Wed, 11 May 2016 16:56:25 -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: Date: Wed, 11 May 2016 14:56:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , LuLop , Emil Ivov , perc@ietf.org Subject: Re: [Perc] Minutes from Design Team call #3 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, 11 May 2016 20:56:30 -0000 > On May 10, 2016, at 5:04 PM, Bernard Aboba = wrote: >=20 > I agree. Without SSRC rewriting PERC does not apply to any real world = conferencing scenarios.=20 Could you please provide details of exactly what you mean here? From nobody Wed May 11 15:01: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 A592D12D753 for ; Wed, 11 May 2016 15:01:44 -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 iSb2_pySY9xo for ; Wed, 11 May 2016 15:01:42 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 4D5CE12D5AC for ; Wed, 11 May 2016 15:01:42 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id j74so56407108ywg.1 for ; Wed, 11 May 2016 15:01:42 -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; bh=xhzgNLPxw8+koIcfCC5wasCFI7SucQQqc+oVvoyYFiA=; b=DZw+rTYhpJUIppvsI2Ixuy8ReiJagieShu+uUPC1ITUfKISOwGGyqs4Wz1rWcEXkm1 jP/fDix/zUaP2jopYQKYStpTLYqQcSn+sBzW5DjoaVUjygkDzjFf9FO4IG0xbG1OVcRd uT3EyRHOvlX+aCYhETSsUJsyfDaLkxvOC4NUlcg/137IcLZ8cKZtVHdEsIK9VMunnIQd /3QzjyAAuQJd57iMGiLoxBEra6Sf3q/WDCyik4liuRZ4oWW9KFpLGpBx1dWVPmNYfIKJ jnCGn5F9fPO/7fwF84wm9WQ4Eu6AUWg9yXcG9V3NX/Qx//jhS560a/ZuW9Og8vJq80It odNg== 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=xhzgNLPxw8+koIcfCC5wasCFI7SucQQqc+oVvoyYFiA=; b=kLBlzIAqSTpU1/yMoEEZtoD+pkMLjytf9p4iZ5qeTgjYZNKdTvjZccvu3SDsvXeq/K oc8Vup7ESKFPlPUHVaTrao8WtB0Qt0jNJLSU4c7oeSUOD+jJolMWh9oP8ZrLR5qiPqIz athT0EZ0Z27aRF12VWAdDL62P1uMdM1wlx10s533hYfS5Uoa0CPQgkkJ0Dt0JJZUkcd+ xSx3AXfAQgLYcnKatBweqq/SHkKiB/bJAvPwzVri+gNNb3Of+vRCeBtZhDgpa8Io+n8X RW4H/LWfZyQyr2o84zi0X+6XFABFiCb8Zk+AXhzEqkJml4XYlB9BqOofFgxgclXuqQfz l+nQ== X-Gm-Message-State: AOPr4FV4tqHyIAKhMozVo+4J1Y03yVD6Xa9QRcCmjmRUAxVJr2YvHJcVuDRzkNyGcDtiNg== X-Received: by 10.129.96.214 with SMTP id u205mr2821553ywb.14.1463004101540; Wed, 11 May 2016 15:01:41 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com. [209.85.161.173]) by smtp.gmail.com with ESMTPSA id v124sm5444625ywb.13.2016.05.11.15.01.40 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 15:01:41 -0700 (PDT) Received: by mail-yw0-f173.google.com with SMTP id j74so56406692ywg.1 for ; Wed, 11 May 2016 15:01:40 -0700 (PDT) X-Received: by 10.13.237.1 with SMTP id w1mr2819448ywe.62.1463004100604; Wed, 11 May 2016 15:01:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.6.138 with HTTP; Wed, 11 May 2016 15:01:21 -0700 (PDT) In-Reply-To: References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> From: Emil Ivov Date: Wed, 11 May 2016 17:01:21 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 11 May 2016 22:01:45 -0000 On Wed, May 11, 2016 at 3:56 PM, Cullen Jennings wrote: > >> On May 10, 2016, at 5:04 PM, Bernard Aboba wrote: >> >> I agree. Without SSRC rewriting PERC does not apply to any real world conferencing scenarios. > > Could you please provide details of exactly what you mean here? I saw a bunch of exact scenarios mentioned here. Things like simulcast and active speaker switching for example have numerous popular implementations through SSRC rewriting. Those include implementations from Kurento, Google, Microsoft, Janus, Jitsi and likely many others. Unless we are explicitly trying to sabotage PERC adoption by all of those, I cannot for the life of me understand why we are so stuck on forbidding rewriting SSRCs. I never saw a satisfactory answer on the subject. The answers that I heard were basically: A) Because otherwise that scr*ws up authentication because we cannot keep track of the overwrites across RTP and RTCP: obviously this is not true as we could simply not use SSRCs for PERC-specific purposes and define PERC specific IDs and B) You are not correct and I, who have never implemented an SFU in my life, am telling you that you can reimplement your SFU to not rely on SSRC rewriting and it will be a piece of cake. I hope I don't have to comment on B. As an IETF WG, PERC's behaviour on this topic has been very confusing to me and I am almost at the point where willful disruption is the only possible explanation that I can find. If we do proceed to ignore implementers the same way we are going to find ourselves debating the same concerns in IETF last call where reason would have a better chance of prevailing. E2E encryption is too important of a subject for us to botch this work. Emil -- https://jitsi.org From nobody Wed May 11 15:19:13 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 1323312D753 for ; Wed, 11 May 2016 15:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 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, T_FILL_THIS_FORM_SHORT=0.01] 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 KW-w1GWjlAq6 for ; Wed, 11 May 2016 15:19:09 -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 A156B12D593 for ; Wed, 11 May 2016 15:19:09 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g133so56803519ywb.2 for ; Wed, 11 May 2016 15:19:09 -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=6yaDSCZVFmFzhjMWuBcQHq4IZG9aHdLVGGLPuW4sCjE=; b=e0dIt1fnU8DFfPaZ0kNyFunaNt7pRhIVHkwfy3joV5PMEMEFPZmURnoWMByMv7nAJe 7ouhT4rhBkmBJmtnkWvPcYEP+jxiB5pcuUS+4L1xLh6oam0m0VSUCPRyCj9l5XY5WnDK n0Aux4oMMBPxNB4Dw7FMrCme76QlchaBDAB0ts+j8CwhOPJRBi8e5E9xpco1esd1/1bk c2V3eBr/4mbKHfqy0lcAl8VGHz9b8zLYvG60lU2ib7yWIg7ngnAnMqRvm/SX1ljh5r+a wBYLaZJsRGS/6bcRdpkBS9ETIH0lDF04R4UxUzcklIASZBX4DCd9aEMgvvFKtx8zVYhs IG9A== 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=6yaDSCZVFmFzhjMWuBcQHq4IZG9aHdLVGGLPuW4sCjE=; b=DC6SK42YywQT3ALqO3detVIvqMfjKhXF2R9s7Kh6fJ15emekKfKRSuilZ4qHNZGmik Eff3CARys6ggwoYzCmk/LBkMY2HRu9yXNDjaUq7B03Fy9XcV8CToDoH0JW0l7AAQqN9O RKeC13AWLOy8a3M+DG5vD7CRqm6kCe3gmh8FqxvnOztj9l/Li7efaw+OIBGXaHArDEWr CiHhnTOAVc5/Bo0UsFKAzmYeAXGWmhn36bNBGbz7EiQMg5hxcnHzznTfQHQVTa6+cufH pxBZGs0JG7wgzIWjBAsA9c0KLpf53GklIVV/Jk2n+q8x0D2BT9knI4OA6ealPTAK64WI FVAA== X-Gm-Message-State: AOPr4FVChEmUjb6ooIyGmsND7ALfJSStCQx+67NfMU/wizXD7liiNQdGmVupOfokiF7eEA== X-Received: by 10.13.215.75 with SMTP id z72mr3216332ywd.278.1463005148974; Wed, 11 May 2016 15:19:08 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com. [209.85.161.182]) by smtp.gmail.com with ESMTPSA id z20sm5476486ywd.44.2016.05.11.15.19.08 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 15:19:08 -0700 (PDT) Received: by mail-yw0-f182.google.com with SMTP id j74so56762847ywg.1 for ; Wed, 11 May 2016 15:19:08 -0700 (PDT) X-Received: by 10.129.121.81 with SMTP id u78mr2869858ywc.239.1463005148161; Wed, 11 May 2016 15:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.6.138 with HTTP; Wed, 11 May 2016 15:18:48 -0700 (PDT) In-Reply-To: References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> From: Emil Ivov Date: Wed, 11 May 2016 17:18:48 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Paul Jones , "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, 11 May 2016 22:19:12 -0000 On Wed, May 11, 2016 at 3:45 PM, Cullen Jennings wrote: > >> On May 11, 2016, at 3:08 AM, Emil Ivov wrote: >> >> >> >> On Wednesday, 11 May 2016, Paul E. Jones wrote. >> >> MDD - change to "Media Switch" or "Switch". >> >> Switching Conference Server is the original term we used, I think. I hav= e no strong preference on this one. >> >> Why is it again that we are not using SFU here? >> >> Emil >> > > Some people felt the "Forward" part implied an architecture where it only= forwarded without modifying. PERC supports that arch but also supports som= e 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 o= f Media Switch but there are other types that both forward and modify. Work= for you? 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. 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." 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 ;) Emil --=20 https://jitsi.org From nobody Wed May 11 15:20: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 CC73D12D593 for ; Wed, 11 May 2016 15:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 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=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 oNQ17MoJ5pOe for ; Wed, 11 May 2016 15:20:18 -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 2FAC312D521 for ; Wed, 11 May 2016 15:20:18 -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 u4BMKGPi024058 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2016 18:20:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463005217; bh=m/kb9xLv2+q1lRViS8/qa9R+8bvlG4ibCvPidoRWU20=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=dJIY0yCftY/8Gvn9poRLNA23o/5CWf6dghOyDzBqWE6k2eLcY6hv9b3p/b+mXLC9J 5LTg2bRQqW9EpLW/7w/zdaqSExIQCf+mXc1aea+4Qgmi78+oweX7AOScIESVmHzfaz Tuf1Svu8Z+zZXg5dChU5gMDhk6V3LlQoFhBmywzc= From: "Paul E. Jones" To: "Cullen Jennings" Date: Wed, 11 May 2016 22:20:27 +0000 Message-Id: In-Reply-To: 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.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 11 May 2016 18:20:17 -0400 (EDT) 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 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, 11 May 2016 22:20:20 -0000 Cullen, >>> EKT Field - use this to describe the place that any type of EKT=20 >>>message get carried >>> >>> Long EKT Field - change to Encrypted Key message. This message=20 >>>simply caries the encrypted form of the SRTP Master Key and calling=20 >>>it EKT Long Field in a protocol called EKT that is negotiated in TLS=20 >>>by including ekt in the handshake is not very enlightening. >>> >>> Short EKT Field - change to Empty message. This message caries=20 >>>nothing and simply is there to indicate that no other EKT message is=20 >>>attached to this packet. >> >> I think changing this to "encrypted" and "empty" are confusing. =20 >>Previously, this thing was called the "EKT Tag". The current terms=20 >>are "Full EKT Field" or "Short EKT Field". If that's too confusing,=20 >>perhaps we just try to find a way to drop the full/short delineation,=20 >>just call it the EKT Tag/Field? Personally, I like the short/full=20 >>description since there is concrete syntax that goes with it. The=20 >>alternatives you suggest make it sound like different messages (versus= =20 >>field elements). > >OK ... back to the drawing boards on this.. > >We need something that helps capture what the purpose and content is of= =20 >the full message so when you see it on a call flow, it inspires the=20 >right thought. > >DItto for short > >We need something that describes the whole set of things so both the=20 >short and long are instances of this thing. Can we just get by with calling it an "EKT Tag" (former name for this)? = =20 What's inside the tag varies, but it's still just the "tag". "EKT=20 Field" works, too. I have no preference, really. Is your goal to get down to one name here? Paul From nobody Wed May 11 16:12:29 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 D441D12D706 for ; Wed, 11 May 2016 16:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, 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 Y0tEA-HOKsHw for ; Wed, 11 May 2016 16:12: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 E0B9B12D141 for ; Wed, 11 May 2016 16:12:25 -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 u4BNCMKY026805 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2016 19:12:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463008343; bh=shEYc9VV4lgNWy0sYO6Q6HJ8898e700L/sMFS24HUKE=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=MHkyyNKhsLLfIBBE+XWTQNfY3z0vRG3xvlp3KFek9+6VYU48kekSf53q1kCT27oWz mJ5kdnjZvJ6/ANSfPW03PYAJ13PBVCcByqHvxpv0GM/Q3ZaYkSGUEH4CqQXLvkPiU4 i9nS8RYtH8FsTdpVnFzb54q56bv+ShkofABMKpbY= From: "Paul E. Jones" To: "Emil Ivov" , "Cullen Jennings" Date: Wed, 11 May 2016 23:12:33 +0000 Message-Id: In-Reply-To: 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.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 11 May 2016 19:12:23 -0400 (EDT) Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 11 May 2016 23:12:28 -0000 Emil, >A) Because otherwise that scr*ws up authentication because we cannot >keep track of the overwrites across RTP and RTCP: obviously this is >not true as we could simply not use SSRCs for PERC-specific purposes >and define PERC specific IDs I'm not following that one. RTCP is HBH, so not an issue. Why would we= =20 need a PERC-specific ID? I assume this is as an alternative to the SSRC= =20 in the cryptographic context? We would not need that given "double"=20 defined a field that could record the original E2E SSRC value. (Yes=20 that is now removed, but see below.) >B) You are not correct and I, who have never implemented an SFU in my >life, am telling you that you can reimplement your SFU to not rely on >SSRC rewriting and it will be a piece of cake. I hope I don't have to >comment on B. It is indeed a fact that you can write a switching function that does=20 not require changing SSRCs. >As an IETF WG, PERC's behaviour on this topic has been very confusing >to me and I am almost at the point where willful disruption is the >only possible explanation that I can find. If we do proceed to ignore >implementers the same way we are going to find ourselves debating the >same concerns in IETF last call where reason would have a better >chance of prevailing. I think the issue is this: you've not attended the meetings. We had=20 accommodated the option to change nearly everything in the RTP header=20 via the OHB in "double". During a recent meeting, it was decided to=20 limit the scope of what can be changed. We made the original "double"=20 proposal to allow for anything to be changed=20 (https://tools.ietf.org/html/draft-jennings-perc-double-00) and=20 participants in the meeting said to reduce the possible set down to PT=20 and sequence number, so we produced=20 https://tools.ietf.org/html/draft-jennings-perc-double-01 accordingly. =20 This change was proposed in a conference call, if I recall, and then=20 discussed face-to-face before the document moved forward to WG adoption. I do not recall any person on a phone call or in the meeting room who=20 opposed the changes. It came as a pleasant surprise to the authors that= =20 everyone was agreeable to such a narrow set of fields that could be=20 changed. Can we support changing SSRCs? Yes, we can put it back in. We will=20 need to change the way we have the OHB encoded, but it's certainly=20 possible. >E2E encryption is too important of a subject for us to botch this work. I can only encourage you to participate in meetings when they're called=20 and to comment on drafts as they're published. Heck, even if you cannot= =20 make a face-to-face meeting, the -01 draft has been out there since=20 March 21 and nobody commented on that change until this week. Paul From nobody Wed May 11 18:39:34 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 6CE7712D842 for ; Wed, 11 May 2016 18:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 GvjIJ_xLJpaT for ; Wed, 11 May 2016 18:39:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF77212D1A5 for ; Wed, 11 May 2016 18:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1463017169; x=1464226769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5ixCNGv8TXz00KNbxlimDj2sxO6GkisQrgEXZiyQpA0=; b=dvIJLOmgz4YIKQobh9u3oT/lcBvxtmm29Pf29qbJe+whL2o5xSOBOMAa rd4bQv/ewtPNSsxe2cZJKd+dPcRyJisF0NtOpvywtCDaDyeStpbf1uwwr SZyC4rzOYDWAqktgDOC31yITSdKVIbQ3AqVdDt52QHLuxc6Dk3CSf7TPY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUBQAV3jNX/5tdJa1egziBUgatW4tzg?= =?us-ascii?q?XaGFAIcgSE5EwEBAQEBAQFlJ4RDAQEEIxE0ERACAQgaAiYCAgIfERUQAgQOBQi?= =?us-ascii?q?IDQMWAal1jEwNhCMBAQEBAQEBAQEBAQEBAQEBAQEBARZ8hSSETIJDgWaDFoJZB?= =?us-ascii?q?Zd2MQGMJIFyjyCHXIdkASIBP4NrbocyAX4BAQE?= Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2016 01:39:29 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4C1dTu9023985 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2016 01:39:29 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 20:39:28 -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.1104.009; Wed, 11 May 2016 20:39:28 -0500 From: "David Benham (dbenham)" To: Bernard Aboba Thread-Topic: [Perc] Minutes from Design Team call #3 Thread-Index: AQHRq6GVc3E/ci+aw0KccCg3Qv8K/p+0azMQ Date: Thu, 12 May 2016 01:39:28 +0000 Message-ID: <4726a7fba3354b8d80728575674dd54d@XCH-RCD-020.cisco.com> References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> <16FDAB1B-EEB6-48F0-98B7-A1554CED229B@gmail.com> In-Reply-To: <16FDAB1B-EEB6-48F0-98B7-A1554CED229B@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: [171.68.20.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Eric Rescorla , "perc@ietf.org" Subject: Re: [Perc] Minutes from Design Team call #3 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, 12 May 2016 01:39:31 -0000 T24gV2VkLCBNYXkgMTEsIDIwMTYgYXQgMTowNCBBTSwgQmVybmFyZCBBYm9iYSA8YmVybmFyZC5h Ym9iYUBnbWFpbC5jb20+IHdyb3RlOg0KQnV0IHNpbmNlIHRoZSBwcm9wb3NlZCBrZXkgbWFuYWdl bWVudCBzY2hlbWUgaGFzIHNpbWlsYXIgc2VjdXJpdHkgcHJvcGVydGllcyB0byBTUlRQL1NERVMs IHRoYXQgbWlnaHQgYmUganVzdCBhcyB3ZWxsLg0KDQpIbW0uLi4gVW5sZXNzIEkndmUgYmFkbHkg bWlzYW5hbHl6ZWQgaXQsIHRoaXMgaXMgbm90IGNvcnJlY3QuIFdoaWxlIHRoZSBzY2hlbWUgZG9l cyBwZXJtaXQgb25lIHNpZGUgdG8gZGljdGF0ZSB0aGUga2V5cywgdGhleSBhcmUgbm90IGF2YWls YWJsZSB0bw0KYSBwYXNzaXZlIHNpZ25hbGluZyBzZXJ2ZXIuIFdoYXQgaGF2ZSBJIG1pc3VuZGVy c3Rvb2Q/DQoNCltCQV0gVGhlIHByb3Bvc2VkIGhvcCBieSBob3Aga2V5IHNoYXJpbmcgYmV0d2Vl biB0aGUgS01GIGFuZCBNREQgaXMgbm90IG1vcmUgc2VjdXJlIHRoYW4gYW4gU1JUUC9TREVTIGV4 Y2hhbmdlIGJldHdlZW4gdGhlIHNhbWUgcGFydGllcywgc2luY2UgaW4gYm90aCBjYXNlcyBhIGtl eSB0aGF0IHdhcyBmb3JtZXJseSBrbm93biBvbmx5IGJ5IDIgcGFydGllcyB3aXRoIERUTFMvU1RU UCBpcyBub3cgcG9zc2Vzc2VkIGJ5IDMgcGFydGllcyBpbnN0ZWFkLsKgDQoNClRoaXMgZW5hYmxl cyBnb3Zlcm5tZW50cyB0byByZXF1ZXN0IGhvcC1ieS1ob3Aga2V5aW5nIG1hdGVyaWFsIGZyb20g ZW5kcG9pbnRzLCB0aGUgS01GIG9yIE1ERCBvd25lcnMgcmF0aGVyIHRoYW4gbWVyZWx5IGZyb20g dGhlIGVuZHBvaW50cyBhbmQgTURELCBjcmVhdGluZyBtb3JlIHJpc2sgcGFydGljdWxhcmx5IHdo ZW4gdGhlIEtNRiBhbmQgTUREIGFyZSBsb2NhdGVkIGluIGRpZmZlcmVudCBjb3VudHJpZXMuIEFs c28sIHNpbmNlIHRoZSBLTUYgcG9zc2Vzc2VzIGUyZSBrZXlzIGJvdGggdGhlIEtNRiBhbmQgZW5k cG9pbnQgb3duZXJzIGFyZSBub3cgcG90ZW50aWFsIHRhcmdldHMgZm9yIGtleSBkaXNjbG9zdXJl IHJlcXVlc3RzLiDCoFdoaWxlIFBFUkMgaXMgZm9jdXNpbmcgb24gbWVkaWEgY29uZmlkZW50aWFs aXR5LCBpbiBzdXJ2ZWlsbGFuY2Ugc2NlbmFyaW9zIG1ldGEtZGF0YSBkaXNjbG9zdXJlIGlzIGFz IHZhbHVhYmxlIGFzIGRlY3J5cHRpbmcgbWVkaWEgLSBhbmQgUEVSQyBjb3VsZCBpbmNyZWFzZSB0 aG9zZSByaXNrcy4NCg0KW2RiZW5oYW0+XSAgIElmIGEgR292IGNhbiBzdWNjZXNzZnVsbHkgY29t cGVsIGFuIG9yZyB3aXRoIGFjY2VzcyB0byBLTUYgdG8gY291Z2ggdXAga2V5IGluZm8sIHRoYXQg R292IGNhbiBhbHNvIGNvbXBlbCB0aGF0IG9yZyB0byBlbnRpdGxlIHRoZSBHb3YncyByZWNvcmRp bmcgZGV2aWNlcyB0byBiZSB2YWxpZCBlbmRwb2ludHMgaW4gYW55IG9mIHRoYXQgb3JnJ3MgY29u ZmVyZW5jZXMuICBUaHVzIHRoYXQgR292IGNhbiBsaXN0ZW4gaW4gdG8gYW55IGNvbmZlcmVuY2Ug cmVnYXJkbGVzcyBvZiB3aGljaCBlbnRpdHkgaXMgaGFuZGluZyBvdXQgSEJIIGluZm8uICANCg0K DQpGb3Igc21hbGwgZ3JvdXBzIGFuIGUyZSBrZXkgZXhjaGFuZ2Ugd291bGQgYmUgcHJlZmVycmVk IHNvIHRoYXQgZTJlIGtleXMgd2VyZSBoZWxkIG9ubHkgaW4gZW5kcG9pbnRzIHdoaWNoIG5laXRo ZXIgYSBLTUYgbm9yIE1ERCBjb3VsZCBwb3NzZXNzLiDCoEl0IGFsc28gd291bGQgYmUgcHJlZmVy cmVkIGZvciBlbmRwb2ludCAtIE1ERCBob3AtYnktaG9wIGtleXMgdG8gYmUga25vd24gb25seSBi eSB0aG9zZSBwYXJ0aWVzLsKgDQoNCltkYmVuaGFtPl0gICBUaGlzIGlzIGFscmVhZHkgdHJ1ZSB3 aXRoIHdoYXQgaXMgcHJvcG9zZWQgaW4gdGhlIGRyYWZ0cy4gIFBFUkMgZW5kcG9pbnRzIGNob29z ZSB0aGVpciBvd24gRTJFIG1lZGlhIGtleXMgYW5kIHNlbmQgdGhhdCBrZXkgaW5mbyB0byB0aGUg b3RoZXIgZW5kcG9pbnRzIGluIHRoZSBjb25mZXJlbmNlIGJ5IGVuY3J5cHRpbmcgaXQgd2l0aCB0 aGUgRTJFIEtFSyAoYWthIEVLVF9LZXkgYXNzaWduZWQgYnkgdGhlIEtNRikuICAgTmVpdGhlciB0 aGUgS01GIG9yIE1ERCBoYXZlIHRoZSBFMkUgbWVkaWEga2V5cyB1c2VkIGJ5IGVuZHBvaW50cywg cGVyaW9kLiAgDQoNCg0KDQo= From nobody Thu May 12 01:22: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 7D54B12D17A for ; Thu, 12 May 2016 01:22:24 -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, 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 (1024-bit key) header.d=kurento.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 zD2DTz-gpSrq for ; Thu, 12 May 2016 01:22:22 -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 610D312B029 for ; Thu, 12 May 2016 01:22:22 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a17so122271638wme.0 for ; Thu, 12 May 2016 01:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurento.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=xkJev3onJ7RunyirVzia3zrT9+BFY7LvoQOqZ+h9QSo=; b=VxfNGqyp0NI1A2HfmixWcKk8YgsKsej722mJg6GLndOfo5f0Jw3ul/c+Zm3f/D4Hr6 97JS2c5XlTx23T6IMuQRGXuv8WOdJnVstbr22RadRPOaEwaRaU/4U+sAQJo3l6vgr99K 3TVRzGvXmcwfm3YezQ8Hf90N1GG68QQG8KouE= 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 :message-id:references:to; bh=xkJev3onJ7RunyirVzia3zrT9+BFY7LvoQOqZ+h9QSo=; b=BYqUj+bKFtxxuZ3MaI18oWMz8R37cEOQS6Qxga2xhX8qs6YxK/OJc3Uq9/5/scEvbo wnovjER1q8KAtFM2QiOW064L2ebQCyx5T7BWx81xvBhijee8ewTlLFKFRp7tWUzJ1Tgw ZbFRFGrgmcgCw7/ij0s4eNn0T3Sf+WMDyQxGzvmABoWizfGPhfNUwwT4HkAoOiRrEjIJ ylnal6R1ZX8WWY3riNRy30TffKECAEUZ5STx1M6ekz4SnPihEQHj4/z4riJyL3XwP+Oy DuwoZy1mKeBoFE1qE8Z9FJLvz7DiAec77KLHVzUHK1+zgq/W68GTEHFTV4d53C1KD5/R JQ5g== X-Gm-Message-State: AOPr4FU3zCPlGkQHvmAZVK6SheasmXC2ueDpvcRgCOkINXlQnME4fmfBl7/dNKVBubKBQA== X-Received: by 10.194.134.170 with SMTP id pl10mr7960925wjb.88.1463041340703; Thu, 12 May 2016 01:22:20 -0700 (PDT) Received: from [193.147.51.18] ([193.147.51.18]) by smtp.gmail.com with ESMTPSA id gk6sm12096617wjc.31.2016.05.12.01.22.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 May 2016 01:22:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0CE82243-B0E3-4B2A-AFFD-8C4BA0A824ED" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luis Lopez In-Reply-To: Date: Thu, 12 May 2016 10:22:18 +0200 Message-Id: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> References: To: "Paul E. Jones" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , Emil Ivov , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 12 May 2016 08:22:24 -0000 --Apple-Mail=_0CE82243-B0E3-4B2A-AFFD-8C4BA0A824ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, Could you develop on this? >=20 > It is indeed a fact that you can write a switching function that does = not require changing SSRCs. I=E2=80=99m very interested in figuring out know to support features = such as simulcast or active speakers switching in an SFU without SSRC = rewriting? I your plan is to negotiate a bunch of SSRCs per participant = and just switch on/off each of them when appropriate, I=E2=80=99m afraid = this will not work. Best regards. L. --Apple-Mail=_0CE82243-B0E3-4B2A-AFFD-8C4BA0A824ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Paul,

Could you develop on = this?

It is indeed a fact = that you can write a switching function that does not require changing = SSRCs.

I=E2=80=99m = very interested in figuring out know to support features such as = simulcast or active speakers switching in an SFU without SSRC rewriting? = I your plan is to negotiate a bunch of SSRCs per participant and just = switch on/off each of them when appropriate, I=E2=80=99m afraid this = will not work.

Best = regards.

L.


= --Apple-Mail=_0CE82243-B0E3-4B2A-AFFD-8C4BA0A824ED-- From nobody Thu May 12 06:24:19 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 68B3312D125 for ; Thu, 12 May 2016 06:24:17 -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 Yf4new9WejaC for ; Thu, 12 May 2016 06:24:14 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 5460212D668 for ; Thu, 12 May 2016 06:24:14 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j74so72486900ywg.1 for ; Thu, 12 May 2016 06:24:14 -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; bh=etNUVWoQMB4yZ3Gqw54piNDr6RQiiEC+4W/NJcuDUXo=; b=usBlswn87PFtaVUnzVgckZggDlh0ZvYY8CL1u/IvFnAAGKPIYwCK5YhJqcNaGH+taY tOWt7He7n1WPB6Wv72uXWwnV+b8su+iwhkm2OSwXuGliI7seoMEPKOne1nz2USW+US2r hUcNKq3g/NJhuUl8dOvxIJl8edtmuuSdz4kf0gsRP6/6uaCxeATb1XAFdxNT2wBGRUIZ 9/+IGctmYIPUgXyqdKQCpDl/osvBPJN3CNgRu9S3/XL5i/bcekISw4gO/tT5IVNdmTSL P/CRBw5PsoDCrXgTwlmuZEsbqvDoGhXQK6bXXDUA2qJZdCTnayJOGLMYmZwvz9hYDUV4 QyDA== 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=etNUVWoQMB4yZ3Gqw54piNDr6RQiiEC+4W/NJcuDUXo=; b=KZrSQ0svVmI5KrSO6QXBCF982AxTyRLueUwYBlw8DVxtKY+RTMyouVY2wFqnvlOYFr 7Dw3Jhp99sVS1zjTDVakhtvKTQFCprd+Y4qkGZ10jsvC9WQXp5+T9oSVndbrBHLVpXpQ wyE+WlOTsnAEzBS9Ry9sH0PV8n4CwdVSJBBWCbzSjlt06dHt86iYO1g773dXKl1vuMiY 1UFg2hopciMFRyXQoTO7n/WR3zgImivDx6xEldjD/bIiWREK72JpfQ/c+SLp32wKA/Mm KWmaXcqzGEBHdMx0QDabIC4KU7g7mWP8n3v5crW5GEvumi5+tFcOr+w3eAFr67Vce2X1 x+jA== X-Gm-Message-State: AOPr4FWpVXLvGGKTR//hVNHDON16AOzlZGb2wgoR8YkUQNslmVBuw3Df4IBmvPx8egYnwg== X-Received: by 10.129.83.11 with SMTP id h11mr4960502ywb.258.1463059453223; Thu, 12 May 2016 06:24:13 -0700 (PDT) Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com. [209.85.161.177]) by smtp.gmail.com with ESMTPSA id r10sm7240860ywe.14.2016.05.12.06.24.12 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 06:24:12 -0700 (PDT) Received: by mail-yw0-f177.google.com with SMTP id t10so81812053ywa.0 for ; Thu, 12 May 2016 06:24:12 -0700 (PDT) X-Received: by 10.129.165.135 with SMTP id c129mr5088716ywh.67.1463059451969; Thu, 12 May 2016 06:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.6.138 with HTTP; Thu, 12 May 2016 06:23:52 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Thu, 12 May 2016 08:23:52 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 12 May 2016 13:24:17 -0000 Hey Paul On Wed, May 11, 2016 at 6:12 PM, Paul E. Jones wrote: > Emil, > >> A) Because otherwise that scr*ws up authentication because we cannot >> keep track of the overwrites across RTP and RTCP: obviously this is >> not true as we could simply not use SSRCs for PERC-specific purposes >> and define PERC specific IDs > > I'm not following that one. RTCP is HBH, so not an issue. Why would we > need a PERC-specific ID? My point is that if you need an immutable ID then you can define your own. As I already stated in this thread: that new ID can be a copy of the original SSRC or something new: whatever works. > I assume this is as an alternative to the SSRC in > the cryptographic context? We would not need that given "double" defined a > field that could record the original E2E SSRC value. (Yes that is now > removed, but see below.) > >> B) You are not correct and I, who have never implemented an SFU in my >> life, am telling you that you can reimplement your SFU to not rely on >> SSRC rewriting and it will be a piece of cake. I hope I don't have to >> comment on B. > > It is indeed a fact that you can write a switching function that does not > require changing SSRCs. Yes you can do that. You can also travel from Paris to London via Sydney: few people are making that choice though. All SFUs I am aware of overwrite SSRCs even if the one that you wrote might have taken a different path. >> As an IETF WG, PERC's behaviour on this topic has been very confusing >> to me and I am almost at the point where willful disruption is the >> only possible explanation that I can find. If we do proceed to ignore >> implementers the same way we are going to find ourselves debating the >> same concerns in IETF last call where reason would have a better >> chance of prevailing. > > I think the issue is this: you've not attended the meetings. We had > accommodated the option to change nearly everything in the RTP header via > the OHB in "double". During a recent meeting, it was decided to limit the > scope of what can be changed. We made the original "double" proposal to > allow for anything to be changed > (https://tools.ietf.org/html/draft-jennings-perc-double-00) and participants > in the meeting said to reduce the possible set down to PT and sequence > number, so we produced > https://tools.ietf.org/html/draft-jennings-perc-double-01 accordingly. This > change was proposed in a conference call, if I recall, and then discussed > face-to-face before the document moved forward to WG adoption. > > I do not recall any person on a phone call or in the meeting room who > opposed the changes. It came as a pleasant surprise to the authors that > everyone was agreeable to such a narrow set of fields that could be changed. I am stunned! Paul, we first had this very conversation five months ago: https://www.ietf.org/mail-archive/web/perc/current/msg00136.html Numerous implementors commented here. This should have been the end of it. then a bit later I raised it again here: https://www.ietf.org/mail-archive/web/perc/current/msg00222.html Now this. So are you now saying: "well Emil the issue is that you are not present on all meetings so every time we try to sneak this back in, you are not there to stop us and that's your problem!" > Can we support changing SSRCs? Yes, we can put it back in. We will need to > change the way we have the OHB encoded, but it's certainly possible. > >> E2E encryption is too important of a subject for us to botch this work. > > I can only encourage you to participate in meetings when they're called and > to comment on drafts as they're published. Heck, even if you cannot make a > face-to-face meeting, the -01 draft has been out there since March 21 and > nobody commented on that change until this week. It is one thing to encourage involvement when new decisions are being made. I support this and we are all doing our best. It is a completely different thing to require participation so that the same points can be made over and over and over again. Emil -- https://jitsi.org From nobody Thu May 12 07:55:36 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 9685412B060 for ; Thu, 12 May 2016 07:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] 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 aCQ-XWEiy_lB for ; Thu, 12 May 2016 07:55:34 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1BC12B022 for ; Thu, 12 May 2016 07:55:33 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id 3520D1EB8496 for ; Thu, 12 May 2016 16:55:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Thu, 12 May 2016 16:55:31 +0200 From: "Hutton, Andrew" To: "perc@ietf.org" Thread-Topic: PERC assumptions about SIP environment Thread-Index: AdGsXlJ9VmXj/fcZRAGTPjJyUx7ZJA== Date: Thu, 12 May 2016 14:55:31 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF261012ED@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Perc] PERC assumptions about SIP environment 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, 12 May 2016 14:55:35 -0000 Hi, I was looking through the framework document (https://tools.ietf.org/html/d= raft-jones-perc-private-media-framework-02) and some of the message flows f= rom previous documents and was hoping to find some information to help me u= nderstand how this would fit within an existing SIP environment but I did n= ot find anything. The PERC charter states "The solution should be implementable by both SIP (= RFC3261) and WebRTC endpoints" so I was thinking about what this means. Since the current PERC proposals are based on DTLS-SRTP is it the assumptio= n that PERC only works in a DTLS-SRTP only environment? If this is the case= then I assume it needs to be clearly stated somewhere as a limitation. Also does the current implementation proposal assume that a SIP endpoint di= scovers it needs to do PERC stuff during the DTLS handshake and there is no= need for SIP/SDP mechanisms to discover this? Regards Andy From nobody Thu May 12 09:41: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 A3EEA12D6C9 for ; Thu, 12 May 2016 09:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 3-SMlxHExSX0 for ; Thu, 12 May 2016 09:41:13 -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 7FAC512D6BB for ; Thu, 12 May 2016 09:41:13 -0700 (PDT) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D2074180504; Thu, 12 May 2016 12:41:10 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 10BEC18046A; Thu, 12 May 2016 12:41:09 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Thu, 12 May 2016 12:41:10 -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: Date: Thu, 12 May 2016 10:41:08 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6AAB39F5-0962-41EC-9799-D6FC2B56E9EE@iii.ca> References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> To: Emil Ivov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 12 May 2016 16:41:15 -0000 > On May 11, 2016, at 4:01 PM, Emil Ivov wrote: >=20 > On Wed, May 11, 2016 at 3:56 PM, Cullen Jennings = wrote: >>=20 >>> On May 10, 2016, at 5:04 PM, Bernard Aboba = wrote: >>>=20 >>> I agree. Without SSRC rewriting PERC does not apply to any real = world conferencing scenarios. >>=20 >> Could you please provide details of exactly what you mean here? >=20 > I saw a bunch of exact scenarios mentioned here. Things like simulcast > and active speaker switching for example have numerous popular > implementations through SSRC rewriting. Those include implementations > from Kurento, Google, Microsoft, Janus, Jitsi and likely many others. >=20 > Unless we are explicitly trying to sabotage PERC adoption by all of > those, I cannot for the life of me understand why we are so stuck on > forbidding rewriting SSRCs. I never saw a satisfactory answer on the > subject. The answers that I heard were basically: >=20 > A) Because otherwise that scr*ws up authentication because we cannot > keep track of the overwrites across RTP and RTCP: obviously this is > not true as we could simply not use SSRCs for PERC-specific purposes > and define PERC specific IDs > and > B) You are not correct and I, who have never implemented an SFU in my > life, am telling you that you can reimplement your SFU to not rely on > SSRC rewriting and it will be a piece of cake. I hope I don't have to > comment on B. Emil, I have designed and implemented multiple SFU products over the = years (first one in 2004) including ones that use SSM multicast which = make things much more complicated. When I read someone say that they = would have to rewrite all their code if the identifier they changed was = inside a RTP header instead of being in the SSRC, I feel like it might = be a lot less work that rewriting all the code. It's not that much = difference if you move where in the RTP packet you grab the identifier = that you are changing.=20 So help folks understand here, how do all theses system that do SSRC = rewrite deal with RTCP? =20 >=20 > As an IETF WG, PERC's behaviour on this topic has been very confusing > to me So in fairness here ...=20 The WG talked a bunch about this last summer and fall.=20 In October Magnus and others wrote = draft-westerlund-perc-rtp-field-considerations with a section on SSRC = and I and other wrote draft-jennings-perc-double-00 which allowed SSRC = to change.=20 We have had several meetings since then and two IETF where those = documents were discussed as they evolved and people argued for what they = are now. In Nov you said that you had tried to to a non SSRC changing = implementation but it did not work well but never provided any technical = details on what did or did not work. I'm not going to try and update you = on everything that happened on theses meeting but as a practical matter = I think the things that would be most helpful to me at this point would = be=20 1) how you deal with RTCP when the MMD changes the SSRC 2) why changing SSRC worked out better than not for interop with = endpoints > and I am almost at the point where willful disruption is the > only possible explanation that I can find. If we do proceed to ignore > implementers the same way we are going to find ourselves debating the > same concerns in IETF last call where reason would have a better > chance of prevailing. >=20 > E2E encryption is too important of a subject for us to botch this = work. >=20 > Emil >=20 >=20 > --=20 > https://jitsi.org >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Thu May 12 09:52:02 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 CB2E312D504 for ; Thu, 12 May 2016 09:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 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] 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 sDu074Nvh8e8 for ; Thu, 12 May 2016 09:51:59 -0700 (PDT) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505A412D1E1 for ; Thu, 12 May 2016 09:51:59 -0700 (PDT) Received: from smtp3.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp3.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 5F3A8300600; Thu, 12 May 2016 12:51:54 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 745A830053B; Thu, 12 May 2016 12:51:53 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Thu, 12 May 2016 12:51:54 -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: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> Date: Thu, 12 May 2016 10:51:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7B7D9C02-32BB-4264-80A0-E1F4D5F3F527@iii.ca> References: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> To: LuLop X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , Paul Jones , Emil Ivov , perc@ietf.org, Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 12 May 2016 16:52:00 -0000 > On May 12, 2016, at 2:22 AM, Luis Lopez wrote: >=20 > Hi Paul, >=20 > Could you develop on this? >>=20 >> It is indeed a fact that you can write a switching function that does = not require changing SSRCs. >=20 > I=E2=80=99m very interested in figuring out know to support features = such as simulcast or active speakers switching in an SFU without SSRC = rewriting? I your plan is to negotiate a bunch of SSRCs per participant = and just switch on/off each of them when appropriate, I=E2=80=99m afraid = this will not work. >=20 > Best regards. >=20 > L. >=20 I don't think I know what you mean by negotiate SSRC? Most uses of SIP = don't even pass the SSRC in the SDP. Allowing the RTP sender to = arbitrarily change the SSRC is a pretty core port of RTP so if that is = not working it sounds like a pretty broken receiver.=20= From nobody Thu May 12 09:56:41 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 97BD212B04D for ; Thu, 12 May 2016 09:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Npe1xXuaA1xb for ; Thu, 12 May 2016 09:56:38 -0700 (PDT) Received: from smtp77.ord1c.emailsrvr.com (smtp77.ord1c.emailsrvr.com [108.166.43.77]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3776312B008 for ; Thu, 12 May 2016 09:56:38 -0700 (PDT) Received: from smtp10.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 8526B3803DA; Thu, 12 May 2016 12:56:37 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp10.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1577638029B; Thu, 12 May 2016 12:56:36 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Thu, 12 May 2016 12:56:37 -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: Date: Thu, 12 May 2016 10:56:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <050485D8-C9CE-4529-B6D2-DD4AD93A5930@iii.ca> To: Emil Ivov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Paul Jones , "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, 12 May 2016 16:56:39 -0000 > 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 Good point. I mostly find topologies too baffling to bother reading but = agree 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 Thu May 12 12: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 706B912D134 for ; Thu, 12 May 2016 12:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 HoFERpyKP3Ic for ; Thu, 12 May 2016 12:42:48 -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 3DC1812B039 for ; Thu, 12 May 2016 12:42:48 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u4CJgjcu060135 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 May 2016 14:42:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Hutton, Andrew" , "perc@ietf.org" References: <9F33F40F6F2CD847824537F3C4E37DDF261012ED@MCHP04MSX.global-ad.net> From: Adam Roach Message-ID: <7d73c4cb-58df-a053-94b8-71a00ae4aa38@nostrum.com> Date: Thu, 12 May 2016 14:42:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF261012ED@MCHP04MSX.global-ad.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] PERC assumptions about SIP environment 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, 12 May 2016 19:42:49 -0000 On 5/12/16 09:55, Hutton, Andrew wrote: > Since the current PERC proposals are based on DTLS-SRTP is it the assumption that PERC only works in a DTLS-SRTP only environment? If this is the case then I assume it needs to be clearly stated somewhere as a limitation. I believe that this is, yes, a prerequisite of the system. SRTP is, of course, given. And it would be like building a steel door in the middle of an open field if we allowed this SRTP to be keyed with SDES. So DTLS-SRTP is required. > Also does the current implementation proposal assume that a SIP endpoint discovers it needs to do PERC stuff during the DTLS handshake and there is no need for SIP/SDP mechanisms to discover this? I don't think this has been discussed yet. I think we're finally getting to a point where it would be reasonable for someone to put together a draft that talks about feature discovery and information flow in a SIP context. If you'd like to spend some cycles doing that, it would probably be a good investment of your time. When I have a few cycles, I plan to do something similar for WebRTC (assuming no one beats me to it) -- we should make sure SDP handling is consistent between the two. /a From nobody Thu May 12 17:57:11 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 D6CCC12B00F for ; Thu, 12 May 2016 17:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 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=-0.996, 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 xpePWRgx0mCB for ; Thu, 12 May 2016 17:57:08 -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 1FD8612B009 for ; Thu, 12 May 2016 17:57:08 -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 u4D0v4lM020567 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2016 20:57:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463101026; bh=EGcb8c7HORR6CgdJp+L3036WIhiTOAePJjlrJ49ghto=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=Efa3AK1B+Q6ZdRqafUWI9Q43vfBoLPN+7CrjIhmucUPa/P4oLheOHkxbXfJnQ6vUC 1CnBHmLgLhn5R4AA/y16ds5saPBaF6I6B8Yte1U3P7JPWi3UnLLvGfa41L562NMONT x+YnLl/pQjkanbLUORFccWS0aqLX6GoCLUflqhdE= From: "Paul E. Jones" To: "Luis Lopez" Date: Fri, 13 May 2016 00:57:10 +0000 Message-Id: In-Reply-To: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> User-Agent: eM_Client/6.0.24928.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB1C901A39-EA02-4571-8FBC-69D78194CC86" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Thu, 12 May 2016 20:57:06 -0400 (EDT) Archived-At: Cc: Richard Barnes , Emil Ivov , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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: Fri, 13 May 2016 00:57:10 -0000 --------=_MB1C901A39-EA02-4571-8FBC-69D78194CC86 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Luis, >Hi Paul, > >Could you develop on this? >> >>It is indeed a fact that you can write a switching function that does=20 >>not require changing SSRCs. > >I=E2=80=99m very interested in figuring out know to support features such= as=20 >simulcast or active speakers switching in an SFU without SSRC=20 >rewriting? I your plan is to negotiate a bunch of SSRCs per participant= =20 >and just switch on/off each of them when appropriate, I=E2=80=99m afraid= this=20 >will not work. I think it's important to mindful of the fact that PERC does not define=20 every aspect of the system, but will instead rely on the work performed=20 in other IETF WGs. Active Speaker switching is one example. The MDD=20 might use audio levels indicated in RTP headers (RFC 6464), for example.= =20 Whatever method is employed, the MDD cannot rely on what is observed in= =20 the media payload, since that will be encrypted. And when it switches=20 based on audio levels, it would be really nice if it also switched the=20 related video flow of the active speaker when the first I-frame is=20 received. Again, this is where we rely on work on other WGs (e.g.,=20 draft-ietf-avtext-framemarking). We might not want to be concrete in=20 specifying the use of RFC 6464, either. Consider a conference with only= =20 deaf participants. Maybe we want a different mechanism for such=20 conferences, but it's certainly not this group that should decide how=20 that works. There is a need to be able to associate audio with video flows, and for=20 simulcast we have the additional need to be able to identify the=20 alternative simulcast flows. For that, we have tools like=20 draft-ietf-mmusic-sdp-simulcast, MID (RFC 5888), and RID=20 (draft-ietf-avtext-rid and draft-ietf-mmusic-rid). Where we identify a=20 need, we can address those in the appropriate working group. However,=20 PERC is not the place to solve every challenge related to conferencing. I would not recommend negotiating a bunch of SSRCs, as I'd prefer to=20 just utilize what's defined in RFC 3550 and allow normal collision=20 detection procedures to be followed. Since we are using EKT, we are not= =20 at risk of the "one-time pad" problem defined in RFC 3711, thus=20 collisions will not introduce security vulnerabilities. Mechanisms like= =20 RTCP and SDES carried in RTP (draft-ietf-avtext-sdes-hdr-ext) are=20 sufficient for conveying information (with the latter being end-to-end=20 secure), though we might find the need to enhance those tools. Again=20 though, many of the other elements we might need are really outside the=20 scope of PERC and we should actively contribute to that work where we=20 identify something that might make PERC work better. Paul --------=_MB1C901A39-EA02-4571-8FBC-69D78194CC86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Luis,
 
Hi Paul,

Could you develop on this?

It is indeed a fact that you= can write a switching function that does not require changing SSRCs.

I=E2=80=99m very interested in figuring out know to support features= such as simulcast or active speakers switching in an SFU without SSRC rewr= iting? I your plan is to negotiate a bunch of SSRCs per participant and = just switch on/off each of them when appropriate, I=E2=80=99m afraid this= will not work.
 
I think it's important to mindful of the fact that PERC does not= define every aspect of the system, but will instead rely on the work= performed in other IETF WGs.  Active Speaker switching is one= example. The MDD might use audio levels indicated in RTP headers (RFC 6464= ), for example.  Whatever method is employed, the MDD cannot= rely on what is observed in the media payload, since that will be encrypte= d.  And when it switches based on audio levels, it would be really = nice if it also switched the related video flow of the active speaker when= the first I-frame is received.  Again, this is where we rely on work= on other WGs (e.g., draft-ietf-avtext-framemarking).  We might not= want to be concrete in specifying the use of RFC 6464, either.  Consi= der a conference with only deaf participants.  Maybe we want a differe= nt mechanism for such conferences, but it's certainly not this group that= should decide how that works. 
 
There is a need to be able to associate audio with video flows, and= for simulcast we have the additional need to be able to identify the alter= native simulcast flows.  For that, we have tools like draft-ietf-mmusi= c-sdp-simulcast, MID (RFC 5888), and RID (draft-ietf-avtext-rid and draft-i= etf-mmusic-rid).  Where we identify a need, we can address those in= the appropriate working group.  However, PERC is not the place to = solve every challenge related to conferencing.
 
I would not recommend negotiating a bunch of SSRCs, as I'd prefer to= just utilize what's defined in RFC 3550 and allow normal collision detecti= on procedures to be followed.  Since we are using EKT, we are not at= risk of the "one-time pad" problem defined in RFC 3711, thus collisions= will not introduce security vulnerabilities.  Mechanisms like RTCP= and SDES carried in RTP (draft-ietf-avtext-sdes-hdr-ext) are sufficient= for conveying information (with the latter being end-to-end secure), thoug= h we might find the need to enhance those tools.  Again though, m= any of the other elements we might need are really outside the scope of = PERC and  we should actively contribute to that work where we identify= something that might make PERC work better.
 
Paul
 
--------=_MB1C901A39-EA02-4571-8FBC-69D78194CC86-- From nobody Thu May 12 19:27:31 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 538AA12B049 for ; Thu, 12 May 2016 19:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, 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 EgBROIpLlJz9 for ; Thu, 12 May 2016 19:27:27 -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 E061F12B027 for ; Thu, 12 May 2016 19:27:26 -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 u4D2ROqp025488 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2016 22:27:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463106445; bh=GUo6EFfZnOwtcAKPiO0TSJROquwR19Sr1x/jLeMq7dE=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=uOzOkZZU1/v0kKu2IW2lFjVYW4H8W+XJqDDWVYhIxVAj2SNapOZFj2xMzgCitae9U L1ZmO0n07f3AF4rFmftSyuw+jDja2s5Mu7Vxju859FQpW2YCSeR3QwtSe/Mfcqty8D yv73jGJrccj1pKGV+A+scDz0yHPi9iJCFqnBSDRw= From: "Paul E. Jones" To: "Emil Ivov" Date: Fri, 13 May 2016 02:27:30 +0000 Message-Id: In-Reply-To: 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.5.16 (dublin.packetizer.com [10.137.60.122]); Thu, 12 May 2016 22:27:25 -0400 (EDT) Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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: Fri, 13 May 2016 02:27:29 -0000 Emil, >Hey Paul > >On Wed, May 11, 2016 at 6:12 PM, Paul E. Jones =20 >wrote: >> Emil, >> >>> A) Because otherwise that scr*ws up authentication because we cannot >>> keep track of the overwrites across RTP and RTCP: obviously this is >>> not true as we could simply not use SSRCs for PERC-specific purposes >>> and define PERC specific IDs >> >> I'm not following that one. RTCP is HBH, so not an issue. Why would= =20 >>we >> need a PERC-specific ID? > >My point is that if you need an immutable ID then you can define your >own. As I already stated in this thread: that new ID can be a copy of >the original SSRC or something new: whatever works. We do not really need an identifier, except to address the one security=20 issue raised here: https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4 With the agreement reached (after a lot of discussion) back in December=20 not to change the SSRC, this issue no longer exists. >> I assume this is as an alternative to the SSRC in >> the cryptographic context? We would not need that given "double"=20 >>defined a >> field that could record the original E2E SSRC value. (Yes that is=20 >>now >> removed, but see below.) >> >>> B) You are not correct and I, who have never implemented an SFU in=20 >>>my >>> life, am telling you that you can reimplement your SFU to not rely=20 >>>on >>> SSRC rewriting and it will be a piece of cake. I hope I don't have=20 >>>to >>> comment on B. >> >> It is indeed a fact that you can write a switching function that does= =20 >>not >> require changing SSRCs. > >Yes you can do that. You can also travel from Paris to London via >Sydney: few people are making that choice though. All SFUs I am aware >of overwrite SSRCs even if the one that you wrote might have taken a >different path. I'm scratching my head on this. ISTM that remapping SSRC is the longer=20 path from Paris to London. I appreciate that you might not have seen all= =20 of the products on the market; there certainly are some that do not=20 rewrite SSRCs. So, I am curious why you cannot build a system that just= =20 leaves the SSRCs alone. >>> As an IETF WG, PERC's behaviour on this topic has been very=20 >>>confusing >>> to me and I am almost at the point where willful disruption is the >>> only possible explanation that I can find. If we do proceed to=20 >>>ignore >>> implementers the same way we are going to find ourselves debating=20 >>>the >>> same concerns in IETF last call where reason would have a better >>> chance of prevailing. >> >> I think the issue is this: you've not attended the meetings. We had >> accommodated the option to change nearly everything in the RTP header= =20 >>via >> the OHB in "double". During a recent meeting, it was decided to=20 >>limit the >> scope of what can be changed. We made the original "double" proposal= =20 >>to >> allow for anything to be changed >> (https://tools.ietf.org/html/draft-jennings-perc-double-00) and=20 >>participants >> in the meeting said to reduce the possible set down to PT and=20 >>sequence >> number, so we produced >> https://tools.ietf.org/html/draft-jennings-perc-double-01=20 >>accordingly. This >> change was proposed in a conference call, if I recall, and then=20 >>discussed >> face-to-face before the document moved forward to WG adoption. >> >> I do not recall any person on a phone call or in the meeting room who >> opposed the changes. It came as a pleasant surprise to the authors=20 >>that >> everyone was agreeable to such a narrow set of fields that could be=20 >>changed. > >I am stunned! > >Paul, we first had this very conversation five months ago: > >https://www.ietf.org/mail-archive/web/perc/current/msg00136.html Yes, I recall the older conversation and, in fact, we had it in our=20 draft to allow the SSRC to change. However, the decision to not modify=20 the SSRC followed email exchange and the decision has been in place=20 since at least early December. >Numerous implementors commented here. This should have been the end of=20 >it. > >then a bit later I raised it again here: > >https://www.ietf.org/mail-archive/web/perc/current/msg00222.html > >Now this. Yes, at the time it was an active topic of discussion. The decision was= =20 made, minutes reported, documents updated, etc. I think it is the rest=20 of us who were participating in the meetings who should be stunned at=20 this issue being raised again. >So are you now saying: "well Emil the issue is that you are not >present on all meetings so every time we try to sneak this back in, >you are not there to stop us and that's your problem!" No, I don't expect anyone to be at every meeting. However, you do need=20 to appreciate that the decision is now 5 months old the group has=20 long-since considered this issue closed. >> Can we support changing SSRCs? Yes, we can put it back in. We will= =20 >>need to >> change the way we have the OHB encoded, but it's certainly possible. >> >>> E2E encryption is too important of a subject for us to botch this=20 >>>work. >> >> I can only encourage you to participate in meetings when they're=20 >>called and >> to comment on drafts as they're published. Heck, even if you cannot= =20 >>make a >> face-to-face meeting, the -01 draft has been out there since March 21= =20 >>and >> nobody commented on that change until this week. > >It is one thing to encourage involvement when new decisions are being >made. I support this and we are all doing our best. > >It is a completely different thing to require participation so that >the same points can be made over and over and over again. I think you're mis-characterizing the events. The SSRC issue was an=20 active topic of discussion back in November / December. We had to=20 settle how we were going to deal with every header field and Magnus led=20 that dialog taking us through a couple of hours of discussion as we went= =20 through each and every header value. That meeting was held on November=20 30 and a recording for that meeting posted to the list: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D2684921e717d4b45aadb88d9a= 8774ce5 The SSRC dialog was at 1:01:43 and we talked about it for about 20=20 minutes. I think it might be worth your time to review that. Maybe you= =20 have a valid point not raised by others in the meeting, but I really=20 think it's unfortunate that you re-raise this issue after we revised the= =20 drafts and went through another IETF meeting where the group adopted=20 text based on this decision. Paul From nobody Thu May 12 19: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 7462C12D0AB for ; Thu, 12 May 2016 19:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, 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 oC2Z_2N_F3ym for ; Thu, 12 May 2016 19:42:47 -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 7898212B077 for ; Thu, 12 May 2016 19:42:47 -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 u4D2gjwT026321 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2016 22:42:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463107366; bh=s7eGGAVI714GJiYoQDeaOGgbokQnyvj0gF9uibDljHQ=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=iUbeIoaWuzjSncWOeFhZhp8YSpP9F9iK3ymsuaTNJdWepyE/NeUKkD47vTALqIlwp 3pJ9aYtKibROrNfIMHPrhvsTeVTdoGJInUnMUGBs96ufNQjO9wTCQcU8ztg11UGwkL 6X3WFvyWOln0YwuIA8WPgmbjLzZSZMrbfLgGT25g= From: "Paul E. Jones" To: "Hutton, Andrew" , "perc@ietf.org" Date: Fri, 13 May 2016 02:42:52 +0000 Message-Id: In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF261012ED@MCHP04MSX.global-ad.net> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Thu, 12 May 2016 22:42:46 -0400 (EDT) Archived-At: Subject: Re: [Perc] PERC assumptions about SIP environment 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: Fri, 13 May 2016 02:42:49 -0000 Andrew, >Hi, > >I was looking through the framework document=20 >(https://tools.ietf.org/html/draft-jones-perc-private-media-framework-02)= =20 >and some of the message flows from previous documents and was hoping to= =20 >find some information to help me understand how this would fit within=20 >an existing SIP environment but I did not find anything. We do not have call flow diagrams in any of the documents. However, the= =20 intent is to reuse the existing SDP syntax we have already, augmented=20 with whatever pieces and parts we need from current work in various=20 other IETF WGs (e.g., MID, RID, and simulcast drafts). So, the impact=20 on SIP is minimal. The impact on SDP construction is a little greater=20 and, of course, media handling is most significant (since we're=20 encrypting everything twice with two different keys). >The PERC charter states "The solution should be implementable by both=20 >SIP (RFC3261) and WebRTC endpoints" so I was thinking about what this=20 >means. I take that to mean we're not going to go invent something that doesn't=20 fit cleanly. Perhaps as extreme examples, we're not going to create a=20 replacement for SDP or SRTP. I would view it as a goal to be able to=20 add PERC support to an existing implementation in a way that is=20 "natural". > Since the current PERC proposals are based on DTLS-SRTP is it the=20 >assumption that PERC only works in a DTLS-SRTP only environment? If=20 >this is the case then I assume it needs to be clearly stated somewhere=20 >as a limitation. I don't personally view that as a limitation. Along with requiring=20 DTLS-SRTP, we are also requiring HBH and E2E encryption using two=20 entirely different keys, with the E2E key conveyed to other endpoints=20 using and EKT provided to the endpoint via the KMF over that=20 aforementioned DTLS-SRTP association. Thus, I don't see it as a=20 limitation, but a design choice that will lead to improved=20 interoperability. >Also does the current implementation proposal assume that a SIP=20 >endpoint discovers it needs to do PERC stuff during the DTLS handshake=20 >and there is no need for SIP/SDP mechanisms to discover this? We do not have anything written about how this will be determined. =20 Clearly, the endpoint knows that it needs to do double encryption and it= =20 needs to know that it is participating in a multipoint conference where=20 multiple video flows coming toward it, perhaps with simulcast flows. To= =20 be secure, it needs a way to convey identity and certificate information= =20 to a higher layer function also not discussed in PERC. We've been=20 focused just on the media aspects, but some of that other stuff would be= =20 needed for a complete solution. You're rightfully observing that not everything is defined the current=20 drafts. Paul From nobody Fri May 13 01:25:38 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 8DF8F12D0E9 for ; Fri, 13 May 2016 01:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] 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 HXKUWEHhVkt5 for ; Fri, 13 May 2016 01:25:34 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB9412B004 for ; Fri, 13 May 2016 01:25:33 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 2C3D023F0406; Fri, 13 May 2016 10:25:32 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Fri, 13 May 2016 10:25:31 +0200 From: "Hutton, Andrew" To: Adam Roach , "perc@ietf.org" Thread-Topic: [Perc] PERC assumptions about SIP environment Thread-Index: AdGsXlJ9VmXj/fcZRAGTPjJyUx7ZJAAF15yAAB49dsA= Date: Fri, 13 May 2016 08:25:30 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26102470@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF261012ED@MCHP04MSX.global-ad.net> <7d73c4cb-58df-a053-94b8-71a00ae4aa38@nostrum.com> In-Reply-To: <7d73c4cb-58df-a053-94b8-71a00ae4aa38@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Perc] PERC assumptions about SIP environment 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, 13 May 2016 08:25:36 -0000 T24gMTIgTWF5IDIwMTYgMjA6NDMgQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21d IFdyb3RlOg0KPiANCj4gT24gNS8xMi8xNiAwOTo1NSwgSHV0dG9uLCBBbmRyZXcgd3JvdGU6DQo+ ID4gU2luY2UgdGhlIGN1cnJlbnQgUEVSQyBwcm9wb3NhbHMgYXJlIGJhc2VkIG9uIERUTFMtU1JU UCBpcyBpdCB0aGUNCj4gYXNzdW1wdGlvbiB0aGF0IFBFUkMgb25seSB3b3JrcyBpbiBhIERUTFMt U1JUUCBvbmx5IGVudmlyb25tZW50PyBJZg0KPiB0aGlzIGlzIHRoZSBjYXNlIHRoZW4gSSBhc3N1 bWUgaXQgbmVlZHMgdG8gYmUgY2xlYXJseSBzdGF0ZWQgc29tZXdoZXJlDQo+IGFzIGEgbGltaXRh dGlvbi4NCj4gDQo+IEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMsIHllcywgYSBwcmVyZXF1aXNpdGUg b2YgdGhlIHN5c3RlbS4gU1JUUCBpcywgb2YNCj4gY291cnNlLCBnaXZlbi4gQW5kIGl0IHdvdWxk IGJlIGxpa2UgYnVpbGRpbmcgYSBzdGVlbCBkb29yIGluIHRoZSBtaWRkbGUNCj4gb2YgYW4gb3Bl biBmaWVsZCBpZiB3ZSBhbGxvd2VkIHRoaXMgU1JUUCB0byBiZSBrZXllZCB3aXRoIFNERVMuIFNv DQo+IERUTFMtU1JUUCBpcyByZXF1aXJlZC4NCj4gDQoNCkFncmVlZCBub3RoaW5nIGVsc2UgbWFr ZXMgc2Vuc2UgYnV0IHRoaXMgaXMgYSBiaWcgZGVhbCBmb3IgdGhlIFNJUCB3b3JsZCBhcyBpdCBp cyB0aGUgZmlyc3QgdGltZSBJIGJlbGlldmUgdGhhdCBhIG1ham9yIGZlYXR1cmUgaGFzIGJlZW4g dG90YWxseSByZWxpYW50IG9uIGEgRFRMUy1TUlRQIG9ubHkgc29sdXRpb24uIEl0IGlzIGFsc28g Z29pbmcgdG8gYmUgdmVyeSBoYXJkIHRvIGRlcGxveSBpbiBhbnkga2luZCBvZiBvcGVuIFNJUCBu ZXR3b3JrIGlmIGl0IG1lYW5zIHRoYXQgYWxsIFNJUCBlbmRwb2ludHMgaW4gdGhlIG5ldHdvcmsg aGF2ZSB0byBzdXBwb3J0IERUTFMtU1JUUC4gSSBndWVzcyB0aGVyZSBpcyBub3RoaW5nIG11Y2gg dGhhdCBjYW4gYmUgZG9uZSBhYm91dCB0aGF0IGl0IGlzIGp1c3QgcmVhbGl0eS4NCg0KSG93ZXZl ciBJIGFtIHRoaW5raW5nIHRoYXQgd2UgdXJnZW50bHkgbmVlZCB0byBnZXQgdGhlIG5ldyBtZWRp YSBzZWN1cml0eSB3b3JraW5nIGdyb3VwIHRoYXQgd2UgZGlzY3Vzc2VkIGluIGRpc3BhdGNoIGF0 IElFVEY5NSB1cCBhbmQgcnVubmluZyB0byBtYWtlIHN1cmUgZXZlcnl0aGluZyBpcyBhbGlnbmVk IHJlZ2FyZGluZyBQRVJDIGFuZCB0aGUgYmVzdCBwcmFjdGljZSBmb3IgU0lQIGVuZC10by1lbmQg dHdvIHBhcnR5IHNlc3Npb25zIGFuZCBTSVAgb3Bwb3J0dW5pc3RpYyBzZWN1cml0eS4gSW4gZmFj dCBJIGFtIHRoaW5raW5nIHRoYXQgd29yayBuZWVkcyB0byBiZSBkb25lIGJlZm9yZSBQRVJDIGdl dHMgdG9vIGZhci4NCg0KDQo+ID4gQWxzbyBkb2VzIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9u IHByb3Bvc2FsIGFzc3VtZSB0aGF0IGEgU0lQDQo+IGVuZHBvaW50IGRpc2NvdmVycyBpdCBuZWVk cyB0byBkbyBQRVJDIHN0dWZmIGR1cmluZyB0aGUgRFRMUyBoYW5kc2hha2UNCj4gYW5kIHRoZXJl IGlzIG5vIG5lZWQgZm9yIFNJUC9TRFAgbWVjaGFuaXNtcyB0byBkaXNjb3ZlciB0aGlzPw0KPiAN Cj4gSSBkb24ndCB0aGluayB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCB5ZXQuIEkgdGhpbmsgd2Un cmUgZmluYWxseQ0KPiBnZXR0aW5nDQo+IHRvIGEgcG9pbnQgd2hlcmUgaXQgd291bGQgYmUgcmVh c29uYWJsZSBmb3Igc29tZW9uZSB0byBwdXQgdG9nZXRoZXIgYQ0KPiBkcmFmdCB0aGF0IHRhbGtz IGFib3V0IGZlYXR1cmUgZGlzY292ZXJ5IGFuZCBpbmZvcm1hdGlvbiBmbG93IGluIGEgU0lQDQo+ IGNvbnRleHQuIElmIHlvdSdkIGxpa2UgdG8gc3BlbmQgc29tZSBjeWNsZXMgZG9pbmcgdGhhdCwg aXQgd291bGQNCj4gcHJvYmFibHkgYmUgYSBnb29kIGludmVzdG1lbnQgb2YgeW91ciB0aW1lLiBX aGVuIEkgaGF2ZSBhIGZldyBjeWNsZXMsIEkNCj4gcGxhbiB0byBkbyBzb21ldGhpbmcgc2ltaWxh ciBmb3IgV2ViUlRDIChhc3N1bWluZyBubyBvbmUgYmVhdHMgbWUgdG8NCj4gaXQpDQo+IC0tIHdl IHNob3VsZCBtYWtlIHN1cmUgU0RQIGhhbmRsaW5nIGlzIGNvbnNpc3RlbnQgYmV0d2VlbiB0aGUg dHdvLg0KPiANCj4gL2ENCg0K From nobody Fri May 13 09:42: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 2107212D5F0 for ; Fri, 13 May 2016 09:42:42 -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 TQz4OuBxm6TS for ; Fri, 13 May 2016 09:42:39 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 8C9D912D5E8 for ; Fri, 13 May 2016 09:42:39 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id v145so178961903oie.0 for ; Fri, 13 May 2016 09:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=89e86/KtXflYrwpY/g9sWupDtLj5UtMQKG5JobJMWXI=; b=UzabV05AAoBq9VnjEYSkZmbMVnGRFtySuKhFYqxFI2AuRjCzvKgiUlMonOaQgbVx/5 OSW+bmdG2rsClgYc2RJU/IuPZ657nfUiXFbYUP6zLOffGRZDrUi7loUQrz+hFO+bI5LL Wl0OoP9nA0eIXOAOqfBbqPwy9dQa7RRhPtfFq7GvqMUP2M4ZUHWRGlpC8qkUKUqCcedl IBs/M5mF6zUvlicq8L2PhTs3hCbWejeeI6pF9iuU+LiZOYyuOfmesipyN9W8IMkTGOiR Li4rFVIAsueMPa2xHGBxnukoQdPtf4BEELdegPESW4CW8rZ5V3EQPC7bB24JIrRoh3gQ z9qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=89e86/KtXflYrwpY/g9sWupDtLj5UtMQKG5JobJMWXI=; b=Oj2nkdoXs0aigIRryGJeRzAJEuTpHlvIJzh2nPKjlgtjpBWH/eJpHLehK7sbtTSzno VkI9BHVPWccWzus+W9RIKd5JGxdbKvA5Dxfd9ZRcpb2UtILDum8CPD2/DFJg7hv9WWLk qa+I47CYH9wxvtFCNtNfS6IzIb4N00PKn9x3nF/Ldfzu/PrNoW6Pt3Nb3UwA24n9KF6K JpOZUzL7yU/n8DpHm3MlRJsYg+Hj022BCi9uRMFsTtIu7DHYEBH6nhWXTTg/IU73cLFT wyLW32Wi0vuxOskLrboVqdBPUAuxeu0houC7vUfRtRd+km5jLsAYspoZz7bXZ2rCMC8n KGkw== X-Gm-Message-State: AOPr4FXcGRkFdoaImzTBm0gEuO0vwYCKnZ2xFU3EC4AvIXLY6rWMam2bHMzoYFQHgnFF4A== X-Received: by 10.202.0.7 with SMTP id 7mr7103290oia.54.1463157758712; Fri, 13 May 2016 09:42:38 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id p1sm5575424obn.22.2016.05.13.09.42.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2016 09:42:37 -0700 (PDT) To: Cullen Jennings References: <5F958B7E-BBE3-49B7-A30A-175D62EF1F17@iii.ca> <8C8D39AC-DCE9-45D3-A5C1-98EF6C51CB44@kurento.com> <6AAB39F5-0962-41EC-9799-D6FC2B56E9EE@iii.ca> From: Emil Ivov Message-ID: <32f60e98-c995-c45c-b575-5fb79b733568@jitsi.org> Date: Fri, 13 May 2016 11:42:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <6AAB39F5-0962-41EC-9799-D6FC2B56E9EE@iii.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 13 May 2016 16:42:42 -0000 On 12.05.16 г. 11:41, Cullen Jennings wrote: > > >> On May 11, 2016, at 4:01 PM, Emil Ivov wrote: >> >> On Wed, May 11, 2016 at 3:56 PM, Cullen Jennings >> wrote: >>> >>>> On May 10, 2016, at 5:04 PM, Bernard Aboba >>>> wrote: >>>> >>>> I agree. Without SSRC rewriting PERC does not apply to any real >>>> world conferencing scenarios. >>> >>> Could you please provide details of exactly what you mean here? >> >> I saw a bunch of exact scenarios mentioned here. Things like >> simulcast and active speaker switching for example have numerous >> popular implementations through SSRC rewriting. Those include >> implementations from Kurento, Google, Microsoft, Janus, Jitsi and >> likely many others. >> >> Unless we are explicitly trying to sabotage PERC adoption by all >> of those, I cannot for the life of me understand why we are so >> stuck on forbidding rewriting SSRCs. I never saw a satisfactory >> answer on the subject. The answers that I heard were basically: >> >> A) Because otherwise that scr*ws up authentication because we >> cannot keep track of the overwrites across RTP and RTCP: obviously >> this is not true as we could simply not use SSRCs for PERC-specific >> purposes and define PERC specific IDs and B) You are not correct >> and I, who have never implemented an SFU in my life, am telling you >> that you can reimplement your SFU to not rely on SSRC rewriting and >> it will be a piece of cake. I hope I don't have to comment on B. > > > Emil, I have designed and implemented multiple SFU products over the > years (first one in 2004) including ones that use SSM multicast which > make things much more complicated. When I read someone say that they > would have to rewrite all their code if the identifier they changed > was inside a RTP header instead of being in the SSRC, I feel like it > might be a lot less work that rewriting all the code. It's not that > much difference if you move where in the RTP packet you grab the > identifier that you are changing. It is. Now what you say may be true when you only care about a handful of endpoints that you control. The situation with WebRTC is significantly more complex though, because of all the dynamics. There are a bunch of endpoint implementations some in big organisations with complex priorities. While they would all acknowledge privacy is important, I don't think PERC would score very high on their priority lists because things related to easily perceptible user experience would beat it any day of the week. This however, is not the most important point of this debate. > So help folks understand here, how do all theses system that do SSRC > rewrite deal with RTCP? We terminate it. All of it. >> As an IETF WG, PERC's behaviour on this topic has been very >> confusing to me > > So in fairness here ... > > The WG talked a bunch about this last summer and fall. > > In October Magnus and others wrote > draft-westerlund-perc-rtp-field-considerations with a section on SSRC > and I and other wrote draft-jennings-perc-double-00 which allowed > SSRC to change. > > We have had several meetings since then and two IETF where those > documents were discussed as they evolved and people argued for what > they are now. In Nov you said that you had tried to to a non SSRC > changing implementation but it did not work wellbut never provided > any technical details on what did or did not work. I believe I did though. The problems with making SSRCs visible to the endpoints is that it requires the endpoints to switch between streams themselves. This is pretty much a lost cause with WebRTC because the JS app has too little information to do that in a quick and stable way. It also requires WebRTC endpoints to reimplement that same switching code across platforms (i.e. write a Java impl on Android and an iOS/swift one for iOS). Now, I somehow feel that someone is ready to jump and say: "yeah, but that's because your browsers were using non-standard offer/answer and it all would have been peachy if they did". The first part of that statement would be sort of true (although it is hardly a cause a cause for the problem ... this is more related to use of RID than the offer/answer semantics). The second part is non-verifiable and I am very sceptical that it would be in the near future. It would basically mean that browsers have to completely change the way they feed packets to all their CC engines and decoders and make them use RIDs instead of SSRCs for all of those. You are certainly welcome to explain to all these people how you've been doing this since 2004 and how they really should roll their sleeves and get on top of it because it's super easy ... but until I see it happening I would remain highly sceptical that they would. That again is still not the main point of this debate. > I'm not going to > try and update you on everything that happened on theses meeting but > as a practical matter I think the things that would be most helpful > to me at this point would be > > 1) how you deal with RTCP when the MMD changes the SSRC As stated above: all RTCP is terminated at the MMD. It has RTX caches, it generates its own SRs and RRs and PLIs and FIRs. > 2) why > changing SSRC worked out better than not for interop with endpoints Explained above. Now ... the main point of this debate is the following: We have a bunch of incumbent implementations that are extremely popular today, that are being used by hundreds of millions of people and that all do things a certain way. PERC is hoping to gain adoption by all of those. PERC is new work that is carrying no legacy and is such has significant freedom in the design choices it is making. The main point is therefore that: it doesn't matter exactly how much time it takes implementors to rewrite, re-test and re-deploy their simulcast implementations. What matters is that this rewrite effort is without a doubt bigger than the effort it would take PERC to accomodate them and work around SSRC rewriting. In other words: it *is* all the same to you, so please be nice to us. Emil > > >> and I am almost at the point where willful disruption is the only >> possible explanation that I can find. If we do proceed to ignore >> implementers the same way we are going to find ourselves debating >> the same concerns in IETF last call where reason would have a >> better chance of prevailing. >> >> E2E encryption is too important of a subject for us to botch this >> work. >> >> Emil >> >> >> -- https://jitsi.org >> >> _______________________________________________ Perc mailing list >> Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc > > -- https://jitsi.org From nobody Fri May 13 10:05:34 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 091FF12D62A for ; Fri, 13 May 2016 10:05:32 -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 sKu0kSfsZHaQ for ; Fri, 13 May 2016 10:05:20 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 719E612D610 for ; Fri, 13 May 2016 10:05:20 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k142so180386362oib.1 for ; Fri, 13 May 2016 10:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=yezrUG2S2smvrczGixw4i2JHF2FQ5q78dSsArZeWCp4=; b=JqPhBj0RttokrnfgbZjYvwRinnYW7RjZ+AQN2mm+62delT5Y3vae6m1fI/q8xZ9WTj Qd62rNXPKunkUlgUq2b3e5CG+otfOovIGpJ+WWOdgOUyWi0jjsmmguT/ZTMigZpcfIRK dMoNVYQTtodHYsjDUB/LCNn4cCHREEX6CwHxdfoLuB4HY+oCnydUM42kHo/v5Rb1jbRM INcdKr1BHyhVlId1MTz6IZrCJZBqvHocmYAKXhwi2r52ls1JdSyuiV3TtmRsrth3z2x4 ViS08slWfsmWWDPmfWuk8M6xdGW/LUPwcmAhfaKOIBS6LFjZaHfSj6YTg7dfku363ARP ++WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yezrUG2S2smvrczGixw4i2JHF2FQ5q78dSsArZeWCp4=; b=C0f6aFqV04h9SFyxS6Byvt4X2xj+2PNO8dbNbIRMuzon0Hgj0vnvu5F+4UVbMXerKK sH9Cl1qCTIWAPOppfUcI4ybe0Ae/znYcbwhY5mehnJuV78Rs469Y7pZVc83krrx0lT6d HDtPTYPNCHhXJzDRJ1ORZNVmCLBUfEs89CfOwAonPSFxFPYMlvdyNdq5TegFGb0SdBKn rAUqR3AJoehzytegCWy6MYU8PD5IfG8atl/OuxFvGRsw+DmoZG/hfsJ4UgAYYet9oVwx riMTH9pQKXeMmmN4yNl7/h+xFmEvds/Uv87Il467zWNPFdoKeHN6lVCb7qfn/E012wp9 pozA== X-Gm-Message-State: AOPr4FVWP0jU6cNg8IyxhwKnoe1lYJT+vu1e71ADYF+b0V8E3KNAja3A7IVHVRgSWbXVdg== X-Received: by 10.202.48.20 with SMTP id w20mr7910135oiw.61.1463159119701; Fri, 13 May 2016 10:05:19 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id q8sm5658703oec.15.2016.05.13.10.05.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2016 10:05:18 -0700 (PDT) To: "Paul E. Jones" References: From: Emil Ivov Message-ID: <49a58087-59d1-a388-2772-92294ce8dda6@jitsi.org> Date: Fri, 13 May 2016 12:05:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 13 May 2016 17:05:32 -0000 Hey Paul, On 12.05.16 г. 21:27, Paul E. Jones wrote: > Emil, > >> Hey Paul >> >> On Wed, May 11, 2016 at 6:12 PM, Paul E. Jones >> wrote: >>> Emil, >>> >>>> A) Because otherwise that scr*ws up authentication because we cannot >>>> keep track of the overwrites across RTP and RTCP: obviously this is >>>> not true as we could simply not use SSRCs for PERC-specific purposes >>>> and define PERC specific IDs >>> >>> I'm not following that one. RTCP is HBH, so not an issue. Why >>> would we >>> need a PERC-specific ID? >> >> My point is that if you need an immutable ID then you can define your >> own. As I already stated in this thread: that new ID can be a copy of >> the original SSRC or something new: whatever works. > > We do not really need an identifier, except to address the one security > issue raised here: > https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4 > > With the agreement reached (after a lot of discussion) back in December > not to change the SSRC, this issue no longer exists. Let's please get that reversed. We need SSRC and seq num rewriting to be possible so let's find a different solution to that *one* security issue that wouldn't make a bunch of implementers whine on this list every few months. It is not a big deal for this WG's work. It has a huge impact on the adoption of that work though. >>> I assume this is as an alternative to the SSRC in >>> the cryptographic context? We would not need that given "double" >>> defined a >>> field that could record the original E2E SSRC value. (Yes that is now >>> removed, but see below.) >>> >>>> B) You are not correct and I, who have never implemented an SFU in my >>>> life, am telling you that you can reimplement your SFU to not rely on >>>> SSRC rewriting and it will be a piece of cake. I hope I don't have to >>>> comment on B. >>> >>> It is indeed a fact that you can write a switching function that >>> does not >>> require changing SSRCs. >> >> Yes you can do that. You can also travel from Paris to London via >> Sydney: few people are making that choice though. All SFUs I am aware >> of overwrite SSRCs even if the one that you wrote might have taken a >> different path. > > I'm scratching my head on this. ISTM that remapping SSRC is the longer > path from Paris to London. You will understand as soon as you try to implement an SFU that works well with WebRTC today. > I appreciate that you might not have seen all > of the products on the market; I am pretty sure I know about most of the WebRTC compatible ones. > there certainly are some that do not > rewrite SSRCs. And they, whoever they are, would be just fine if we relaxed the requirements on immutable seq nums and SSRCs. > So, I am curious why you cannot build a system that just > leaves the SSRCs alone. I have already built my system. So have Google and Vidyo and Janus and Microsoft and Kurento. We are *all* rewriting sequence numbers and SSRCs. >>>> As an IETF WG, PERC's behaviour on this topic has been very confusing >>>> to me and I am almost at the point where willful disruption is the >>>> only possible explanation that I can find. If we do proceed to ignore >>>> implementers the same way we are going to find ourselves debating the >>>> same concerns in IETF last call where reason would have a better >>>> chance of prevailing. >>> >>> I think the issue is this: you've not attended the meetings. We had >>> accommodated the option to change nearly everything in the RTP >>> header via >>> the OHB in "double". During a recent meeting, it was decided to >>> limit the >>> scope of what can be changed. We made the original "double" >>> proposal to >>> allow for anything to be changed >>> (https://tools.ietf.org/html/draft-jennings-perc-double-00) and >>> participants >>> in the meeting said to reduce the possible set down to PT and sequence >>> number, so we produced >>> https://tools.ietf.org/html/draft-jennings-perc-double-01 >>> accordingly. This >>> change was proposed in a conference call, if I recall, and then >>> discussed >>> face-to-face before the document moved forward to WG adoption. >>> >>> I do not recall any person on a phone call or in the meeting room who >>> opposed the changes. It came as a pleasant surprise to the authors >>> that >>> everyone was agreeable to such a narrow set of fields that could be >>> changed. >> >> I am stunned! >> >> Paul, we first had this very conversation five months ago: >> >> https://www.ietf.org/mail-archive/web/perc/current/msg00136.html > > Yes, I recall the older conversation and, in fact, we had it in our > draft to allow the SSRC to change. However, the decision to not modify > the SSRC followed email exchange and the decision has been in place > since at least early December. > >> Numerous implementors commented here. This should have been the end of >> it. >> >> then a bit later I raised it again here: >> >> https://www.ietf.org/mail-archive/web/perc/current/msg00222.html >> >> Now this. > > Yes, at the time it was an active topic of discussion. The decision was > made, minutes reported, documents updated, etc. I think it is the rest > of us who were participating in the meetings who should be stunned at > this issue being raised again. I cannot believe you are making that point. Did you at any point see any of the concerned implementers come back and say: "Oh right! That totally makes sense now! Forget about immutable seq nums and SSRCs, we can do with out them. Roll on!" As a responsible document editor, *that* is what you should be looking for. Same for all actively participating WG members. You know me, you know Lorenzo, you know Bernard I assume you also know people from the other companies/orgs implementing simulcast through SSRC and seq num rewrites. Did you see them take part of the discussion? Did you take any steps to go and check with them? "You weren't there to complain then, so get lost now" is a pretty bad argument and I certainly didn't expect it from someone with your experience. >> So are you now saying: "well Emil the issue is that you are not >> present on all meetings so every time we try to sneak this back in, >> you are not there to stop us and that's your problem!" > > No, I don't expect anyone to be at every meeting. However, you do need > to appreciate that the decision is now 5 months old the group has > long-since considered this issue closed. I fail to see how that is in any way relevant. The concerns were stated before the decision was made. The people having made the concerns were absent when it was decided to not address them. This doesn't mean they didn't care. If they didn't they wouldn't have stated them. This simply means that they trusted the WG to do the right thing. It did not! >>> Can we support changing SSRCs? Yes, we can put it back in. We will >>> need to >>> change the way we have the OHB encoded, but it's certainly possible. >>> >>>> E2E encryption is too important of a subject for us to botch this >>>> work. >>> >>> I can only encourage you to participate in meetings when they're >>> called and >>> to comment on drafts as they're published. Heck, even if you cannot >>> make a >>> face-to-face meeting, the -01 draft has been out there since March >>> 21 and >>> nobody commented on that change until this week. >> >> It is one thing to encourage involvement when new decisions are being >> made. I support this and we are all doing our best. >> >> It is a completely different thing to require participation so that >> the same points can be made over and over and over again. > > I think you're mis-characterizing the events. The SSRC issue was an > active topic of discussion back in November / December. We had to > settle how we were going to deal with every header field and Magnus led > that dialog taking us through a couple of hours of discussion as we went > through each and every header value. That meeting was held on November > 30 and a recording for that meeting posted to the list: > https://cisco.webex.com/ciscosales/lsr.php?RCID=2684921e717d4b45aadb88d9a8774ce5 > > > The SSRC dialog was at 1:01:43 and we talked about it for about 20 > minutes. I think it might be worth your time to review that. Maybe you > have a valid point not raised by others in the meeting, but I really > think it's unfortunate that you re-raise this issue after we revised the > drafts and went through another IETF meeting where the group adopted > text based on this decision. I couldn't agree more. It is very unfortunate and so easily avoidable if only steps had been taken to ping the concerned parties. Now ... can we please stop this arguing and just work around the issue with s.num/ssrc rewriting? Please! Emil -- https://jitsi.org From nobody Fri May 13 10:27:59 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 1E0DF12B043 for ; Fri, 13 May 2016 10:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 h2f9EyNG6Ms9 for ; Fri, 13 May 2016 10:27:54 -0700 (PDT) Received: from smtpcmd05149.aruba.it (smtpcmd0871.aruba.it [62.149.156.71]) by ietfa.amsl.com (Postfix) with ESMTP id E7A8812D09E for ; Fri, 13 May 2016 10:27:53 -0700 (PDT) Received: from lminiero ([79.56.51.76]) by smtpcmd08.ad.aruba.it with bizsmtp id ttTm1s00D1eee6701tTmzg; Fri, 13 May 2016 19:27:52 +0200 Date: Fri, 13 May 2016 19:27:45 +0200 From: Lorenzo Miniero To: Emil Ivov Message-ID: <20160513192745.0d482b62@lminiero> In-Reply-To: <49a58087-59d1-a388-2772-92294ce8dda6@jitsi.org> References: <49a58087-59d1-a388-2772-92294ce8dda6@jitsi.org> Organization: Meetecho X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, "Paul E. Jones" , Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 13 May 2016 17:27:58 -0000 On Fri, 13 May 2016 12:05:18 -0500 Emil Ivov wrote: > Hey Paul, >=20 > On 12.05.16 =D0=B3. 21:27, Paul E. Jones wrote: > > Emil, > > =20 > >> Hey Paul > >> > >> On Wed, May 11, 2016 at 6:12 PM, Paul E. Jones > >> wrote: =20 > >>> Emil, > >>> =20 > >>>> A) Because otherwise that scr*ws up authentication because we > >>>> cannot keep track of the overwrites across RTP and RTCP: > >>>> obviously this is not true as we could simply not use SSRCs for > >>>> PERC-specific purposes and define PERC specific IDs =20 > >>> > >>> I'm not following that one. RTCP is HBH, so not an issue. Why > >>> would we > >>> need a PERC-specific ID? =20 > >> > >> My point is that if you need an immutable ID then you can define > >> your own. As I already stated in this thread: that new ID can be a > >> copy of the original SSRC or something new: whatever works. =20 > > > > We do not really need an identifier, except to address the one > > security issue raised here: > > https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7= .2.4 > > > > With the agreement reached (after a lot of discussion) back in > > December not to change the SSRC, this issue no longer exists. =20 >=20 > Let's please get that reversed. We need SSRC and seq num rewriting to > be possible so let's find a different solution to that *one* security > issue that wouldn't make a bunch of implementers whine on this list > every few months. >=20 > It is not a big deal for this WG's work. It has a huge impact on the=20 > adoption of that work though. >=20 > >>> I assume this is as an alternative to the SSRC in > >>> the cryptographic context? We would not need that given "double" > >>> defined a > >>> field that could record the original E2E SSRC value. (Yes that > >>> is now removed, but see below.) > >>> =20 > >>>> B) You are not correct and I, who have never implemented an SFU > >>>> in my life, am telling you that you can reimplement your SFU to > >>>> not rely on SSRC rewriting and it will be a piece of cake. I > >>>> hope I don't have to comment on B. =20 > >>> > >>> It is indeed a fact that you can write a switching function that > >>> does not > >>> require changing SSRCs. =20 > >> > >> Yes you can do that. You can also travel from Paris to London via > >> Sydney: few people are making that choice though. All SFUs I am > >> aware of overwrite SSRCs even if the one that you wrote might have > >> taken a different path. =20 > > > > I'm scratching my head on this. ISTM that remapping SSRC is the > > longer path from Paris to London. =20 >=20 > You will understand as soon as you try to implement an SFU that works=20 > well with WebRTC today. >=20 > > I appreciate that you might not have seen all > > of the products on the market; =20 >=20 > I am pretty sure I know about most of the WebRTC compatible ones. >=20 > > there certainly are some that do not > > rewrite SSRCs. =20 >=20 > And they, whoever they are, would be just fine if we relaxed the=20 > requirements on immutable seq nums and SSRCs. >=20 > > So, I am curious why you cannot build a system that just > > leaves the SSRCs alone. =20 >=20 > I have already built my system. So have Google and Vidyo and Janus > and Microsoft and Kurento. We are *all* rewriting sequence numbers > and SSRCs. >=20 > >>>> As an IETF WG, PERC's behaviour on this topic has been very > >>>> confusing to me and I am almost at the point where willful > >>>> disruption is the only possible explanation that I can find. If > >>>> we do proceed to ignore implementers the same way we are going > >>>> to find ourselves debating the same concerns in IETF last call > >>>> where reason would have a better chance of prevailing. =20 > >>> > >>> I think the issue is this: you've not attended the meetings. We > >>> had accommodated the option to change nearly everything in the RTP > >>> header via > >>> the OHB in "double". During a recent meeting, it was decided to > >>> limit the > >>> scope of what can be changed. We made the original "double" > >>> proposal to > >>> allow for anything to be changed > >>> (https://tools.ietf.org/html/draft-jennings-perc-double-00) and > >>> participants > >>> in the meeting said to reduce the possible set down to PT and > >>> sequence number, so we produced > >>> https://tools.ietf.org/html/draft-jennings-perc-double-01 > >>> accordingly. This > >>> change was proposed in a conference call, if I recall, and then > >>> discussed > >>> face-to-face before the document moved forward to WG adoption. > >>> > >>> I do not recall any person on a phone call or in the meeting > >>> room who opposed the changes. It came as a pleasant surprise to > >>> the authors that > >>> everyone was agreeable to such a narrow set of fields that could > >>> be changed. =20 > >> > >> I am stunned! > >> > >> Paul, we first had this very conversation five months ago: > >> > >> https://www.ietf.org/mail-archive/web/perc/current/msg00136.html =20 > > > > Yes, I recall the older conversation and, in fact, we had it in our > > draft to allow the SSRC to change. However, the decision to not > > modify the SSRC followed email exchange and the decision has been > > in place since at least early December. > > =20 > >> Numerous implementors commented here. This should have been the > >> end of it. > >> > >> then a bit later I raised it again here: > >> > >> https://www.ietf.org/mail-archive/web/perc/current/msg00222.html > >> > >> Now this. =20 > > > > Yes, at the time it was an active topic of discussion. The > > decision was made, minutes reported, documents updated, etc. I > > think it is the rest of us who were participating in the meetings > > who should be stunned at this issue being raised again. =20 >=20 > I cannot believe you are making that point. Did you at any point see > any of the concerned implementers come back and say: "Oh right! That > totally makes sense now! Forget about immutable seq nums and SSRCs, > we can do with out them. Roll on!" >=20 > As a responsible document editor, *that* is what you should be > looking for. Same for all actively participating WG members. >=20 > You know me, you know Lorenzo, you know Bernard I assume you also > know people from the other companies/orgs implementing simulcast > through SSRC and seq num rewrites. >=20 > Did you see them take part of the discussion? Did you take any steps > to go and check with them? >=20 > "You weren't there to complain then, so get lost now" is a pretty bad=20 > argument and I certainly didn't expect it from someone with your=20 > experience. >=20 That's probably needless to say, but I obviously support Emil, Luis and other implementors on this. Emil has already voiced my concerns much better than I would have been able to do, so I won't add to that. What I'd like to highlight, though, is that I certainly don't recall such a decision being echoed on the ML, as I would expect in the IETF typically, especially on an aspect that had seen such controversy. Had this happened, we definitely would have made our point timely again, and not 5 months later. Lorenzo > >> So are you now saying: "well Emil the issue is that you are not > >> present on all meetings so every time we try to sneak this back in, > >> you are not there to stop us and that's your problem!" =20 > > > > No, I don't expect anyone to be at every meeting. However, you do > > need to appreciate that the decision is now 5 months old the group > > has long-since considered this issue closed. =20 >=20 > I fail to see how that is in any way relevant. The concerns were > stated before the decision was made. The people having made the > concerns were absent when it was decided to not address them. >=20 > This doesn't mean they didn't care. If they didn't they wouldn't have=20 > stated them. This simply means that they trusted the WG to do the > right thing. >=20 > It did not! >=20 > >>> Can we support changing SSRCs? Yes, we can put it back in. We > >>> will need to > >>> change the way we have the OHB encoded, but it's certainly > >>> possible.=20 > >>>> E2E encryption is too important of a subject for us to botch > >>>> this work. =20 > >>> > >>> I can only encourage you to participate in meetings when they're > >>> called and > >>> to comment on drafts as they're published. Heck, even if you > >>> cannot make a > >>> face-to-face meeting, the -01 draft has been out there since > >>> March 21 and > >>> nobody commented on that change until this week. =20 > >> > >> It is one thing to encourage involvement when new decisions are > >> being made. I support this and we are all doing our best. > >> > >> It is a completely different thing to require participation so that > >> the same points can be made over and over and over again. =20 > > > > I think you're mis-characterizing the events. The SSRC issue was an > > active topic of discussion back in November / December. We had to > > settle how we were going to deal with every header field and Magnus > > led that dialog taking us through a couple of hours of discussion > > as we went through each and every header value. That meeting was > > held on November 30 and a recording for that meeting posted to the > > list: > > https://cisco.webex.com/ciscosales/lsr.php?RCID=3D2684921e717d4b45aadb8= 8d9a8774ce5 > > > > > > The SSRC dialog was at 1:01:43 and we talked about it for about 20 > > minutes. I think it might be worth your time to review that. > > Maybe you have a valid point not raised by others in the meeting, > > but I really think it's unfortunate that you re-raise this issue > > after we revised the drafts and went through another IETF meeting > > where the group adopted text based on this decision. =20 >=20 > I couldn't agree more. It is very unfortunate and so easily avoidable > if only steps had been taken to ping the concerned parties. >=20 > Now ... can we please stop this arguing and just work around the > issue with s.num/ssrc rewriting? >=20 > Please! >=20 > Emil >=20 >=20 From nobody Fri May 13 20:21:28 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 C1A9212B02B for ; Fri, 13 May 2016 20:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, 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 0ZIuN4SZT0Yq for ; Fri, 13 May 2016 20:21:25 -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 85F4912B01B for ; Fri, 13 May 2016 20:21:25 -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 u4E3LLOX019474 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 23:21:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463196084; bh=FqquE7Jpidy6ThkNkJeCHG527U9Vs2mq0NSzleZxof8=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=OoLOmX2SP7CIe/Zax/eEuhf8Fwh66fiVSgJ+C6WBBOPLvqAvC9rsRaGpAd/RTBfB9 oaxge4vksNk/doZgKNwLClUfuI4JynnX598EdYsJvgleLQwdf7Pa1/FxIG/uoVTrzb R4pHvM5+CRxmG/40P1sMVI/A1EjQZ+L98y1aZ14Y= From: "Paul E. Jones" To: "Emil Ivov" Date: Sat, 14 May 2016 03:21:23 +0000 Message-Id: In-Reply-To: <49a58087-59d1-a388-2772-92294ce8dda6@jitsi.org> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Fri, 13 May 2016 23:21:24 -0400 (EDT) Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 14 May 2016 03:21:27 -0000 Emil, >>We do not really need an identifier, except to address the one=20 >>security >>issue raised here: >>https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2= .4 >> >>With the agreement reached (after a lot of discussion) back in=20 >>December >>not to change the SSRC, this issue no longer exists. > >Let's please get that reversed. We need SSRC and seq num rewriting to=20 >be possible so let's find a different solution to that *one* security=20 >issue that wouldn't make a bunch of implementers whine on this list=20 >every few months. > >It is not a big deal for this WG's work. It has a huge impact on the=20 >adoption of that work though. The group concluded that sequence numbers could be changed. So, I think= =20 only the SSRC is an issue, right? Or are there other fields? (The=20 three fields that can change per current agreement is PT, X, and=20 sequence number.) As an aside, I would still prefer we did not re-write RTP sequence=20 numbers, but I appreciate the argument that it would be more appropriate= =20 for the receiver in terms of RFC 3550 intent. >>>> I assume this is as an alternative to the SSRC in >>>> the cryptographic context? We would not need that given "double" >>>>defined a >>>> field that could record the original E2E SSRC value. (Yes that is= =20 >>>>now >>>> removed, but see below.) >>>> >>>>> B) You are not correct and I, who have never implemented an SFU in= =20 >>>>>my >>>>> life, am telling you that you can reimplement your SFU to not rely= =20 >>>>>on >>>>> SSRC rewriting and it will be a piece of cake. I hope I don't have= =20 >>>>>to >>>>> comment on B. >>>> >>>> It is indeed a fact that you can write a switching function that >>>>does not >>>> require changing SSRCs. >>> >>>Yes you can do that. You can also travel from Paris to London via >>>Sydney: few people are making that choice though. All SFUs I am aware >>>of overwrite SSRCs even if the one that you wrote might have taken a >>>different path. >> >>I'm scratching my head on this. ISTM that remapping SSRC is the longer >>path from Paris to London. > >You will understand as soon as you try to implement an SFU that works=20 >well with WebRTC today. Given that browsers today do not support what's being proposed, I don't=20 see where you're going. Browsers will have to explicitly add support=20 for PERC, and I think they'll be able to manage. >>So, I am curious why you cannot build a system that just >>leaves the SSRCs alone. > >I have already built my system. So have Google and Vidyo and Janus and=20 >Microsoft and Kurento. We are *all* rewriting sequence numbers and=20 >SSRCs. But it's not doing PERC. It's not doing end-to-end encryption with HBH=20 in the middle, using appropriate logic for switching based on active=20 speaker, and simulcast in a manner that will allow the receiver to=20 compose media flows into something useful. There are still many things=20 we need to realize PERC in practice. Let's avoid designing around what=20 we have and figure out what we need. I'm personally unconvinced that=20 SSRC rewriting buys us anything. >>>Numerous implementors commented here. This should have been the end=20 >>>of >>>it. >>> >>>then a bit later I raised it again here: >>> >>>https://www.ietf.org/mail-archive/web/perc/current/msg00222.html >>> >>>Now this. >> >>Yes, at the time it was an active topic of discussion. The decision=20 >>was >>made, minutes reported, documents updated, etc. I think it is the=20 >>rest >>of us who were participating in the meetings who should be stunned at >>this issue being raised again. > >I cannot believe you are making that point. Did you at any point see=20 >any of the concerned implementers come back and say: "Oh right! That=20 >totally makes sense now! Forget about immutable seq nums and SSRCs, we=20 >can do with out them. Roll on!" People from Cisco, Ericsson, Mozilla, Vidyo, Huawei, etc. were on a call= =20 and we reached agreement following a discussion about it. It was a=20 public call, minutes reported, etc. We then revised the documents=20 accordingly, published them, and then reviewed them face-to-face with a=20 much larger audience. Nobody presented a technical argument during that= =20 time for why this will not work, and the adopted approach is definitely=20 in the spirit of RFC 3550. >Did you see them take part of the discussion? Did you take any steps to= =20 >go and check with them? I think your frustration with me is like "shooting the messenger." If=20 you'll listen to that recording I referenced in my last message, I=20 suspect you will not even hear me speak up on the issue. No decision=20 was done in a vacuum; I'm just responding to the fact that you're=20 digging up bones at this point. >"You weren't there to complain then, so get lost now" is a pretty bad=20 >argument and I certainly didn't expect it from someone with your=20 >experience. Again, don't shoot the messenger here, but the decision was reached 5=20 months ago, with all of the material put put online for discussion, a=20 F2F meeting held, etc. So, to some extent I think it is reasonable to=20 counter-argue with why you're re-opening points that were considered=20 closed. A good technical argument for why the current agreement is=20 flawed would be helpful, but you are not making such an argument. >>>So are you now saying: "well Emil the issue is that you are not >>>present on all meetings so every time we try to sneak this back in, >>>you are not there to stop us and that's your problem!" >> >>No, I don't expect anyone to be at every meeting. However, you do=20 >>need >>to appreciate that the decision is now 5 months old the group has >>long-since considered this issue closed. > >I fail to see how that is in any way relevant. The concerns were stated= =20 >before the decision was made. The people having made the concerns were=20 >absent when it was decided to not address them. With all due respect, it's been out on the list for 5 months, documents=20 published showing how it will work, etc. I told you I don't expect=20 people will be at meetings (they cost money), but the particular meeting= =20 where this agreement was reached cost no money to attend, recording was=20 posted, minutes posted, documents revised and published several months=20 later with no strong opposition to the decision, then no opposition at=20 the meeting in April, etc. >This doesn't mean they didn't care. If they didn't they wouldn't have=20 >stated them. This simply means that they trusted the WG to do the right= =20 >thing. > >It did not! You are suggesting that the decision of the WG is somehow technically=20 flawed, but what you're really concerned about is that you have to do=20 some work to support PERC. Everyone has to do some work to support=20 PERC. It is two-pass encryption with a switching function in the=20 middle, DTLS-SRTP from the endpoints (which is not common at all=20 presently, but viewed as far more secure than Security Descriptions),=20 etc. >>The SSRC dialog was at 1:01:43 and we talked about it for about 20 >>minutes. I think it might be worth your time to review that. Maybe=20 >>you >>have a valid point not raised by others in the meeting, but I really >>think it's unfortunate that you re-raise this issue after we revised=20 >>the >>drafts and went through another IETF meeting where the group adopted >>text based on this decision. > >I couldn't agree more. It is very unfortunate and so easily avoidable=20 >if only steps had been taken to ping the concerned parties. This was not a secret meeting. As I noted above, the meeting was called= =20 in public, recording posted in public, meeting minutes from two=20 different people posted in public, time elapsed with no departure from=20 that consensus, so in March we revised the documents per the agreement=20 in December and an announcement was sent to the list. We then had a=20 meeting F2F and discussed the texts again and adopted them. So, you=20 were pinged. :) >Now ... can we please stop this arguing and just work around the issue=20 >with s.num/ssrc rewriting? PERC will allow rewriting sequence numbers so that systems can strictly=20 comply with RFC 3550 (and to help network monitoring functions that are=20 looking for packet drops, I guess). But, I do not know what to tell=20 you on SSRC. I'm just one guy in the crowd here. Paul From nobody Fri May 13 20:45:35 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 88ABC12B01B for ; Fri, 13 May 2016 20:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 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=-0.996, 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 e6mTjQf6ko8U for ; Fri, 13 May 2016 20:45:32 -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 D1A2912B007 for ; Fri, 13 May 2016 20:45:32 -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 u4E3jUjY020704 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 23:45:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463197531; bh=L0ppN92BZzFJJz+gIm7XC+vtxwshHu2KyRlAnTQGRW0=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=paeIlFRzQ7TLDSVrsidPVE2QAB70Prc0hoTI8RoIkEYezdT+CAutlpf2aE1cyX5Zz Gl8qZQPI6lqE3LReLaBMn1KcOScsMyP2hW372OMQeg3vhNv8oXBGkU5++53xk9LA+c PmQjbWYJsYK9l8+ItBqh/2ZTCgjHyhW0UZv9IjZc= From: "Paul E. Jones" To: "Lorenzo Miniero" , "Emil Ivov" Date: Sat, 14 May 2016 03:45:31 +0000 Message-Id: In-Reply-To: <20160513192745.0d482b62@lminiero> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Fri, 13 May 2016 23:45:31 -0400 (EDT) Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 14 May 2016 03:45:34 -0000 Lorenzo, >What I'd like to highlight, though, is that I certainly don't recall >such a decision being echoed on the ML, as I would expect in the IETF >typically, especially on an aspect that had seen such controversy. Had >this happened, we definitely would have made our point timely again, >and not 5 months later. IETF 94 was pretty much in agreement, so a call for getting Concensus: https://www.ietf.org/mail-archive/web/perc/current/msg00125.html And we did have a lot of discussion on this on the list. During that=20 time Magnus undertook a very careful study into the problem and all=20 other RTP headers. Meeting to take up the issues on what is and is not immutable was=20 announced (based on previously posted poll): https://www.ietf.org/mail-archive/web/perc/current/msg00193.html Minutes posted by different attendees (one chair): https://www.ietf.org/mail-archive/web/perc/current/msg00216.html https://www.ietf.org/mail-archive/web/perc/current/msg00231.html Emil asked about the decision: https://www.ietf.org/mail-archive/web/perc/current/msg00222.html (There was no follow-up to this, as I assume that all of those who=20 favored the decision had nothing to say. Nobody opposed the group=20 decision explicitly.) There was dialog over the next few months on other things, but this=20 issue was not raised again. I posted an announcement on the revised set of drafts (nearly 4 months=20 later near the end of March): https://www.ietf.org/mail-archive/web/perc/current/msg00260.html We then had an IETF meeting in April where documents were again=20 considered. So, everything has been out in the open for discussion. Paul From nobody Fri May 13 22:49:54 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 55ED112B00D; Fri, 13 May 2016 22:49:53 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160514054953.10616.85864.idtracker@ietfa.amsl.com> Date: Fri, 13 May 2016 22:49:53 -0700 Archived-At: Cc: perc@ietf.org Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-00.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: Sat, 14 May 2016 05:49:53 -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 Jones David Benham Filename : draft-ietf-perc-private-media-framework-00.txt Pages : 18 Date : 2016-05-13 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-00 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 Sat May 14 12:38:57 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 2E3ED12D1E2 for ; Sat, 14 May 2016 12:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 jMxCqQVpdoev for ; Sat, 14 May 2016 12:38:53 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 B330412B04D for ; Sat, 14 May 2016 12:38:53 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k142so217850812oib.1 for ; Sat, 14 May 2016 12:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=DVQMwaAE9FZLIrcHP1MSMHPnTJF+X+k7aC3J23alIBs=; b=yIYG3EKpR5L8ZPcn1yoVEoc5XyBv8Z+1eKE6afV0PPtNfbez65GhhoMBs5vbnlUpWW tkraCGUGdMdcGpqzKUo+0vxS9yof6Bnm1BOvrshjPLVfdO79JZPtGGUpjoT8qPtm9NBe 7/4NLho+AxqAIZmN+4NVS3lgfr5ojLQO6DGQB3Zf87HGzIbG/huDsxqqggBrvnkEv7Pm z0AwJxq6PnM6FzJBWyKOrACJ/AMhzrU8CgOPibZXjbTmX/NHhq6ZrHZdCjTcMgmhP+M4 ZjpQu/4p0Ghz/bnHlNag10g+mbitUXbZJ1DoqSzJwJQptbNd3WTYUURQ9uNT04jAQoDN QvbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DVQMwaAE9FZLIrcHP1MSMHPnTJF+X+k7aC3J23alIBs=; b=I758MUejtLRbjUgR8CBuuhfEGJ7CQhzCRbMsksWxWaYTOY41/v5nZ1pChOMLScNKjW oGPS/QOmjfXlSYRUd5192zJA7AkNVhWVl4/qFGORQ+T7U8HLiiwhrNxYan8zxUr7Khox UTKV2h+qs0QsabrxQiVdrUj9rcqr148bsRv6UxFbU/rAITgLCUh5qZi3VEOX0t0nYkbP w9GtT/dzKyxJYJE/g1NOoccZsR9iUluwxLNS+PWs7c2VpyQpWm+96vUU1R9HmO7Ub7Km k6uYt4okp5A6KkADdJSXtXTT3+bjWd17vse+zmgtExviy/20z2mh3D3iBGtLKi/6+zis L38g== X-Gm-Message-State: AOPr4FUufcmVWSOIVthlF45AThu2YuhgxJ2FHZReKIAn8UkhrDWRXJgvKDDxMdol9oEpJw== X-Received: by 10.157.39.202 with SMTP id c68mr11262418otb.36.1463254732915; Sat, 14 May 2016 12:38:52 -0700 (PDT) Received: from camionet.local ([2602:306:83fc:cd90:476:5c4d:aac5:a5b]) by smtp.googlemail.com with ESMTPSA id 50sm7210299otu.26.2016.05.14.12.38.51 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 May 2016 12:38:51 -0700 (PDT) To: "Paul E. Jones" References: From: Emil Ivov Message-ID: Date: Sat, 14 May 2016 14:38:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Richard Barnes , LuLop , perc@ietf.org, Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 14 May 2016 19:38:56 -0000 Hey Paul, On 13.05.16 г. 22:21, Paul E. Jones wrote: > Emil, > >>> We do not really need an identifier, except to address the one security >>> issue raised here: >>> https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4 >>> >>> >>> With the agreement reached (after a lot of discussion) back in December >>> not to change the SSRC, this issue no longer exists. >> >> Let's please get that reversed. We need SSRC and seq num rewriting to >> be possible so let's find a different solution to that *one* security >> issue that wouldn't make a bunch of implementers whine on this list >> every few months. >> >> It is not a big deal for this WG's work. It has a huge impact on the >> adoption of that work though. > > The group concluded that sequence numbers could be changed. So, I think > only the SSRC is an issue, right? They both go hand in hand and yes, immutable SSRCs is the missing piece. > Or are there other fields? (The > three fields that can change per current agreement is PT, X, and > sequence number.) Timestamps. That's part of the simulcast package. > As an aside, I would still prefer we did not re-write RTP sequence > numbers, but I appreciate the argument that it would be more appropriate > for the receiver in terms of RFC 3550 intent. > >>>>> I assume this is as an alternative to the SSRC in >>>>> the cryptographic context? We would not need that given "double" >>>>> defined a >>>>> field that could record the original E2E SSRC value. (Yes that is >>>>> now >>>>> removed, but see below.) >>>>> >>>>>> B) You are not correct and I, who have never implemented an SFU >>>>>> in my >>>>>> life, am telling you that you can reimplement your SFU to not >>>>>> rely on >>>>>> SSRC rewriting and it will be a piece of cake. I hope I don't >>>>>> have to >>>>>> comment on B. >>>>> >>>>> It is indeed a fact that you can write a switching function that >>>>> does not >>>>> require changing SSRCs. >>>> >>>> Yes you can do that. You can also travel from Paris to London via >>>> Sydney: few people are making that choice though. All SFUs I am aware >>>> of overwrite SSRCs even if the one that you wrote might have taken a >>>> different path. >>> >>> I'm scratching my head on this. ISTM that remapping SSRC is the longer >>> path from Paris to London. >> >> You will understand as soon as you try to implement an SFU that works >> well with WebRTC today. > > Given that browsers today do not support what's being proposed, I don't > see where you're going. I said: doing away with SSRC rewriting will significantly complicate the life of SFUs You said: it sounds to me that the very fact they are doing SSRC re-writing is the source of their complication. I said: If you were to implement a WebRTC compatible SFU, you would understand exactly how SSRC rewriting is the (significantly) simpler option. > Browsers will have to explicitly add support > for PERC, and I think they'll be able to manage. I wouldn't be so sure. We have no people here representing Chrome. We've had people from MS speak against it and the only pro-voice from a browser vendor has been Adam's. >>> So, I am curious why you cannot build a system that just >>> leaves the SSRCs alone. >> >> I have already built my system. So have Google and Vidyo and Janus and >> Microsoft and Kurento. We are *all* rewriting sequence numbers and SSRCs. > > But it's not doing PERC. No it is not. I would really like it to but what you are asking us to do in order to support PERC is to throw away our simulcast implementation and I am not going to do that. If it ever came to that then I'd much rather do without PERC and rely on something more reasonable even if it meant depending on rich clients. > It's not doing end-to-end encryption with HBH > in the middle, using appropriate logic for switching based on active > speaker, and simulcast in a manner that will allow the receiver to > compose media flows into something useful. There are still many things > we need to realize PERC in practice. Let's avoid designing around what > we have and figure out what we need. I'm personally unconvinced that > SSRC rewriting buys us anything. It buys us adoption. Whether that matters to you is a different subject. >>>> Numerous implementors commented here. This should have been the end of >>>> it. >>>> >>>> then a bit later I raised it again here: >>>> >>>> https://www.ietf.org/mail-archive/web/perc/current/msg00222.html >>>> >>>> Now this. >>> >>> Yes, at the time it was an active topic of discussion. The decision was >>> made, minutes reported, documents updated, etc. I think it is the rest >>> of us who were participating in the meetings who should be stunned at >>> this issue being raised again. >> >> I cannot believe you are making that point. Did you at any point see >> any of the concerned implementers come back and say: "Oh right! That >> totally makes sense now! Forget about immutable seq nums and SSRCs, we >> can do with out them. Roll on!" > > People from Cisco, Ericsson, Mozilla, Vidyo, Huawei, etc. were on a call > and we reached agreement following a discussion about it. It was a > public call, minutes reported, etc. We then revised the documents > accordingly, published them, and then reviewed them face-to-face with a > much larger audience. Nobody presented a technical argument during that > time for why this will not work, and the adopted approach is definitely > in the spirit of RFC 3550. This is going in circles ... Look, if that's what this is about then I am happy to take the blame for not taking that point far enough. Now that this is out of the way, could we please revisit the decisions? Chairs? ADs? All? It wouldn't be a big deal. It wouldn't hurt anyone, and it would make this entire problem go away. >> Did you see them take part of the discussion? Did you take any steps >> to go and check with them? > > I think your frustration with me is like "shooting the messenger." If > you'll listen to that recording I referenced in my last message, I > suspect you will not even hear me speak up on the issue. No decision > was done in a vacuum; I'm just responding to the fact that you're > digging up bones at this point. As a co-author in two of the three WG documents you are more than just a messenger. Didn't mean to shoot anyone though. I am grateful you have engaged in the discussions! >> "You weren't there to complain then, so get lost now" is a pretty bad >> argument and I certainly didn't expect it from someone with your >> experience. > > Again, don't shoot the messenger here, but the decision was reached 5 > months ago, with all of the material put put online for discussion, a > F2F meeting held, etc. So, to some extent I think it is reasonable to > counter-argue with why you're re-opening points that were considered > closed. A good technical argument for why the current agreement is > flawed would be helpful, but you are not making such an argument. That's ... quite a confusing statement. People from Microsoft, Kurento, Janus, as well as myself have all explained how our implementations rely on SSRC rewriting for things such as simulcast. How is that not a technical argument? >>>> So are you now saying: "well Emil the issue is that you are not >>>> present on all meetings so every time we try to sneak this back in, >>>> you are not there to stop us and that's your problem!" >>> >>> No, I don't expect anyone to be at every meeting. However, you do need >>> to appreciate that the decision is now 5 months old the group has >>> long-since considered this issue closed. >> >> I fail to see how that is in any way relevant. The concerns were >> stated before the decision was made. The people having made the >> concerns were absent when it was decided to not address them. > > With all due respect, it's been out on the list for 5 months, documents > published showing how it will work, etc. I told you I don't expect > people will be at meetings (they cost money), but the particular meeting > where this agreement was reached cost no money to attend, recording was > posted, minutes posted, documents revised and published several months > later with no strong opposition to the decision, then no opposition at > the meeting in April, etc. Again, happy to take the blame if that would make things better. Now that it is all out there and everyone is well aware of the tradeoffs, could we please reverse this decision? It would be a trivial change for PERC and it would make the difference between adopting or ignoring it for a bunch of implementers. >> This doesn't mean they didn't care. If they didn't they wouldn't have >> stated them. This simply means that they trusted the WG to do the >> right thing. >> >> It did not! > > You are suggesting that the decision of the WG is somehow technically > flawed, That's quite a misrepresentation and I would appreciate it if you didn't attribute to me statements I never made. I have never said anything about PERC being technically broken in its current state. All this is about is the fact that it is going in a direction that compromises its adoption. > but what you're really concerned about is that you have to do > some work to support PERC. Everyone has to do some work to support > PERC. It is two-pass encryption with a switching function in the > middle, DTLS-SRTP from the endpoints (which is not common at all > presently, but viewed as far more secure than Security Descriptions), etc. Oh come on Paul. Really? Some work? Do you really believe that or are you just writing it to be spiteful? I am happy to ask my team to do the work to implement PERC support. What I will not do is ask them to do that and then go and reimplement simulcast just because the people who created the protocols decided they didn't care about our problems. >>> The SSRC dialog was at 1:01:43 and we talked about it for about 20 >>> minutes. I think it might be worth your time to review that. Maybe you >>> have a valid point not raised by others in the meeting, but I really >>> think it's unfortunate that you re-raise this issue after we revised the >>> drafts and went through another IETF meeting where the group adopted >>> text based on this decision. >> >> I couldn't agree more. It is very unfortunate and so easily avoidable >> if only steps had been taken to ping the concerned parties. > > This was not a secret meeting. Please point me to the message where I said that it was. > As I noted above, the meeting was called > in public, recording posted in public, meeting minutes from two > different people posted in public, time elapsed with no departure from > that consensus, so in March we revised the documents per the agreement > in December and an announcement was sent to the list. We then had a > meeting F2F and discussed the texts again and adopted them. So, you > were pinged. :) > >> Now ... can we please stop this arguing and just work around the issue >> with s.num/ssrc rewriting? > > PERC will allow rewriting sequence numbers so that systems can strictly > comply with RFC 3550 (and to help network monitoring functions that are > looking for packet drops, I guess). But, I do not know what to tell > you on SSRC. I'm just one guy in the crowd here. Well if the crowd doesn't care then I guess we wouldn't either. At this point I can only consider that this was the goal all along so ... good job! Emil -- https://jitsi.org From nobody Sat May 14 18:22: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 CAE1612D0A9 for ; Sat, 14 May 2016 18:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cwHKFJ3pyeQU for ; Sat, 14 May 2016 18:22:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 B239C12B028 for ; Sat, 14 May 2016 18:22:41 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 40E65CBF33407; Sun, 15 May 2016 01:22:39 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4F1MaSn020211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 May 2016 01:22:36 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4F1MZMu032247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 May 2016 03:22:35 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.13]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Sun, 15 May 2016 03:22:35 +0200 From: "Drage, Keith (Nokia - GB)" To: "Paul E. Jones" , Lorenzo Miniero , Emil Ivov Thread-Topic: [Perc] Minutes from Design Team call #3 Thread-Index: AQHRrZMPIi8qq5CojEySNX31r92yrZ+46h5Q Date: Sun, 15 May 2016 01:22:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEF500E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160513192745.0d482b62@lminiero> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Richard Barnes , LuLop , "perc@ietf.org" , Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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: Sun, 15 May 2016 01:22:44 -0000 I'd note that the meeting you specifically refer to in this mail was formal= ly called as a design team meeting (not an interim meeting), and a design t= eam meeting has no decision making process for the working group. Any design team results always need to be presented to the working group an= d agreed (or rejected). Regards Keith -----Original Message----- From: Perc [mailto:perc-bounces@ietf.org] On Behalf Of EXT Paul E. Jones Sent: 14 May 2016 04:46 To: Lorenzo Miniero; Emil Ivov Cc: Richard Barnes; LuLop; perc@ietf.org; Cullen Jennings; Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 Lorenzo, >What I'd like to highlight, though, is that I certainly don't recall=20 >such a decision being echoed on the ML, as I would expect in the IETF=20 >typically, especially on an aspect that had seen such controversy. Had=20 >this happened, we definitely would have made our point timely again,=20 >and not 5 months later. IETF 94 was pretty much in agreement, so a call for getting Concensus: https://www.ietf.org/mail-archive/web/perc/current/msg00125.html And we did have a lot of discussion on this on the list. During that time = Magnus undertook a very careful study into the problem and all other RTP he= aders. Meeting to take up the issues on what is and is not immutable was announced= (based on previously posted poll): https://www.ietf.org/mail-archive/web/perc/current/msg00193.html Minutes posted by different attendees (one chair): https://www.ietf.org/mail-archive/web/perc/current/msg00216.html https://www.ietf.org/mail-archive/web/perc/current/msg00231.html Emil asked about the decision: https://www.ietf.org/mail-archive/web/perc/current/msg00222.html (There was no follow-up to this, as I assume that all of those who favored = the decision had nothing to say. Nobody opposed the group decision explicit= ly.) There was dialog over the next few months on other things, but this issue w= as not raised again. I posted an announcement on the revised set of drafts (nearly 4 months late= r near the end of March): https://www.ietf.org/mail-archive/web/perc/current/msg00260.html We then had an IETF meeting in April where documents were again considered. So, everything has been out in the open for discussion. Paul _______________________________________________ Perc mailing list Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc From nobody Sat May 14 18: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 B476B12D0C3 for ; Sat, 14 May 2016 18:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 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.426, 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 P4_IeLrFXPzj for ; Sat, 14 May 2016 18:35:28 -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 538A812D0C1 for ; Sat, 14 May 2016 18:35:28 -0700 (PDT) Received: from dyn-229.arid.us (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 u4F1ZP4a029245 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 May 2016 21:35:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463276126; bh=HEt2cmGoZVufwRHwQa7Wh4enFbHck68RsiNlDgeohwA=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=o+ozWnEEOEFIBSAj45XgWVpnCEVzkSrmtSqFWAYJQWUJyxKn3+q+qOI7egRjfBtDo GPHaVHJmeflqUVEGm8FpDW79NmfbxOLqi/g7+XAKrP9+EXOXWz2/92gIqrLvNAsLSM e1QGq7CRqpevGkhap8SBt5UFVZhHHva8gwxRBD00= User-Agent: K-9 Mail for Android In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEF500E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160513192745.0d482b62@lminiero> <949EF20990823C4C85C18D59AA11AD8BADEF500E@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----5ZPA78TYJH25TOC7FTAL36XTEKVSHB" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Sat, 14 May 2016 21:35:24 -0400 To: "Drage, Keith (Nokia - GB)" , Lorenzo Miniero , Emil Ivov Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Sat, 14 May 2016 21:35:26 -0400 (EDT) Archived-At: Cc: Richard Barnes , LuLop , "perc@ietf.org" , Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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: Sun, 15 May 2016 01:35:31 -0000 ------5ZPA78TYJH25TOC7FTAL36XTEKVSHB Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 They were at the following IETF meeting. Paul -------- Original Message -------- From: "Drage, Keith (Nokia - GB)" Sent: May 14, 2016 9:22:34 PM EDT To: "Paul E. Jones" , Lorenzo Miniero , Emil Ivov Cc: Richard Barnes , LuLop , "perc@ietf.org" , Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 I'd note that the meeting you specifically refer to in this mail was formally called as a design team meeting (not an interim meeting), and a design team meeting has no decision making process for the working group. Any design team results always need to be presented to the working group and agreed (or rejected). Regards Keith -----Original Message----- From: Perc [mailto:perc-bounces@ietf.org] On Behalf Of EXT Paul E. Jones Sent: 14 May 2016 04:46 To: Lorenzo Miniero; Emil Ivov Cc: Richard Barnes; LuLop; perc@ietf.org; Cullen Jennings; Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 Lorenzo, >What I'd like to highlight, though, is that I certainly don't recall >such a decision being echoed on the ML, as I would expect in the IETF >typically, especially on an aspect that had seen such controversy. Had >this happened, we definitely would have made our point timely again, >and not 5 months later. IETF 94 was pretty much in agreement, so a call for getting Concensus: https://www.ietf.org/mail-archive/web/perc/current/msg00125.html And we did have a lot of discussion on this on the list. During that time Magnus undertook a very careful study into the problem and all other RTP headers. Meeting to take up the issues on what is and is not immutable was announced (based on previously posted poll): https://www.ietf.org/mail-archive/web/perc/current/msg00193.html Minutes posted by different attendees (one chair): https://www.ietf.org/mail-archive/web/perc/current/msg00216.html https://www.ietf.org/mail-archive/web/perc/current/msg00231.html Emil asked about the decision: https://www.ietf.org/mail-archive/web/perc/current/msg00222.html (There was no follow-up to this, as I assume that all of those who favored the decision had nothing to say. Nobody opposed the group decision explicitly.) There was dialog over the next few months on other things, but this issue was not raised again. I posted an announcement on the revised set of drafts (nearly 4 months later near the end of March): https://www.ietf.org/mail-archive/web/perc/current/msg00260.html We then had an IETF meeting in April where documents were again considered. So, everything has been out in the open for discussion. Paul _______________________________________________ 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 ------5ZPA78TYJH25TOC7FTAL36XTEKVSHB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit They were at the following IETF meeting.

Paul

From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
Sent: May 14, 2016 9:22:34 PM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, Lorenzo Miniero <lorenzo@meetecho.com>, Emil Ivov <emcho@jitsi.org>
Cc: Richard Barnes <rlb@ipv.sx>, LuLop <lulop@kurento.com>, "perc@ietf.org" <perc@ietf.org>, Cullen Jennings <fluffy@iii.ca>, Bernard Aboba <bernard.aboba@gmail.com>
Subject: Re: [Perc] Minutes from Design Team call #3

I'd note that the meeting you specifically refer to in this mail was formally called as a design team meeting (not an interim meeting), and a design team meeting has no decision making process for the working group.

Any design team results always need to be presented to the working group and agreed (or rejected).

Regards

Keith

-----Original Message-----
From: Perc [mailto:perc-bounces@ietf.org] On Behalf Of EXT Paul E. Jones
Sent: 14 May 2016 04:46
To: Lorenzo Miniero; Emil Ivov
Cc: Richard Barnes; LuLop; perc@ietf.org; Cullen Jennings; Bernard Aboba
Subject: Re: [Perc] Minutes from Design Team call #3

Lorenzo,

What I'd like to highlight, though, is that I certainly don't recall 
such a decision being echoed on the ML, as I would expect in the I!
 ETF 
typically, especially on an aspect that had seen such controversy. Had 
this happened, we definitely would have made our point timely again, 
and not 5 months later.
IETF 94 was pretty much in agreement, so a call for getting Concensus:
https://www.ietf.org/mail-archive/web/perc/current/msg00125.html

And we did have a lot of discussion on this on the list.  During that time Magnus undertook a very careful study into the problem and all other RTP headers.

Meeting to take up the issues on what is and is not immutable was announced (based on previously posted poll):
https://www.ietf.org/mail-archive/web/perc/current/msg00193.html

Minutes posted by different attendees (one chair):
https://www.ietf.org/mail-archive/web/perc/current/msg00216.html
https://www.ietf.org/mail-archive/web/perc/current/msg00231.html

Emil asked about the decision:
https://www.ietf.org/mail-archive/web/perc/current/msg00222.html
(There was no follow-up to this, as I assume that all of those who favored the decision had nothing to say. Nobody opposed the group decision explicitly.)

There was dialog over the next few months on other things, but this issue was not raised again.

I posted an announcement on the revised set of drafts (nearly 4 months later near the end of March):
https://www.ietf.org/mail-archive/web/perc/current/msg00260.html

We then had an IETF meeting in April where documents were again considered.

So, everything has been out in the open for discussion.

Paul


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
------5ZPA78TYJH25TOC7FTAL36XTEKVSHB-- From nobody Mon May 16 12:42: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 30AE512D9AF for ; Mon, 16 May 2016 12:42:42 -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 3x6TaNg03dGs for ; Mon, 16 May 2016 12:42:40 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 826A412D9AC for ; Mon, 16 May 2016 12:42:40 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x19so284419599oix.2 for ; Mon, 16 May 2016 12:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=0qDCM7YCLazCd1nUrf6uvvpTLwpxW6m5gnPgKV98FVE=; b=l2z+YxTCgEA0yN3FsyCsHc/gMBS7zxNIMPmyEpLAbIYUJKG0dnqZrx/8hgudmSjrQv hH3fDiGfDasizPuiXTwnVFPJQIu+94ykv8mmtZ+WpY1nFEuoDtWR5rAhfiytAIfqu1JT WPEy3CYVyXHXceXekUycWO6ZRSb+CbkKsANxTskkJBmo7VTdgD3LwwVPuo+/o+cflaDf MVEVJ1Atn1HxhyyR1EPXHutQ4R/1OPjAXurQ9yaTQvxsLzXqQ08BtrQwrw96rPJDoCx8 90jq4hl0/q1caW1QCPAxgvPqgciqpWbe6mtdZeIf7KttoiAWo4yhRUN0JTFmmK4maPl9 8DDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=0qDCM7YCLazCd1nUrf6uvvpTLwpxW6m5gnPgKV98FVE=; b=j5ma2jhyYqCaS2E0L6xrtgdSzUsr2bNmUEdwoEbH6YNRw1KnJz6qksp0FrohH0nOLJ Xnmg6SLW24ZfUg/cX+0ug2FMAeedHrK1DxvrSB6LsedozTTAlxlURN9M+x9aiRailwtk lMPvxE+ZRUQwnMjdlfw7XOtp2xU3C1efE5sqETzh3h4RMx0HYkKFuNAL8HbIe1Pkz9Pp DgCWiLx3mC9AnI6JoMGDQdjesWL405ax/GIH/9VdsGW9FeDGeE5waDuZfRkVdIonOBb6 1G1Cbxq0pVLrHuxtQQnu5Vc4ofCMKRy0AZeFEjUt4CQHxVvK+L5FQNUbuujpc97QR0gH ogYA== X-Gm-Message-State: AOPr4FWWhXvEgUOJoLOOGzRus6wX2hCXaEOP7fGp8hUZyszYF32c0cPZf9QBNtxWBBuK4g== X-Received: by 10.202.79.68 with SMTP id d65mr18495373oib.134.1463427759663; Mon, 16 May 2016 12:42:39 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id zb6sm10240338obb.29.2016.05.16.12.42.37 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 12:42:37 -0700 (PDT) To: perc@ietf.org From: Emil Ivov Message-ID: Date: Mon, 16 May 2016 14:42:36 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [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: Mon, 16 May 2016 19:42:42 -0000 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 From nobody Mon May 16 14:01: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 4C38012DA6C for ; Mon, 16 May 2016 14:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 o-mTpF8pDwjN for ; Mon, 16 May 2016 14:01:12 -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 6EE5A12DA6A for ; Mon, 16 May 2016 14:01:11 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4GL18D2084625 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 16 May 2016 16:01:10 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Emil Ivov , perc@ietf.org References: From: Adam Roach Message-ID: Date: Mon, 16 May 2016 16:01:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 16 May 2016 21:01:13 -0000 On 5/16/16 14:42, Emil Ivov wrote: > 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. Cullen's message on May 10th called out some specific, hard problems in the PERC system -- problems that don't arise in non-PERC systems, like ensuring the focus doesn't engage in intentional misattribution. Keeping the SSRCs immutable prevents these problems. If you would like to engage in a discussion of allowing SSRCs to change, it seems that it is first necessary for someone to figure out alternate means of solving those problems. The people who don't agree with the need to allow the focus to change SSRCs aren't going to be very motivated to come up with those solutions, so it would seem that those people insisting that they be mutable -- i.e., you -- are on the hook for coming up with something viable. What do you propose? /a From nobody Mon May 16 14:19: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 1D99D12DAC6 for ; Mon, 16 May 2016 14:19:08 -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 8Dlk5GRqRD4P for ; Mon, 16 May 2016 14:19:06 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 852CB12DAC8 for ; Mon, 16 May 2016 14:18:59 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x201so288835994oif.3 for ; Mon, 16 May 2016 14:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=ll/7mVlySOtXpa/amuarISNGnqBzmfmLgzCCEs1M42A=; b=sFGfcG2pdsPla1Sgkp0n0N29EPU9t+RUpr5stJ9XrE2JrGrzXxDki8C55kAl7KXqsf 6LNDAFkdUETie5i5RX1/gssbFQ91FzjDAbGwbihM6YpJSri4XOn2577IzHxLVuKNAWfr v63gm4QktLijscnu9AEwi95i+SCLq0pstyTtGlESZTSV/5+Dy94ftWViO3AkNaJdmbBu RJOI0dKBBzVjgENXy94Be3nhrtBJDndViRbnAVj8u7AIgdpjHcgRv3ghxfHvsKkwAkfX /r3rW8+1isPSnwmAoJe4wOyi+F9HFCkDDxD5BCS2l4usFe48ouTfGSOq23SFJLF5rLvS o2bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ll/7mVlySOtXpa/amuarISNGnqBzmfmLgzCCEs1M42A=; b=nMTXD5hvS5dy39ntea0o96315C+R10kI9Nv+QTiqXtJbmgR2Sg3h01UabZzedGi71K ieJ7nwSvaZLzIspjyNcniWwNVO+kzVhndr6OsLCGplXJyRJ1v6j/k70Lx6ClZzDxuG8t 9UgKyi9ewiFefMKrO/fW3FICKvJbaLnhZbA3dAINhD/y+Msb3LWs2TUr6uDcsCPxPDB3 2XwyKZar0vT84+6R6cRW/zN1mVjU4PAtm2OMvuVn7fxwLYRquQTXXH/lwpnZSVic6NYH TFI1GGGOu9Cn1xqn7OBptJo9mlyn3lKwROEtV++KtEjei4ECt7EVnxqUzCTlAhDpYWqM t5Lg== X-Gm-Message-State: AOPr4FWefGsCrQYGzE0roMxRdJrRqQ+dm+h/oCQGQh2f5AKEh6jJ+u0hWLltbq3Z4jcdVA== X-Received: by 10.157.41.202 with SMTP id g10mr19716331otd.122.1463433538907; Mon, 16 May 2016 14:18:58 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id cc15sm10371375obb.2.2016.05.16.14.18.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 14:18:58 -0700 (PDT) To: Adam Roach , perc@ietf.org References: From: Emil Ivov Message-ID: Date: Mon, 16 May 2016 16:18:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 16 May 2016 21:19:08 -0000 On 16.05.16 г. 16:01, Adam Roach wrote: > On 5/16/16 14:42, Emil Ivov wrote: >> 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. > > Cullen's message on May 10th called out some specific, hard problems in > the PERC system -- problems that don't arise in non-PERC systems, like > ensuring the focus doesn't engage in intentional misattribution. Keeping > the SSRCs immutable prevents these problems. > > If you would like to engage in a discussion of allowing SSRCs to change, > it seems that it is first necessary for someone to figure out alternate > means of solving those problems. > > The people who don't agree with the need to allow the focus to change > SSRCs aren't going to be very motivated to come up with those solutions, > so it would seem that those people insisting that they be mutable -- > i.e., you -- are on the hook for coming up with something viable. What > do you propose? That makes sense. Cullen's mail asks about how we handle RTCP. I already answered this: it's always terminated. I am not sure I see where the problem lies here. The second problem mentioned by Cullen on May 10 is the one about splicing that's also described here: https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4 This can be resolved by simply having an rtp-hdrext attached and signed by the sender that carries the original SSRC. That part will not be allowed to change and needs to be copied over by the MDD/SFU together with the rests of the immutable parts. If we need the same thing in RTCP, we add a similar extension there. How does that work for everyone? Emil -- https://jitsi.org From nobody Mon May 16 14:47:49 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 51F5B12D51C for ; Mon, 16 May 2016 14:47:49 -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 nQcmvsYC3JOL for ; Mon, 16 May 2016 14:47:47 -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 7484C12B04A for ; Mon, 16 May 2016 14:47:47 -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 u4GLljDF018644 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 May 2016 17:47:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463435266; bh=FlaJmCGmpmEbBS2fDrEoOB+mnrgpx+EDAPpqVwWFhN0=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=TJz5kpUjQTsxSaNoI7bS68/wJBN3mRfqE9eeIVhpYNE6ee0HIYNo1/0HV2zxqR8Tu ktMhsINVcZlNQfwHIO1I6YWpnRmQt+Py7cH6WXCZpMEbHqaWen+acieT4qXqKT7TVg JnSE3+WgR492d1/SEUXf+/Wiu+qp/kVXXv8y4m6o= From: "Paul E. Jones" To: "Emil Ivov" , "Adam Roach" , perc@ietf.org Date: Mon, 16 May 2016 21:47:52 +0000 Message-Id: In-Reply-To: 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.5.16 (dublin.packetizer.com [10.137.60.122]); Mon, 16 May 2016 17:47:46 -0400 (EDT) Archived-At: 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: Mon, 16 May 2016 21:47:49 -0000 Emil, >The second problem mentioned by Cullen on May 10 is the one about=20 >splicing that's also described here: >https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.= 4 > >This can be resolved by simply having an rtp-hdrext attached and signed= =20 >by the sender that carries the original SSRC. That part will not be=20 >allowed to change and needs to be copied over by the MDD/SFU together=20 >with the rests of the immutable parts. I don't think there is even an additional signing process required. The= =20 sender of the packet will encrypt the packet containing the original=20 SSRC value, with the authentication including that SSRC field. If the=20 MDD preserves that value in the OHB (described in the "double" draft),=20 then the receiving endpoint could restore the original SSRC value in the= =20 packet header before attempting to decrypt. If the wrong SSRC is=20 provided, the packet will fail authentication. Having two SSRC numbering spaces that can overlap is unfortunate,=20 though. Using libraries like libsrtp, we would need to have an E2E=20 context and a HBH context. That is, we have to initialize the library=20 twice, because every SSRC and related cryptograhic parameters, replay=20 database, etc. expects a single number space. Thus, to decrypt a packet= =20 we would have to do this: srtp_unprotect(hbh_context, packet); do_perc_stuff(packet); // Such as dealing with the OHB field srtp_unprotect(e2e_context, packet); We could hide that extra step by having the library create the second=20 context under-the-covers or creating a wrapper layer around libsrtp (or=20 whatever SRTP library is employed). If we did not create overlapping=20 number spaces, this could be avoided. I personally think having overlapping number spaces is messy. And for=20 what? I still fail to see how performing a 1:1 mapping of an SSRC value= =20 does anything to make building the MDD any easier. In fact, I see it as= =20 just more complexity. And, it's more complexity for the endpoint (as I=20 note above), juggling E2E and HBH SSRC values. Paul From nobody Mon May 16 18:50:52 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 9476912D1B0 for ; Mon, 16 May 2016 18:50:51 -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 d3Pm2YAMc8Mi for ; Mon, 16 May 2016 18:50:49 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 3C2CC12B018 for ; Mon, 16 May 2016 18:50:49 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id x201so3113557oif.3 for ; Mon, 16 May 2016 18:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=ve4jCg0/NhxKxv1fauNFgD462z3uuVm/Ejd9GZriGVg=; b=Qvf8eSpKynkzlM/bG5xPQML1DxNqU/a6n3L8HTJ2HRROYH0nR7teYUKJZuN7G1swmN JqLaSd4a/d1Gt4YCSoQY808gXZs8gxB8JBZtbnWlKKTdmx9tjHgQhx66gzTXkVKrlc8/ fXD40uEkQTvCdJOfeeLm7pbn9RBpTI++XTNZ5YowsEfTY2DZu1D8gfLM/fR0Z52fZdgb 7KrisSCejq0EB0gBYJnu6r4lnIebSrRSqy7D74j5zAbEX7Xf0ZLlp4y4cARd0+ycEJ26 jwbvVbKSdsW4yHy1IUNNTGsshZ64sUmLQUGfNiCpc85fZzGIqemTRK0tx0L4cLBvBb2W Hc5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ve4jCg0/NhxKxv1fauNFgD462z3uuVm/Ejd9GZriGVg=; b=XJte7asyD/78uODD9t5XCr07OVYjgp7PVN8b+BlqojoUxjZejDCD6eoYn8KOhEC2UO 3vlPvW0Y0eSI/4m7Yo+275EszSYHxj7UsjiaXp8G3SgddqIwoMIaqPHaRiwwkvbaKEES yrqbOnhIK448Ko2ez7OvnmEaf8b51X4LKPfEivzv20ZgeJJnjcGYalUMHW535Wp5FQCu jAK1O3AbTtfpxN+TS/2GhT2qcFVBEBQOwKYacujxzT1m22NDCmAldGtgQ5/LaB7yHO0X pNR7W6ij0lNJmi7yl8n90/1iQGFzkKXHuX9WdELypLnPrN3TweFKgQ9lj5ULVS6jydrV Fgsg== X-Gm-Message-State: AOPr4FVvoPmegc+FfpoYPy+cbyew0NKngwJtTAVyxVVQvq7Zl+37hxPXxT1l1552Xn1tgQ== X-Received: by 10.202.90.212 with SMTP id o203mr19233478oib.117.1463449848591; Mon, 16 May 2016 18:50:48 -0700 (PDT) Received: from camionet.local ([2602:306:83fc:cd90:adbf:6a92:36dc:3e41]) by smtp.googlemail.com with ESMTPSA id aq9sm119125obc.12.2016.05.16.18.50.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 18:50:46 -0700 (PDT) To: "Paul E. Jones" , Adam Roach , perc@ietf.org References: From: Emil Ivov Message-ID: <4a0ba091-74e3-3adf-7e2d-7ea5d7f76ebe@jitsi.org> Date: Mon, 16 May 2016 20:50:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Tue, 17 May 2016 01:50:51 -0000 Hey Paul, On 16.05.16 г. 16:47, Paul E. Jones wrote: > Emil, > >> The second problem mentioned by Cullen on May 10 is the one about >> splicing that's also described here: >> https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4 >> >> >> This can be resolved by simply having an rtp-hdrext attached and >> signed by the sender that carries the original SSRC. That part will >> not be allowed to change and needs to be copied over by the MDD/SFU >> together with the rests of the immutable parts. > > I don't think there is even an additional signing process required. No of course not. I just meant that it would be part of the data that is signed E2E. > The > sender of the packet will encrypt the packet containing the original > SSRC value, with the authentication including that SSRC field. If the > MDD preserves that value in the OHB (described in the "double" draft), > then the receiving endpoint could restore the original SSRC value in the > packet header before attempting to decrypt. If the wrong SSRC is > provided, the packet will fail authentication. So ... I admit I haven't fully wrapped my head around the OBH thing just yet. Specifically I don't understand the wording about how it should be placed after the original header extensions and why that even matters given that it's removed before verification ... I also don't understand exactly how it allows for changing other fields, such as the timestamp, or whether it is meant to allow for changing of (which) header extensions. That said, I agree that if we tweak these definitions then using the OBH could work. > Having two SSRC numbering spaces that can overlap is unfortunate, > though. Using libraries like libsrtp, we would need to have an E2E > context and a HBH context. That is, we have to initialize the library > twice, because every SSRC and related cryptograhic parameters, replay > database, etc. expects a single number space. Thus, to decrypt a packet > we would have to do this: > > srtp_unprotect(hbh_context, packet); > do_perc_stuff(packet); // Such as dealing with the OHB field > srtp_unprotect(e2e_context, packet); > > We could hide that extra step by having the library create the second > context under-the-covers or creating a wrapper layer around libsrtp (or > whatever SRTP library is employed). If we did not create overlapping > number spaces, this could be avoided. I don't get it. Given your sample above, it sounds to me that this issue is bound to happen exactly when you are not changing the SSRC because you have two crypto contexts for the same SSRC. You are actually avoiding that issue if you can be certain of using different SSRCs in HBH and E2E, which you can't anyway in either of the solutions we are discussing. What am I missing? > I personally think having overlapping number spaces is messy. And for > what? I still fail to see how performing a 1:1 mapping of an SSRC value > does anything to make building the MDD any easier. I am not sure if my previous explanations were unclear or unconvincing so I am just going to try and explain again: The way simulcast is being implemented in SFUs today is by having all the logic at the sender and at the SFU. There is never any of it in the receiver. This essentially means that the sender feeds two or three SSRCs to the SFU. The SFU then makes sure that what goes out on the other side is one single and coherent RTP flow with a single SSRC. This allows it to handle all the logic of layer switching including things like requesting keyframes, detecting layer drops, detecting keyframes during layer switches, timestamp uplifts and others. The receiver in this picture lives with the impression that it only ever gets a single video stream that simply happens to change its resolution every now and again. This makes things much simpler and quicker than trying to have the receiver detect and juggle with layers, request keyframes and such ... No receiver does that today and PERC would be a much tougher sell if you tried to get people to not only implement a new SRTP layer but also force them into adopting receiver side simulcast support which virtually no one does today. > In fact, I see it as > just more complexity. And, it's more complexity for the endpoint (as I > note above), juggling E2E and HBH SSRC values. I really fail to understand how immutable SSRCs would fix your issue above (and again, I am probably the one missing something here) but even with that I can assure you that having one extra libsrtp call is incomparably simpler than trying to get a receiver to handle simulcast layer switching. Emil -- https://jitsi.org From nobody Mon May 16 19:29:22 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 43E6212B018 for ; Mon, 16 May 2016 19:29:21 -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 CsjvjBM0SwPk for ; Mon, 16 May 2016 19:29: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 61B2912D585 for ; Mon, 16 May 2016 19:29:19 -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 u4H2THuT002208 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 May 2016 22:29:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463452158; bh=CQ+UaoQViHkDlnyO0vI8cHmXoUX8qKw0D9996wzz3XI=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=oUkDQ34uXGwwzX3WLikDL/c9hiCaDYO+rmpouh4Q8Cc7nIWlmJCkXCLLnjntFQ5qb lkh28T1rQT9dBu7fsJJ+2O8d+cNpgj1/cpKjlXsoeQtiwnXliljuXB77uWZQx/M0C8 1CfVpiy7nfRNJs3IdgHViIO4ryrMs1+m+vkbCIX8= From: "Paul E. Jones" To: "Emil Ivov" , "Adam Roach" , perc@ietf.org Date: Tue, 17 May 2016 02:29:23 +0000 Message-Id: In-Reply-To: <4a0ba091-74e3-3adf-7e2d-7ea5d7f76ebe@jitsi.org> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Mon, 16 May 2016 22:29:18 -0400 (EDT) Archived-At: 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: Tue, 17 May 2016 02:29:21 -0000 Emil, >>Having two SSRC numbering spaces that can overlap is unfortunate, >>though. Using libraries like libsrtp, we would need to have an E2E >>context and a HBH context. That is, we have to initialize the library >>twice, because every SSRC and related cryptograhic parameters, replay >>database, etc. expects a single number space. Thus, to decrypt a=20 >>packet >>we would have to do this: >> >> srtp_unprotect(hbh_context, packet); >> do_perc_stuff(packet); // Such as dealing with the OHB field >> srtp_unprotect(e2e_context, packet); > > >>We could hide that extra step by having the library create the second >>context under-the-covers or creating a wrapper layer around libsrtp=20 >>(or >>whatever SRTP library is employed). If we did not create overlapping >>number spaces, this could be avoided. > >I don't get it. Given your sample above, it sounds to me that this=20 >issue is bound to happen exactly when you are not changing the SSRC=20 >because you have two crypto contexts for the same SSRC. > >You are actually avoiding that issue if you can be certain of using=20 >different SSRCs in HBH and E2E, which you can't anyway in either of the= =20 >solutions we are discussing. > >What am I missing? So you see the example code I have above? It won't work, is the=20 problem. Let's say Alice uses SSRC 1 and Carol uses SSRC 1. Let's say=20 the MDD remaps those to 101 and 102, respectively. We can then do=20 srtp_unprotect() on the HBH packet, but then when we call=20 srtp_unprotect() for the E2E version (following the perc stuff), the=20 SRTP library will not be able to find the right crypto context, because=20 there are two SSRCs in the system that have the same value "1". That's=20 not valid. So, we'd have to program around this. It's doable, but it makes=20 everything more complicated. Maybe we initialize the SRTP library once=20 for every HBH SSRC (really ugly, IMO) or we pass to the "unprotect" call= =20 the HBH SSRC so that we then can look for some "extended" SSRC value=20 (some 64-bit value vs. 32-bit value). Anyway, I know what we'd need to do to handle the HBH/E2E number=20 overlapping problem, but it would be a heck of a lot easier if we just=20 avoid it to start with. If there is a conference-wide number space, we=20 don't have to jump through hoops to support this in the SRTP libraries. = =20 (There would still be work, but it's simpler and would require less code= =20 change. And, we could just use two SRTP instances as I showed above as=20 the laziest approach.) >>I personally think having overlapping number spaces is messy. And for >>what? I still fail to see how performing a 1:1 mapping of an SSRC=20 >>value >>does anything to make building the MDD any easier. > >I am not sure if my previous explanations were unclear or unconvincing=20 >so I am just going to try and explain again: I was unconvinced. :) >The way simulcast is being implemented in SFUs today is by having all=20 >the logic at the sender and at the SFU. There is never any of it in the= =20 >receiver. This essentially means that the sender feeds two or three=20 >SSRCs to the SFU. The SFU then makes sure that what goes out on the=20 >other side is one single and coherent RTP flow with a single SSRC. This= =20 >allows it to handle all the logic of layer switching including things=20 >like requesting keyframes, detecting layer drops, detecting keyframes=20 >during layer switches, timestamp uplifts and others. > >The receiver in this picture lives with the impression that it only=20 >ever gets a single video stream that simply happens to change its=20 >resolution every now and again. > >This makes things much simpler and quicker than trying to have the=20 >receiver detect and juggle with layers, request keyframes and such ... > >No receiver does that today and PERC would be a much tougher sell if=20 >you tried to get people to not only implement a new SRTP layer but also= =20 >force them into adopting receiver side simulcast support which=20 >virtually no one does today. I have assumed that the receiver would receive different media flows and= =20 perform local composition. The receiver would know that the video=20 resolution changed, but it would know why: because now it is receiving=20 PT=3D98 (360p) rather than PT=3D97 (1080p) and those are mapped to differen= t=20 simulcast flows in SDP (on the same m=3D line). Also, I had assumed that the sender will always send out 97 and 98 since= =20 it does not know when it will be the active speaker. It sends out both=20 flows and the MDD decides which of the two to forward to receivers (if=20 any at all). I think on this point, we have the same idea. Are you=20 assuming the same SSRC would be used for both flows in line with the=20 simulcast signaling spec? Thus, the difference might be in MDD behavior. Are you changing PTs=20 when the image size changes or using the same PT? I had assumed the PT=20 value will change. If you agree with that last paragraph on PT changing, then I'm left=20 wondering exactly what the difference is in the receiver. If the=20 receiver is expecting to get either 97 or 98, which is one size video=20 vs. another, then why would it care about the SSRC value. Either would=20 use same SSRC. Let's drill in on this a little, because maybe this is where we have the= =20 disconnect. >>In fact, I see it as >>just more complexity. And, it's more complexity for the endpoint (as=20 >>I >>note above), juggling E2E and HBH SSRC values. > >I really fail to understand how immutable SSRCs would fix your issue=20 >above (and again, I am probably the one missing something here) but=20 >even with that I can assure you that having one extra libsrtp call is=20 >incomparably simpler than trying to get a receiver to handle simulcast=20 >layer switching. Having immutable SSRCs does not fix an issue, because there isn't one. =20 Having mutable SSRCs, though, creates a problem where one did not exist=20 before. I suspect you have not encountered this, because you have a=20 single SSRC number space and you're doing one one decryption step at the= =20 receiver. With PERC doing both a HBH and E2E decryption step, having=20 potentially overlapping number spaces with collisions is a headache I'd=20 like to avoid. Paul From nobody Mon May 16 20:22: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 7755712D102 for ; Mon, 16 May 2016 20:22:46 -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 9nA2xdABr1Ce for ; Mon, 16 May 2016 20:22:44 -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 23EA012B022 for ; Mon, 16 May 2016 20:22:44 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x194so3585386ywd.0 for ; Mon, 16 May 2016 20:22:44 -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; bh=Dnt7aDTZUoRiOg+iU2U14lAyq3JCIhY/M+L9pe7E6II=; b=lODB6OFlZF394Rrlenbk+BALMLGgTg7lWuIAfeiF0Y1rd75H+XGy21KNx5rnYXMECQ Nly2azId3oivT7dviCD0JRHZpw9mdGr+CUE1Z/HM+vRcUsdm0tnHAVXQVD8LF6o4dVDY 51fX641SAvOuKr6HRHD8/4H/y8TOzoCqds6VphpuPrGEX5rbIHpG2WEoaY4xZwP80fE6 AdjgGyBIrYGOlsa5NEfq2sj1y6yJe8LVUsMui/tIZ5Gujkdfr8/xHKQu41+EvFKIC4DW uKxrHI/FsXYsr58yWghAzEX4dfb3VF9/MpoT79c9LWiwLIGA71ubgGtCk63TiBjbk6p4 JlOA== 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=Dnt7aDTZUoRiOg+iU2U14lAyq3JCIhY/M+L9pe7E6II=; b=TEKgD/YEEBUPFKvxa2NLyrzRUt2/yVCXPp1XftDgnMDBMVsLjStsdxTcj1wnWDFIrb /6fLiFRXVkVvGD6ivfn7+4K9zwO5eOYb8+zWaARQ2L98D2HPBgnH1WP6hXmnBogKTYYq QepPVCD4+OMIJFbh2lty5JdVxfItT/o3SGs1LhMx39Xp1crYksVdRk0qOmBZ9MaGXmsY KxND2xRHhkIHtHgikjnBWUBlUI9x5P/j19Q4+TMfqS6Ysnbucnr09cksx/t6qd7NDhSA mmDq8XtJjEylnjRpla73RyafhTRm+TeDx80qKlTOTaD2IkGc/A9jNho7HMN633yomKpU 0vYA== X-Gm-Message-State: AOPr4FUaOsYUyC3DfglBqtc9VK7b/FnGxwkfccrIn489zRuJo7ZLljwRhlpUwBd9S01GQw== X-Received: by 10.13.215.75 with SMTP id z72mr17559875ywd.278.1463455363216; Mon, 16 May 2016 20:22:43 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com. [209.85.161.173]) by smtp.gmail.com with ESMTPSA id d68sm438994ywe.53.2016.05.16.20.22.42 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 20:22:42 -0700 (PDT) Received: by mail-yw0-f173.google.com with SMTP id g133so3552202ywb.2 for ; Mon, 16 May 2016 20:22:42 -0700 (PDT) X-Received: by 10.37.33.65 with SMTP id h62mr16288122ybh.58.1463455362338; Mon, 16 May 2016 20:22:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.6.138 with HTTP; Mon, 16 May 2016 20:22:22 -0700 (PDT) In-Reply-To: References: <4a0ba091-74e3-3adf-7e2d-7ea5d7f76ebe@jitsi.org> From: Emil Ivov Date: Mon, 16 May 2016 22:22:22 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Roach , 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: Tue, 17 May 2016 03:22:46 -0000 Hey Paul, On Mon, May 16, 2016 at 9:29 PM, Paul E. Jones wrote: > Emil, > > >>> Having two SSRC numbering spaces that can overlap is unfortunate, >>> though. Using libraries like libsrtp, we would need to have an E2E >>> context and a HBH context. That is, we have to initialize the library >>> twice, because every SSRC and related cryptograhic parameters, replay >>> database, etc. expects a single number space. Thus, to decrypt a packet >>> we would have to do this: >>> >>> srtp_unprotect(hbh_context, packet); >>> do_perc_stuff(packet); // Such as dealing with the OHB field >>> srtp_unprotect(e2e_context, packet); >> >> > >>> >>> We could hide that extra step by having the library create the second >>> context under-the-covers or creating a wrapper layer around libsrtp (or >>> whatever SRTP library is employed). If we did not create overlapping >>> number spaces, this could be avoided. >> >> >> I don't get it. Given your sample above, it sounds to me that this issue >> is bound to happen exactly when you are not changing the SSRC because you >> have two crypto contexts for the same SSRC. >> >> You are actually avoiding that issue if you can be certain of using >> different SSRCs in HBH and E2E, which you can't anyway in either of the >> solutions we are discussing. >> >> What am I missing? > > > So you see the example code I have above? It won't work, is the problem. > Let's say Alice uses SSRC 1 and Carol uses SSRC 1. Let's say the MDD remaps > those to 101 and 102, respectively. > We can then do srtp_unprotect() on the > HBH packet, but then when we call srtp_unprotect() for the E2E version > (following the perc stuff), the SRTP library will not be able to find the > right crypto context, because there are two SSRCs in the system that have > the same value "1". That's not valid. If you are concerned about that, you could have simply chosen to have the SSRC collision obvious to Alice or Carol. > So, we'd have to program around this. It's doable, but it makes everything > more complicated. Maybe we initialize the SRTP library once for every HBH > SSRC (really ugly, IMO) > or we pass to the "unprotect" call the HBH SSRC so > that we then can look for some "extended" SSRC value (some 64-bit value vs. > 32-bit value). > Anyway, I know what we'd need to do to handle the HBH/E2E number overlapping > problem, but it would be a heck of a lot easier if we just avoid it to start > with. If there is a conference-wide number space, we don't have to jump > through hoops to support this in the SRTP libraries. (There would still be > work, but it's simpler and would require less code change. And, we could > just use two SRTP instances as I showed above as the laziest approach.) OK. There are two things that are wrong with this argument. First: There is absolutely nothing that prevents you from keeping a single SSRC space. This is exactly what we do. SSRC rewriting does not in any way imply creating a new context for every SSRC. In fact it may very often mean simply reducing the number of SSRCs that are visible to receivers. Second: There is absolutely nothing that requires your MDD to actually do SSRC rewriting. If you don't like it: don't do it. >>> I personally think having overlapping number spaces is messy. And for >>> what? I still fail to see how performing a 1:1 mapping of an SSRC value >>> does anything to make building the MDD any easier. >> >> >> I am not sure if my previous explanations were unclear or unconvincing so >> I am just going to try and explain again: > > I was unconvinced. :) > > >> The way simulcast is being implemented in SFUs today is by having all the >> logic at the sender and at the SFU. There is never any of it in the >> receiver. This essentially means that the sender feeds two or three SSRCs to >> the SFU. The SFU then makes sure that what goes out on the other side is one >> single and coherent RTP flow with a single SSRC. This allows it to handle >> all the logic of layer switching including things like requesting keyframes, >> detecting layer drops, detecting keyframes during layer switches, timestamp >> uplifts and others. >> >> The receiver in this picture lives with the impression that it only ever >> gets a single video stream that simply happens to change its resolution >> every now and again. >> >> This makes things much simpler and quicker than trying to have the >> receiver detect and juggle with layers, request keyframes and such ... >> >> No receiver does that today and PERC would be a much tougher sell if you >> tried to get people to not only implement a new SRTP layer but also force >> them into adopting receiver side simulcast support which virtually no one >> does today. > > I have assumed that the receiver would receive different media flows and > perform local composition. > > The receiver would know that the video > resolution changed, but it would know why: because now it is receiving PT=98 > (360p) rather than PT=97 (1080p) and those are mapped to different simulcast > flows in SDP (on the same m= line). That is not how most of the popular SFUs work today. > Also, I had assumed that the sender will always send out 97 and 98 since it > does not know when it will be the active speaker. It sends out both flows > and the MDD decides which of the two to forward to receivers (if any at > all). I think on this point, we have the same idea. We don't. There is no reason for the sender to use different payload types, as long as it uses different SSRCs. > Are you assuming the > same SSRC would be used for both flows in line with the simulcast signaling > spec? > > Thus, the difference might be in MDD behavior. Are you changing PTs when > the image size changes or using the same PT? I had assumed the PT value > will change. It will not. Regardless of whether the PT changes at the sender, the receiver will always get a single continuous and coherent RTP stream with the same SSRC, the same PT, continuous seq. nums and continuous timestamps. > If you agree with that last paragraph on PT changing, then I'm left > wondering exactly what the difference is in the receiver. If the receiver > is expecting to get either 97 or 98, which is one size video vs. another, > then why would it care about the SSRC value. Either would use same SSRC. > > Let's drill in on this a little, because maybe this is where we have the > disconnect. I hope this clarifies things. >>> In fact, I see it as >>> just more complexity. And, it's more complexity for the endpoint (as I >>> note above), juggling E2E and HBH SSRC values. >> >> >> I really fail to understand how immutable SSRCs would fix your issue above >> (and again, I am probably the one missing something here) but even with that >> I can assure you that having one extra libsrtp call is incomparably simpler >> than trying to get a receiver to handle simulcast layer switching. > > > Having immutable SSRCs does not fix an issue, because there isn't one. And there is no reason why you would need to have one with SSRC rewriting. If your worry is only about conflict detection then let's just require a single SSRC space per conference as part of PERC. I would have no problem with that. > Having mutable SSRCs, though, creates a problem where one did not exist > before. I suspect you have not encountered this, because you have a single > SSRC number space and you're doing one one decryption step at the receiver. > With PERC doing both a HBH and E2E decryption step, having potentially > overlapping number spaces with collisions is a headache I'd like to avoid. Again, I think that issue is far smaller than reimplementing simulcast but if we have consensus on trying to avoid it then let's just work on that and avoid throwing the baby with the bath water. Emil -- https://jitsi.org From nobody Mon May 16 22:28: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 2150B12D12A for ; Mon, 16 May 2016 22:28:42 -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 y40zXlcqw6yO for ; Mon, 16 May 2016 22:28:40 -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 318A012D122 for ; Mon, 16 May 2016 22:28:40 -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 u4H5SclX014252 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 May 2016 01:28:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1463462919; bh=wjuMDDY+ZSEYAwHltZgAk6HrNPSn2wLX20K/fIrAXCM=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=KmRvkQ8XQ9T3EQF5gls22AZHcN8gjfLDlMzVcrL8XudrR/tDlR8m+sxY04V/4C76o N8UG9Cgfc9E8JbnLflphB5lApMyt+G/AZca4awLuQt5GlhgBaH0wtWcvLV+liZ2oUI 5eTRBLjRd5hU9QKLT95du2iS8dbzqu9QQlkasVUY= From: "Paul E. Jones" To: "Emil Ivov" Date: Tue, 17 May 2016 05:28:45 +0000 Message-Id: In-Reply-To: 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.5.16 (dublin.packetizer.com [10.137.60.122]); Tue, 17 May 2016 01:28:39 -0400 (EDT) Archived-At: Cc: Adam Roach , perc@ietf.org 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: Tue, 17 May 2016 05:28:42 -0000 Emil, >> So you see the example code I have above? It won't work, is the=20 >>problem. >> Let's say Alice uses SSRC 1 and Carol uses SSRC 1. Let's say the MDD= =20 >>remaps >> those to 101 and 102, respectively. >> We can then do srtp_unprotect() on the >> HBH packet, but then when we call srtp_unprotect() for the E2E=20 >>version >> (following the perc stuff), the SRTP library will not be able to find= =20 >>the >> right crypto context, because there are two SSRCs in the system that= =20 >>have >> the same value "1". That's not valid. > >If you are concerned about that, you could have simply chosen to have >the SSRC collision obvious to Alice or Carol. It would be unfortunate to have to statically assign SSRCs to endpoints=20 and m=3D lines. >> So, we'd have to program around this. It's doable, but it makes=20 >>everything >> more complicated. Maybe we initialize the SRTP library once for=20 >>every HBH >> SSRC (really ugly, IMO) >> or we pass to the "unprotect" call the HBH SSRC so >> that we then can look for some "extended" SSRC value (some 64-bit=20 >>value vs. >> 32-bit value). >> Anyway, I know what we'd need to do to handle the HBH/E2E number=20 >>overlapping >> problem, but it would be a heck of a lot easier if we just avoid it=20 >>to start >> with. If there is a conference-wide number space, we don't have to=20 >>jump >> through hoops to support this in the SRTP libraries. (There would=20 >>still be >> work, but it's simpler and would require less code change. And, we=20 >>could >> just use two SRTP instances as I showed above as the laziest=20 >>approach.) > >OK. There are two things that are wrong with this argument. > >First: There is absolutely nothing that prevents you from keeping a >single SSRC space. This is exactly what we do. SSRC rewriting does not >in any way imply creating a new context for every SSRC. In fact it may >very often mean simply reducing the number of SSRCs that are visible >to receivers. I can do that by not mapping SSRCs. If we map SSRCs, we then create the complex problem of ensuring that=20 every entity uses an SSRC that no other entity is using. That gets=20 really complex when there are cascaded MDDs and lots of endpoints=20 hanging off each one. >Second: There is absolutely nothing that requires your MDD to actually >do SSRC rewriting. If you don't like it: don't do it. It's far less of an MDD issue than an endpoint issue. The endpoint will= =20 be responsible for decrypting the packet using HBH authenticated=20 encryption. Then, it needs to modify the RTP headers to put the=20 original packet back into the buffer. Then it needs to decrypt using=20 the E2E cipher. This is where it gets messy. It needs to look up this=20 context. It could use the HBH context, and have data hanging off of=20 that for E2E. That would work. But, the normal SRTP processing would=20 want to do replay protection. We'd have to disable that to avoid the=20 stack getting confused over the fact there is "1" from Alice and "1"=20 from Carol. The challenge we face here is on the receiver when there=20 are collisions in the E2E numbering space. Again, if we don't re-write, we don't have this problem. >>>... >>> No receiver does that today and PERC would be a much tougher sell if= =20 >>>you >>> tried to get people to not only implement a new SRTP layer but also= =20 >>>force >>> them into adopting receiver side simulcast support which virtually=20 >>>no one >>> does today. >> >> I have assumed that the receiver would receive different media flows= =20 >>and >> perform local composition. >> >> The receiver would know that the video >> resolution changed, but it would know why: because now it is=20 >>receiving PT=3D98 >> (360p) rather than PT=3D97 (1080p) and those are mapped to different= =20 >>simulcast >> flows in SDP (on the same m=3D line). > >That is not how most of the popular SFUs work today. Isn't that how the current I-Ds specify it? Are you describing a=20 proprietary transmission logic? >> Also, I had assumed that the sender will always send out 97 and 98=20 >>since it >> does not know when it will be the active speaker. It sends out both= =20 >>flows >> and the MDD decides which of the two to forward to receivers (if any= =20 >>at >> all). I think on this point, we have the same idea. > >We don't. There is no reason for the sender to use different payload >types, as long as it uses different SSRCs. You're suggesting the same media source use different SSRCs? Why? It=20 seems like this is just one more place where things can get complex and=20 not be within the spirit of RFC 3550. (And I'll ignore that big ol'=20 statement in RFC 3550 that says audio and video should not be=20 multiplexed in the same RTP session, since WebRTC clearly violates that=20 and everybody thought that was just fine. :P ). >> Are you assuming the >> same SSRC would be used for both flows in line with the simulcast=20 >>signaling >> spec? >> >> Thus, the difference might be in MDD behavior. Are you changing PTs= =20 >>when >> the image size changes or using the same PT? I had assumed the PT=20 >>value >> will change. > >It will not. Regardless of whether the PT changes at the sender, the >receiver will always get a single continuous and coherent RTP stream >with the same SSRC, the same PT, continuous seq. nums and continuous >timestamps. Now add to that an SSRC from the sender and one from the MDD, and do=20 authenticated encryption on each one. It's doable, but complicated. With the current PERC proposal, the SSRCs would be constant, so not an=20 issue. PT value would change for multicast per the current I-Ds,=20 otherwise PT values are constant. Sequence numbers can change to=20 produce sequential numbers per RFC 3550. So, it appears it's still an difference of opinion about how the=20 receiver is to deal with overlapping SSRC number spaces. With PERC the=20 group agreed to have one number space. With what you're proposing,=20 there are two number spaces: the original source SSRC space and the MDD=20 space. >> If you agree with that last paragraph on PT changing, then I'm left >> wondering exactly what the difference is in the receiver. If the=20 >>receiver >> is expecting to get either 97 or 98, which is one size video vs.=20 >>another, >> then why would it care about the SSRC value. Either would use same=20 >>SSRC. >> >> Let's drill in on this a little, because maybe this is where we have= =20 >>the >> disconnect. > >I hope this clarifies things. I think so, but I do feel changing the SSRC is making things complex. >> Having mutable SSRCs, though, creates a problem where one did not=20 >>exist >> before. I suspect you have not encountered this, because you have a=20 >>single >> SSRC number space and you're doing one one decryption step at the=20 >>receiver. >> With PERC doing both a HBH and E2E decryption step, having=20 >>potentially >> overlapping number spaces with collisions is a headache I'd like to=20 >>avoid. > >Again, I think that issue is far smaller than reimplementing simulcast >but if we have consensus on trying to avoid it then let's just work on >that and avoid throwing the baby with the bath water. I think an important revelation that arose from this dialog is that the=20 decision to change the SSRC or not will have an impact on the receiving=20 terminal. Significantly, this is true regardless of whether PERC exists= =20 or not. If we follow the current I-Ds on simulcast, then receivers you=20 describe that do not properly deal with switching based on PT values=20 will not work right. With the specs being driven in the IETF, SSRCs do=20 not change. PERC is consistent with that approach. Importantly, the=20 PERC and IETF simulcast approach also appears consistent with RFC 3550. If we allow SSRC values to change, there is an incompatibility with the=20 current simulcast specs. And for PERC, it presents a challenge in=20 effectively performing HBH and E2E decryption. The HBH part is easy,=20 but then we have to deal with potential collisions in the SSRC number=20 space for E2E. Paul From nobody Tue May 17 08:11:39 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 D702E12D1AA for ; Tue, 17 May 2016 08:11:37 -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 gpEnr9nyr7LY for ; Tue, 17 May 2016 08:11:36 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 EACA412D16F for ; Tue, 17 May 2016 08:11:35 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 206so7937291pfu.0 for ; Tue, 17 May 2016 08:11:35 -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=EjshxAU7gpAC/HLiH21VkfsMdNH7Fnf5glZyBvmmnf4=; b=f4yPR6s3wo/B9yl40+f5IU7C5sNfA5DNL1ODkBZRwtAIrYEH/lV6gkl/GMvO37lI84 nv+nqJSs6aphAGz6YPXZqJSkOxWgbfYopkEoGVYszgC89mrctwBvwldAxrxKpNm4SxpP u4+tjuhQifpSld8FLMoIU/0MyupoFp4dqxvC1OEA0peezhdGkJvAMCJUp+liRpuqcbCs caGG0lV9vtCiYyBRBrC2fGEKfP5pkuSnOP32tsA3iZZsfQ2AqoPwMNBTO8J6FIkBYrBl uccpXKCG6yAJKhZSRAmtRiaWlWdHYEL0ihpRFUYde3jOx5bMJAoQpqQxjAlEUdTn4WwS nJWA== 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=EjshxAU7gpAC/HLiH21VkfsMdNH7Fnf5glZyBvmmnf4=; b=DeUgp/+nVmb1nWBP02EYWBVVjn9oITT+PPSO30LNZ4QpnOy3+VxPItFQHBfsu3gZa7 BWw8ngqtZZeXirXttYa9XE0eQisCOTawEuU4q4OvmV7P1vuC22sKbEef0oKJPBIDuzlm Qst+pm8VBTLHQsdcXyYAdADif83REQ/jSZQDOF2LEjkRCXm1KlGURYwYc5wwElMWhbyv pkrGRqGjo/wXYjgTFfdeQJVflvxbxuacz/ldVRrW8bAk2cbaSmg4i+nNV1btWojtwk+0 U8yVc+zy9M7rPUhKtp8UE77xEX6W2bJA12Ju20ieQOajt9J+IVUMgCvvRcNZwzD09RnE oy2w== X-Gm-Message-State: AOPr4FW7F7LazR1O2VewZsgOxW3mwrdkU5NDack7DgL6yldBipGGGUOmUVY+v59TfNu7LA== X-Received: by 10.98.77.199 with SMTP id a190mr2783812pfb.37.1463497895507; Tue, 17 May 2016 08:11:35 -0700 (PDT) Received: from [192.168.1.104] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id e2sm5595027pfd.20.2016.05.17.08.11.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 08:11:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (13E238) In-Reply-To: <4a0ba091-74e3-3adf-7e2d-7ea5d7f76ebe@jitsi.org> Date: Tue, 17 May 2016 08:11:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a0ba091-74e3-3adf-7e2d-7ea5d7f76ebe@jitsi.org> To: Emil Ivov Archived-At: Cc: Adam Roach , 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: Tue, 17 May 2016 15:11:38 -0000 On May 16, 2016, at 18:50, Emil Ivov wrote: >=20 > No receiver does that today and PERC would be a much tougher sell if you t= ried to get people to not only implement a new SRTP layer but also force the= m into adopting receiver side simulcast support which virtually no one does t= oday. [BA] It is worse than that. WebRTC 1.0 API does not support simulcast recept= ion (only sending). ORTC does support reception, but only ORTC Lib implement= s this in a general way (non-codec specific) and doing so adds quite a bit o= f complexity so it is not clear that feature is worth keeping.= From nobody Tue May 17 11:22:27 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 EBF0012D5C7 for ; Tue, 17 May 2016 11:22:25 -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 EXavbvD8Cx2o for ; Tue, 17 May 2016 11:22:24 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 E7E0412D5C1 for ; Tue, 17 May 2016 11:22:23 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id k142so38847031oib.1 for ; Tue, 17 May 2016 11:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=fkUbgcspWWKP17+gPmIpiKa8NmGKdLKJhPQDSJ3aTi0=; b=G1VswpwFmPH/5qXsmzwN33qXmI+MnqqGzUSSnVu1MyH6fbGmOnytHnzu0dnKhgmNbd mu7QPHyML5p0fdBplWMH5iqWJf84OPBqvAM7mezKZIZiJfU4lAg09yStDewozL5uBbKp 6JoP0klZXaszrpOdJpNcfirCYvmgWmzJICcMjtYM11BryAPAq14F86oC+kefg2P78E+r SlKFSK84S2zBn4PLL2Q8753PSSqzYuz6N1Dvb21nCkxrJWfZ5Ts8ERtuBTz08OzYyG2B QduVSEEgUNt1sgQFA/aK14iLvOhApRihVZfZdtsUcdk9XoPwXtL2C2P5s/Pit+eiEwpg gN2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fkUbgcspWWKP17+gPmIpiKa8NmGKdLKJhPQDSJ3aTi0=; b=XUT+JC2b9CnF125iVOrdgK6mktJjiah/PMXh9wHzYvkdjL5+UxfAl05Gh8DYauK+HV WFtjqBwv1N01BymKnEC1UguFQSjZLKhAE59ixDg8/TivHIFZgYew5KvKrRHFwLI0syJo WcPZ0AOQcyxI542eV4v5tY4koh7+8cYDmHAd2UhWRfyKL5ID/zHaGZp/R15g1peEef+e CSzdRDikdV1LoEeCMO4z+rwFSnEmOAjPPDSH36ymMjEgQNHnilm/jkRKak8SxHpyuCZr uBSivWw7mii3iO47dT7YekDeT+V5aH/DMsMSlL1EoRV8zM8AVfWGupd4YNUgHgJm9iYZ dV6Q== X-Gm-Message-State: AOPr4FVO73snKsu/qx5vVYdibz7zYBTLRGfYwzVhTNPjLs03b1YYhe4FJnKRcteV59LIJA== X-Received: by 10.157.46.177 with SMTP id w46mr1501962ota.181.1463509343135; Tue, 17 May 2016 11:22:23 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id b45sm1098016ote.35.2016.05.17.11.22.21 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 11:22:21 -0700 (PDT) To: "Paul E. Jones" References: From: Emil Ivov Message-ID: <8a144972-b88a-1ddc-f71a-8be0d10b1b5b@jitsi.org> Date: Tue, 17 May 2016 13:22:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Adam Roach , 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: Tue, 17 May 2016 18:22:26 -0000 Hey Paul, On 17.05.16 г. 0:28, Paul E. Jones wrote: > Emil, >>> So you see the example code I have above? It won't work, is the >>> problem. >>> Let's say Alice uses SSRC 1 and Carol uses SSRC 1. Let's say the >>> MDD remaps >>> those to 101 and 102, respectively. >>> We can then do srtp_unprotect() on the >>> HBH packet, but then when we call srtp_unprotect() for the E2E version >>> (following the perc stuff), the SRTP library will not be able to >>> find the >>> right crypto context, because there are two SSRCs in the system that >>> have >>> the same value "1". That's not valid. >> >> If you are concerned about that, you could have simply chosen to have >> the SSRC collision obvious to Alice or Carol. > > It would be unfortunate to have to statically assign SSRCs to endpoints > and m= lines. I have no idea what you mean and why we are talking about static SSRCs. What I meant was that if you want to use the native SSRC collision mechanism then you can and we should just state that as a constraint. There is nothing that justifies the jump from there to "DO NOT OVERWRITE" It is up to implementers to decide how to enforce it and the native 3550 mechanism is very much still workable. In other words: do not assume that SSRC overwriting necessarily implies new SSRCs. >>> So, we'd have to program around this. It's doable, but it makes >>> everything >>> more complicated. Maybe we initialize the SRTP library once for >>> every HBH >>> SSRC (really ugly, IMO) >>> or we pass to the "unprotect" call the HBH SSRC so >>> that we then can look for some "extended" SSRC value (some 64-bit >>> value vs. >>> 32-bit value). >>> Anyway, I know what we'd need to do to handle the HBH/E2E number >>> overlapping >>> problem, but it would be a heck of a lot easier if we just avoid it >>> to start >>> with. If there is a conference-wide number space, we don't have to >>> jump >>> through hoops to support this in the SRTP libraries. (There would >>> still be >>> work, but it's simpler and would require less code change. And, we >>> could >>> just use two SRTP instances as I showed above as the laziest approach.) >> >> OK. There are two things that are wrong with this argument. >> >> First: There is absolutely nothing that prevents you from keeping a >> single SSRC space. This is exactly what we do. SSRC rewriting does not >> in any way imply creating a new context for every SSRC. In fact it may >> very often mean simply reducing the number of SSRCs that are visible >> to receivers. > > I can do that by not mapping SSRCs. > > If we map SSRCs, we then create the complex problem of ensuring that > every entity uses an SSRC that no other entity is using. That is not correct as I stated above. > That gets > really complex when there are cascaded MDDs and lots of endpoints > hanging off each one. It really doesn't. Of courses there are cases where it might but just the fact that you are overwriting some SSRCs doesn't mean that you are automatically in one of those cases. >> Second: There is absolutely nothing that requires your MDD to actually >> do SSRC rewriting. If you don't like it: don't do it. > > It's far less of an MDD issue than an endpoint issue. The endpoint will > be responsible for decrypting the packet using HBH authenticated > encryption. Then, it needs to modify the RTP headers to put the > original packet back into the buffer. Then it needs to decrypt using > the E2E cipher. This is where it gets messy. It needs to look up this > context. It could use the HBH context, and have data hanging off of > that for E2E. That would work. But, the normal SRTP processing would > want to do replay protection. We'd have to disable that to avoid the > stack getting confused over the fact there is "1" from Alice and "1" > from Carol. The challenge we face here is on the receiver when there > are collisions in the E2E numbering space. > > Again, if we don't re-write, we don't have this problem. Again: I don't think you need to do these things just because you are re-writing. Even if you did though you are still looking at a much lesser effort than the one you are facing if you ask people to do simulcast your way. >>>> ... >>>> No receiver does that today and PERC would be a much tougher sell >>>> if you >>>> tried to get people to not only implement a new SRTP layer but also >>>> force >>>> them into adopting receiver side simulcast support which virtually >>>> no one >>>> does today. >>> >>> I have assumed that the receiver would receive different media flows >>> and >>> perform local composition. >>> >>> The receiver would know that the video >>> resolution changed, but it would know why: because now it is >>> receiving PT=98 >>> (360p) rather than PT=97 (1080p) and those are mapped to different >>> simulcast >>> flows in SDP (on the same m= line). >> >> That is not how most of the popular SFUs work today. > > Isn't that how the current I-Ds specify it? Are you describing a > proprietary transmission logic? The current simulcast I-Ds have had their faire share of controversy so I wouldn't rely too much on them as the only compatibility threshold to pass. If http only allowed and in fact required a single form of "standard" html, then the world would be a very different place today. >>> Also, I had assumed that the sender will always send out 97 and 98 >>> since it >>> does not know when it will be the active speaker. It sends out both >>> flows >>> and the MDD decides which of the two to forward to receivers (if any at >>> all). I think on this point, we have the same idea. >> >> We don't. There is no reason for the sender to use different payload >> types, as long as it uses different SSRCs. > > You're suggesting the same media source use different SSRCs? Difference SSRCs for the same physical device yes. > Why? I find that "Why should we use different PTs for the same payload" is a more appropriate question. We have different sources in all ways that matter. They may (and often do) have different timestamp bases, different sequence numbering ... > It > seems like this is just one more place where things can get complex and > not be within the spirit of RFC 3550. Huh? Aside from the complexity comment being completely subjective here (certainly entirely contrary to our experience) how the heck does that contradict 3550??? > (And I'll ignore that big ol' > statement in RFC 3550 that says audio and video should not be > multiplexed in the same RTP session, since WebRTC clearly violates that > and everybody thought that was just fine. :P ). Wait, what??? How did we even get audio involved here? I fail to see the relevance that this has to ... anything. >>> Are you assuming the >>> same SSRC would be used for both flows in line with the simulcast >>> signaling >>> spec? >>> >>> Thus, the difference might be in MDD behavior. Are you changing PTs >>> when >>> the image size changes or using the same PT? I had assumed the PT >>> value >>> will change. >> >> It will not. Regardless of whether the PT changes at the sender, the >> receiver will always get a single continuous and coherent RTP stream >> with the same SSRC, the same PT, continuous seq. nums and continuous >> timestamps. > > Now add to that an SSRC from the sender and one from the MDD, and do > authenticated encryption on each one. It's doable, but complicated. Completely lost you. Why would I be adding SSRCs? For what reason? Just to make your arguments work? The whole point of what I am describing is that the receiver only sees one SSRC for one stream. > With the current PERC proposal, the SSRCs would be constant, so not an > issue. PT value would change for multicast per the current I-Ds, > otherwise PT values are constant. Sequence numbers can change to > produce sequential numbers per RFC 3550. > > So, it appears it's still an difference of opinion about how the > receiver is to deal with overlapping SSRC number spaces. With PERC the > group agreed to have one number space. With what you're proposing, > there are two number spaces: the original source SSRC space and the MDD > space. Please do not say that again. I explained multiple times already why this is not true. Please stop misrepresenting. >>> If you agree with that last paragraph on PT changing, then I'm left >>> wondering exactly what the difference is in the receiver. If the >>> receiver >>> is expecting to get either 97 or 98, which is one size video vs. >>> another, >>> then why would it care about the SSRC value. Either would use same >>> SSRC. >>> >>> Let's drill in on this a little, because maybe this is where we have >>> the >>> disconnect. >> >> I hope this clarifies things. > > I think so, but I do feel changing the SSRC is making things complex. Again, I am inviting you to look at how WebRTC SFUs do that. I am happy to get on a call with you and walk you through it. >>> Having mutable SSRCs, though, creates a problem where one did not exist >>> before. I suspect you have not encountered this, because you have a >>> single >>> SSRC number space and you're doing one one decryption step at the >>> receiver. >>> With PERC doing both a HBH and E2E decryption step, having potentially >>> overlapping number spaces with collisions is a headache I'd like to >>> avoid. >> >> Again, I think that issue is far smaller than reimplementing simulcast >> but if we have consensus on trying to avoid it then let's just work on >> that and avoid throwing the baby with the bath water. > > I think an important revelation that arose from this dialog is that the > decision to change the SSRC or not will have an impact on the receiving > terminal. > > Significantly, this is true regardless of whether PERC exists > or not. If we follow the current I-Ds on simulcast, then receivers you > describe that do not properly deal with switching based on PT values > will not work right. With the specs being driven in the IETF, SSRCs do > not change. PERC is consistent with that approach. Importantly, the > PERC and IETF simulcast approach also appears consistent with RFC 3550. > > If we allow SSRC values to change, there is an incompatibility with the > current simulcast specs. And for PERC, it presents a challenge in > effectively performing HBH and E2E decryption. The HBH part is easy, > but then we have to deal with potential collisions in the SSRC number > space for E2E. The conclusion here is simply wrong and the only revelation I see is that the reasoning for avoiding SSRC modifications have much more to do with subjective preferences than with rational arguments. Emil -- https://jitsi.org From nobody Tue May 17 13:31:16 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 5CF9E12D9D0 for ; Tue, 17 May 2016 13:31:14 -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 b4BZEPkJRV9X for ; Tue, 17 May 2016 13:31:11 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c: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 DF0D912D9C8 for ; Tue, 17 May 2016 13:31:10 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id z184so35570922vkg.0 for ; Tue, 17 May 2016 13:31:10 -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=Yp8wp0z6T8WrRlgR9IjwvkNyUb0I5yhzhu23K/DsZPY=; b=vcvSR9Iu/t1E1VfeRU9QiCabH6XNu1W9IDyP6TFJ52tEqUndR0qR5qNBWZZK3Q+BuU Yc5KymElL9lac211td4jFqG1lKDhNP1G3JXi4taqyZrahlMmMmUho6/qzEFcO+heaxmq PtHsleaADE+EXPehQNzTnGYyF/vcVoKsWx4CEJl3kd1tdZKaOoz/aQyCFoQmjyyqTdPy PDNmO8YTB+80BW+kzZUCO6m8RQz1LB1yvWb6ENuWGJ0ug4EawK9xVSVITul8PAK/7W2c 4YneP7mlhrRWr1F3apeQqKWJnSL4/Jpg4CKmPgPqB/ouoAnMnebcOLdr5myWUyoh4jHv YX3g== 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=Yp8wp0z6T8WrRlgR9IjwvkNyUb0I5yhzhu23K/DsZPY=; b=epdw0BGE8L3EH1duS7stLUcdQ2MKqUCkR5sYw9trSedh1lEm12mN5B7Q0u2rsC84c1 Z+/WCadQQMN/vK3u+oIaw1+4IfM8i0oHu0ndG8oQ+alvH43rIJJI99i1Wz0Tpw9AIyEN 0Nv18KljtWtE697tS8IDUwd2aidF908jAERm95+ewSrkfKSS2e7TFfPnWe40R4mGjq13 g6Irt27FMH/va22yBhil4ZJTpAaDlrgmPsBh09in1kMR8+3rDWJhho7B7/dOGgrFmrp5 nx0ORCWQhHLIogEnMsATD27gBHfIozmthmqWjrhWz510y/ePlINWzL7Lx/MWWI7O1jZx 7jIw== X-Gm-Message-State: AOPr4FVa5QXbOr0TjpypflsZzIHla1Y0/cknnH0z9EpNGJv4JDOJ8/nJpbT8LCXSn73ZfNoPCV0edO0qAnnCZQ== X-Received: by 10.31.98.135 with SMTP id w129mr1666084vkb.106.1463517070015; Tue, 17 May 2016 13:31:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.102 with HTTP; Tue, 17 May 2016 13:30:50 -0700 (PDT) In-Reply-To: <8a144972-b88a-1ddc-f71a-8be0d10b1b5b@jitsi.org> References: <8a144972-b88a-1ddc-f71a-8be0d10b1b5b@jitsi.org> From: Bernard Aboba Date: Tue, 17 May 2016 13:30:50 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=94eb2c094e6814e64005330f9ff1 Archived-At: Cc: "Paul E. Jones" , Adam Roach , 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: Tue, 17 May 2016 20:31:14 -0000 --94eb2c094e6814e64005330f9ff1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Emil said: > If we map SSRCs, we then create the complex problem of ensuring that > every entity uses an SSRC that no other entity is using. > That is not correct as I stated above. [BA] It seems to me that PERC is making some assumptions about the RTP topology which need to be made explicit. For example, is PERC assuming an RTP translator topology? Since few (any?) existing SFUs support the RTP translator topology, that is going to limit applicability. In a topology where the SFU is the RTP/RTCP endpoint (and modifies SSRCs), = RTCP SDES/BYE messages are typically modified as well so that SSRC collisions can only occur between the endpoint and the SFU, On Tue, May 17, 2016 at 11:22 AM, Emil Ivov wrote: > Hey Paul, > > On 17.05.16 =D0=B3. 0:28, Paul E. Jones wrote: > >> Emil, >> >>> So you see the example code I have above? It won't work, is the >>>> problem. >>>> Let's say Alice uses SSRC 1 and Carol uses SSRC 1. Let's say the >>>> MDD remaps >>>> those to 101 and 102, respectively. >>>> We can then do srtp_unprotect() on the >>>> HBH packet, but then when we call srtp_unprotect() for the E2E versio= n >>>> (following the perc stuff), the SRTP library will not be able to >>>> find the >>>> right crypto context, because there are two SSRCs in the system that >>>> have >>>> the same value "1". That's not valid. >>>> >>> >>> If you are concerned about that, you could have simply chosen to have >>> the SSRC collision obvious to Alice or Carol. >>> >> >> It would be unfortunate to have to statically assign SSRCs to endpoints >> and m=3D lines. >> > > I have no idea what you mean and why we are talking about static SSRCs. > What I meant was that if you want to use the native SSRC collision > mechanism then you can and we should just state that as a constraint. The= re > is nothing that justifies the jump from there to "DO NOT OVERWRITE" > > It is up to implementers to decide how to enforce it and the native 3550 > mechanism is very much still workable. > > In other words: do not assume that SSRC overwriting necessarily implies > new SSRCs. > > So, we'd have to program around this. It's doable, but it makes >>>> everything >>>> more complicated. Maybe we initialize the SRTP library once for >>>> every HBH >>>> SSRC (really ugly, IMO) >>>> or we pass to the "unprotect" call the HBH SSRC so >>>> that we then can look for some "extended" SSRC value (some 64-bit >>>> value vs. >>>> 32-bit value). >>>> Anyway, I know what we'd need to do to handle the HBH/E2E number >>>> overlapping >>>> problem, but it would be a heck of a lot easier if we just avoid it >>>> to start >>>> with. If there is a conference-wide number space, we don't have to >>>> jump >>>> through hoops to support this in the SRTP libraries. (There would >>>> still be >>>> work, but it's simpler and would require less code change. And, we >>>> could >>>> just use two SRTP instances as I showed above as the laziest approach= .) >>>> >>> >>> OK. There are two things that are wrong with this argument. >>> >>> First: There is absolutely nothing that prevents you from keeping a >>> single SSRC space. This is exactly what we do. SSRC rewriting does not >>> in any way imply creating a new context for every SSRC. In fact it may >>> very often mean simply reducing the number of SSRCs that are visible >>> to receivers. >>> >> >> I can do that by not mapping SSRCs. >> >> If we map SSRCs, we then create the complex problem of ensuring that >> every entity uses an SSRC that no other entity is using. >> > > That is not correct as I stated above. > > That gets >> really complex when there are cascaded MDDs and lots of endpoints >> hanging off each one. >> > > It really doesn't. Of courses there are cases where it might but just the > fact that you are overwriting some SSRCs doesn't mean that you are > automatically in one of those cases. > > Second: There is absolutely nothing that requires your MDD to actually >>> do SSRC rewriting. If you don't like it: don't do it. >>> >> >> It's far less of an MDD issue than an endpoint issue. The endpoint will >> be responsible for decrypting the packet using HBH authenticated >> encryption. Then, it needs to modify the RTP headers to put the >> original packet back into the buffer. Then it needs to decrypt using >> the E2E cipher. This is where it gets messy. It needs to look up this >> context. It could use the HBH context, and have data hanging off of >> that for E2E. That would work. But, the normal SRTP processing would >> want to do replay protection. We'd have to disable that to avoid the >> stack getting confused over the fact there is "1" from Alice and "1" >> from Carol. The challenge we face here is on the receiver when there >> are collisions in the E2E numbering space. >> >> Again, if we don't re-write, we don't have this problem. >> > > Again: I don't think you need to do these things just because you are > re-writing. Even if you did though you are still looking at a much lesser > effort than the one you are facing if you ask people to do simulcast your > way. > > ... >>>>> No receiver does that today and PERC would be a much tougher sell >>>>> if you >>>>> tried to get people to not only implement a new SRTP layer but also >>>>> force >>>>> them into adopting receiver side simulcast support which virtually >>>>> no one >>>>> does today. >>>>> >>>> >>>> I have assumed that the receiver would receive different media flows >>>> and >>>> perform local composition. >>>> >>>> The receiver would know that the video >>>> resolution changed, but it would know why: because now it is >>>> receiving PT=3D98 >>>> (360p) rather than PT=3D97 (1080p) and those are mapped to different >>>> simulcast >>>> flows in SDP (on the same m=3D line). >>>> >>> >>> That is not how most of the popular SFUs work today. >>> >> >> Isn't that how the current I-Ds specify it? Are you describing a >> proprietary transmission logic? >> > > The current simulcast I-Ds have had their faire share of controversy so I > wouldn't rely too much on them as the only compatibility threshold to pas= s. > If http only allowed and in fact required a single form of "standard" htm= l, > then the world would be a very different place today. > > Also, I had assumed that the sender will always send out 97 and 98 >>>> since it >>>> does not know when it will be the active speaker. It sends out both >>>> flows >>>> and the MDD decides which of the two to forward to receivers (if any = at >>>> all). I think on this point, we have the same idea. >>>> >>> >>> We don't. There is no reason for the sender to use different payload >>> types, as long as it uses different SSRCs. >>> >> >> You're suggesting the same media source use different SSRCs? >> > > Difference SSRCs for the same physical device yes. > > Why? >> > > I find that "Why should we use different PTs for the same payload" is a > more appropriate question. We have different sources in all ways that > matter. They may (and often do) have different timestamp bases, different > sequence numbering ... > > It >> seems like this is just one more place where things can get complex and >> not be within the spirit of RFC 3550. >> > > Huh? Aside from the complexity comment being completely subjective here > (certainly entirely contrary to our experience) how the heck does that > contradict 3550??? > > (And I'll ignore that big ol' >> statement in RFC 3550 that says audio and video should not be >> multiplexed in the same RTP session, since WebRTC clearly violates that >> and everybody thought that was just fine. :P ). >> > > Wait, what??? How did we even get audio involved here? I fail to see the > relevance that this has to ... anything. > > Are you assuming the >>>> same SSRC would be used for both flows in line with the simulcast >>>> signaling >>>> spec? >>>> >>>> Thus, the difference might be in MDD behavior. Are you changing PTs >>>> when >>>> the image size changes or using the same PT? I had assumed the PT >>>> value >>>> will change. >>>> >>> >>> It will not. Regardless of whether the PT changes at the sender, the >>> receiver will always get a single continuous and coherent RTP stream >>> with the same SSRC, the same PT, continuous seq. nums and continuous >>> timestamps. >>> >> >> Now add to that an SSRC from the sender and one from the MDD, and do >> authenticated encryption on each one. It's doable, but complicated. >> > > Completely lost you. Why would I be adding SSRCs? For what reason? Just t= o > make your arguments work? > > The whole point of what I am describing is that the receiver only sees on= e > SSRC for one stream. > > With the current PERC proposal, the SSRCs would be constant, so not an >> issue. PT value would change for multicast per the current I-Ds, >> otherwise PT values are constant. Sequence numbers can change to >> produce sequential numbers per RFC 3550. >> >> So, it appears it's still an difference of opinion about how the >> receiver is to deal with overlapping SSRC number spaces. With PERC the >> group agreed to have one number space. With what you're proposing, >> there are two number spaces: the original source SSRC space and the MDD >> space. >> > > Please do not say that again. I explained multiple times already why this > is not true. Please stop misrepresenting. > > If you agree with that last paragraph on PT changing, then I'm left >>>> wondering exactly what the difference is in the receiver. If the >>>> receiver >>>> is expecting to get either 97 or 98, which is one size video vs. >>>> another, >>>> then why would it care about the SSRC value. Either would use same >>>> SSRC. >>>> >>>> Let's drill in on this a little, because maybe this is where we have >>>> the >>>> disconnect. >>>> >>> >>> I hope this clarifies things. >>> >> >> I think so, but I do feel changing the SSRC is making things complex. >> > > Again, I am inviting you to look at how WebRTC SFUs do that. I am happy t= o > get on a call with you and walk you through it. > > Having mutable SSRCs, though, creates a problem where one did not exist >>>> before. I suspect you have not encountered this, because you have a >>>> single >>>> SSRC number space and you're doing one one decryption step at the >>>> receiver. >>>> With PERC doing both a HBH and E2E decryption step, having potentiall= y >>>> overlapping number spaces with collisions is a headache I'd like to >>>> avoid. >>>> >>> >>> Again, I think that issue is far smaller than reimplementing simulcast >>> but if we have consensus on trying to avoid it then let's just work on >>> that and avoid throwing the baby with the bath water. >>> >> >> I think an important revelation that arose from this dialog is that the >> decision to change the SSRC or not will have an impact on the receiving >> terminal. >> > > > >> Significantly, this is true regardless of whether PERC exists >> or not. If we follow the current I-Ds on simulcast, then receivers you >> describe that do not properly deal with switching based on PT values >> will not work right. With the specs being driven in the IETF, SSRCs do >> not change. PERC is consistent with that approach. Importantly, the >> PERC and IETF simulcast approach also appears consistent with RFC 3550. >> >> If we allow SSRC values to change, there is an incompatibility with the >> current simulcast specs. And for PERC, it presents a challenge in >> effectively performing HBH and E2E decryption. The HBH part is easy, >> but then we have to deal with potential collisions in the SSRC number >> space for E2E. >> > > The conclusion here is simply wrong and the only revelation I see is that > the reasoning for avoiding SSRC modifications have much more to do with > subjective preferences than with rational arguments. > > > Emil > > -- > https://jitsi.org > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --94eb2c094e6814e64005330f9ff1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Emil said:=C2=A0


If we map SSRCs, we then create the complex problem of ensu= ring that
every entity uses an SSRC that no other entity is using.

= That is not correct as I stated above.

[B= A] It seems to me that PERC is making some assumptions about the RTP topolo= gy which need to be made explicit.=C2=A0 For example, is PERC assuming an R= TP translator topology? =C2=A0 Since few (any?) existing SFUs support the R= TP translator topology, that is going to limit applicability.=C2=A0<= /div>

In a topology where the SFU is the RTP/RTCP endpoint= (and modifies SSRCs),=C2=A0RTCP SD= ES/BYE messages are typically modified as well so that=C2=A0SSRC collisions can only occur between the endpoin= t and the SFU, =C2=A0

On Tue, May 17, 2016 at 11:22 AM, Emil Ivov <emcho@ji= tsi.org> wrote:
Hey Paul,

On 17.05.16 =D0=B3. 0:28, Paul E. Jones wrote:
Emil,
=C2=A0So you see the example code I have above?=C2=A0 It won't work, is= the
problem.
=C2=A0Let's say Alice uses SSRC 1 and Carol uses SSRC 1.=C2=A0 Let'= s say the
MDD remaps
=C2=A0those to 101 and 102, respectively.
=C2=A0 We can then do srtp_unprotect() on the
=C2=A0HBH packet, but then when we call srtp_unprotect() for the E2E versio= n
=C2=A0(following the perc stuff), the SRTP library will not be able to
find the
=C2=A0right crypto context, because there are two SSRCs in the system that<= br> have
=C2=A0the same value "1".=C2=A0 That's not valid.

If you are concerned about that, you could have simply chosen to have
the SSRC collision obvious to Alice or Carol.

It would be unfortunate to have to statically assign SSRCs to endpoints
and m=3D lines.

I have no idea what you mean and why we are talking about static SSRCs. Wha= t I meant was that if you want to use the native SSRC collision mechanism t= hen you can and we should just state that as a constraint. There is nothing= that justifies the jump from there to "DO NOT OVERWRITE"

It is up to implementers to decide how to enforce it and the native 3550 me= chanism is very much still workable.

In other words: do not assume that SSRC overwriting necessarily implies new= SSRCs.

=C2=A0So, we'd have to program around this.=C2=A0 It's doable, but = it makes
everything
=C2=A0more complicated.=C2=A0 Maybe we initialize the SRTP library once for=
every HBH
=C2=A0SSRC (really ugly, IMO)
=C2=A0or we pass to the "unprotect" call the HBH SSRC so
=C2=A0that we then can look for some "extended" SSRC value (some = 64-bit
value vs.
=C2=A032-bit value).
=C2=A0Anyway, I know what we'd need to do to handle the HBH/E2E number<= br> overlapping
=C2=A0problem, but it would be a heck of a lot easier if we just avoid it to start
=C2=A0with.=C2=A0 If there is a conference-wide number space, we don't = have to
jump
=C2=A0through hoops to support this in the SRTP libraries.=C2=A0 (There wou= ld
still be
=C2=A0work, but it's simpler and would require less code change.=C2=A0 = And, we
could
=C2=A0just use two SRTP instances as I showed above as the laziest approach= .)

OK. There are two things that are wrong with this argument.

First:=C2=A0 There is absolutely nothing that prevents you from keeping a single SSRC space. This is exactly what we do. SSRC rewriting does not
in any way imply creating a new context for every SSRC. In fact it may
very often mean simply reducing the number of SSRCs that are visible
to receivers.

I can do that by not mapping SSRCs.

If we map SSRCs, we then create the complex problem of ensuring that
every entity uses an SSRC that no other entity is using.

That is not correct as I stated above.

That gets
really complex when there are cascaded MDDs and lots of endpoints
hanging off each one.

It really doesn't. Of courses there are cases where it might but just t= he fact that you are overwriting some SSRCs doesn't mean that you are a= utomatically in one of those cases.

Second: There is absolutely nothing that requires your MDD to actually
do SSRC rewriting. If you don't like it: don't do it.

 It's far less of an MDD issue than an endpoint issue.=C2=A0 The endpoin= t will
be responsible for decrypting the packet using HBH authenticated
encryption.=C2=A0 Then, it needs to modify the RTP headers to put the
original packet back into the buffer.=C2=A0 Then it needs to decrypt using<= br> the E2E cipher.=C2=A0 This is where it gets messy.=C2=A0 It needs to look u= p this
context.=C2=A0 It could use the HBH context, and have data hanging off of that for E2E.=C2=A0 That would work.=C2=A0 But, the normal SRTP processing = would
want to do replay protection.=C2=A0 We'd have to disable that to avoid = the
stack getting confused over the fact there is "1" from Alice and = "1"
from Carol.=C2=A0 The challenge we face here is on the receiver when there<= br> are collisions in the E2E numbering space.

Again, if we don't re-write, we don't have this problem.

Again: I don't think you need to do these things just because you are r= e-writing. Even if you did though you are still looking at a much lesser ef= fort than the one you are facing if you ask people to do simulcast your way= .

...
=C2=A0No receiver does that today and PERC would be a much tougher sell
if you
=C2=A0tried to get people to not only implement a new SRTP layer but also force
=C2=A0them into adopting receiver side simulcast support which virtually no one
=C2=A0does today.

=C2=A0I have assumed that the receiver would receive different media flows<= br> and
=C2=A0perform local composition.

=C2=A0The receiver would know that the video
=C2=A0resolution changed, but it would know why: because now it is
receiving PT=3D98
=C2=A0(360p) rather than PT=3D97 (1080p) and those are mapped to different<= br> simulcast
=C2=A0flows in SDP (on the same m=3D line).

That is not how most of the popular SFUs work today.

Isn't that how the current I-Ds specify it?=C2=A0 Are you describing a<= br> proprietary transmission logic?

The current simulcast I-Ds have had their faire share of controversy so I w= ouldn't rely too much on them as the only compatibility threshold to pa= ss. If http only allowed and in fact required a single form of "standa= rd" html, then the world would be a very different place today.

=C2=A0Also, I had assumed that the sender will always send out 97 and 98 since it
=C2=A0does not know when it will be the active speaker.=C2=A0 It sends out = both
flows
=C2=A0and the MDD decides which of the two to forward to receivers (if any = at
=C2=A0all).=C2=A0 I think on this point, we have the same idea.

We don't. There is no reason for the sender to use different payload types, as long as it uses different SSRCs.

 You're suggesting the same media source use different SSRCs?

Difference SSRCs for the same physical device yes.

Why?

I find that "Why should we use different PTs for the same payload"= ; is a more appropriate question. We have different sources in all ways tha= t matter. They may (and often do) have different timestamp bases, different= sequence numbering ...

It
seems like this is just one more place where things can get complex and
not be within the spirit of RFC 3550.

Huh? Aside from the complexity comment being completely subjective here (ce= rtainly entirely contrary to our experience) how the heck does that contrad= ict 3550???

(And I'll ignore that big ol'
statement in RFC 3550 that says audio and video should not be
multiplexed in the same RTP session, since WebRTC clearly violates that
and everybody thought that was just fine. :P ).

Wait, what??? How did we even get audio involved here? I fail to see the re= levance that this has to ... anything.

=C2=A0Are you assuming the
=C2=A0same SSRC would be used for both flows in line with the simulcast
signaling
=C2=A0spec?

=C2=A0Thus, the difference might be in MDD behavior.=C2=A0 Are you changing= PTs
when
=C2=A0the image size changes or using the same PT?=C2=A0 I had assumed the = PT
value
=C2=A0will change.

It will not. Regardless of whether the PT changes at the sender, the
receiver will always get a single continuous and coherent RTP stream
with the same SSRC, the same PT, continuous seq. nums and continuous
timestamps.

 Now add to that an SSRC from the sender and one from the MDD, and do
authenticated encryption on each one.=C2=A0 It's doable, but complicate= d.

Completely lost you. Why would I be adding SSRCs? For what reason? Just to = make your arguments work?

The whole point of what I am describing is that the receiver only sees one = SSRC for one stream.

With the current PERC proposal, the SSRCs would be constant, so not an
issue.=C2=A0 PT value would change for multicast per the current I-Ds,
otherwise PT values are constant.=C2=A0 Sequence numbers can change to
produce sequential numbers per RFC 3550.

So, it appears it's still an difference of opinion about how the
receiver is to deal with overlapping SSRC number spaces.=C2=A0 With PERC th= e
group agreed to have one number space.=C2=A0 With what you're proposing= ,
there are two number spaces: the original source SSRC space and the MDD
space.

Please do not say that again. I explained multiple times already why this i= s not true. Please stop misrepresenting.

=C2=A0If you agree with that last paragraph on PT changing, then I'm le= ft
=C2=A0wondering exactly what the difference is in the receiver.=C2=A0 If th= e
receiver
=C2=A0is expecting to get either 97 or 98, which is one size video vs.
another,
=C2=A0then why would it care about the SSRC value.=C2=A0 Either would use s= ame
SSRC.

=C2=A0Let's drill in on this a little, because maybe this is where we h= ave
the
=C2=A0disconnect.

I hope this clarifies things.

 I think so, but I do feel changing the SSRC is making things complex.

Again, I am inviting you to look at how WebRTC SFUs do that. I am happy to = get on a call with you and walk you through it.

=C2=A0Having mutable SSRCs, though, creates a problem where one did not exi= st
=C2=A0before. I suspect you have not encountered this, because you have a single
=C2=A0SSRC number space and you're doing one one decryption step at the=
receiver.
=C2=A0With PERC doing both a HBH and E2E decryption step, having potentiall= y
=C2=A0overlapping number spaces with collisions is a headache I'd like = to
avoid.

Again, I think that issue is far smaller than reimplementing simulcast
but if we have consensus on trying to avoid it then let's just work on<= br> that and avoid throwing the baby with the bath water.

 I think an important revelation that arose from this dialog is that the
decision to change the SSRC or not will have an impact on the receiving
terminal.
>
Significantly, this is true regardless of whether PERC exists
or not.=C2=A0 If we follow the current I-Ds on simulcast, then receivers yo= u
describe that do not properly deal with switching based on PT values
will not work right.=C2=A0 With the specs being driven in the IETF, SSRCs d= o
not change.=C2=A0 PERC is consistent with that approach.=C2=A0 Importantly,= the
PERC and IETF simulcast approach also appears consistent with RFC 3550.

If we allow SSRC values to change, there is an incompatibility with the
current simulcast specs.=C2=A0 And for PERC, it presents a challenge in
effectively performing HBH and E2E decryption.=C2=A0 The HBH part is easy,<= br> but then we have to deal with potential collisions in the SSRC number
space for E2E.

The conclusion here is simply wrong and the only revelation I see is that t= he reasoning for avoiding SSRC modifications have much more to do with subj= ective preferences than with rational arguments.


Emil

--
https://= jitsi.org

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

--94eb2c094e6814e64005330f9ff1-- From nobody Thu May 19 15:32:31 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 F0A2C12D689 for ; Thu, 19 May 2016 15:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 bS1ZhmvTOiV9 for ; Thu, 19 May 2016 15:32:20 -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 D58AC12D681 for ; Thu, 19 May 2016 15:32:20 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4JMWJa3088993 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 19 May 2016 17:32:20 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Hutton, Andrew" Date: Thu, 19 May 2016 17:32:19 -0500 Message-ID: <414FA1AC-7409-4312-96D5-CC57F8BBB3EB@nostrum.com> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF26102470@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF261012ED@MCHP04MSX.global-ad.net> <7d73c4cb-58df-a053-94b8-71a00ae4aa38@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF26102470@MCHP04MSX.global-ad.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Adam Roach , "perc@ietf.org" Subject: Re: [Perc] PERC assumptions about SIP environment 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, 19 May 2016 22:32:30 -0000 On 13 May 2016, at 3:25, Hutton, Andrew wrote: [...] > > Agreed nothing else makes sense but this is a big deal for the SIP > world as it is the first time I believe that a major feature has been > totally reliant on a DTLS-SRTP only solution. It is also going to be > very hard to deploy in any kind of open SIP network if it means that > all SIP endpoints in the network have to support DTLS-SRTP. I guess > there is nothing much that can be done about that it is just reality. > > However I am thinking that we urgently need to get the new media > security working group that we discussed in dispatch at IETF95 up and > running to make sure everything is aligned regarding PERC and the best > practice for SIP end-to-end two party sessions and SIP opportunistic > security. In fact I am thinking that work needs to be done before PERC > gets too far. > > On a side note: there's a proposed charter for that work on the dispatch list[1]. I encourage people to go there and comment on it asap. [1] https://mailarchive.ietf.org/arch/msg/dispatch/wPZSo34sd5Iwsu90cthQpRDygPs [...] Thanks! Ben. From nobody Mon May 23 03:46:12 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 82F9C12D1AF for ; Mon, 23 May 2016 03:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, URIBL_SBL=1.623, URIBL_SBL_A=0.1] 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 AEHnYMXLL9nf for ; Mon, 23 May 2016 03:46:08 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407EA12D0CD for ; Mon, 23 May 2016 03:46:08 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 8435523F041F; Mon, 23 May 2016 12:46:06 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0279.002; Mon, 23 May 2016 12:46:06 +0200 From: "Hutton, Andrew" To: "Paul E. Jones" , "Drage, Keith (Nokia - GB)" , Lorenzo Miniero , Emil Ivov Thread-Topic: [Perc] Minutes from Design Team call #3 Thread-Index: AQHRrTmgbMfdhR9WM0Gf+prGCH2oQZ+2/YuAgACsmoCAAWpkAIAAA5YAgA1I9rA= Date: Mon, 23 May 2016 10:46:04 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF2610DD2E@MCHP04MSX.global-ad.net> References: <20160513192745.0d482b62@lminiero> <949EF20990823C4C85C18D59AA11AD8BADEF500E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF2610DD2EMCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: Richard Barnes , LuLop , "perc@ietf.org" , Cullen Jennings , Bernard Aboba Subject: Re: [Perc] Minutes from Design Team call #3 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, 23 May 2016 10:46:10 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF2610DD2EMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFBFUkMgSUVURjk1IG1lZXRpbmcgbWludXRlcyBzdGF0ZToNCg0KTW/igJlzIE5vdGVzOg0K TWFnbnVzIFdlc3Rlcmx1bmQ6IFNob3VsZCB3ZSByZXZpc2l0IGltbXV0YWJsZSBTU1JDIGRpc2N1 c3Npb24/DQpDaGFpcjogTGV0J3MgZGlzY3VzcyBvbiBsaXN0Lg0KDQpIYXJhbGTigJlzIE5vdGVz DQpNYWdudXM6IFBsZWFzZSByZXZpc2l0IGNvbnNlbnN1cyBvbiB3aGV0aGVyIFNTUkMgaXMgaW1t dXRhYmxlIG9yIG5vdC4NCkNoYWlyczogV2lsbCBkbyBvZmZsaW5lLg0KDQpJIGxvb2tlZCBhdCB0 aGUgcmVjb3JkaW5nIGFuZCBhY3R1YWxseSB3aGF0IE1hZ251cyBzYWlkIHdhcyB0aGF0IGl0IHdh cyBub3QgY2xlYXIgd2hldGhlciB0aGVyZSB3YXMgY29uc2Vuc3VzIG9uIHRoaXMgaXNzdWUuICBM b29raW5nIGJhY2sgYXQgdGhlIG1haWxpbmcgbGlzdCBhbmQgbWludXRlcyBJIGRvbuKAmXQgdGhp bmsgdGhlcmUgaGFzIGV2ZXIgYmVlbiBhbnkgY2xlYXIgY29uc2Vuc3VzIG9uIHRoaXMgaXNzdWUg b3IgZGVjaXNpb24gbWFkZS4NCg0KUmVnYXJkcw0KQW5keQ0KDQoNCg0KRnJvbTogUGVyYyBbbWFp bHRvOnBlcmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhdWwgRS4gSm9uZXMNClNl bnQ6IDE1IE1heSAyMDE2IDAyOjM1DQpUbzogRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgTG9y ZW56byBNaW5pZXJvOyBFbWlsIEl2b3YNCkNjOiBSaWNoYXJkIEJhcm5lczsgTHVMb3A7IHBlcmNA aWV0Zi5vcmc7IEN1bGxlbiBKZW5uaW5nczsgQmVybmFyZCBBYm9iYQ0KU3ViamVjdDogUmU6IFtQ ZXJjXSBNaW51dGVzIGZyb20gRGVzaWduIFRlYW0gY2FsbCAjMw0KDQpUaGV5IHdlcmUgYXQgdGhl IGZvbGxvd2luZyBJRVRGIG1lZXRpbmcuDQoNClBhdWwNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpGcm9tOiAiRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKSIgPGtlaXRoLmRyYWdl QG5va2lhLmNvbTxtYWlsdG86a2VpdGguZHJhZ2VAbm9raWEuY29tPj4NClNlbnQ6IE1heSAxNCwg MjAxNiA5OjIyOjM0IFBNIEVEVA0KVG86ICJQYXVsIEUuIEpvbmVzIiA8cGF1bGVqQHBhY2tldGl6 ZXIuY29tPG1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20+PiwgTG9yZW56byBNaW5pZXJvIDxs b3JlbnpvQG1lZXRlY2hvLmNvbTxtYWlsdG86bG9yZW56b0BtZWV0ZWNoby5jb20+PiwgRW1pbCBJ dm92IDxlbWNob0BqaXRzaS5vcmc8bWFpbHRvOmVtY2hvQGppdHNpLm9yZz4+DQpDYzogUmljaGFy ZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiwgTHVMb3AgPGx1bG9wQGt1 cmVudG8uY29tPG1haWx0bzpsdWxvcEBrdXJlbnRvLmNvbT4+LCAicGVyY0BpZXRmLm9yZzxtYWls dG86cGVyY0BpZXRmLm9yZz4iIDxwZXJjQGlldGYub3JnPG1haWx0bzpwZXJjQGlldGYub3JnPj4s IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYTxtYWlsdG86Zmx1ZmZ5QGlpaS5jYT4+LCBC ZXJuYXJkIEFib2JhIDxiZXJuYXJkLmFib2JhQGdtYWlsLmNvbTxtYWlsdG86YmVybmFyZC5hYm9i YUBnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFtQZXJjXSBNaW51dGVzIGZyb20gRGVzaWduIFRl YW0gY2FsbCAjMw0KDQoNCkknZCBub3RlIHRoYXQgdGhlIG1lZXRpbmcgeW91IHNwZWNpZmljYWxs eSByZWZlciB0byBpbiB0aGlzIG1haWwgd2FzIGZvcm1hbGx5IGNhbGxlZCBhcyBhIGRlc2lnbiB0 ZWFtIG1lZXRpbmcgKG5vdCBhbiBpbnRlcmltIG1lZXRpbmcpLCBhbmQgYSBkZXNpZ24gdGVhbSBt ZWV0aW5nIGhhcyBubyBkZWNpc2lvbiBtYWtpbmcgcHJvY2VzcyBmb3IgdGhlIHdvcmtpbmcgZ3Jv dXAuDQoNCkFueSBkZXNpZ24gdGVhbSByZXN1bHRzIGFsd2F5cyBuZWVkIHRvIGJlIHByZXNlbnRl ZCB0byB0aGUgd29ya2luZyBncm91cCBhbmQgYWdyZWVkIChvciByZWplY3RlZCkuDQoNClJlZ2Fy ZHMNCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBlcmMgW21h aWx0bzpwZXJjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFWFQgUGF1bCBFLiBKb25l cw0KU2VudDogMTQgTWF5IDIwMTYgMDQ6NDYNClRvOiBMb3JlbnpvIE1pbmllcm87IEVtaWwgSXZv dg0KQ2M6IFJpY2hhcmQgQmFybmVzOyBMdUxvcDsgcGVyY0BpZXRmLm9yZzxtYWlsdG86cGVyY0Bp ZXRmLm9yZz47IEN1bGxlbiBKZW5uaW5nczsgQmVybmFyZCBBYm9iYQ0KU3ViamVjdDogUmU6IFtQ ZXJjXSBNaW51dGVzIGZyb20gRGVzaWduIFRlYW0gY2FsbCAjMw0KDQpMb3JlbnpvLA0KDQpXaGF0 IEknZCBsaWtlIHRvIGhpZ2hsaWdodCwgdGhvdWdoLCBpcyB0aGF0IEkgY2VydGFpbmx5IGRvbid0 IHJlY2FsbA0Kc3VjaCBhIGRlY2lzaW9uIGJlaW5nIGVjaG9lZCBvbiB0aGUgTUwsIGFzIEkgd291 bGQgZXhwZWN0IGluIHRoZSBJIQ0KDQogRVRGDQp0eXBpY2FsbHksIGVzcGVjaWFsbHkgb24gYW4g YXNwZWN0IHRoYXQgaGFkIHNlZW4gc3VjaCBjb250cm92ZXJzeS4gSGFkDQp0aGlzIGhhcHBlbmVk LCB3ZSBkZWZpbml0ZWx5IHdvdWxkIGhhdmUgbWFkZSBvdXIgcG9pbnQgdGltZWx5IGFnYWluLA0K YW5kIG5vdCA1IG1vbnRocyBsYXRlci4NCg0KSUVURiA5NCB3YXMgcHJldHR5IG11Y2ggaW4gYWdy ZWVtZW50LCBzbyBhIGNhbGwgZm9yIGdldHRpbmcgQ29uY2Vuc3VzOg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wZXJjL2N1cnJlbnQvbXNnMDAxMjUuaHRtbA0KDQpBbmQg d2UgZGlkIGhhdmUgYSBsb3Qgb2YgZGlzY3Vzc2lvbiBvbiB0aGlzIG9uIHRoZSBsaXN0LiAgRHVy aW5nIHRoYXQgdGltZSBNYWdudXMgdW5kZXJ0b29rIGEgdmVyeSBjYXJlZnVsIHN0dWR5IGludG8g dGhlIHByb2JsZW0gYW5kIGFsbCBvdGhlciBSVFAgaGVhZGVycy4NCg0KTWVldGluZyB0byB0YWtl IHVwIHRoZSBpc3N1ZXMgb24gd2hhdCBpcyBhbmQgaXMgbm90IGltbXV0YWJsZSB3YXMgYW5ub3Vu Y2VkIChiYXNlZCBvbiBwcmV2aW91c2x5IHBvc3RlZCBwb2xsKToNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvcGVyYy9jdXJyZW50L21zZzAwMTkzLmh0bWwNCg0KTWludXRl cyBwb3N0ZWQgYnkgZGlmZmVyZW50IGF0dGVuZGVlcyAob25lIGNoYWlyKToNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGVyYy9jdXJyZW50L21zZzAwMjE2Lmh0bWwNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGVyYy9jdXJyZW50L21zZzAwMjMx Lmh0bWwNCg0KRW1pbCBhc2tlZCBhYm91dCB0aGUgZGVjaXNpb246DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3BlcmMvY3VycmVudC9tc2cwMDIyMi5odG1sDQooVGhlcmUg d2FzIG5vIGZvbGxvdy11cCB0byB0aGlzLCBhcyBJIGFzc3VtZSB0aGF0IGFsbCBvZiB0aG9zZSB3 aG8gZmF2b3JlZCB0aGUgZGVjaXNpb24gaGFkIG5vdGhpbmcgdG8gc2F5LiBOb2JvZHkgb3Bwb3Nl ZCB0aGUgZ3JvdXAgZGVjaXNpb24gZXhwbGljaXRseS4pDQoNClRoZXJlIHdhcyBkaWFsb2cgb3Zl ciB0aGUgbmV4dCBmZXcgbW9udGhzIG9uIG90aGVyIHRoaW5ncywgYnV0IHRoaXMgaXNzdWUgd2Fz IG5vdCByYWlzZWQgYWdhaW4uDQoNCkkgcG9zdGVkIGFuIGFubm91bmNlbWVudCBvbiB0aGUgcmV2 aXNlZCBzZXQgb2YgZHJhZnRzIChuZWFybHkgNCBtb250aHMgbGF0ZXIgbmVhciB0aGUgZW5kIG9m IE1hcmNoKToNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGVyYy9jdXJy ZW50L21zZzAwMjYwLmh0bWwNCg0KV2UgdGhlbiBoYWQgYW4gSUVURiBtZWV0aW5nIGluIEFwcmls IHdoZXJlIGRvY3VtZW50cyB3ZXJlIGFnYWluIGNvbnNpZGVyZWQuDQoNClNvLCBldmVyeXRoaW5n IGhhcyBiZWVuIG91dCBpbiB0aGUgb3BlbiBmb3IgZGlzY3Vzc2lvbi4NCg0KUGF1bA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpQZXJjIG1haWxpbmcgbGlzdA0KUGVyY0Bp ZXRmLm9yZzxtYWlsdG86UGVyY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGVyYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpQ ZXJjIG1haWxpbmcgbGlzdA0KUGVyY0BpZXRmLm9yZzxtYWlsdG86UGVyY0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGVyYw0K --_000_9F33F40F6F2CD847824537F3C4E37DDF2610DD2EMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgUEVSQyBJRVRGOTUgbWVldGluZyBtaW51dGVzIHN0 YXRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TW/igJlz IE5vdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5NYWdudXMgV2VzdGVybHVuZDogU2hvdWxkIHdlIHJldmlzaXQgaW1t dXRhYmxlIFNTUkMgZGlzY3Vzc2lvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Q2hhaXI6IExldCdzIGRpc2N1c3Mgb24g bGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhhcmFs ZOKAmXMgTm90ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+TWFnbnVzOiBQbGVhc2UgcmV2aXNpdCBjb25zZW5zdXMgb24g d2hldGhlciBTU1JDIGlzIGltbXV0YWJsZSBvciBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoYWlyczogV2lsbCBk byBvZmZsaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBsb29rZWQgYXQgdGhlIHJlY29yZGluZyBhbmQgYWN0dWFs bHkgd2hhdCBNYWdudXMgc2FpZCB3YXMgdGhhdCBpdCB3YXMgbm90IGNsZWFyIHdoZXRoZXIgdGhl cmUgd2FzIGNvbnNlbnN1cyBvbiB0aGlzIGlzc3VlLiAmbmJzcDtMb29raW5nIGJhY2sgYXQgdGhl IG1haWxpbmcgbGlzdA0KIGFuZCBtaW51dGVzIEkgZG9u4oCZdCB0aGluayB0aGVyZSBoYXMgZXZl ciBiZWVuIGFueSBjbGVhciBjb25zZW5zdXMgb24gdGhpcyBpc3N1ZSBvciBkZWNpc2lvbiBtYWRl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gUGVyYyBbbWFpbHRvOnBlcmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+UGF1bCBFLiBKb25lczxicj4NCjxiPlNlbnQ6PC9iPiAxNSBNYXkgMjAxNiAwMjozNTxicj4N CjxiPlRvOjwvYj4gRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgTG9yZW56byBNaW5pZXJvOyBF bWlsIEl2b3Y8YnI+DQo8Yj5DYzo8L2I+IFJpY2hhcmQgQmFybmVzOyBMdUxvcDsgcGVyY0BpZXRm Lm9yZzsgQ3VsbGVuIEplbm5pbmdzOyBCZXJuYXJkIEFib2JhPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbUGVyY10gTWludXRlcyBmcm9tIERlc2lnbiBUZWFtIGNhbGwgIzM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPlRoZXkgd2VyZSBhdCB0aGUgZm9sbG93aW5nIElFVEYgbWVldGluZy48YnI+DQo8YnI+ DQpQYXVsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3Nw YW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gJnF1b3Q7 RHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlaXRo LmRyYWdlQG5va2lhLmNvbSI+a2VpdGguZHJhZ2VAbm9raWEuY29tPC9hPiZndDs8YnI+DQo8Yj5T ZW50OjwvYj4gTWF5IDE0LCAyMDE2IDk6MjI6MzQgUE0gRURUPGJyPg0KPGI+VG86PC9iPiAmcXVv dDtQYXVsIEUuIEpvbmVzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGF1bGVqQHBhY2tldGl6 ZXIuY29tIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OywgTG9yZW56byBNaW5pZXJvICZs dDs8YSBocmVmPSJtYWlsdG86bG9yZW56b0BtZWV0ZWNoby5jb20iPmxvcmVuem9AbWVldGVjaG8u Y29tPC9hPiZndDssIEVtaWwgSXZvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGppdHNpLm9y ZyI+ZW1jaG9Aaml0c2kub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFJpY2hhcmQgQmFybmVz ICZsdDs8YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCI+cmxiQGlwdi5zeDwvYT4mZ3Q7LCBMdUxv cCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1bG9wQGt1cmVudG8uY29tIj5sdWxvcEBrdXJlbnRvLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cGVyY0BpZXRmLm9yZyI+cGVyY0BpZXRm Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwZXJjQGlldGYub3JnIj5wZXJjQGll dGYub3JnPC9hPiZndDssIEN1bGxlbiBKZW5uaW5ncw0KICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1 ZmZ5QGlpaS5jYSI+Zmx1ZmZ5QGlpaS5jYTwvYT4mZ3Q7LCBCZXJuYXJkIEFib2JhICZsdDs8YSBo cmVmPSJtYWlsdG86YmVybmFyZC5hYm9iYUBnbWFpbC5jb20iPmJlcm5hcmQuYWJvYmFAZ21haWwu Y29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtQZXJjXSBNaW51dGVzIGZyb20g RGVzaWduIFRlYW0gY2FsbCAjMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+SSdkIG5vdGUgdGhhdCB0aGUgbWVldGluZyB5b3Ugc3BlY2lmaWNhbGx5 IHJlZmVyIHRvIGluIHRoaXMgbWFpbCB3YXMgZm9ybWFsbHkgY2FsbGVkIGFzIGEgZGVzaWduIHRl YW0gbWVldGluZyAobm90IGFuIGludGVyaW0gbWVldGluZyksIGFuZCBhIGRlc2lnbiB0ZWFtIG1l ZXRpbmcgaGFzIG5vIGRlY2lzaW9uIG1ha2luZyBwcm9jZXNzIGZvciB0aGUgd29ya2luZyBncm91 cC48YnI+PGJyPkFueSBkZXNpZ24gdGVhbSByZXN1bHRzIGFsd2F5cyBuZWVkIHRvIGJlIHByZXNl bnRlZCB0byB0aGUgd29ya2luZyBncm91cCBhbmQgYWdyZWVkIChvciByZWplY3RlZCkuPGJyPjxi cj5SZWdhcmRzPGJyPjxicj5LZWl0aDxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+RnJvbTogUGVyYyBbPGEgaHJlZj0ibWFpbHRvOnBlcmMtYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOnBlcmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBFWFQgUGF1bCBFLiBK b25lczxicj5TZW50OiAxNCBNYXkgMjAxNiAwNDo0Njxicj5UbzogTG9yZW56byBNaW5pZXJvOyBF bWlsIEl2b3Y8YnI+Q2M6IFJpY2hhcmQgQmFybmVzOyBMdUxvcDsgPGEgaHJlZj0ibWFpbHRvOnBl cmNAaWV0Zi5vcmciPnBlcmNAaWV0Zi5vcmc8L2E+OyBDdWxsZW4gSmVubmluZ3M7IEJlcm5hcmQg QWJvYmE8YnI+U3ViamVjdDogUmU6IFtQZXJjXSBNaW51dGVzIGZyb20gRGVzaWduIFRlYW0gY2Fs bCAjMzxicj48YnI+TG9yZW56byw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XaGF0IEknZCBsaWtl IHRvIGhpZ2hsaWdodCwgdGhvdWdoLCBpcyB0aGF0IEkgY2VydGFpbmx5IGRvbid0IHJlY2FsbCA8 YnI+c3VjaCBhIGRlY2lzaW9uIGJlaW5nIGVjaG9lZCBvbiB0aGUgTUwsIGFzIEkgd291bGQgZXhw ZWN0IGluIHRoZSBJITxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBFVEYgPGJyPnR5cGljYWxseSwg ZXNwZWNpYWxseSBvbiBhbiBhc3BlY3QgdGhhdCBoYWQgc2VlbiBzdWNoIGNvbnRyb3ZlcnN5LiBI YWQgPGJyPnRoaXMgaGFwcGVuZWQsIHdlIGRlZmluaXRlbHkgd291bGQgaGF2ZSBtYWRlIG91ciBw b2ludCB0aW1lbHkgYWdhaW4sIDxicj5hbmQgbm90IDUgbW9udGhzIGxhdGVyLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SUVURiA5NCB3YXMgcHJl dHR5IG11Y2ggaW4gYWdyZWVtZW50LCBzbyBhIGNhbGwgZm9yIGdldHRpbmcgQ29uY2Vuc3VzOjxi cj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3BlcmMvY3Vy cmVudC9tc2cwMDEyNS5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3BlcmMvY3VycmVudC9tc2cwMDEyNS5odG1sPC9hPjxicj48YnI+QW5kIHdlIGRpZCBoYXZlIGEg bG90IG9mIGRpc2N1c3Npb24gb24gdGhpcyBvbiB0aGUgbGlzdC4mbmJzcDsgRHVyaW5nIHRoYXQg dGltZSBNYWdudXMgdW5kZXJ0b29rIGEgdmVyeSBjYXJlZnVsIHN0dWR5IGludG8gdGhlIHByb2Js ZW0gYW5kIGFsbCBvdGhlciBSVFAgaGVhZGVycy48YnI+PGJyPk1lZXRpbmcgdG8gdGFrZSB1cCB0 aGUgaXNzdWVzIG9uIHdoYXQgaXMgYW5kIGlzIG5vdCBpbW11dGFibGUgd2FzIGFubm91bmNlZCAo YmFzZWQgb24gcHJldmlvdXNseSBwb3N0ZWQgcG9sbCk6PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGVyYy9jdXJyZW50L21zZzAwMTkzLmh0bWwiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGVyYy9jdXJyZW50L21zZzAwMTkz Lmh0bWw8L2E+PGJyPjxicj5NaW51dGVzIHBvc3RlZCBieSBkaWZmZXJlbnQgYXR0ZW5kZWVzIChv bmUgY2hhaXIpOjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3BlcmMvY3VycmVudC9tc2cwMDIxNi5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls LWFyY2hpdmUvd2ViL3BlcmMvY3VycmVudC9tc2cwMDIxNi5odG1sPC9hPjxicj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3BlcmMvY3VycmVudC9tc2cwMDIz MS5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3BlcmMvY3VycmVu dC9tc2cwMDIzMS5odG1sPC9hPjxicj48YnI+RW1pbCBhc2tlZCBhYm91dCB0aGUgZGVjaXNpb246 PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGVyYy9j dXJyZW50L21zZzAwMjIyLmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvcGVyYy9jdXJyZW50L21zZzAwMjIyLmh0bWw8L2E+PGJyPihUaGVyZSB3YXMgbm8gZm9sbG93 LXVwIHRvIHRoaXMsIGFzIEkgYXNzdW1lIHRoYXQgYWxsIG9mIHRob3NlIHdobyBmYXZvcmVkIHRo ZSBkZWNpc2lvbiBoYWQgbm90aGluZyB0byBzYXkuIE5vYm9keSBvcHBvc2VkIHRoZSBncm91cCBk ZWNpc2lvbiBleHBsaWNpdGx5Lik8YnI+PGJyPlRoZXJlIHdhcyBkaWFsb2cgb3ZlciB0aGUgbmV4 dCBmZXcgbW9udGhzIG9uIG90aGVyIHRoaW5ncywgYnV0IHRoaXMgaXNzdWUgd2FzIG5vdCByYWlz ZWQgYWdhaW4uPGJyPjxicj5JIHBvc3RlZCBhbiBhbm5vdW5jZW1lbnQgb24gdGhlIHJldmlzZWQg c2V0IG9mIGRyYWZ0cyAobmVhcmx5IDQgbW9udGhzIGxhdGVyIG5lYXIgdGhlIGVuZCBvZiBNYXJj aCk6PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGVy Yy9jdXJyZW50L21zZzAwMjYwLmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvcGVyYy9jdXJyZW50L21zZzAwMjYwLmh0bWw8L2E+PGJyPjxicj5XZSB0aGVuIGhhZCBh biBJRVRGIG1lZXRpbmcgaW4gQXByaWwgd2hlcmUgZG9jdW1lbnRzIHdlcmUgYWdhaW4gY29uc2lk ZXJlZC48YnI+PGJyPlNvLCBldmVyeXRoaW5nIGhhcyBiZWVuIG91dCBpbiB0aGUgb3BlbiBmb3Ig ZGlzY3Vzc2lvbi48YnI+PGJyPlBhdWw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPlBlcmMgbWFpbGlu ZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpQZXJjQGlldGYub3JnIj5QZXJjQGlldGYub3JnPC9h Pjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BlcmMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGVyYzwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxociBzaXplPSIyIiB3aWR0 aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+PC9wcmU+DQo8cHJlPjxicj5QZXJjIG1haWxpbmcgbGlz dDxicj48YSBocmVmPSJtYWlsdG86UGVyY0BpZXRmLm9yZyI+UGVyY0BpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wZXJjIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BlcmM8L2E+PG86cD48L286cD48L3By ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF2610DD2EMCHP04MSXglobal_-- From nobody Mon May 23 10:03:30 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 88AFE12D11D for ; Mon, 23 May 2016 10:03:28 -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 b5menphdHaxm for ; Mon, 23 May 2016 10:03:26 -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 D49BA12D10E for ; Mon, 23 May 2016 10:03:26 -0700 (PDT) Received: from smtp24.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DBD2E1804C7; Mon, 23 May 2016 13:03:25 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8F3C218040D; Mon, 23 May 2016 13:03:25 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.92.108.159] (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); Mon, 23 May 2016 13:03:25 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_C73B27CE-A434-41D9-8FD8-3663803345AF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 23 May 2016 10:03:24 -0700 Message-Id: References: To: Emil Ivov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: 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: Mon, 23 May 2016 17:03:28 -0000 --Apple-Mail=_C73B27CE-A434-41D9-8FD8-3663803345AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 16, 2016, at 12:42 PM, Emil Ivov wrote: >=20 > At this point, after the many conversations on the topic, it sounds = like no one would really have a problem with SSRCs being mutable.=20 I don=E2=80=99t think that is true - lots of people just can=E2=80=99t = be bothered to repeat what they said at the previous meetings. If there = was a proposal on the table that was easy for existing DTLS-SRTP = endpoints to implement, it would be easier to discuss.=20 Clearly we need a solution that does not require for terminating all = the RTCP at the MDD for people that don=E2=80=99t want to do that.=20 I=E2=80=99m still not clear on what problem mutable SSRC solves.=20 --Apple-Mail=_C73B27CE-A434-41D9-8FD8-3663803345AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 16, 2016, at 12:42 PM, Emil Ivov <emcho@jitsi.org> = wrote:

At this point, after the many conversations on = the topic, it sounds like no one would really have a problem with SSRCs = being mutable. 

I don=E2=80=99t think that is true - = lots of people just can=E2=80=99t be bothered to repeat what they said = at the previous meetings.  If there was a proposal on the table = that was easy for existing DTLS-SRTP endpoints to implement, it would be = easier to discuss. 

Clearly we  need a solution that does not require for = terminating all the RTCP at the  MDD for people that don=E2=80=99t = want to do that. 

I=E2=80=99m still not clear on what problem mutable SSRC = solves. 


= --Apple-Mail=_C73B27CE-A434-41D9-8FD8-3663803345AF-- From nobody Mon May 23 11:21:39 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 CAC1C12D1B0 for ; Mon, 23 May 2016 11:21:37 -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 UnB0ltGd7enU for ; Mon, 23 May 2016 11:21: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 A569712D195 for ; Mon, 23 May 2016 11:21:35 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id x189so178914074ywe.3 for ; Mon, 23 May 2016 11:21:35 -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=e0d4Xuv0zwhHOAnfDT7DQ/QsWoQPwlzuvpmkkoqrvdo=; b=S2ZFQ/j1xK2angM96ZR7xprKGz6jO4kB1J6Je/91r+tZUyO7jB8N1mTZaKdoves2gN z+VTIXIIrBJP+/cz8kzbXhEWCF88AauQ3QPx2M8L1nafPlxH8PtziCVQB69iK+/haV2X TtT3TeF3y6gHD7M+YtuLS8dYKxXarPh4YvGH1JBdpnzZSLwrjYeV2y+Bb7PD+hBcyPyU cUIklcPlsJ7PpDyTEXnNRYt4/pSY/tA4xdOyMMsGfDSXYi6GWmHKU2i3LdDyp+h4uput 5RSyFPAtYBGAsfRf4kyZK+s5L0OqEQVNMeyAn/Btcb4ytrGm3MkyhcwuRaoZ+uKabPHY 4F1g== 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=e0d4Xuv0zwhHOAnfDT7DQ/QsWoQPwlzuvpmkkoqrvdo=; b=MuQduZxAymMWTiPFeOR5Vezi1Bk8SIkhhsqpItuw08ADZJysmDcVbRAk6aoQn0UJ17 cCybDASTOZRJcLKaCgXaKRqDlN07PhOLXeIubh5ikWb/eZprDdg3Q5pOJ004dFHaG7R8 ozIDoxDDnDTk2gekQrvvaLlx6sZVig7XUYNa7ekT0MnD5PIO+hR2Ke2RCvZG4jKJc4KN FeduRxXB4VhdhuQWs+6A/YnfK36wPbHQLXrAYNGJT0Qiito/dCq6nz9Enb7aS+YVY+dy obNW5vz5lw1P7AdUGTfrMT6Iy7iSXLZjjBMLehNw3n0W1C5J2nXs5E7wcXoHBUidalXT iS0A== X-Gm-Message-State: ALyK8tKWg0i+gINHrgkSLQJz8zSPF5JyMdrxtzSCucLBb1MPONIIiv1rNF35xzxVMuTaPA== X-Received: by 10.129.156.82 with SMTP id t79mr149220ywg.152.1464027694747; Mon, 23 May 2016 11:21:34 -0700 (PDT) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com. [209.85.161.182]) by smtp.gmail.com with ESMTPSA id i129sm11700717ywd.35.2016.05.23.11.21.33 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 11:21:34 -0700 (PDT) Received: by mail-yw0-f182.google.com with SMTP id o16so61320814ywd.2 for ; Mon, 23 May 2016 11:21:33 -0700 (PDT) X-Received: by 10.13.237.1 with SMTP id w1mr150029ywe.62.1464027693433; Mon, 23 May 2016 11:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.50.7 with HTTP; Mon, 23 May 2016 11:21:13 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Mon, 23 May 2016 13:21:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 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: Mon, 23 May 2016 18:21:38 -0000 On Mon, May 23, 2016 at 12:03 PM, Cullen Jennings wrote: > > On May 16, 2016, at 12:42 PM, Emil Ivov wrote: > > > At this point, after the many conversations on the topic, it sounds lik= e no > > one would really have a problem with SSRCs being mutable. > > > I don=E2=80=99t think that is true - lots of people just can=E2=80=99t be= bothered to repeat > what they said at the previous meetings. Well luckily, if whatever they said is to be given any consideration at all, it would have been on this list, so I am happy to be pointed to those argumentations. The only technical argument I've heard thus far is Paul saying that mutable SSRCs would make it a bit harder for PERC to be implemented as two SRTP-compatible operations on top of each other. As he also agreed though, things are still implementable that way. > If there was a proposal on the > table that was easy for existing DTLS-SRTP endpoints to implement, it wou= ld > be easier to discuss. I doubt that but there isn't one anyway so we are where we are. > Clearly we need a solution that does not require for terminating all the > RTCP at the MDD for people that don=E2=80=99t want to do that. Now, if you want to sell a worthless SFU that doesn't terminate RTCP, then you should really not worry: nothing I ever suggested would prevent that (neither conserving the original SSRC nor coming up with a new PERC ID). So, please go ahead. What I am asking for is that we don't prevent existing SFUs from doing PERC= . > I=E2=80=99m still not clear on what problem mutable SSRC solves. OK, then I will also pretend that you actually do want to understand and explain it again :) It is not possible for WebRTC compatible browsers today to support incoming simulcast unless it is completely transparent to them. All layers need to come in as part of the same flow. RID awareness would in theory make this better except that this is far from being done. It is not implemented today and it is not part of WebRTC 1.0. It may become implemented at some point in the future but we are not there yet. So in other words: there is NO running code in browsers today that would support the architecture this group has currently chosen for anything but the most basic scenarios. Presence and absence of running code used to matter around here ... but obviously we are somehow unconcerned about it in this working group. Emil --=20 https://jitsi.org From nobody Mon May 23 11:54: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 56E1D12DA86 for ; Mon, 23 May 2016 11:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] 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 BKFPoaHED450 for ; Mon, 23 May 2016 11:54:43 -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 A195F12DA7E for ; Mon, 23 May 2016 11:54:43 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4NIse9a009992 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 May 2016 13:54:41 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Emil Ivov , Cullen Jennings References: From: Adam Roach Message-ID: <3e80ae98-3256-8de3-cfeb-b42463482b27@nostrum.com> Date: Mon, 23 May 2016 13:54:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F125AB27801C93CD16413CB0" Archived-At: Cc: 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: Mon, 23 May 2016 18:54:45 -0000 This is a multi-part message in MIME format. --------------F125AB27801C93CD16413CB0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/23/16 13:21, Emil Ivov wrote: > It is not possible for WebRTC compatible browsers today to support > incoming simulcast unless it is completely transparent to them. All > layers need to come in as part of the same flow. > > RID awareness would in theory make this better except that this is far > from being done. It is not implemented today and it is not part of > WebRTC 1.0. It may become implemented at some point in the future but > we are not there yet. You are working from erroneous assumptions and incorrect data. Let's clear that up. 1. The RID work is far ahead of PERC; in fact, the baseline spec is halfway through WGLC in AVTEXT: 2. RID is in the WebRTC 1.0 specs: 3. Firefox has RID support. It landed in Firefox 46, which is already in release: The only *other* argument I've found so far is "some implementors have historically done it another way," which is relevant, but not as compelling as the countervailing argument of "it will make the crypto properties of this system harder to think about and harder to implement." /a --------------F125AB27801C93CD16413CB0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 5/23/16 13:21, Emil Ivov wrote:
It is not possible for WebRTC compatible browsers today to support
incoming simulcast unless it is completely transparent to them. All
layers need to come in as part of the same flow.

RID awareness would in theory make this better except that this is far
from being done. It is not implemented today and it is not part of
WebRTC 1.0. It may become implemented at some point in the future but
we are not there yet.


You are working from erroneous assumptions and incorrect data. Let's clear that up.

  1. The RID work is far ahead of PERC; in fact, the baseline spec is halfway through WGLC in AVTEXT: <https://mailarchive.ietf.org/arch/msg/avtext/eRsaN0zMHNfUxr1lFYSrQr8lmqY>

  2. RID is in the WebRTC 1.0 specs: <http://w3c.github.io/webrtc-pc/#idl-def-rtcrtpencodingparameters>

  3. Firefox has RID support. It landed in Firefox 46, which is already in release: <https://bugzilla.mozilla.org/showdependencytree.cgi?id=1192390&hide_resolved=0>


The only *other* argument I've found so far is "some implementors have historically done it another way," which is relevant, but not as compelling as the countervailing argument of "it will make the crypto properties of this system harder to think about and harder to implement."

/a

--------------F125AB27801C93CD16413CB0-- From nobody Mon May 23 13:39: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 2E5D112DBAB for ; Mon, 23 May 2016 13:39:32 -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 zsV8FFusjQ3Y for ; Mon, 23 May 2016 13:39:30 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 43FA812DB85 for ; Mon, 23 May 2016 13:39:29 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x19so297018608oix.2 for ; Mon, 23 May 2016 13:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=p8U0q6/W4RVTdoPL/xMyaTDWE7NRge8PkRxnse4gK+c=; b=eud5Lk/jn58fS3mWdOQ0ewxJzGPmuiUmlFEs8YKCBSBZATNP41qfAMPIq2S6cf33hh wumOZQNCiqYTnYeFQTpQc6Yt/tJIZAQnf7kgEjX3r8vL7P4iOojijK8dCbjlWW9oomC5 qQeGGXhhPiam2HTEhBKGCUbcuNyW1G4BRP+0ed8x5SBB6SrHszRTfbVl/zz/G1du7KTQ ligPsYtR9QSZogZiW7gKbBnOegPkJxGpwtb2gDkaXJjej/uxof/Up+Vv8OuWPfNkACxz 00q9lZfmH6GZ0BpdWybi79NcpmzZ9O441PfARxlroiHoca0knSE7ICwxn8mgZ8H+ZW16 sgjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=p8U0q6/W4RVTdoPL/xMyaTDWE7NRge8PkRxnse4gK+c=; b=WiR53aK8W86dP5LONUtfHcWa1uUjWPY27D6QsBeenqvCSETaCkahczTGT2NnRnm0ee gtLuYA/QvhZagIL4MhX0Q1LqILlx2LlmpBp1l3h6KgCTZm9AX8MC1eTlcteoEtZLD0hv nZdR7m8oxWclXNylf7kCMZZ6bwB7in1XwyjKNkwT2Snsy84hzQwSsJ7M/rAaTJmx8E+v JEQCEr0fCQU0AdR1aoR2WhfRmnDdU1ntdGlE4vXxbjVpOIKGIzWN7fnJh3v6uQjg4z4k sBXNfI//jprJIEUz+3JN9FnT6wPrf1LAuoNWs3XSw3DFrZMKevAzFXiEhIgFf+Ok5RXG t9rA== X-Gm-Message-State: ALyK8tIsaqTDC4eCePZbtw4l7wa04/VW7xQkxm8HI1BkytnWaW48xEADUfNnZHjKKIHu4g== X-Received: by 10.202.213.88 with SMTP id m85mr5292146oig.24.1464035969188; Mon, 23 May 2016 13:39:29 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id c5sm1653123otb.33.2016.05.23.13.39.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 13:39:27 -0700 (PDT) To: Adam Roach , Cullen Jennings References: <3e80ae98-3256-8de3-cfeb-b42463482b27@nostrum.com> From: Emil Ivov Message-ID: <37e9ce5d-7276-9797-c768-baa0dd7dfb54@jitsi.org> Date: Mon, 23 May 2016 15:39:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <3e80ae98-3256-8de3-cfeb-b42463482b27@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 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: Mon, 23 May 2016 20:39:32 -0000 On 23.05.16 г. 13:54, Adam Roach wrote: > On 5/23/16 13:21, Emil Ivov wrote: >> It is not possible for WebRTC compatible browsers today to support >> incoming simulcast unless it is completely transparent to them. All >> layers need to come in as part of the same flow. >> >> RID awareness would in theory make this better except that this is far >> from being done. It is not implemented today and it is not part of >> WebRTC 1.0. It may become implemented at some point in the future but >> we are not there yet. > > You are working from erroneous assumptions and incorrect data. You might have missed some aspects of the discussion. > Let's clear that up. Let's indeed. > 1. The RID work is far ahead of PERC; Maybe ... but that's not saying much. > in fact, the baseline spec is > halfway through WGLC in AVTEXT: > True, however in order for RID to be "done" it would take a lot more than just taking the syntax for the rtp extension out the door. We still need to work out the congestion control side of things, the expectations for sender and receiver behaviour as well as the signalling, especially for the WebRTC case. So no, not close to being done. > 2. RID is in the WebRTC 1.0 specs: > Except that receiver-side simulcast isn't. There is nothing in JSEP that allows a WebRTC receiver to configure itself for receiving multiple layers. Are you implying that the single ID in the encoding params should somehow suffice? > 3. Firefox has RID support. It landed in Firefox 46, which is already > in release: > So just to be clear ... because this is sort of a biggie: you are claiming that Firefox 46 has support for receiving and demultiplexing based on RID. Right? One of us is obviously confused so could you please point me to the demux code in the mozilla repos? > The only *other* argument I've found so far is "some implementors have > historically done it another way," which is relevant, but not as > compelling as the countervailing argument of "it will make the crypto > properties of this system harder to think about and harder to implement." Another biggie: please explain to me what crypto properties will be harder to think about and harder to implement if we were to just relay the original SSRC as either the early versions of double were proposing or as a separate extension? Emil -- https://jitsi.org From nobody Mon May 23 14:42:37 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 E643912D58F for ; Mon, 23 May 2016 14:42:35 -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 q5lsqfXWW7HM for ; Mon, 23 May 2016 14:42:31 -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 626DD12D177 for ; Mon, 23 May 2016 14:42:31 -0700 (PDT) Received: from [10.54.74.189] (32.239.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.239.32]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4NLgPWq015816 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 17:42:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464039750; bh=jrYRfqk31thx6+CkYTrh/c8LsTMbO+UB9awZ1ES2O+A=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=kB6PsuNL/nw4TyWnGPeAWl9QNhO1t8iirqZpoa0S1+PgjvjmcR/JyjQu+EB5KxruE n39TJN+ST4S2mCX7NHX3kKgFEcKv3+HCHdqOg7B++xY6D6ZA2T5Y1tCy2cRIk+J1Bu vF2+rNlKqDIsF7v6a5d8hQcJ0QCU5lIaoVMSRE5g= From: "Paul E. Jones" To: "Emil Ivov" , "Adam Roach" , "Cullen Jennings" Date: Mon, 23 May 2016 21:42:25 +0000 Message-Id: In-Reply-To: <37e9ce5d-7276-9797-c768-baa0dd7dfb54@jitsi.org> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Mon, 23 May 2016 17:42:30 -0400 (EDT) Archived-At: Cc: perc@ietf.org 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: Mon, 23 May 2016 21:42:36 -0000 Emil, > >>The only *other* argument I've found so far is "some implementors have >>historically done it another way," which is relevant, but not as >>compelling as the countervailing argument of "it will make the crypto >>properties of this system harder to think about and harder to=20 >>implement." > >Another biggie: please explain to me what crypto properties will be=20 >harder to think about and harder to implement if we were to just relay=20 >the original SSRC as either the early versions of double were proposing= =20 >or as a separate extension? If we keep the SSRC value unchanged, this simplifies the logic in the=20 SRTP code since we avoid the possibility of having both Alice and Carol=20 using the same E2E SSRC value. SSRCs are what is used to identify the=20 media stream and related cryptographic parameters (per section 3.2.3 of=20 RFC 3711). If E2E SSRC values can potentially conflict, it would mean=20 we'd need to use a new identifier (e.g., SSRC_HBH || SSRC_E2E) that is=20 "new" to SRTP or prehaps an "instance" of a SRTP library per media flow=20 (which would be terribly unfortunate). Paul From nobody Mon May 23 14:54: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 CCCD112D57B for ; Mon, 23 May 2016 14:54:46 -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 CWVB0t-JQaDf for ; Mon, 23 May 2016 14:54:42 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 A060212D58F for ; Mon, 23 May 2016 14:54:42 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id o16so66732664ywd.2 for ; Mon, 23 May 2016 14:54:42 -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; bh=smW6Vr+mh9zOMR27uflEC/w14e4Ocb7pMRnvp5gfNJw=; b=FgxI2tMki/Xyhc9vrhDSZrYV03k5fPKHWNFpnEf6ChACrd8w9wpE6MkSIGgTmKRgiU PNMP8Izfdw0N5UUTHZW8ykJcJlTj56woI7K4c+1OIzX2r6T/WywwxQ8wLZxpGW3nj/eJ DBWBZ5SNw0avx5Gy+L+3tPoI2n91DmfiphaQmPAqwAmHlWCRWPntT+l5loVVbiu2kr7j oiMef7giPn21dxiV+lacfhI/dhX58+UvypuEvqMHFgIMrrExQGJsf/z77CPO3lIIPRFg H0nvGSvDC5aaNR9veC6XZX0r+Znz1c/vcCCj62gI2cOpcsMTfZM24wflYow6nT0G6ekI YcIQ== 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=smW6Vr+mh9zOMR27uflEC/w14e4Ocb7pMRnvp5gfNJw=; b=d+oX2e5G40y1TzfpTaAbSQATokhAScHLR2oyc22Gtbwyo5UVCsQoGXyRn1wyXWGNQ1 VWKeGteeCuqQFz1eDRd6GWGQn4LntOvt7BIZukBBcc502lUh+3+Qs8wgudn8AHhtIVM8 VCznUlkt00gJN+nUzFe570SyQqYR8sTLiz575JFshpnzajpZs2/D2c5Ib6DInRabGsFs prSXCaUCoixhK4G+vuDjSoYSBrqc7oFlI/DQY5WyH7ak2l6wQstHyWY1g7+nd6vonIFr SermNONrba+S/cZn5ByHV+rTIvKEzBJ9goQh7WEY45HgM9UnXPDJ1qcRTz7Gtu3JHzrg Rbnw== X-Gm-Message-State: ALyK8tIaJguQ5HBmCkLUnDz9Lr4XCqTx9vshVFOznjEKo9di46SXYgoKWqJsbD4jwCeIkw== X-Received: by 10.13.252.6 with SMTP id m6mr661736ywf.85.1464040481851; Mon, 23 May 2016 14:54:41 -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 z17sm10266309ywz.56.2016.05.23.14.54.40 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 14:54:41 -0700 (PDT) Received: by mail-yw0-f179.google.com with SMTP id o16so66732208ywd.2 for ; Mon, 23 May 2016 14:54:40 -0700 (PDT) X-Received: by 10.37.203.79 with SMTP id b76mr663006ybg.136.1464040480639; Mon, 23 May 2016 14:54:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.50.7 with HTTP; Mon, 23 May 2016 14:54:21 -0700 (PDT) In-Reply-To: References: <37e9ce5d-7276-9797-c768-baa0dd7dfb54@jitsi.org> From: Emil Ivov Date: Mon, 23 May 2016 16:54:21 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 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: Mon, 23 May 2016 21:54:46 -0000 On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones wrote: > Emil, > > >> >>> The only *other* argument I've found so far is "some implementors have >>> historically done it another way," which is relevant, but not as >>> compelling as the countervailing argument of "it will make the crypto >>> properties of this system harder to think about and harder to implement." >> >> >> Another biggie: please explain to me what crypto properties will be harder >> to think about and harder to implement if we were to just relay the original >> SSRC as either the early versions of double were proposing or as a separate >> extension? > > > If we keep the SSRC value unchanged, this simplifies the logic in the SRTP > code since we avoid the possibility of having both Alice and Carol using the > same E2E SSRC value. As I have mentioned at least twice already :) ... this is not necessarily true. Simulcast rewriting often reuses one of the original SSRCs without introducing new ones, so conflict resolution could still work as per 3550. Anyways, I think we shouldn't rely on that, but we need to be accurate. > SSRCs are what is used to identify the media stream > and related cryptographic parameters (per section 3.2.3 of RFC 3711). If E2E > SSRC values can potentially conflict, it would mean we'd need to use a new > identifier (e.g., SSRC_HBH || SSRC_E2E) that is "new" to SRTP or prehaps an > "instance" of a SRTP library per media flow (which would be terribly > unfortunate). PERC will rely on SRTP for HBH. Nothing I ever said challenges that. Relying on stock unmodified SRTP primitives to handle E2E is a goal that comes out of nowhere. It would be neat, sure, but not doing so does not in any compromise the crypto properties of PERC. It is just an implementation detail with a relatively low (aesthetic) cost at the SRTP side and a huge gain on the SFU side. Emil -- https://jitsi.org From nobody Mon May 23 15:20: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 104D612B050 for ; Mon, 23 May 2016 15:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 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.426, 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 ohQOu7MwFUXU for ; Mon, 23 May 2016 15:20:00 -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 0CC3912D136 for ; Mon, 23 May 2016 15:19:59 -0700 (PDT) Received: from [10.54.74.174] (228.239.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.239.228]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4NMJujk017860 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2016 18:19:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464041999; bh=ziBRFSYeSRwGWzH/uhDSHPZeAckRR9fc8BwCaMxTlTs=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=sjmO0Soj/jguEuVbKzypwBBAheIPK138QtXhk2vL7JSkuteiqdYbQ94THSZ5/ekAQ BdMTQZKGmqn3zEIGoLCe7r34d0EvOVn0KvmuIha7pqXhJ+rv+NoFyp2jiyLjHOII1E eLi1geJVqcfa2gst0tj7vmSr0/y7qwwZiafVVS2k= User-Agent: K-9 Mail for Android In-Reply-To: References: <37e9ce5d-7276-9797-c768-baa0dd7dfb54@jitsi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----7SULG5915DUVYCCKDGI8Z6DKUDT9Q0" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Tue, 24 May 2016 00:19:54 +0200 To: Emil Ivov Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Mon, 23 May 2016 18:19:59 -0400 (EDT) Archived-At: Cc: 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: Mon, 23 May 2016 22:20:02 -0000 ------7SULG5915DUVYCCKDGI8Z6DKUDT9Q0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Emil, The whole point of PERC is E2E encryption. And, if Alice and Carol chose the same SSRC value, the MDD can't change that. It can only rewrite it and preserve the original value, as that original value is needed for E2E decryption. And that's where we run into the number space conflict. Paul -------- Original Message -------- From: Emil Ivov Sent: May 23, 2016 11:54:21 PM GMT+02:00 To: "Paul E. Jones" Cc: Adam Roach , Cullen Jennings , perc@ietf.org Subject: Re: [Perc] Request for decision review On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones wrote: > Emil, > > >> >>> The only *other* argument I've found so far is "some implementors have >>> historically done it another way," which is relevant, but not as >>> compelling as the countervailing argument of "it will make the crypto >>> properties of this system harder to think about and harder to implement." >> >> >> Another biggie: please explain to me what crypto properties will be harder >> to think about and harder to implement if we were to just relay the original >> SSRC as either the early versions of double were proposing or as a separate >> extension? > > > If we keep the SSRC value unchanged, this simplifies the logic in the SRTP > code since we avoid the possibility of having both Alice and Carol using the > same E2E SSRC value. As I have mentioned at least twice already :) ... this is not necessarily true. Simulcast rewriting often reuses one of the original SSRCs without introducing new ones, so conflict resolution could still work as per 3550. Anyways, I think we shouldn't rely on that, but we need to be accurate. > SSRCs are what is used to identify the media stream > and related cryptographic parameters (per section 3.2.3 of RFC 3711). If E2E > SSRC values can potentially conflict, it would mean we'd need to use a new > identifier (e.g., SSRC_HBH || SSRC_E2E) that is "new" to SRTP or prehaps an > "instance" of a SRTP library per media flow (which would be terribly > unfortunate). PERC will rely on SRTP for HBH. Nothing I ever said challenges that. Relying on stock unmodified SRTP primitives to handle E2E is a goal that comes out of nowhere. It would be neat, sure, but not doing so does not in any compromise the crypto properties of PERC. It is just an implementation detail with a relatively low (aesthetic) cost at the SRTP side and a huge gain on the SFU side. Emil -- https://jitsi.org ------7SULG5915DUVYCCKDGI8Z6DKUDT9Q0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Emil,

The whole point of PERC is E2E encryption. And, if Alice and Carol chose the same SSRC value, the MDD can't change that. It can only rewrite it and preserve the original value, as that original value is needed for E2E decryption. And that's where we run into the number space conflict.

Paul

From: Emil Ivov <emcho@jitsi.org>
Sent: May 23, 2016 11:54:21 PM GMT+02:00
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Adam Roach <adam@nostrum.com>, Cullen Jennings <fluffy@iii.ca>, perc@ietf.org
Subject: Re: [Perc] Request for decision review

On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones <paulej@packetizer.com> wrote:
 Emil,



 The only *other* argument I've found so far is "some implementors have
 historically done it another way," which is relevant, but not as
 compelling as the countervailing argument of "it will make the crypto
 properties of this system harder to think about and harder to implement."


 Another biggie: please explain to me what crypto properties will be harder
 to think about and harder to implement if we were to just relay the original
 SS!
 RC as
either the early versions of double were proposing or as a separate
 extension?


 If we keep the SSRC value unchanged, this simplifies the logic in the SRTP
 code since we avoid the possibility of having both Alice and Carol using the
 same E2E SSRC value.

As I have mentioned at least twice already :) ... this is not
necessarily true. Simulcast rewriting often reuses one of the original
SSRCs without introducing new ones, so conflict resolution could still
work as per 3550. Anyways, I think we shouldn't rely on that, but we
need to be accurate.

 SSRCs are what is used to identify the media stream
 and related cryptographic parameters (per section 3.2.3 of RFC 3711). If E2E
 SSRC values can potentially conflict, it would mean we'd need to use a new

identifier (e.g., SSRC_HBH || SSRC_E2E) that is "new" to SRTP or prehaps an
 "instance" of a SRTP library per media flow (which would be terribly
 unfortunate).

PERC will rely on SRTP for HBH. Nothing I ever said challenges that.
Relying on stock unmodified SRTP primitives to handle E2E is a goal
that comes out of nowhere. It would be neat, sure, but not doing so
does not in any compromise the crypto properties of PERC. It is just
an implementation detail with a relatively low (aesthetic) cost at the
SRTP side and a huge gain on the SFU side.

Emil

------7SULG5915DUVYCCKDGI8Z6DKUDT9Q0-- From nobody Mon May 23 16:51:13 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 E3C4312D5DE for ; Mon, 23 May 2016 16:51:09 -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 UTPR4LbUxN3s for ; Mon, 23 May 2016 16:51:09 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 E2FC912D5E9 for ; Mon, 23 May 2016 16:51:08 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id y2so939878vka.3 for ; Mon, 23 May 2016 16:51:08 -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=6RlVcf918BCtzpjYP1nIFK/AiqDiM7WoYuN8O4uuxgk=; b=jZDa5ypA+EaRBDEHaUYTmawl17pHd3YI7wIqZC0fLc857GukMSE1lydbDa6NU9YS+4 WSPhA/1IrQSCoLe6++5Yad+K0z9EoF7r3ZcMu7iKL3R2T03zVi0fgwQyhQWv7VQCq3gZ Norc1IWoPhuDbfDr0SnhNCcsyGAp/MpZ0GNgNinJCoJSN+MHCvA3Mf4tfgOiK7Ypv7cB rHvQK2mKBfl+Y65CtQ6KdBjDyzSmV9EhpuRTEFlNF1/ZUd6jY7/CNmdIw06KtKwVe2j1 fkYqzMtzYc5iH8q5XRWmavFxwEX0zTVqjPoGEkSMENAWUyCWH7QFRObc3BRiM+mIqRuR VzGg== 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=6RlVcf918BCtzpjYP1nIFK/AiqDiM7WoYuN8O4uuxgk=; b=gpGOJBbwMaH2h00F+X7qvTVAmwxkOSDuCqsaSPHLCX13YFUudRjHlerSKm3qQ7nqMK QGB0Fr4fb6HPG0xERSR+D13ZQ/BdY09fj3Te4VXu/oEFTqb0WnkBluozNp4Zb8E5/aTz AJYvomUifG4QLKncQQK5IDPBXe+LMCn+1nOF0I+KFT+uG+Z4M/lP7R8dVbl3SHYTLwcV T/pLTlfVC/yI5pYSRo4cd7c2IVsNxNblc1zlgZuEAuiTlnK0JKQ3Sq5HwkFKHEBtf/TV ZUXw33Dbo0yI9+AVjHXlWJLLE/b2iMplE1+oxwmpebwi5+VWowdKAgSBKDl/K6enAqrV lXlQ== X-Gm-Message-State: ALyK8tLKa8JkA0n0BQT/t+DKCyYhmuSoLaCik6uAG3CUBK470tqi0h0NPmYawLYISqWgsii3NCacYfFjIv8HLQ== X-Received: by 10.159.54.193 with SMTP id p59mr969502uap.100.1464047468077; Mon, 23 May 2016 16:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.40 with HTTP; Mon, 23 May 2016 16:50:48 -0700 (PDT) In-Reply-To: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> References: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> From: Bernard Aboba Date: Mon, 23 May 2016 16:50:48 -0700 Message-ID: To: Luis Lopez Content-Type: multipart/alternative; boundary=94eb2c0494e844ea2605338b1d72 Archived-At: Cc: Richard Barnes , "Paul E. Jones" , Emil Ivov , perc@ietf.org, Cullen Jennings Subject: Re: [Perc] Minutes from Design Team call #3 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, 23 May 2016 23:51:10 -0000 --94eb2c0494e844ea2605338b1d72 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Luis said: "Could you develop this?" [BA] A switching function that does not require changing SSRCs is quite difficult to develop. Basically, this would require the SFU to act as an RTP translator. To my knowledge, I do not believe that an SFU with any sophistication has been done this way, because of the complexity that it would introduce. On Thu, May 12, 2016 at 1:22 AM, Luis Lopez wrote: > Hi Paul, > > Could you develop on this? > > > It is indeed a fact that you can write a switching function that does not > require changing SSRCs. > > > I=E2=80=99m very interested in figuring out know to support features such= as > simulcast or active speakers switching in an SFU without SSRC rewriting? = I > your plan is to negotiate a bunch of SSRCs per participant and just switc= h > on/off each of them when appropriate, I=E2=80=99m afraid this will not wo= rk. > > Best regards. > > L. > > > --94eb2c0494e844ea2605338b1d72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Luis said:=C2=A0

"Could you develo= p this?"

[BA] A switching function that does = not require changing SSRCs is quite difficult to develop.=C2=A0 Basically, = this would require the SFU to act as an RTP translator.=C2=A0
To my knowledge, I do not believe that an SFU with any sophisti= cation has been done this way, because of the complexity that it would intr= oduce.=C2=A0

On Thu, May 12, 2016 at 1:22 AM, Luis Lopez <lulop@kurento.com&= gt; wrote:
Hi Paul,

Could you develop on th= is?

It is indeed a fact that yo= u can write a switching function that does not require changing SSRCs.

I=E2=80=99m very interested in f= iguring out know to support features such as simulcast or active speakers s= witching in an SFU without SSRC rewriting? I your plan is to negotiate a bu= nch of SSRCs per participant and just switch on/off each of them when appro= priate, I=E2=80=99m afraid this will not work.

Bes= t regards.

L.


<= br>
--94eb2c0494e844ea2605338b1d72-- From nobody Mon May 23 19:36: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 2858312D59D for ; Mon, 23 May 2016 19:36:46 -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 zVKLUCbiQgQt for ; Mon, 23 May 2016 19:36:44 -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 0EEDD12B05E for ; Mon, 23 May 2016 19:36:43 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h19so3585972ywc.0 for ; Mon, 23 May 2016 19:36:43 -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; bh=Z1sbVbe2H35fFCmOw6I13aYGNvtviefAuJ1qYam3Pe4=; b=Ve7am6YloyyyXzY3FCbUoKGCv+urXFtwxT67GwE5q+/b8vbFKDUN89I2KNnA6RIeE/ kvHgd4Tdftkd23QLNcH8SPtVmYiFL3CbH8n4kg6V1iS00+6DCdiB1M8FBm2x+AVFE7hh S3y9T7dv9GbfRBdfTh6iU/qfarxi1aEo/1OMALtYoYUqyQa/CgwnOCVAH+RdgNAwMgzA VOyzwvAbWSspRFkQCMfDA3yl/2814CoLGKrnVR1Mh78bipBNCb7PjrZLRrxXwlI+1E+5 /XrmaoAaaVmZnHyKmvR6ucsATU9zx7z856Mk635OruTn84fP9SPhjak+eZiL4/j9Kno1 /TxA== 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=Z1sbVbe2H35fFCmOw6I13aYGNvtviefAuJ1qYam3Pe4=; b=agieDiBJ6+5hcfkR0Bc6NYXBc++svjrDmr3/2d6VC99DwQlit//WwI06eZr1azwWk1 33/Vp4nQ6kbOqu5X0NQTQTiFyEQpwBM/IRBTSBH0PTnFLtxR4VM+s3exLWmYZKpNxADP kxxvyX7CtivPm9iRqiJUbBu7NQpGzt4OM+3mrokoO2Dc7Kc8cXmz3F3n/zd/KQVc0pTy mxC0oMKXdHLMIJ+irPUUsySlEbgKFrFSOpvpXzsQ9yawIcIzzQR1NC8Fvg4SWmLWN4T7 +waH1qz8H8FRe//Z4T+jCo2lDUqUc1TsratBICDIQO5Hld44C4u2TQNWrSiJo7+TV/wV ysDw== X-Gm-Message-State: ALyK8tIBsolxm6uJWUAGQ4qrkvidjv0CpopyIrDVmMT3UKNNQ+46MiQuhbLfl4gbHzWwJw== X-Received: by 10.13.210.68 with SMTP id u65mr1338163ywd.112.1464057403205; Mon, 23 May 2016 19:36:43 -0700 (PDT) Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com. [209.85.161.178]) by smtp.gmail.com with ESMTPSA id k205sm2681504ywe.19.2016.05.23.19.36.42 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 19:36:42 -0700 (PDT) Received: by mail-yw0-f178.google.com with SMTP id x189so3487640ywe.3 for ; Mon, 23 May 2016 19:36:42 -0700 (PDT) X-Received: by 10.37.5.20 with SMTP id 20mr1110911ybf.29.1464057402264; Mon, 23 May 2016 19:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.50.7 with HTTP; Mon, 23 May 2016 19:36:22 -0700 (PDT) In-Reply-To: References: <37e9ce5d-7276-9797-c768-baa0dd7dfb54@jitsi.org> From: Emil Ivov Date: Mon, 23 May 2016 21:36:22 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: 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: Tue, 24 May 2016 02:36:46 -0000 Hey Paul, On Mon, May 23, 2016 at 5:19 PM, Paul E. Jones wrote: > Emil, > > The whole point of PERC is E2E encryption. Yup ... I think we are on the same page there :) > And, if Alice and Carol chose the > same SSRC value, the MDD can't change that. It can only rewrite it and > preserve the original value, as that original value is needed for E2E > decryption. ... I won't re-explain this a sixth time :). Please read any of my five previous explanations about this is not true. > And that's where we run into the number space conflict. Even if we do go for full rewriting preserving the original SSRC is trivial and, as per your words, is only a matter of using 64bit identifiers (the concatenation of the two SSRCs) at the receiving end in order to get it to work with the double srtp unprotect. Where is the problem with that. Emil > From: Emil Ivov > Sent: May 23, 2016 11:54:21 PM GMT+02:00 > To: "Paul E. Jones" > Cc: Adam Roach , Cullen Jennings , > perc@ietf.org > Subject: Re: [Perc] Request for decision review > > On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones > wrote: >> >> Emil, >> >> >>> >>>> The only *other* argument I've found so far is "some implementors have >>>> historically done it another way," which is relevant, but not as >>>> compelling as the countervailing argument of "it will make the crypto >>>> properties of this system harder to think about and harder to >>>> implement." >>> >>> >>> >>> Another biggie: please explain to me what crypto properties will be >>> harder >>> to think about and harder to implement if we were to just relay the >>> original >>> SS! >>> RC as >>> either the early versions of double were proposing or as a separate >>> extension? >> >> >> >> If we keep the SSRC value unchanged, this simplifies the logic in the >> SRTP >> code since we avoid the possibility of having both Alice and Carol using >> the >> same E2E SSRC value. > > > As I have mentioned at least twice already :) ... this is not > necessarily true. Simulcast rewriting often reuses one of the original > SSRCs without introducing new ones, so conflict resolution could still > work as per 3550. Anyways, I think we shouldn't rely on that, but we > need to be accurate. > >> SSRCs are what is used to identify the media stream >> and related cryptographic parameters (per section 3.2.3 of RFC 3711). If >> E2E >> SSRC values can potentially conflict, it would mean we'd need to use a >> new >> >> identifier (e.g., SSRC_HBH || SSRC_E2E) that is "new" to SRTP or prehaps >> an >> "instance" of a SRTP library per media flow (which would be terribly >> unfortunate). > > > PERC will rely on SRTP for HBH. Nothing I ever said challenges that. > Relying on stock unmodified SRTP primitives to handle E2E is a goal > that comes out of nowhere. It would be neat, sure, but not doing so > does not in any compromise the crypto properties of PERC. It is just > an implementation detail with a relatively low (aesthetic) cost at the > SRTP side and a huge gain on the SFU side. > > Emil > -- https://jitsi.org From nobody Tue May 24 00:24: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 EC33412DC93 for ; Tue, 24 May 2016 00:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 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.426, 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 cfHVNMiPyR0P for ; Tue, 24 May 2016 00:24:39 -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 12C4712DC87 for ; Tue, 24 May 2016 00:24:38 -0700 (PDT) Received: from [156.106.224.123] ([156.106.224.123]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4O7OZKf017756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2016 03:24:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464074678; bh=kKOP6k+1VQfYzRqmLZCm+7KEfdEqrt67iEawRF2JmiE=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=qQ/AiArCLn2K99PTm5IgoTn4iPkT+6RcbayDiCLhefFxS56LCxnjy3qLoU7n8zkrS 3KMyxpxraylSB0OWJb2S+JA9/tqTuo72lo461UnycFLKBlNdqfcBqXbggYeJQRHJM+ wHJcAug6sagvpVBVKbkhC9VsW1+GK7LB7A42Ruck= User-Agent: K-9 Mail for Android In-Reply-To: References: <37e9ce5d-7276-9797-c768-baa0dd7dfb54@jitsi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ZJQ04VOAOIJ5X8EBLKNATBF8KAGPZX" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Tue, 24 May 2016 09:24:33 +0200 To: Emil Ivov Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Tue, 24 May 2016 03:24:38 -0400 (EDT) Archived-At: Cc: 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: Tue, 24 May 2016 07:24:42 -0000 ------ZJQ04VOAOIJ5X8EBLKNATBF8KAGPZX Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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. 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. The problem with using a 64 bit value is that any existing SRTP library would have to change to associate the context that way. 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. 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.) Paul -------- Original Message -------- From: Emil Ivov Sent: May 24, 2016 4:36:22 AM GMT+02:00 To: "Paul E. Jones" Cc: Adam Roach , Cullen Jennings , perc@ietf.org Subject: Re: [Perc] Request for decision review Hey Paul, On Mon, May 23, 2016 at 5:19 PM, Paul E. Jones wrote: > Emil, > > The whole point of PERC is E2E encryption. Yup ... I think we are on the same page there :) > And, if Alice and Carol chose the > same SSRC value, the MDD can't change that. It can only rewrite it and > preserve the original value, as that original value is needed for E2E > decryption. ... I won't re-explain this a sixth time :). Please read any of my five previous explanations about this is not true. > And that's where we run into the number space conflict. Even if we do go for full rewriting preserving the original SSRC is trivial and, as per your words, is only a matter of using 64bit identifiers (the concatenation of the two SSRCs) at the receiving end in order to get it to work with the double srtp unprotect. Where is the problem with that. Emil > From: Emil Ivov > Sent: May 23, 2016 11:54:21 PM GMT+02:00 > To: "Paul E. Jones" > Cc: Adam Roach , Cullen Jennings , > perc@ietf.org > Subject: Re: [Perc] Request for decision review > > On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones > wrote: >> >> Emil, >> >> >>> >>>> The only *other* argument I've found so far is "some implementors have >>>> historically done it another way," which is relevant, but not as >>>> compelling as the countervailing argument of "it will make the crypto >>>> properties of this system harder to think about and harder to >>>> implement." >>> >>> >>> >>> Another biggie: please explain to me what crypto properties will be >>> harder >>> to think about and harder to implement if we were to just relay the >>> original >>> SS! >>> RC as >>> either the early versions of double were proposing or as a separate >>> extension? >> >> >> >> If we keep the SSRC value unchanged, this simplifies the logic in the >> SRTP >> code since we avoid the possibility of having both Alice and Carol using >> the >> same E2E SSRC value. > > > As I have mentioned at least twice already :) ... this is not > necessarily true. Simulcast rewriting often reuses one of the original > SSRCs without introducing new ones, so conflict resolution could still > work as per 3550. Anyways, I think we shouldn't rely on that, but we > need to be accurate. > >> SSRCs are what is used to identify the media stream >> and related cryptographic parameters (per section 3.2.3 of RFC 3711). If >> E2E >> SSRC values can potentially conflict, it would mean we'd need to use a >> new >> >> identifier (e.g., SSRC_HBH || SSRC_E2E) that is "new" to SRTP or prehaps >> an >> "instance" of a SRTP library per media flow (which would be terribly >> unfortunate). > > > PERC will rely on SRTP for HBH. Nothing I ever said challenges that. > Relying on stock unmodified SRTP primitives to handle E2E is a goal > that comes out of nowhere. It would be neat, sure, but not doing so > does not in any compromise the crypto properties of PERC. It is just > an implementation detail with a relatively low (aesthetic) cost at the > SRTP side and a huge gain on the SFU side. > > Emil > -- https://jitsi.org ------ZJQ04VOAOIJ5X8EBLKNATBF8KAGPZX Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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. 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.

The problem with using a 64 bit value is that any existing SRTP library would have to change to associate the context that way. 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.
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.)

Paul

From: Emil Ivov <emcho@jitsi.org>
Sent: May 24, 2016 4:36:22 AM GMT+02:00
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Adam Roach <adam@nostrum.com>, Cullen Jennings <fluffy@iii.ca>, perc@ietf.org
Subject: Re: [Perc] Request for decision review

Hey Paul,

On Mon, May 23, 2016 at 5:19 PM, Paul E. Jones <paulej@packetizer.com> wrote:
 Emil,

 The whole point of PERC is E2E encryption.

Yup ... I think we are on the same page there :)

 And, if Alice and Carol chose the
 same SSRC value, the MDD can't change that. It can only rewrite it and
 preserve the original value, as that original value is needed for E2E
 decryption.

 ... I won't re-explain this a sixth time :). Please read any of my
five previous explanations about this is not true.


And that's where we run into the number space conflict.

Even if we do go for full rewriting preserving the original SSRC is
trivial and, as per your words, is only a matter of using 64bit
identifiers (the concatenation of the two SSRCs) at the receiving end
in order to get it to work with the double srtp unprotect.

Where is the problem with that.

Emil


 From: Emil Ivov <emcho@jitsi.org>
 Sent: May 23, 2016 11:54:21 PM GMT+02:00
 To: "Paul E. Jones" <paulej@packetizer.com>
 Cc: Adam Roach <adam@nostrum.com>, Cullen Jennings <fluffy@iii.ca>,
 perc@ietf.org
 Subject: Re: [Perc] Request for decision review

 On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones <paulej@packetizer.com>
 wrote:

  Emil,



  The only *other* argument I've found so far is "some implementors have
  historically done it another way," which is relevant, but not as
  compelling as the countervailing argument of "it will make the crypto
  properties of this system harder to think about and harder to
 implement."



  Another biggie: please explain to me what crypto properties will be
 harder
  to think about and harder to implement if we were to just relay the
 original
  SS!
  RC as
 either the early versions of double were proposing or as a separate
  extensi!
 on?



  If we keep the SSRC value unchanged, this simplifies the logic in the
 SRTP
  code since we avoid the possibility of having both Alice and Carol using
 the
  same E2E SSRC value.


 As I have mentioned at least twice already :) ... this is not
 necessarily true. Simulcast rewriting often reuses one of the original
 SSRCs without introducing new ones, so conflict resolution could still
 work as per 3550. Anyways, I think we shouldn't rely on that, but we
 need to be accurate.

  SSRCs are what is used to identify the media stream
  and related cryptographic parameters (per section 3.2.3 of RFC 3711). If
 E2E
  SSRC values can potentially conflict, it would mean we'd need to use a
 new

 identifier (e.g., SSRC_HBH || SSR!
 C_E2E)
that is "new" to SRTP or prehaps
 an
  "instance" of a SRTP library per media flow (which would be terribly
  unfortunate).


 PERC will rely on SRTP for HBH. Nothing I ever said challenges that.
 Relying on stock unmodified SRTP primitives to handle E2E is a goal
 that comes out of nowhere. It would be neat, sure, but not doing so
 does not in any compromise the crypto properties of PERC. It is just
 an implementation detail with a relatively low (aesthetic) cost at the
 SRTP side and a huge gain on the SFU side.

 Emil



------ZJQ04VOAOIJ5X8EBLKNATBF8KAGPZX-- From nobody Tue May 24 09:52:22 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 7884912D8F4 for ; Tue, 24 May 2016 09:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aKYBD_EzSTHy for ; Tue, 24 May 2016 09:50:54 -0700 (PDT) Received: from smtp85.ord1c.emailsrvr.com (smtp85.ord1c.emailsrvr.com [108.166.43.85]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4502B12D8E2 for ; Tue, 24 May 2016 09:50:16 -0700 (PDT) Received: from smtp3.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C62A8180462; Tue, 24 May 2016 12:50:15 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 2472018045A; Tue, 24 May 2016 12:50:15 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.92.108.159] (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); Tue, 24 May 2016 12:50:15 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_73BC36AB-094C-44FD-8A62-405A58FB5BFA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Tue, 24 May 2016 09:50:16 -0700 Message-Id: References: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , Paul Jones , LuLop , Emil Ivov , perc@ietf.org Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 24 May 2016 16:51:02 -0000 X-List-Received-Date: Tue, 24 May 2016 16:51:02 -0000 --Apple-Mail=_73BC36AB-094C-44FD-8A62-405A58FB5BFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can you explain what part of this becomes significantly more complicated = if you don=E2=80=99t change the SSRC because that has not been my = experience.=20 > On May 23, 2016, at 4:50 PM, Bernard Aboba = wrote: >=20 > Luis said:=20 >=20 > "Could you develop this?" >=20 > [BA] A switching function that does not require changing SSRCs is = quite difficult to develop. Basically, this would require the SFU to = act as an RTP translator.=20 >=20 > To my knowledge, I do not believe that an SFU with any sophistication = has been done this way, because of the complexity that it would = introduce.=20 >=20 > On Thu, May 12, 2016 at 1:22 AM, Luis Lopez > wrote: > Hi Paul, >=20 > Could you develop on this? >>=20 >> It is indeed a fact that you can write a switching function that does = not require changing SSRCs. >=20 > I=E2=80=99m very interested in figuring out know to support features = such as simulcast or active speakers switching in an SFU without SSRC = rewriting? I your plan is to negotiate a bunch of SSRCs per participant = and just switch on/off each of them when appropriate, I=E2=80=99m afraid = this will not work. >=20 > Best regards. >=20 > L. >=20 >=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_73BC36AB-094C-44FD-8A62-405A58FB5BFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Can you explain what = part of this becomes significantly more complicated if you don=E2=80=99t = change the SSRC because that has not been my experience. 

On May 23, 2016, at 4:50 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Luis said: 

"Could you develop this?"

[BA] A switching function that does not = require changing SSRCs is quite difficult to develop.  Basically, = this would require the SFU to act as an RTP translator. 

To my knowledge, I do = not believe that an SFU with any sophistication has been done this way, = because of the complexity that it would introduce. 

On Thu, = May 12, 2016 at 1:22 AM, Luis Lopez <lulop@kurento.com> wrote:
Hi = Paul,

Could = you develop on this?

It is indeed a fact that you can write a switching = function that does not require changing = SSRCs.

I=E2=80=99m very interested in figuring out know to support = features such as simulcast or active speakers switching in an SFU = without SSRC rewriting? I your plan is to negotiate a bunch of SSRCs per = participant and just switch on/off each of them when appropriate, I=E2=80=99= m afraid this will not work.

Best regards.

L.


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

= --Apple-Mail=_73BC36AB-094C-44FD-8A62-405A58FB5BFA-- From nobody Tue May 24 10:26:07 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 E635912D14C for ; Tue, 24 May 2016 10:26:04 -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 4NU6U9hGXTSl for ; Tue, 24 May 2016 10:26:02 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62A3612D0AA for ; Tue, 24 May 2016 10:25:59 -0700 (PDT) Received: by mail-pa0-x234.google.com with SMTP id xk12so8607695pac.0 for ; Tue, 24 May 2016 10:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=P/Qi7thF7ZWruIgrcqmxWP5Bx06gTpMslB7FtfukTZg=; b=M+sfxPGA0c3QwwN8W1/+jV6lJhL+3THPJKxvf6fzVQP3ig1CWMH+6Gk8H0cpdCOkL/ S57RggMkdwT6RB71bTjNAVm4hTvb6wHt8syGdeQOZsSL1TnF1OFek8IR1CwyIE6HpJWb krX10e7oxcvJ/gUzvnP87IYdx7tS/UX9DxUS1x3HBa1ZjEklIcdIC6HaeexZoRKrXuHc ZjlSObKa/D0Z6j8OvW0SigBISiAgqGGl3/iflAR9puzGVW4SfA8FKQOJU79e5Rjc885Z vevOQaJQGejP6vE7IDQt9g36xE1jHzVDGOxKJZ/zZyLsapcyY6tQjiTZEk3Y76AhpXAd InIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P/Qi7thF7ZWruIgrcqmxWP5Bx06gTpMslB7FtfukTZg=; b=eZm8R7C14fbFOpJn1w2JM+zr1L6NycNgUMwPEiZL2Iy7XnNknYiA0zl70y/wSEXrbk Kv3XnMxeNHr9huMFDAW81ouUkwFOwvkV297H7dPytgDvNZyIrG7JYSB8xMmuU8fPOSsh /GS1bBgiRsTdhbG64UkQftSMCoOFl+KH0ZEWLsduvx24dqBT2EDa8WN8q7ODBzQxNy4C C0WE8HPm1WuBt6RC5hHCSMzZ2xX4Zg17ga/z6B8q3cejEW3lGosrwG09CeVEgRYbTRZ5 r+A+qnq1H5e007JkKfw46Bpkx6r/uaKVnzS9JLrX7kzx0Nv9u6yKAOZvLhUYYbX1INv4 wR8w== X-Gm-Message-State: ALyK8tLG9IMu+FXxBWmQKX7NAeey12pFR5dHwXf8j52n2/xmBzAG1W8S5Zfk52hFtONlJQ== X-Received: by 10.66.55.101 with SMTP id r5mr8662393pap.146.1464110758750; Tue, 24 May 2016 10:25:58 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id g82sm6432153pfj.22.2016.05.24.10.25.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 10:25:57 -0700 (PDT) To: Cullen Jennings , Bernard Aboba References: <71840D5F-68F9-45A3-80FE-37B442365959@kurento.com> From: Emil Ivov Message-ID: <8bf31a99-d957-9488-5803-1b356500a562@jitsi.org> Date: Tue, 24 May 2016 12:25:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Richard Barnes , Paul Jones , LuLop , perc@ietf.org Subject: Re: [Perc] Minutes from Design Team call #3 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: Tue, 24 May 2016 17:26:05 -0000 On 24.05.16 г. 11:50, Cullen Jennings wrote: > > Can you explain what part of this becomes significantly more complicated > if you don’t change the SSRC because that has not been my experience. Sender ≡≡≡> SFU ---> Receiver [ RTP stack --> Decoder --> Video Tag] The single stream to the right of the SFU has to be fed into the receiver and its components as a continuous RTP flow, so that it goes through the same chain of RTP streams, decoder and video tag. This makes stream switches transparent and gives you a smooth user experience. If you weren't re-writing SSRCs you would inevitably end with something like this: Sender ≡≡≡> SFU ---> Receiver1[ RTPstream1 --> Decoder1 --> Video Tag1] ---> Receiver2[ RTPstream2 --> Decoder2 --> Video Tag2] ---> Receiver3[ RTPstream3 --> Decoder3 --> Video Tag3] So there is the general practicality concern with this approach which is that a switching logic on the receiver would require reimplementing it on all supporting clients. With WebRTC this would basically imply: JS, objc/swift and Java implementations of the exact same thing. More importantly though there is the bigger concern that nothing in WebRTC today allows you to do that switching at the "right time" so that you have a good user experience. Not in the stack and certainly not in JS. Receiver-side RID would supposedly address this but we have never seen that working. We would have to wait for consensus on the API and the SDP, then for browsers to implement it and then for SFUs to redo their implementations. There is no good reason for PERC to be dependent on all of that (unless you actually want it to not be adopted). Again, please note that relaxing the requirement on SSRC rewriting DOES NOT in anyway require you to do it. You can still wait for receiver-side RID support to land if that's what you want. Emil > >> On May 23, 2016, at 4:50 PM, Bernard Aboba > > wrote: >> >> Luis said: >> >> "Could you develop this?" >> >> [BA] A switching function that does not require changing SSRCs is >> quite difficult to develop. Basically, this would require the SFU to >> act as an RTP translator. >> >> To my knowledge, I do not believe that an SFU with any sophistication >> has been done this way, because of the complexity that it would >> introduce. >> >> On Thu, May 12, 2016 at 1:22 AM, Luis Lopez > > wrote: >> >> Hi Paul, >> >> Could you develop on this? >>> >>> It is indeed a fact that you can write a switching function that >>> does not require changing SSRCs. >> >> I’m very interested in figuring out know to support features such >> as simulcast or active speakers switching in an SFU without SSRC >> rewriting? I your plan is to negotiate a bunch of SSRCs per >> participant and just switch on/off each of them when appropriate, >> I’m afraid this will not work. >> >> Best regards. >> >> L. >> >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc > -- https://jitsi.org From nobody Tue May 24 10:37: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 DE3CD12D934 for ; Tue, 24 May 2016 10:37:30 -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 8kXCzI8BK1kF for ; Tue, 24 May 2016 10:37:28 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 A2DFC12D932 for ; Tue, 24 May 2016 10:37:28 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id qo8so8727613pab.1 for ; Tue, 24 May 2016 10:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=aAaTFeAX9SUnTmqJnXAmx0V/p3Vb8jjXltL67OGlZzs=; b=Ez0fAC+IpC929GDQNgRzdGPIE8j7kxCFPjGh/Q3RdFdWnLMi7Dibe8cj97SnU99V30 vRNW3GbvPbnVSoEsHWuKoMVpkIeeJs1TvtPBOd2eyvhJDJyBjV6XB0IKcg5XrPzfpVvZ ayW5nU+wR3ugRvJgRlCaeoapSqyEyF2UGlUBf7vr3PG4hYlJ6lWE2Dqdq30O1+Sdl4Sq 9uSn9uD9AIPrIqZHZRYhK6F5/Y38DUfLe1K5bXmyvDaSPqIVB2KcQxx3pLJFSpmUQlXa YaGs6RRtt2NFPywFHHGVrdfPGw+CT1G2RFcnPWoEP75l23q8AZSaQg0ViJyjcAer6TSh 06Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aAaTFeAX9SUnTmqJnXAmx0V/p3Vb8jjXltL67OGlZzs=; b=HaepAHxMbCt0NcoLaf2IAw5Nx3TsktnpU18osQzt3rtJChYVJwJCPxG21t8KCRxr0M xkAqcWzMhbEpgyLivBosCfwFBG6qJPVOf8oRSCSZDKKeI4GvUDCUj4czxF96uR5UGa0B KWwTILP59dvNynrlTgvXsL1RjCtCDxdBNZQUK1/HGB+Ekhd5EFVg/rBnh8S906QsVQEv PyzeHJDUgK6kre6gDk5EB02ZopjtAsQwAmF3PaY6WdsAQemYkspZnZyzqx/UhOJe+Ltl SeY/9I7a7oLHw2Sn/3OftwyUQ2Nt1gPvFXYZWsM+ZYke608rUY3Bc9ngtMWEuYbSWKGO mjNA== X-Gm-Message-State: ALyK8tLvtinnMKBVeEcCyY/PH2tJf4HAcljLcnxOb/+tcwD/OIBIv6j/f92LwEj7KifeBQ== X-Received: by 10.66.178.139 with SMTP id cy11mr8730249pac.157.1464111447995; Tue, 24 May 2016 10:37:27 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id w125sm55841224pfb.53.2016.05.24.10.37.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 10:37:26 -0700 (PDT) To: "Paul E. Jones" References: <37e9ce5d-7276-9797-c768-baa0dd7dfb54@jitsi.org> From: Emil Ivov Message-ID: <16c9af41-b92e-2726-6713-e89bcffa5ba1@jitsi.org> Date: Tue, 24 May 2016 12:37:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 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: Tue, 24 May 2016 17:37:31 -0000 On 24.05.16 г. 2:24, 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 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". Again, signalling whether rewrites are done should address your concern. > 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? > 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. > 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. Emil > > Paul > > ------------------------------------------------------------------------ > *From:* Emil Ivov > *Sent:* May 24, 2016 4:36:22 AM GMT+02:00 > *To:* "Paul E. Jones" > *Cc:* Adam Roach , Cullen Jennings , > perc@ietf.org > *Subject:* Re: [Perc] Request for decision review > > Hey Paul, > > On Mon, May 23, 2016 at 5:19 PM, Paul E. Jones wrote: > > Emil, > > The whole point of PERC is E2E encryption. > > > Yup ... I think we are on the same page there :) > > And, if Alice and Carol chose the > same SSRC value, the MDD can't change that. It can only rewrite it and > preserve the original value, as that original value is needed for E2E > decryption. > > > ... I won't re-explain this a sixth time :). Please read any of my > five previous explanations about this is not true. > > And that's where we run into the number space conflict. > > > Even if we do go for full rewriting preserving the original SSRC is > trivial and, as per your words, is only a matter of using 64bit > identifiers (the concatenation of the two SSRCs) at the receiving end > in order to get it to work with the double srtp unprotect. > > Where is the problem with that. > > Emil > > > From: Emil Ivov > Sent: May 23, 2016 11:54:21 PM GMT+02:00 > To: "Paul E. Jones" > Cc: Adam Roach , Cullen Jennings , > perc@ietf.org > Subject: Re: [Perc] Request for decision review > > On Mon, May 23, 2016 at 4:42 PM, Paul E. Jones > wrote: > > > Emil, > > > > The only *other* argument I've found so far is "some > implementors have > historically done it another way," which is relevant, > but not as > compelling as the countervailing argument of "it will > make the crypto > properties of this system harder to think about and > harder to > implement." > > > > > Another biggie: please explain to me what crypto properties > will be > harder > to think about and harder to implement if we were to just > relay the > original > SS! > RC as > either the early versions of double were proposing or as a > separate > extensi! on? > > > > > If we keep the SSRC value unchanged, this simplifies the logic > in the > SRTP > code since we avoid the possibility of having both Alice and > Carol using > the > same E2E SSRC value. > > > > As I have mentioned at least twice already :) ... this is not > necessarily true. Simulcast rewriting often reuses one of the original > SSRCs without introducing new ones, so conflict resolution could still > work as per 3550. Anyways, I think we shouldn't rely on that, but we > need to be accurate. > > SSRCs are what is used to identify the media stream > and related cryptographic parameters (per section 3.2.3 of RFC > 3711). If > E2E > SSRC values can potentially conflict, it would mean we'd need to > use a > new > > identifier (e.g., SSRC_HBH || SSR! C_E2E) that is "new" to SRTP > or prehaps > an > "instance" of a SRTP library per media flow (which would be terribly > unfortunate). > > > > PERC will rely on SRTP for HBH. Nothing I ever said challenges that. > Relying on stock unmodified SRTP primitives to handle E2E is a goal > that comes out of nowhere. It would be neat, sure, but not doing so > does not in any compromise the crypto properties of PERC. It is just > an implementation detail with a relatively low (aesthetic) cost at the > SRTP side and a huge gain on the SFU side. > > Emil > > > > -- https://jitsi.org From nobody Wed May 25 05:22: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 BA88512D1D1 for ; Wed, 25 May 2016 05:22:41 -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 vWIerWx8jPck for ; Wed, 25 May 2016 05:22:40 -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 F371412B03C for ; Wed, 25 May 2016 05:22:39 -0700 (PDT) Received: from [156.106.219.64] ([156.106.219.64]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4PCMZ3T010399 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2016 08:22:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464178959; bh=on5YrFhsaZ6hQ5/hOUimlCQ7SI5eEH0Y6FTNaXG5uFM=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=ZFrDu2E0j5qAHLW2v6899jHkSt6r23v63sSp6w7QPvtUKLPr77XnPHZkEDNRsRkHf Eg2XrS5Pmo32mrasGGzMuLTEq6hFQZRIIA2f5N9zPEQqLo6skBXQM65j00ZhP/R5My /F8Rcok6NVc5OPF1937Y7FB9Kad9FI/9QyRfhGc8= From: "Paul E. Jones" To: "Emil Ivov" Date: Wed, 25 May 2016 12:22:36 +0000 Message-Id: In-Reply-To: <16c9af41-b92e-2726-6713-e89bcffa5ba1@jitsi.org> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 25 May 2016 08:22:39 -0400 (EDT) Archived-At: Cc: 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, 25 May 2016 12:22:42 -0000 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=20 >mandate that SFUs preserve the SSRC space. That's not hard to=20 >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=20 >that has to be signalled so clients can choose whether to support it or= =20 >not. This should address your concern. The SFU has nothing to do with the E2E SSRC collision problem. When an=20 endpoints sends out an RTP packet and it goes though an SFU that changes= =20 the SSRC, there is a HBH SSRC and an E2E SSRC. I fully agree that the=20 SFU can ensure that the HBH SSRCs do not collide, but it cannot control=20 the fact that the E2E SSRCs collide. > >>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=20 >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= =20 nonetheless SRTP. What PERC is adding are some additional steps between= =20 each pass for HBH authentication of packets at the sender (and the=20 reverse at the receiver). The MDD doesn't have two steps: it just does=20 one normal SRTP decryption for the packet received and one SRTP=20 encryption step sending the packet. The only special requirement PERC=20 introduces is that if the MDD changes either the PT field or sequence=20 number, the original values have to be added to the packet inside an RTP= =20 header extension called OHB (if not already present). >>The problem with using a 64 bit value is that any existing SRTP=20 >>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=20 >long? No, lamenting that this would not align with what RFC 3711 says to use=20 to identify the context. >>Further, if we >>wish to break up the PERC processing into two steps, that HBH SSRC=20 >>would >>have to be extracted and passed in by the application. While I think=20 >>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=20 >to see how FEC is any different than regular media. As you say it=20 >yourself, it all just works out properly as long as you do your FEC=20 >after E2E and before HBH as that way the SFU would be able to de- or=20 >re-FEC. Historically, there were two options for FEC. Either we do FEC first=20 and then SRTP, or SRTP first then FEC. The order has to match at both=20 the sender and receiver. Either way, it generally makes very little=20 difference. An MDD might want to be a good citizen and reconstruct lost packets=20 before sending a stream to a receiver. In order to do that, the sender=20 will either need to do SRTP (both passes) then FEC or it could do the=20 first SRTP pass (the E2E encryption pass) then FEC then SRTP for the=20 HBH. It really depends on what we want that FEC flow to look like. Do=20 we want it to be FEC over a bunch of E2E+HBH encrypted packets or just=20 over the E2E packets. (The latter would be parallel to the current FEC=20 order of "FEC then SRTP". So, thinking of how this might be implemented in an SRTP library, if we=20 allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when the=20 application encrypts the packet, it would pass the packet into the SRTP=20 libtary once to encrypt HBH. It then does whatever FEC processing it=20 wants, then it calls into the SRTP library again to encrypt the second=20 pass (HBH pass). It could be two entirely instances of the SRTP library= =20 that handles each pass. On the MDD, it decrypts the flow and does=20 whatevever FEC magic it wants to do. There is only one SRTP operation=20 at the MDD, so no problem. At the receiver, it decrypts the packet=20 received using HBH decryption. It then does whatever FEC processing it=20 needs to do. Next, it would call into the SRTP library to decrypt for=20 E2E. If the SSRCs never change, this works fine. One could implement=20 this using two instances of an SRTP library today. If a single library=20 is used, then the only requirement is to ensure the second call into the= =20 library does not encounter issues with the replay database (since it=20 might otherwise think it's a replayed packet). In either case, the=20 crypto context would be looked up as per RFC 3711 using SSRC. If,=20 however, the SSRC value is allowed to change, then the second call into=20 the SRTP library (same or different instance of the library) would be a=20 problem since Alice and Bob both used SSRC 1. The collision is going to= =20 prevent the library from working properly. If we take the approach of using a 64-bit identifier (in contradiction=20 to RFC 3711) to identify the crypto context, then we would need to pass=20 that identifier into the SRTP library when attempting to decrypt the=20 packet, because it could not simply discover it by looking at the packet= =20 (which it could do normally since the SSRC value is right there in the=20 packet). It would be necessary to make a call like=20 srtp_unprotect(context, packet, stream_identifiier) (where=20 stream_identifier is something that identifies the stream other than the= =20 SSRC per 3711, like E2E_SSRC || HBH_SSRC). A beautiful thing about SRTP today is the library can operate on streams= =20 without the application having to pass in such identifiers. The stream=20 is self-identifying. But, we lose that elegance when we modify the SSRC= =20 in the MDD when we break the operation into two passes to handle this=20 FEC order. >>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= =20 >optimization if we get it but I really don't think the alternative is=20 >anywhere near the complexity that would justify banning SSRC=20 >re-writing. At least we agree that it would be a good goal to find an approach that=20 would eliminate or minimize changes to the SRTP logic. :) Now to the complexity part... that's in the thread you're having with=20 Cullen which, as I understand, is an expression of a concern that=20 receiving endpoints are not going to properly handle multiple simulcast=20 streams coming toward them. Since I don't work for a browser vendor, I cannot speak to their plans. = =20 I can only assume that proper handling of received simulcast flows would= =20 be implemented per the current drafts. And if that's the case, then I=20 don't think changing the SSRC would be needed. If receiving endpoints=20 fail to do that, then you're right that this could be a problem. Paul From nobody Wed May 25 11:23:54 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 6749512D7F4 for ; Wed, 25 May 2016 11:23:52 -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 LcOhTK8nF3PO for ; Wed, 25 May 2016 11:23:49 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 624ED12D52C for ; Wed, 25 May 2016 11:23:46 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j1so92294015oih.3 for ; Wed, 25 May 2016 11:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=TH3O9/IWh5sqI/AITV0roH4HJboeMSHEQTAzCn43IAw=; b=FVzJt2XkZBG69IKS2+WF39NrtI/zDYmkgJYNAt5aphMfOVq7izuY4G/+a+zmXNnZSh HTdt5RVdtFerJDZhOYNl9BOYfPeg7ivnDA4+nIUMdI3J79pa1YZc7SGkWJEcNDxfPudz SKlFBQWnOwiRgHdOv9zxU2ZYNVMzzMPax9jaGLBkvTpETM4h6OM+htNl5x8Qum17OGm9 d/TPOiIg+SmgkL/i7JMl+JKUsBi1yrCXHxYhZBnqEnzuke8IH6rkD7RXhRLtutaJ0WoP n1fU/NrCse3Ve7AEVQ9Kgnj2zAX2S/1T3B/Laj/Fs6fsLgASN6zyj/BlXDcvE6tSDONt A+lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=TH3O9/IWh5sqI/AITV0roH4HJboeMSHEQTAzCn43IAw=; b=N/e6PG/fbVyxuPRzDSXRl7E3Q6R8vGVRqnb/bKVU6CD8KwobVNkYu5pxBHb7Q/uSWa wMmFaSrW9J5+/e2A4qZyOK/GlOx/ymxYnHSf5sUknVp5uAKnCNO3Dz6RHGBV0Y5WaFTh PQZnV2ekjO5VX3MJPvf7FmKqLjZi6hKpNEtsEMowA9FZdV6C+uxkcq1jLH/AhxHG95KE OkQTismTqXMlb7qjIl055iyEgrtEHZnMiBiY0LdEqeAkF85/Xj64tMNcG7rMuUelHCGh cDOHkckXm6DudJUple7BOTVlW7N2rwKNy1xU0bMCgIUvOrQKvmwZIhrmRH9K9aNumsx8 MIEA== X-Gm-Message-State: ALyK8tKPckS87VmyLsg6mmLcNLwIVVDua3DJkRUwaUJ8i9R4SufVJsZEMs4H+FMrb3Kcag== X-Received: by 10.157.16.55 with SMTP id h52mr3590329ote.175.1464200625407; Wed, 25 May 2016 11:23:45 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id o6sm4532757oik.20.2016.05.25.11.23.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 11:23:44 -0700 (PDT) To: "Paul E. Jones" References: From: Emil Ivov Message-ID: <92c44be4-6339-a15c-e921-bf39b7d32690@jitsi.org> Date: Wed, 25 May 2016 13:23:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 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, 25 May 2016 18:23:53 -0000 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 г. 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 > 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 > 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 > 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. 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 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 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 > 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 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 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 > 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 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 From nobody Wed May 25 13:20: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 0AA4012D7E8 for ; Wed, 25 May 2016 13:20:24 -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 SNmNPjRUX4xG for ; Wed, 25 May 2016 13:20:21 -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 371AB12D4FD for ; Wed, 25 May 2016 13:20:21 -0700 (PDT) Received: from [156.106.229.0] ([156.106.229.0]) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u4PKKISa012366 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2016 16:20:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464207620; bh=tiBHWa5XioR5lOHQHWM34qz/TLz3nyG4NKdgUbGzDt8=; h=From:To:Subject:Cc:Date:In-Reply-To:Reply-To; b=K3Llc5sIPpZlga4Id0dfuqHX+HTAGTTD99HKqyyKgUysDUZikGQFgZbAdPAxW362E rkFoYQ8NUG3qLCnHnGSMF2asMgXOJz8mYuOrZCBhtnCJLvEUKAdgI/nMXnAvH9iGTG HM08mVJL5OakzdvOqRCUq2NNsVYEZ+OdiYaTsXJo= From: "Paul E. Jones" To: "Emil Ivov" Date: Wed, 25 May 2016 20:20:19 +0000 Message-Id: In-Reply-To: <92c44be4-6339-a15c-e921-bf39b7d32690@jitsi.org> 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.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 25 May 2016 16:20:20 -0400 (EDT) Archived-At: Cc: 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, 25 May 2016 20:20:24 -0000 Emil, You are saying that endpoints would negotiate via signaling which SSRC=20 value(s) to use before actually joining the conference? That doesn't strike me as terribly appealing, honestly. Between that=20 and the pain of dealing with conflicting SSRCs, I might favor the=20 latter. What I'd prefer most, though, is neither and just let endpoints= =20 do their thing. I'd still like to hear confirmation that receiving browsers will=20 definitely be doing the right thing w.r.t. receiving simulcast streams. = =20 Adam seemed to suggest Firefox will be doing the right thing (probably=20 before PERC is done). What about popular browsers? 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 suggestion=20 >I made and I consider it important: > >We can allow SSRC rewriting and make it negotiable by signalling. This=20 >way SFUs can state they support rewriting/immutability/both and=20 >endpoints can choose to use what's available or reject the session as=20 >unsupported. > >I believe this should address the concerns that have been expressed so=20 >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=20 >>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 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 it's=20 >potential solutions. What you describe is one way to handle things.=20 >Another one would be to just make SSRC conflicts obvious to senders so=20 >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=20 >>it's >>nonetheless SRTP. > >Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock=20 >SRTP endpoint would do anything meaningful with them. So what you are=20 >looking is to just optimize implementations, which is relevant but not=20 >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=20 >>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=20 >>RTP >>header extension called OHB (if not already present). >> >> >>>>The problem with using a 64 bit value is that any existing SRTP=20 >>>>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=20 >>>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=20 >E2E as possible and that's admirable but it's not a reason why we=20 >should significantly disrupt existing implementations. > >>>>Further, if we >>>>wish to break up the PERC processing into two steps, that HBH SSRC=20 >>>>would >>>>have to be extracted and passed in by the application. While I think= =20 >>>>the >>>>intent with Double is for this to be an autonomous operation, it=20 >>>>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 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 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 >>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=20 >>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. =20 >>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=20 >>FEC >>order of "FEC then SRTP". >> >>So, thinking of how this might be implemented in an SRTP library, if=20 >>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=20 >>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=20 >>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=20 >>library >>is used, then the only requirement is to ensure the second call into=20 >>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=20 >>into >>the SRTP library (same or different instance of the library) would be=20 >>a >>problem since Alice and Bob both used SSRC 1. The collision is going=20 >>to >>prevent the library from working properly. > >I still fail to see how FEC changes any of this (for better or worse).=20 >The problem you describe here is exactly the same with or without FEC=20 >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=20 >encryptions are not part of 3711. We simply need to set the=20 >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=20 >>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=20 >>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=20 >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 the=20 >>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=20 >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=20 >>>>a >>>>two-step wrapper around the existing SRTP library to avoid 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 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 approach=20 >>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=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 flows=20 >>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=20 >breaking in the way browsers handle simulcast reception today. They are= =20 >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=20 >RID does go through all of the IETF process. > >Also, the availability of this option (simulcast unaware receivers) and= =20 >its existence today make the motivation for RID support on the=20 >receiving end pretty low. It does not give you anything extra in terms=20 >of functionality. There are no substantial benefits from doing it (and=20 >no it doesn't allow for significantly simpler SFUs ... those would=20 >still have to keep 95% of their existing logic). We can decide to make=20 >PERC dependent on it and hope that this would sway all browser vendors=20 >... 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=20 >compromise may lie in the option for PERC to allow an SSRC rewriting=20 >mode combined with the option for endpoints to not support it. In other= =20 >words we can have part of the PERC signalling indicate whether the=20 >client and the server support these modes and whether they use them.=20 >This is not beautiful (by any means) but it wouldn't prevent either of=20 >us to do things their way. > >Emil >-- https://jitsi.org From nobody Wed May 25 13:43:54 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 3B97512D906 for ; Wed, 25 May 2016 13:43:53 -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 BAZam2aJ1JXx for ; Wed, 25 May 2016 13:43:50 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 E40B612D0A3 for ; Wed, 25 May 2016 13:43:49 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j1so96704498oih.3 for ; Wed, 25 May 2016 13:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=eeVbG9zjYe2EnddbQsHG1Us7rr6j/KwgLzfgVytXk9A=; b=VkCnmWDrJhpisYlI7sGR8FFl6+qNAMIfM0tJ5XnM4/unNStAzJN0ebzd5wEMCsmL+h cjHKl3QllxZNlO91px0oMI+elVIqd4I4xE3U1zcmOcVRwZaQoYK3wgAyZj0Y72AnNQU9 +HOLVaJSjINOtSk7I7o1Jgcb9tMpmNXdrJUZTjrebiOn9bGUyz7LwoyHTqsoknC+Iop5 bqRxsEhMIWwPOzGTBc8oo3CE+YCilvRDV4zG/8PjhB5GorMTxS+7TgYlhizSRYZhGeaA 3AcZCDLy7AnMmHk8MKyoq3/vZkJow1akicbkwc8BMBwuYM2LqiKWXcvYIA8++fsKQGjW 0Q3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eeVbG9zjYe2EnddbQsHG1Us7rr6j/KwgLzfgVytXk9A=; b=BT1btLLb0myudM4TEdAG0MAgs6bX1fqcff/xkcSufPuXgHxvX7ZiP+FYm49lm/AtrX HV+hvVmXh4zzWzJKnQfZJ1MfyKAc+kuar54XZFyk5r1DuIRPd/Dk8T/B1dFKWiUIbQmI WrhXAYMSF3sxqXCUKfWMUjXkKmmQJdSSYV9IfKbipQynNO39aq7T58xXg7ZY/fq/tp3o iXqedDoniB8h01/uS3ejo8gKHsQ8qoMC4XZykMBHc81h64h39t+9D5Mf0mp9EE8oCoqe Rk2Gt1lux1SQAUY9U72XXgFsi66ZwgfbqpMHIASy8V6QlLxpjmz7J2a6cXdWcFkOCiiu kjqQ== X-Gm-Message-State: ALyK8tLORDgp8hbCcLZK0KA0cjIVkY/Pwg24LPOYWHoI8RC7cHB6lmvBKfttwBGqtOYGMw== X-Received: by 10.202.204.20 with SMTP id c20mr3699012oig.17.1464209029138; Wed, 25 May 2016 13:43:49 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id 99sm4762332otf.36.2016.05.25.13.43.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 13:43:48 -0700 (PDT) To: "Paul E. Jones" References: From: Emil Ivov Message-ID: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> Date: Wed, 25 May 2016 15:43:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 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, 25 May 2016 20:43:53 -0000 On 25.05.16 г. 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 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 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. it's not part of webrtc 1.0. we'd like to do it in the future. 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 г. 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 >>> 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 >>> 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 >>> 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. 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 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 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 >>> 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 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 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 >>> 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 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 From nobody Wed May 25 14:25:05 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 B219812D16A for ; Wed, 25 May 2016 14:25: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 SFRuX4TsUT0q for ; Wed, 25 May 2016 14:25:01 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 E7F4812D1ED for ; Wed, 25 May 2016 14:25:00 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id x189so59808157ywe.3 for ; Wed, 25 May 2016 14:25: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=St774POEcKKl5SOXKpRfB/dtKE6aReaDrvVvqCtS3Lk=; b=LO6Ky0yY7ZmT4pY9aqdtIibh3kM7JJUhUqKoPrQTm7ZTEmQFbnq7dvhMTihr1TzSTS ly2MSKAslrKIdV2wdU31BYbp9diRahzxmmoa34pfnkkQALMdZGZ2O6LqZcMIOOxS8Vdq 0mpm5BxaT+BUcs8gzMcUetmLckyAo6MUliD15lQbLwk8VcZ2bKekyLhxrPrG+A8nZdd9 0T4wWEhw9yhMWN49591Q/z4iZxiaPVaqQar5R5YP5+omedPAtUwjjme8R3ljKEHrLnXE gFuhCRYh6Xbif8EdJrew2VBVWMZrS2lHSPdhanx75z4wvEWldOgFBMbpn6LbotKyqjMA 8YNw== 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=St774POEcKKl5SOXKpRfB/dtKE6aReaDrvVvqCtS3Lk=; b=LsI/19s9ByM3mfbC261vbjaSAK6WkVfHBkPLqz6fZTED/Zc+cNl8yYOYGe5ZvF9zZN KzrDoC0kJBNes4NPWGNHdahi+Xqsgti5lNn8jYOxXYVgz7cWvpPWulBe9qreZ8zphnGe fYPST74liQ2BeV7V+QmkaZR0mJNYlYP0rovlKk/ELRnINbsx+U18NRtWLubvW+FARuNF qKiR87qxYki6gprQi3rG9nX+s9EK15RBW68EIBO575GweHWCs9CTWMgVhUfBu/0oFPDK Iw4t4Qzqtap14z1ylNccej5nNp9MwiMoi5HI9sLwhfcLq0n40dOiBhL9LE9sY/cfp/Ac /JnA== X-Gm-Message-State: ALyK8tLgUNmoVH1Cu96JNPraJYWOx/5BFZaIsMGNxuk8KMay6jfInEtyzzVCz9KcrwmynPBZQkKoSbZz2Wm11g== X-Received: by 10.37.218.141 with SMTP id n135mr3534497ybf.146.1464211498779; Wed, 25 May 2016 14:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.132.12 with HTTP; Wed, 25 May 2016 14:24:19 -0700 (PDT) In-Reply-To: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> References: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> From: Eric Rescorla Date: Wed, 25 May 2016 14:24:19 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=94eb2c07f17c42f8650533b14e4c Archived-At: Cc: "Paul E. Jones" , 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, 25 May 2016 21:25:03 -0000 --94eb2c07f17c42f8650533b14e4c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 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 > negotiate whether or not they will be dealing with a single end-to-end SS= RC > 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 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 (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. 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? > 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 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 a= n >>>> endpoints sends out an RTP packet and it goes though an SFU that chang= es >>>> 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 contro= l >>>> 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 doe= s >>>> 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 R= TP >>>> 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 mig= ht >>>>>> not be implemented that way for two reasons: >>>>>> 1) If there is a desire to do HBH FEC, the process might be to encry= pt >>>>>> 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 introdu= ce >>>>>> 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 >>>> 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 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. It really depends on what we want that FEC flow to look like. D= o >>>> 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 FE= C >>>> order of "FEC then SRTP". >>>> >>>> So, thinking of how this might be implemented in an SRTP library, if w= e >>>> 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 SRT= P >>>> 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 libra= ry >>>> 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 librar= y >>>> is used, then the only requirement is to ensure the second call into t= he >>>> 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 int= o >>>> 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 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 pack= et >>>> (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 t= he >>>> 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 strea= m >>>> is self-identifying. 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 otherwis= e >>>>>> 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 bannin= g >>>>> SSRC re-writing. >>>>> >>>> >>>> At least we agree that it would be a good goal to find an approach tha= t >>>> 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 simulcas= t >>>> 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 wou= ld >>>> 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 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 > --94eb2c07f17c42f8650533b14e4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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. 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?


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

Yes.

-Ekr
= =C2=A0



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: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

--94eb2c07f17c42f8650533b14e4c-- From nobody Wed May 25 14:47:13 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 AB81C12DA28 for ; Wed, 25 May 2016 14:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 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.426, 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 i4U71qE30_Ub for ; Wed, 25 May 2016 14:47:09 -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 D3FF812B051 for ; Wed, 25 May 2016 14:47:08 -0700 (PDT) Received: from dev002.vpn.arid.us (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 u4PLl4jE020386 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2016 17:47:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1464212827; bh=obDet9XasLVYINMaQrNvg7cL78t54C3dq8FYpwDaPcA=; h=In-Reply-To:References:Subject:From:Date:To:CC; b=WiOZvGLt/Cx3S5oVh4GNMr/vG6iPsRMIfjrI/jXKH4iOjSiRgWaCjMIjuo2Cwu9sn G+CSIajT7G6PZ0hHygHdQ8RzARIao8pKdgu69jnXqlxNKhF62ZwVZqTW1MmMCeB75U whY95/T8mfREjHn16SQRM79UwgggPZ+N8mycfd84= User-Agent: K-9 Mail for Android In-Reply-To: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> References: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WPS2ROC4S5NHNBFFWEC4H4BIQP00YI" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Wed, 25 May 2016 23:47:02 +0200 To: Emil Ivov Message-ID: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.16 (dublin.packetizer.com [10.137.60.122]); Wed, 25 May 2016 17:47:07 -0400 (EDT) Archived-At: Cc: 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, 25 May 2016 21:47:12 -0000 ------WPS2ROC4S5NHNBFFWEC4H4BIQP00YI Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Emil, I want trying to attribute anything negative to you, just like I didn't mean to smack the Mozilla folks in the face with my "what about popular browsers" question that should have had "other" stuck in there. :) So negotiate a single E2E space doesn't sound helpful if the other negotiated result still leaves the other option where it changes. Multiple options just leads to the same or higher complexity. Maybe we should make this decision once we have a better feel for the browser behavior? Paul -------- Original Message -------- From: Emil Ivov Sent: May 25, 2016 10:43:47 PM GMT+02:00 To: "Paul E. Jones" Cc: Adam Roach , Cullen Jennings , perc@ietf.org Subject: Re: [Perc] Request for decision review On 25.05.16 г. 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 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 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. it's not part of webrtc 1.0. we'd like to do it in the future. 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 г. 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 >>> 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 >>> 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 >>> 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. 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 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 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 >>> 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 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 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 >>> 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 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 ------WPS2ROC4S5NHNBFFWEC4H4BIQP00YI Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Emil,

I want trying to attribute anything negative to you, just like I didn't mean to smack the Mozilla folks in the face with my "what about popular browsers" question that should have had "other" stuck in there. :)

So negotiate a single E2E space doesn't sound helpful if the other negotiated result still leaves the other option where it changes. Multiple options just leads to the same or higher complexity.

Maybe we should make this decision once we have a better feel for the browser behavior?

Paul

From: Emil Ivov <emcho@jitsi.org>
Sent: May 25, 2016 10:43:47 PM GMT+02:00
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Adam Roach <adam@nostrum.com>, Cullen Jennings <fluffy@iii.ca>, perc@ietf.org
Subject: Re: [Perc] Request for decision review



On 25.05.16 г. 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 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 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. it's not part of webrtc 1.0. we'd like to do 
it in the
future.

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: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 signalli!
 ng.
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 г. 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
 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
 SR!
 TP
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 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 abl!
 e 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 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.  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 fo!
 r 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 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 instance!
 s 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
 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 t!
 ake 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 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 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 conc!
 ern
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 ma!
 ke 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

------WPS2ROC4S5NHNBFFWEC4H4BIQP00YI-- From nobody Wed May 25 16:04:56 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 AE21C12DE15 for ; Wed, 25 May 2016 16:04:53 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=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 dITw8cnS5la4 for ; Wed, 25 May 2016 16:04:50 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 C180B12D587 for ; Wed, 25 May 2016 16:04:49 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id c127so61112104ywb.1 for ; Wed, 25 May 2016 16:04:49 -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:date:message-id:subject:from:to :cc; bh=5F4Whja8hyj7+Rr8eJV47kpk9IsZyZuobQcTGJ6YXTw=; b=Iwjzks+biU0cB2I0rc2spibaAJ1scM1Rqf8uD85bD09uueZt/uKzob9lJ5Bt3UxBsm 34Mv/arww1rHQFQg79cZo/LUmQPiwywHv22xEXhJTMvAGXplkiQqU+X3dfJ2XYrBTqqD ee1zJpZpSNg7mE2MBh20FAqiyjpi/Icf65Ws60wxqvqC8CYTJPl8Ub4vHYYYc7uQnEB/ uRFICOSRKyyE5um9Dn3AXJHhNmTdBtoP1fsOPjOFSqnOfowYrG3OBa98CsCei+OmXTJq yBSm+bCT0D7erqFYuuho3yZE1FczcvgFP24z8kmDTdooj5uNk9ea1I13zD9WbNW59eYk a/zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5F4Whja8hyj7+Rr8eJV47kpk9IsZyZuobQcTGJ6YXTw=; b=Ofw/NCfj53UiEId4LIqmSqtiWiGexedvEaggAScoCm6HeuUbkQ8sacNR5LhmjnCr9B a+6m9fQhgLiXYrbmiCVjOPwRyV8W0vGazfcBAVcaOG0NdtWIFR5kQQFbePrkYyPDaNrQ Yz61VAv87S9ooDbeIvY7cpdytnvf0zUPjOKb3g5Y/2jNB6bApKlVE1QQA+Dmvq4HGLNN ZKvU4euHiyiEJ1N2Ze1NCgDHTAkWd9H2FwumiNmxpOK0El+WFqRl9AycwUlWzky0meL0 ruJqbsd0bQGbltEs+UT0jiNS7mLU3pxU1Rm0EX9SOmutVzb3nYRydQFzj4ZkM45ORPHK Jjjg== X-Gm-Message-State: ALyK8tJNGHHEHjAlcFtgZYku9yaCbQP64LKoUUqPHhsaiI0PulR+oCqrLRT4csZe9zW9dA== X-Received: by 10.140.93.161 with SMTP id d30mr5953134qge.55.1464217488626; Wed, 25 May 2016 16:04:48 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com. [209.85.220.175]) by smtp.gmail.com with ESMTPSA id 188sm2992864qhf.44.2016.05.25.16.04.47 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 16:04:47 -0700 (PDT) Received: by mail-qk0-f175.google.com with SMTP id x7so46523237qkd.3 for ; Wed, 25 May 2016 16:04:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.218.65 with SMTP id c62mr4005714ywe.36.1464217486839; Wed, 25 May 2016 16:04:46 -0700 (PDT) Received: by 10.83.50.7 with HTTP; Wed, 25 May 2016 16:04:46 -0700 (PDT) In-Reply-To: References: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> Date: Wed, 25 May 2016 18:04:46 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=94eb2c0805082dd9a50533b2b3b0 Archived-At: Cc: 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, 25 May 2016 23:04:54 -0000 --94eb2c0805082dd9a50533b2b3b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, 25 May 2016, Paul E. Jones wrote: > Emil, > > I want trying to attribute anything negative to you, just like I didn't > mean to smack the Mozilla folks in the face with my "what about popular > browsers" question that should have had "other" stuck in there. :) > > So negotiate a single E2E space doesn't sound helpful if the other > negotiated result still leaves the other option where it changes. Multipl= e > options just leads to the same or higher complexity. > The option would be for a client to refuse to participate in a conference where an E2E SSRC space cannot be guaranteed. This means that your endpoints will be able to work with MDDs that are implemented the (according to you) right way and would be able to safely reject all others. Emil > > > Maybe we should make this decision once we have a better feel for the > browser behavior? > > Paul > > ------------------------------ > *From:* Emil Ivov > > *Sent:* May 25, 2016 10:43:47 PM GMT+02:00 > *To:* "Paul E. Jones" > > *Cc:* Adam Roach >, Cullen Jennings < > fluffy@iii.ca >, > perc@ietf.org > *Subject:* Re: [Perc] Request for decision review > > > > 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 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 are not doing this now. it's not part of webrtc 1.0. we'd like to do > it in the > future. > > 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 signalli! >>> ng. >>> 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 featur= e >>>>> 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 chan= ges >>>> the SSRC, there is a HBH SSRC and an E2E SSRC. I fully agree that th= e >>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot contr= ol >>>> 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 i= t's >>>> nonetheless SRTP. >>>> >>> >>> Exactly! And two passes of SRTP happen to NOT be SRTP as in: no stock >>> SR! >>> TP >>> 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 do= es >>>> one normal SRTP decryption for the packet received and one SRTP >>>> encryption step sending the packet. The only special requirement PER= C >>>> 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 us= e >>>> 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 mi= ght >>>>>> not be implemented that way for two reasons: >>>>>> 1) If there is a desire to do HBH FEC, the process might be to encr= ypt >>>>>> E2E -> FEC -> HBH. So the second call to the SRTP library would nee= d >>>>>> that HBH SSRC passed in when doing these steps in reverse to introd= uce >>>>>> that 64-bit context ID. >>>>>> >>>>> >>>>> Em ... you'd have to explain this in a bit more detail because I fai= l >>>>> 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 abl! >>>>> e 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 bot= h >>>> 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 send= er >>>> 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 encrypted packets or jus= t >>>> over the E2E packets. (The latter would be parallel to the current F= EC >>>> 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 fo! >>>> r FEC >>>> order, then when the >>>> application encrypts the packet, it would pass the packet into the SR= TP >>>> 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 secon= d >>>> pass (HBH pass). It could be two entirely instances of the SRTP libr= ary >>>> 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 operatio= n >>>> 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 fo= r >>>> E2E. If the SSRCs never change, this works fine. One could implemen= t >>>> this using two instance! >>>> s 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 in= to >>>> 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 FEC >>> and it's what we are having the argument about. >>> >>> If we t! >>>> ake 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 pac= ket >>>> (which it could do normally since the SSRC value is right there in th= e >>>> 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 stre= am >>>> 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 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 otherwis= e >>>>> 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 bannin= g >>>> SSRC re-writing. >>>> >>> >>> At least we agree that it would be a good goal to find an approach tha= t >>> 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 conc! >>> ern >>> that >>> receiving endpoints are not going to properly handle multiple simulcas= t >>> 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 wou= ld >>> 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 ma! >> ke 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 >> > > --=20 sent from my mobile --94eb2c0805082dd9a50533b2b3b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, 25 May 2016, Paul E. Jones <paulej@packetizer.com> wrote:
Emil,

I want trying to attribute anything negative to you, just like I didn't= mean to smack the Mozilla folks in the face with my "what about popul= ar browsers" question that should have had "other" stuck in = there. :)

So negotiate a single E2E space doesn't sound helpful if the other nego= tiated result still leaves the other option where it changes. Multiple opti= ons just leads to the same or higher complexity.
The option would be for a client to refuse to participate in a = conference where an E2E SSRC space cannot be guaranteed. This means that yo= ur endpoints will be able to work with MDDs that are implemented the (accor= ding to you) right way and would be able to safely reject all others.
=

Emil

=C2=A0
=


Maybe we should make this decision once we have a better feel for the brows= er behavior?

Paul

From: Emil Ivov <emcho@jitsi.org>
Sent: May 25, 2016 10:43:47 PM GMT+02:00
To: "Paul E. Jones" <paulej@pa= cketizer.com>
Cc: Adam Roach <adam@nostrum.com>, Cul= len Jennings <fluffy@iii.ca>, p= erc@ietf.org
Subject: Re: [Perc] Request for decision review



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 actuall=
y joining the conference?

It's awesome how you woul= d always attribute to me the least appealing of
all possible interpreta= tions :).

Whether or not we negotiate SSRCs should not be within PER= C'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 ortho= gonal to PERC.

What I was suggesting is the possibility for PERC end= points 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 an= d E2E SSRC spaces.

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

Does this make more sense?

That doesn't strike me as terribly appealin= g, honestly. Between that
and the pain of dealing with conflicting SSR= Cs, I might favor the
latter. What I'd prefer most, though, is nei= ther and just let endpoints
do their thing.

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

I think at this point th= e answers that I've heard are for both browsers:
we are not doing t= his now. it's not part of webrtc 1.0. we'd like to do
it in the future.

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
<= br> ------ Original Message ------
From: "Emil Ivov" <emcho@jitsi.org>
To: "Paul E. Jones" &l= t;paulej@packetizer.com>
Cc: "Adam= Roach" <adam@nostrum.com>; "Cullen= Jennings" <fluffy@iii.ca>;
perc@ietf.org
Sent: 5/25/2016 2:23:43 PM
Subject: Re: [Pe= rc] 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 allo= w SSRC rewriting and make it negotiable by signalli! ng. 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 h= ave been expressed so
far.

Now for the rest of the points:
<= br> On 25.05.16 =D0=B3. 7:22, Paul E. Jones wrote:
Emil,

Since we are not enforcing a re= quirement that endpoints select a
distinct SSRC per media flow, there i= s 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.

W= e can also say that whether or not SFUs do that rewrite is a feature
th= at has to be signalled so clients can choose whether to support it
or n= ot. This should address your concern.

The SFU has noth= ing 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, the= re is a HBH SSRC and an E2E SSRC. I fully agree that the
SFU can ensur= e that the HBH SSRCs do not collide, but it cannot control
the fact tha= t the E2E SSRCs collide.

The SFU has everytihng to do = with the E2E collision problem and it's
potential solutions. What y= ou describe is one way to handle things.
Another one would be to just m= ake 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 wor= k
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 happen= s 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 st= ock
SR! TP endpoint would do anything meaningful with them. So what you are
lookin= g is to just optimize implementations, which is relevant but not
the pr= imary concern.

What PERC i= s adding are some additional steps between
each pass for HBH authentica= tion of packets at the sender (and the
reverse at the receiver). The M= DD 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 chan= ges 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 n= ot already present).


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

So just to be clear ... we are lame= nting about changing an int to a
long?

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

Again, 3711 applies to HBH. We are tryin= g to reuse as much of it for
E2E as possible and that's admirable b= ut it's not a reason why we
should significantly disrupt existing i= mplementations.

Fur= ther, if we
wish to break up the PERC processing into two steps, that H= BH 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 autonom= ous 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 nee= d
that HBH SSRC passed in when doing these steps in reverse to introduc= e
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 work= s out properly as long as you do your FEC
after E2E and before HBH as t= hat way the SFU would be abl! e to de- or
re-FEC.

Historically, there were two options fo= r 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 b= e a good citizen and reconstruct lost packets
before sending a stream t= o a receiver. In order to do that, the sender
will either need to do S= RTP (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 encrypted packets or just
over the E2E packets. (Th= e latter would be parallel to the current FEC
order of "FEC then S= RTP".

So, thinking of how this might be implemented in an SRTP= library, if we
allow the SRTP(E2E)+FEC+SRTP(HBH) option fo! r 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 th= en does whatever FEC processing it
wants, then it calls into the SRTP l= ibrary again to encrypt the second
pass (HBH pass). It could be two en= tirely instances of the SRTP library
that handles each pass. On the MD= D, 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 rec= eiver, it decrypts the packet
received using HBH decryption. It then do= es whatever FEC processing it
needs to do. Next, it would call into th= e SRTP library to decrypt for
E2E. If the SSRCs never change, this wor= ks fine. One could implement
this using two instance! s of an SRTP library today. If a single library
is used, then the only require= ment is to ensure the second call into the
library does not encounter i= ssues with the replay database (since it
might otherwise think it's= a replayed packet). In either case, the
crypto context would be looke= d up as per RFC 3711 using SSRC. If,
however, the SSRC value is allowe= d to change, then the second call into
the SRTP library (same or differ= ent instance of the library) would be a
problem since Alice and Bob bot= h used SSRC 1. The collision is going to
prevent the library from work= ing 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 argum= ent about.

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

:) ... It is NOT in contradiction with 3711 because laye= rs of
encryptions are not part of 3711. We simply need to set the
e= xpectations right for implementers.

to identify the crypto context, then we would need to pass
t= hat identifier into the SRTP library when attempting to decrypt the
pac= ket, 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
p= acket). It would be necessary to make a call like
srtp_unprotect(conte= xt, packet, stream_identifiier) (where
stream_identifier is something t= hat 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 s= imply apply a
second srtp unprotect it is still not stock 3711).
is the library can operate on st= reams
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 hand= le 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 ha= ving a 100 mail thread. I am speechless.

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

As I said, being able to reuse SRTP libraries with n= o change is a
great optimization if we get it but I really don't th= ink 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 minim= ize changes to the SRTP logic. :)

Now to the complexity part... tha= t's in the thread you're having with
Cullen which, as I underst= and, is an expression of a conc! ern that
receiving endpoints are not going to properly handle multiple simu= lcast
streams coming toward them.

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

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

The= re 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 ma! ke 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 substa= ntial benefits from doing it (and
no it doesn't allow for significa= ntly simpler SFUs ... those would
still have to keep 95% of their exist= ing logic). We can decide to make
PERC dependent on it and hope that th= is 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 al= low an SSRC rewriting
mode combined with the option for endpoints to no= t support it. In
other words we can have part of the PERC signalling in= dicate 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


=C2=A0

--
sent from my mobile
--94eb2c0805082dd9a50533b2b3b0-- From nobody Wed May 25 16:19:10 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 C56CE12B03B for ; Wed, 25 May 2016 16:19:06 -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, HEADER_FROM_DIFFERENT_DOMAINS=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=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 k647jNhAv9kE for ; Wed, 25 May 2016 16:19:03 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 D806E12B007 for ; Wed, 25 May 2016 16:19:02 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id k23so99367380oih.0 for ; Wed, 25 May 2016 16:19:02 -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:date:message-id:subject:from:to :cc; bh=FJ6bfgSlji1oO/dFLL5i+JpjPByGTGzex4rwt6iEAuo=; b=roOF/RZziZHfUozxGA1x7NHL1NyeHMj59GFeuxMfqOZEzCaFM5MBq6YsMPIckAM0Rp I5/Fw2TwwnSI0acwyzY+5ySDty2CjCQUzTPlg6755RssV6P9v3vHRN8/VtVIFdfq+jf9 1w8GfqT6bUPzwQN/2TbHu5uM+X2QHDRkLpHDGBubCmh0K/Bf8vinraq7Zh5VVwUgi861 h8tW+YfUv6QUMDQRi5M1GwXyoi67DDFrLoyDARt8Km2psw5vXbnvJXZqz7quCrB+hzOx b218mfXm88/81x0ixNicrCBQrlZbHs5ryyE/z5uQvYLEOXaHl9KitQlEtL9xOHc8RU36 3Qkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FJ6bfgSlji1oO/dFLL5i+JpjPByGTGzex4rwt6iEAuo=; b=YCmL1lZ5qEGDNBjt7xmjSmyknGOhE4T/q9z853NgQzF7sMNYa0SI7MAxFPFaMxs+XZ ZU7Bt2vmh4SK8doipFoZ6Bhe1AdTV4+TsK6Xj0fRT7ffh0+QePbxK+rgdXFHGGXo2+RD WAU5pkD6b1R8orsRDG5RFlZ8HKVCe9mr7JFvZiqcB4qqQPYUlvxIo6PWzhG6e/W6s0b3 HSVz2anML85Eij4ur3xi/qLlq+eVLmrn30hDYqcczRHQHD/93bpdRFzViCbf2JiGUH7g YITEmu7Dni+W+HlPA4E0KZTpjp4FwcbeSvNhPiH0RghF1WB4VNdFB0CtEi/yJQ+uYl9C sJmA== X-Gm-Message-State: ALyK8tJa7z44cAEco1Im2Kr3TaiawUgEIpwUa9ZUbrlIDYXmshMKXUuLxtnGYCh2ofJ1Bg== X-Received: by 10.202.52.6 with SMTP id b6mr3519106oia.103.1464218342067; Wed, 25 May 2016 16:19:02 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com. [209.85.218.46]) by smtp.gmail.com with ESMTPSA id w9sm5122108otw.16.2016.05.25.16.19.01 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 16:19:01 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id w184so92395148oiw.2 for ; Wed, 25 May 2016 16:19:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.165.135 with SMTP id c129mr4258217ywh.67.1464217952126; Wed, 25 May 2016 16:12:32 -0700 (PDT) Received: by 10.83.50.7 with HTTP; Wed, 25 May 2016 16:12:31 -0700 (PDT) In-Reply-To: References: <8f578154-46ee-9781-1b23-f93b1fe25848@jitsi.org> Date: Wed, 25 May 2016 18:12:31 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c12a062e974f20533b2ce7c Archived-At: Cc: "Paul E. Jones" , 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, 25 May 2016 23:19:06 -0000 --94eb2c12a062e974f20533b2ce7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 peop= le >> 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 S= SRC >> 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 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 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" = < >>> 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 featur= e >>>>>> 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 th= e >>>>> SFU can ensure that the HBH SSRCs do not collide, but it cannot contr= ol >>>>> 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 do= es >>>>> one normal SRTP decryption for the packet received and one SRTP >>>>> encryption step sending the packet. The only special requirement PER= C >>>>> 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 us= e >>>>> 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 nee= d >>>>>>> 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 fai= l >>>>>> 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 bot= h >>>>> 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 send= er >>>>> 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 encrypted packets or jus= t >>>>> over the E2E packets. (The latter would be parallel to the current F= EC >>>>> 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 SR= TP >>>>> 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 secon= d >>>>> 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 operatio= n >>>>> 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 fo= r >>>>> E2E. If the SSRCs never change, this works fine. One could implemen= t >>>>> this using two instances of an SRTP library today. If a single libra= ry >>>>> 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 in= to >>>>> 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 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 th= e >>>>> 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 stre= am >>>>> 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 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 Doubl= e, >>>>>>> but I can appreciate how some might prefer to not change an otherwi= se >>>>>>> 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 banni= ng >>>>>> SSRC re-writing. >>>>>> >>>>> >>>>> At least we agree that it would be a good goal to find an approach th= at >>>>> 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 simulca= st >>>>> streams coming toward them. >>>>> >>>>> Since I don't work for a browser vendor, I cannot speak to their plan= s. >>>>> 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 endpoint= s >>>>> 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 >> > > --=20 sent from my mobile --94eb2c12a062e974f20533b2ce7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 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 saying that = simulcast itself is not a good enough reason to implement=C2=A0=C2=A0receiv= er-side simulcast support ... but a minor optimization to=C2=A0PERC is ...<= /div>

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

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


We're looking at it soon and plan to try to i= mplement it pretty much as soon as it's baked enough to do.
<= br>

it's not part o= f webrtc 1.0.

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

How would you tell FF what group an RID c= orresponds to?

Emil=C2=A0


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

-Ekr
=C2=A0
<= div>


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><= br> To: "Paul E. Jones" <paulej@packetize= r.com>
 Cc: "Adam Roach" <adam@nostrum.com>= ; "Cullen Jennings" <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
--94eb2c12a062e974f20533b2ce7c--