From nobody Sun Jul 2 16:36:13 2017 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 D4BA312F3CB for ; Sun, 2 Jul 2017 16:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bz533Ts_ydm9 for ; Sun, 2 Jul 2017 16:36:09 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 5132712F290 for ; Sun, 2 Jul 2017 16:36:09 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id w19so79727632uac.0 for ; Sun, 02 Jul 2017 16:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J/LYyteDS+dtqgWT+S4SN82t7j4QSfpXehOEzKG4+8s=; b=muaQeNRWCdfoAyWHQa4iGVIWmYeMF6tmzpr0LGHbl+RQkf6628/ePP2DuLONo7b6lP rxOdHtlIIoW7h8vFfJToQBnMnN96bft61KopA6b+qbvcpoRus6ey81FIfmfatqwZIkA7 KMCl1sWsNpf9yyUTPizLdt5Uqa5pWxKo/wL8Wh4uc3SXT9v75yA4qBahwzjKrDxjomgu Cu2dmLddbxKgEnYLTfvYHai0yY8zC27sCQ9wVSZMQBBU61lsNjY+cidNitThZrysSVv0 b7UcOGLloCiSxC24f8h5ZdUBDxI4auxYbwudpstGDsH3NJTPnDxr9/ERUqz6SBEJXxDh lg+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J/LYyteDS+dtqgWT+S4SN82t7j4QSfpXehOEzKG4+8s=; b=AHfwd27jkBYV4kAUeLeGWZj4J3K9tVGnNTeAlc049Mhjv5Z/Lor/5kqPKhBrwrHXK8 sk6BEZMeutvJ0hDV+c9/zQH8OZF7eZQtMsxnMQJUluZOHnZoOA9E074I9ii8/SsqZTXE Fm3/ycpGha/3ZRIJJtGXAlYzgJU5Ku/4nZSkPLIpBMjWNFEazpbxcxD8+3cbc6rQ/YiA zQMvXLuZlp3SDM6vec/vdWVbWJqkL+ROMRr4l8S0nqGfo13IO24W4yUfNPHCU5y56saC kJsV4K1246YKOr18EboYSjBuidIi2Sqs+G+TziDm4vPPQeNFs27/OQl37dHonWirPF0a 9/3w== X-Gm-Message-State: AKS2vOwoW46tdpnTyhUfNAB+Eo012UVLuMLi5lvoVSWtY/gDtFmD5eya +jqWxEWq9R8VGL3qHRdvsF9FBvm2GQ== X-Received: by 10.176.4.50 with SMTP id 47mr19843599uav.151.1499038568244; Sun, 02 Jul 2017 16:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.6.199 with HTTP; Sun, 2 Jul 2017 16:36:07 -0700 (PDT) In-Reply-To: <669b3819-83de-f27e-9214-73c2ac808f0e@gmail.com> References: <203ee906-0af0-99ea-994f-2fd36d7fbf6a@gmail.com> <4C7F07F1-E4C9-474C-97E5-1CB5D9B9A9AB@iii.ca> <669b3819-83de-f27e-9214-73c2ac808f0e@gmail.com> From: Alexandre GOUAILLARD Date: Sun, 2 Jul 2017 16:36:07 -0700 Message-ID: To: Cullen Jennings Cc: "perc@ietf.org" Content-Type: multipart/alternative; boundary="001a114b927e5d6ee205535e1de9" Archived-At: Subject: Re: [Perc] Double PERC draft 5 and webrtc audio FEC X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 23:36:12 -0000 --001a114b927e5d6ee205535e1de9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Invite sent. I wrote a little document to try to list and illustrate (with colours because i m not as good as you guys) the small remaining differences between the two approaches. I hope this will help. https://docs.google.com/document/d/1akiageNJDCQ4sfAIsa40bGEXszXL35yEbEIbKvx= A2z0 Regards, Alex On Fri, Jun 30, 2017 at 1:17 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 30/06/2017 2:03, Cullen Jennings wrote: > > > On Jun 29, 2017, at 5:45 PM, Bernard Aboba wrote: > > [BA] Opus FEC can't handle burst loss, but RED can. So if you have burs= t loss (quite likely on wireless networks), RED can substantially outperfor= m Opus FEC. I realize this would involve use of RED in an *atypical* way, = though. > > I realize some people want to use RED so I'm not arguing that we don't ne= ed to worry about it. It seems with RED for burst loss you have to decide h= ow long a delay you want on the RED packets - more delay gives better burst= loss protection but worse latency. When you implement FEC in opus, you hav= e to decide more or less the same thing of how much delay to put in the red= undant coding. So I see them somewhat similar to burst loss. But not sure i= t matters much because I'm fine with trying to have a solution that works f= or RED. > > Hi Cullen, Bernard, > > I am not against or in favor on RED. My point was just that in the new > draft when it addresses the FEC part, it says: > > The algorithms recommended in [I-D.ietf-rtcweb-fec ] for audio wor= k with no additional considerations. > > which is incorrect as RED cannot be supported HBH for the reasons > mentioned on my original mail, and the draft should be updated to reflect > that fact. > > Deciding if RED is a good FEC mechanism for webrtc or not, while being a > very interesting topic, I think it is outside of the scope of this group. > > Best regards > > Sergio > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- President - CoSMo Software Consulting, Singapore ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --001a114b927e5d6ee205535e1de9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Invite sent.

I wrote a little document = to try to list and illustrate (with colours because i m not as good as you = guys) the small remaining differences between the two approaches. I hope th= is will help.

<= div>
Regards,

Alex

On Fri, Jun 30, 2017 at= 1:17 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail= .com> wrote:
=20 =20 =20
On 30/06/2017 2:03, = Cullen Jennings wrote:

On Jun 29, 2017, at 5:45 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

[BA]  Opus FEC can't handle burst loss, but RED can.  So if you have bu=
rst loss (quite likely on wireless networks), RED can substantially outperf=
orm Opus FEC.  I realize this would involve use of RED in an *atypical* way=
, though.

I realize some people want to use RED so I'm not arguing tha=
t we don't need to worry about it. It seems with RED for burst loss you=
 have to decide how long a delay you want on the RED packets - more delay g=
ives better burst loss protection but worse latency. When you implement FEC=
 in opus, you have to decide more or less the same thing of how much delay =
to put in the redundant coding. So I see them somewhat similar to burst los=
s. But not sure it matters much because I'm fine with trying to have a =
solution that works for RED.

Hi Cullen, Bernard,

I am not against or in favor on RED. My point was just that in the new draft when it addresses the FEC part, it says: 

   T=
he algorithms recommended in [I-D.ietf-rtc=
web-fec] for audio work with no additional considerations.

which is incorrect as RED cannot be supported HBH for the rea= sons mentioned on my original mail, and the draft should be updated to reflect that fact.

Deciding if RED is a good FEC mechanism for webrtc or not, while being a very interesting topic, I think it is outside of the scope of this group.

Best regards

Sergio


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




--
=
Alex. Gouaillard, P= hD, PhD, MBA
----------------------------------------------------------= --------------------------
President - CoSMo Software Consulting,= Singapore
------------------------------------------------------= ------------------------------

    • --001a114b927e5d6ee205535e1de9-- From nobody Mon Jul 3 10:56:10 2017 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 B4EC81316E3; Mon, 3 Jul 2017 10:56:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910456170.22840.11324927023292028958@ietfa.amsl.com> Date: Mon, 03 Jul 2017 10:56:01 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-04.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 17:56:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing of the IETF. Title : A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing Authors : Paul E. Jones David Benham Christian Groves Filename : draft-ietf-perc-private-media-framework-04.txt Pages : 23 Date : 2017-07-03 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-04 https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-framework-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 7 16:19:22 2017 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 62DB31200C1 for ; Fri, 7 Jul 2017 16:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0k1GyxErQziU for ; Fri, 7 Jul 2017 16:19:17 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 87E5612ECAD for ; Fri, 7 Jul 2017 16:19:17 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 32so38742925qtv.1 for ; Fri, 07 Jul 2017 16:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eW2nFfVBye8N8W5dEwqJJODPuF4kJiXzvmmQywueYAk=; b=PLB/md8GUKHwLn5NUgw0r3lczDoGF4kbPNUyoLJEWWuvrGq4Mi75cSNok8CLXnBCiW AxVeMHQODMoxGwP7GvD3zY/fx9TjU5OcCohtUixvYyOp5gS7qFADLSJVENkAqnW5vjMQ 1FuYHUWGWfhFu9ZNP8irwXKiDnBTrpMKqw7/79+JOmt0BHuKBhKp/m1fZ8lKw/bII4hY lkHPedBwa4RmvqTy8bCK5MvuuwKgAw/DuZlM0aHLMJ42oZpFIEViA4zqCu7ZWfTh68xP 4T2cnQs8E6Rk5+KUY/Si4ylCeDm6D9D0UWE1MKPEhCreUftR2YHqDssQ7KdwVL15CmAL n0tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eW2nFfVBye8N8W5dEwqJJODPuF4kJiXzvmmQywueYAk=; b=cI71YBm2vKhy3cCZYEMI6SYfCRdMtQefLiy0xB2yh5wEHhqzB45STn+gtktIxeEXil 3TWjceeHcN9U0+W3b6eDl4w0hy3x80RPorxudLzpsUF1b58M+z/MfhitmyQAKmRlAaXM eDjjszcPtXixjZzuVPCYyzlaHsdqOpAPYEBnBWMlUPY6ipzXGsqateC9ne5K1CvaP4xU wXiZhfhu5g5xP+XrrvZ8A6zGPDdpM2nxCn5cvZMthMu/q/T12vpEyL9uqRsVzQL+IQVo N3Afe1kH1K2k9zG2K+7PDmfyNbr/95EL2bvy9ri0TzeX3VrBlVe61QTICvbi72S1TY+w Sdvw== X-Gm-Message-State: AKS2vOwrMk1NAUqv/F1U+PBwLzVAo9HHG7ZaS0nO8o/hrzi0MaYplqDP 3e59tYzSLl8BCzaasSGm+foMxpYQXrEH X-Received: by 10.200.3.98 with SMTP id w34mr72374697qtg.203.1499469556555; Fri, 07 Jul 2017 16:19:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.6 with HTTP; Fri, 7 Jul 2017 16:19:16 -0700 (PDT) From: Suhas Nandakumar Date: Fri, 7 Jul 2017 16:19:16 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="f4030435bf6045257f0553c2760d" Archived-At: Subject: [Perc] PRRC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 23:19:19 -0000 --f4030435bf6045257f0553c2760d Content-Type: text/plain; charset="UTF-8" Hello All Here is the draft agenda for the PERC WG meeting to be held on Tuesday (July 18th) https://datatracker.ietf.org/doc/agenda-99-perc/ Please let the chairs know if you have any comments/questions. We will be publishing the final agenda by Monday EOD Cheers perc chairs --f4030435bf6045257f0553c2760d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello All

    Here is the d= raft agenda for the PERC WG meeting to be held on Tuesday (July 18th)

    Please let the chairs know if you have any comments/quest= ions. We will be publishing the final agenda by Monday EOD


    Cheers
    perc chairs

    --f4030435bf6045257f0553c2760d-- From nobody Fri Jul 7 16:20:52 2017 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 A0018127601 for ; Fri, 7 Jul 2017 16:20:50 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 EPCsYBP2oXE9 for ; Fri, 7 Jul 2017 16:20:47 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 D8C981200C1 for ; Fri, 7 Jul 2017 16:20:46 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id 16so39303477qkg.2 for ; Fri, 07 Jul 2017 16:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UV1yqSOoB6D0Nr2+858U2O6VyR3JyMF6i/bc5hWI5b0=; b=f0iTtlP8HmW0ZEvsF5E3DnOetYckAeFv2+ILjaN7hq1EezXkz2PrAoIXtZof2NtUwF rfT6Pv0tR46GwWeTMzRnoOrvR9yrTlH8IdQKPgWWp2iXLvRUFGQ0IKLxe1XrLCKe5F7t H/C6weyrrrc8gjowiSqefTXVPcKnmR1D6Ixl3NylmhGWEHdOW1CN6JiFBTsq4sEMldye cswi/YSNd/MZOEd0xtnbY0EGynjKCUghhwepDuWU95eD1jbNkwDml7w2L9on3BBZOa23 Wo2HyZTJVfW3rqCJGH1boFKWKMZnNcNTil1pdyeZgfpx6gXtUT2Hk0z9VDqKVv+D1sSA ykUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UV1yqSOoB6D0Nr2+858U2O6VyR3JyMF6i/bc5hWI5b0=; b=d9FsvQdjAGSbtf+5GE7V8wpS507sJdTUikMNtLJnxA4+HX8kZKr/bHz/iGCcLmzcEX z9jNIuyTslFRRa2yJ4+gSwoUQ5/bACfF7FgrOb3Gjwwc0mLJhRkQkUQTRnlESrq51As1 CSKctUeUwk2G52rZW9NwmTZqkA1RDC6pwU0y2s1TcPjHcgpqwVKrYH6e/oJgwLA3JZmW JsIYSWXtZ/cTXe36BGGI14fbcHe5mj3jnqN9fVp+Z0zS9F8pi+fAklakNsX6VVwXa7WR /kwLpCcV2paMvgDkkQq0/UV3v+bKdX+BaTc7km2w9qu16PwCSzGkemGDBEw/hHp6k62+ MASA== X-Gm-Message-State: AKS2vOy2S6YbePgA8NRhAiiVYXNtRkO8ajRPWi/SDTI7I3NYft0MoxZU 4vskS5ZD4Ksl8X9FpByH7TwqMIMOww== X-Received: by 10.55.33.80 with SMTP id h77mr63725916qkh.86.1499469645891; Fri, 07 Jul 2017 16:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.6 with HTTP; Fri, 7 Jul 2017 16:20:45 -0700 (PDT) From: Suhas Nandakumar Date: Fri, 7 Jul 2017 16:20:45 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="001a1144c196984ee30553c27b79" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 23:20:50 -0000 --001a1144c196984ee30553c27b79 Content-Type: text/plain; charset="UTF-8" Here is the correct link : https://datatracker.ietf.org/doc/agenda-99-perc/ On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar wrote: > Hello All > > Here is the draft agenda for the PERC WG meeting to be held on Tuesday > (July 18th) > > https://datatracker.ietf.org/doc/agenda-99-perc/ > > > https://datatracker.ietf.org/doc/agenda-99-perc/ > > Please let the chairs know if you have any comments/questions. We will be > publishing the final agenda by Monday EOD > > > Cheers > perc chairs > > --001a1144c196984ee30553c27b79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Here is the correct link := =C2=A0https://= datatracker.ietf.org/doc/agenda-99-perc/

    On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nand= akumar <suhasietf@gmail.com> wrote:
    Hello All
    Here is the draft agenda for the PERC WG meeting to be he= ld on Tuesday (July 18th)


    <= span style=3D"font-size:12.8px">
    Please let the chairs kno= w if you have any comments/questions. We will be publishing the final agend= a by Monday EOD


    Cheers
    pe= rc chairs


    --001a1144c196984ee30553c27b79-- From nobody Fri Jul 7 16:23:48 2017 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 4C6BC126D73 for ; Fri, 7 Jul 2017 16:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dYt4SPjs46ZX for ; Fri, 7 Jul 2017 16:23:44 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 27129131570 for ; Fri, 7 Jul 2017 16:23:44 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id r103so66120949wrb.0 for ; Fri, 07 Jul 2017 16:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RNt1JzTctqF7pypIKKzdmfUeeidZhVonk6dRjvUHrco=; b=uH8d7DwsqLmGzwRlb0xheDNvlup5n8/coLvvhDjQ1yo85om/YGauchjTDCtSy80X0l FJpNlpWGVddkrOnijjx84dG+ojOIVRwLWhiebQUotOepoVO5VydCFvuylmTv7xUhRaOf jslJmiCWzAQdE4LliqSmzaEqDsZRIjNFGb/6Dr31BSITmRaj3je+OE9jZzh7pguDH1PO 8KMB/hgMiHs57BDQrSFC4QtZJV0Ks5gKc7t/3MdYoRF5rn19GbCb8WiZWEFm9XuJ6XGm ocG9yXPKRNqwDCOiGhsE30fW0GUQ4+vDJJlVAOSSshJhFSt68rU0jfIRaknC6PySMhYQ sUiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RNt1JzTctqF7pypIKKzdmfUeeidZhVonk6dRjvUHrco=; b=RplfxBwMeJTbyGL2fExpgXLDptN40soHAjPVngSgs+QFGO7zlPzM0CcnQoZRDjihVV wXaXFmlna/IuGG4PGs144wp1XXGh3s5PixzgdxLb+kh+Bg8PlDUULwQi4QjGfpp8BJrq zJR6tD3tKSiSOknmIHLGp4ehfjygekeuF5PbiwhioeIRD5sHMQG4INrQdoZtTsTnutgR AaFDPavH51XNQDD5RPox6un39pCUjDliWq8grZmO2li7dmQxZnav3aEnFW5LBJ1Fgjip NxjGbGvojlHaIRDUvSDZ4RvMLbVQCAji+K1G0ZzQvmSNayXiLmu7qTR+f4Bgc4Z+zLMf YQIA== X-Gm-Message-State: AIVw1128HRGb43F4tr5wS3O1qOxAsBQAFZltBmNEW4sGsJGpn7aqgUe7 LBxCCjot3+55qQCdPagRxYy2oYfrnBCV89s= X-Received: by 10.80.205.86 with SMTP id d22mr3579044edj.74.1499469822726; Fri, 07 Jul 2017 16:23:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Emil Ivov Date: Fri, 07 Jul 2017 23:23:30 +0000 Message-ID: To: Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1af85022b65b0553c2862c" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 23:23:46 -0000 --94eb2c1af85022b65b0553c2862c Content-Type: text/plain; charset="UTF-8" Any chance we can add some time for RTX? Also I still don't think we have consensus on SSRC rewriting. Emil On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar wrote: > > Here is the correct link : > https://datatracker.ietf.org/doc/agenda-99-perc/ > > On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar > wrote: > >> Hello All >> >> Here is the draft agenda for the PERC WG meeting to be held on Tuesday >> (July 18th) >> >> https://datatracker.ietf.org/doc/agenda-99-perc/ >> >> >> https://datatracker.ietf.org/doc/agenda-99-perc/ > >> >> Please let the chairs know if you have any comments/questions. We will be >> publishing the final agenda by Monday EOD >> >> >> Cheers >> perc chairs >> >> > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > -- sent from my mobile --94eb2c1af85022b65b0553c2862c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Any chance we can add some time for RTX?=C2=A0
    =

    Also I still don't think = we have consensus on SSRC rewriting.

    Emil

    On Fri, 7 Jul 20= 17 at 18:20, Suhas Nandakumar <su= hasietf@gmail.com> wrote:

    Here is the correct link :=C2=A0htt= ps://datatracker.ietf.org/doc/agenda-99-perc/

    On Fri, Jul 7, 2017 at 4:19 PM, Suhas= Nandakumar <suhasietf@gmail.com> wrote:
    Hello Al= l

    <= span style=3D"font-size:12.8px">Here is the draft agenda for the PERC WG meeting to be held on Tuesday (July 1= 8th)

    https://datatracker.ietf= .org/doc/agenda-99-perc/


    Please let the chairs know if you have any co= mments/questions. We will be publishing the final agenda by Monday EOD


    Cheers
    perc chairs
    =

    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    sent from my mobile
    --94eb2c1af85022b65b0553c2862c-- From nobody Fri Jul 7 16:38:44 2017 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 EC1B812ECBC for ; Fri, 7 Jul 2017 16:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 gvYScH4vJrLn for ; Fri, 7 Jul 2017 16:38:39 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 9D61812EC03 for ; Fri, 7 Jul 2017 16:38:39 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id q86so23680586pfl.3 for ; Fri, 07 Jul 2017 16:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ew2mF10jwsPmr7K5ADEfRNtSnjF8vbQ6oFgRjp5jQR4=; b=GwiaqwC4hO95wcgqMhijEAFAxeFzGW4SzHFxLjRvkPHagIaRbfaHBajFzZOmqsVwiy 9zhJppvduty6Nrxx48+k5m59WJq9+zZgaNOs0vYLYNG4gMKmpPNUTpv/Su42owO7NGtQ r8kXu+t3rfOtigFwj6O/cFCbEmCQSoEODrbOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ew2mF10jwsPmr7K5ADEfRNtSnjF8vbQ6oFgRjp5jQR4=; b=n3V9ZXJY0bfKsVKcyhNjYKQpmyE0OOZJlsGvDL4ZFMG+DJpR22D7kbhEbFOOQfl40K /QwfLBVf3EXXnHAGyqXKeZ9IdOK6C8CG+KhDZp0Chf9LcswEfQOJe2iP29ZG+VynPzM2 UAocFPNiAJWXDYzXu/PYvy6J3WPJeNkykH/vQiUt5Cgbqvu9eak6wkmX3RrJ9Cwq6kO4 WDeXUDZWfeCDpBnRnAP0RL9BboPugMwDf5oED0RuCGm7aN2kBXA3bH5S5w/Vnt308xQV iH/zkGB8+uBIn9FrpklLrTazu4OoYzJ7fAl5RdhciTmCRzNU9wsTO4E/6vJWYO3NsFka 4cyw== X-Gm-Message-State: AIVw1132dKxJNaUcKWeR3Y2NychkI1wiwqB1Qn02ItP6sQ4C3NUP6A/6 si8oFoSwGq0S+Wg0Js4rPQ== X-Received: by 10.99.8.66 with SMTP id 63mr3840052pgi.15.1499470719053; Fri, 07 Jul 2017 16:38:39 -0700 (PDT) Received: from ?IPv6:2620:101:80fc:224:f940:3e44:c0b5:f176? ([2620:101:80fc:224:f940:3e44:c0b5:f176]) by smtp.gmail.com with ESMTPSA id d185sm6832467pgc.39.2017.07.07.16.38.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 16:38:37 -0700 (PDT) From: Nils Ohlmeier Message-Id: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6A878AF1-18F8-4DC1-81E1-1EF449376002"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Jul 2017 16:38:32 -0700 In-Reply-To: Cc: Suhas Nandakumar , perc@ietf.org To: Emil Ivov References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 23:38:43 -0000 --Apple-Mail=_6A878AF1-18F8-4DC1-81E1-1EF449376002 Content-Type: multipart/alternative; boundary="Apple-Mail=_348AFA74-043D-4B32-8D4E-03F5BE314E05" --Apple-Mail=_348AFA74-043D-4B32-8D4E-03F5BE314E05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 7, 2017, at 16:23, Emil Ivov wrote: >=20 > Any chance we can add some time for RTX? If you mean RTX in the context of double then I would expect that to be = part of the initial double discussion. Or do you want to talk about your draft which modifies the OHB for RTX? Cheers Nils >=20 > Also I still don't think we have consensus on SSRC rewriting. >=20 > Emil >=20 > On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar > wrote: >=20 > Here is the correct link : = https://datatracker.ietf.org/doc/agenda-99-perc/ = >=20 > On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar > wrote: > Hello All >=20 > Here is the draft agenda for the PERC WG meeting to be held on Tuesday = (July 18th) >=20 > https://datatracker.ietf.org/doc/agenda-99-perc/ = >=20 > https://datatracker.ietf.org/doc/agenda-99-perc/ = >=20 > Please let the chairs know if you have any comments/questions. We will = be publishing the final agenda by Monday EOD >=20 >=20 > Cheers > perc chairs >=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = > -- > sent from my mobile > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_348AFA74-043D-4B32-8D4E-03F5BE314E05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    On Jul 7, 2017, at 16:23, Emil Ivov <emcho@jitsi.org> = wrote:

    Any chance we can add some time = for RTX? 

    If = you mean RTX in the context of double then I would expect that to be = part of the initial double discussion.
    Or do you want to talk = about your draft which modifies the OHB for RTX?

    Cheers
      Nils


    Also I still don't think we have consensus on = SSRC rewriting.

    Emil

    On Fri, 7 Jul 2017 = at 18:20, Suhas Nandakumar <suhasietf@gmail.com> wrote:

    Here is the correct link : https://datatracker.ietf.org/doc/agenda-99-perc/

    On Fri, = Jul 7, 2017 at 4:19 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
    Hello All

    Here is the = draft agenda for the = PERC WG meeting to be held on Tuesday (July 18th)

    https://datatracker.ietf.org/doc/agenda-99-perc/

    https://datatracker.ietf.org/doc/agenda-99-perc/ 

    Please= let the chairs know if you have any comments/questions. We will be = publishing the final agenda by Monday EOD


    Cheers
    perc chairs


    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    sent = from my mobile
    _______________________________________________
    Perc = mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc

    = --Apple-Mail=_348AFA74-043D-4B32-8D4E-03F5BE314E05-- --Apple-Mail=_6A878AF1-18F8-4DC1-81E1-1EF449376002 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZYBt5AAoJEJ3NnGfOORkkX58P+waH2z+329HcwqNF8B622/q8 a582EAcOaXQ37I/46vj6TRnzJ1NSquj9WENTFlbUWvp5/Sakw2Aabl6yS2POE4Og 0pf5k69FZ40x+XQFQ3ZQBOsytvb8T3vAfmVwFXbx1HAo+0rMCQT1QrbNfYdkdNDD RbKsChBDOWGTzhXI2dKtfELaEF++j8PGWx67SOGG+Ok40+fW9y//PumLUQ+PS9hp zP0TIXMxcpGoNEwL3RARO5lf3VSyfUf8qtmnavHSZOvueB7bibUcWWbgtRFW74X+ 2vgH0UCWjD8HlYR4Pv9H8d3hQi2ie2RaNOii9ySrLu1ycNoNgF2c6ceIqAHTNuu9 A8r2wdZ4bWNFmVBsUUOW2HOIDCSNp/cjL1VsCd4KVo+OWYIwbtgAPEZXss92tCRC aluLzmpUCKPOroelakrEJlqqs4rHVOjTlNmd4H0ACZZs9FGtoSd4ZHJXBVyNOOUE RaOlfOEpV0U24APw2pjrDMc2b6ZyC6Cd+gfLnUFvtGz/molpgFsHjRZrcrUsGVUG 7GvU1g1C843RtSIY6bzn05s16vTZfNJfl95igXVsTgvibLgy5l1tOn3mUwcOLua4 UFXjcbMcHoqJDvR2XsdmULgLIM4rYFp7YOSTRZ+xDN4ndTjK7iCtkPzxo3hUBLbo H3eXNg1k+wRENgBObDfs =2M1p -----END PGP SIGNATURE----- --Apple-Mail=_6A878AF1-18F8-4DC1-81E1-1EF449376002-- From nobody Fri Jul 7 20:44:48 2017 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 0EF6C129B21 for ; Fri, 7 Jul 2017 20:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FQQv9lMlHVTi for ; Fri, 7 Jul 2017 20:44:46 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 023E2129476 for ; Fri, 7 Jul 2017 20:44:45 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id c11so69977194wrc.3 for ; Fri, 07 Jul 2017 20:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y+0ra6zFfWF79dCL50uR6vJoUzxkSZb10kq4/hgUp7g=; b=qdQE3cmS1PfP4n6Bc5m80oOK7YSvk71S+PJ1Wxr1oUMJK2A2KoIR+EZiYLPPv8WclJ SjDropLZtVZ0nYYStPKJBNZs67v3GsP4QMqzSW5gGj6jdUdKCyWSq+CoGirF9p+T6JFY m5sEjZJSoYk25tvT2zd+tKiDWcT2pRIPYn8hhWVIDOQdJBTAWNSWOQxEwY7ySy/Xzewz YoASEiFcRj1ux4E3pR4K55CnOUJUPgd0vbc111ZtC2HIzhqnuw2fIVR7KEPDpFRAtjsr 2RplGHyR9H6phK/mB7xmp5sNXVDs6hcZ8oeg5HjT3mbR8rxAuRaY3oa7DeuSpP7UZcWR KCaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y+0ra6zFfWF79dCL50uR6vJoUzxkSZb10kq4/hgUp7g=; b=RlZPqBlrqht2gKqG8FKCVXTholGXOEWcXndYr617sqdb/2rYBcgbsgtOcM30hADlPz +ZTQlVNRTdeIVBXuhSRBV0BT9QF43k+t9Dbo2UiGWZAsU5ueGYTpauMh9oDep1z0zDV7 cPIkBk6TBgMwNKx6HoP2CoXzYKguJpGfcRRdDWd9p3tVCIEMQq/77OVeZSVQ+P1lfzBa om+M1CH90H/PRJ/wv3iCAFHN9WLzGmICDbtCszCpw5Mr7QzKPfMYONbDjZuHbHhnOaX1 ZhXbvr50balNIz8c5XTq/kCWXoySfJ/CbGh+T1YIXcFtB3XO9b/CR++O7D9gcbIzeyqn ilzQ== X-Gm-Message-State: AIVw110GswCA8F9QfQV1YtA505DSxxFAHyjyPxPUDTiiLZ9zLQfoLh0x uIOudg9MElYnJTR+hmO23D9qOjk9pF1J X-Received: by 10.80.166.101 with SMTP id d92mr4387273edc.132.1499485484450; Fri, 07 Jul 2017 20:44:44 -0700 (PDT) MIME-Version: 1.0 References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> In-Reply-To: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> From: Emil Ivov Date: Sat, 08 Jul 2017 03:44:34 +0000 Message-ID: To: Nils Ohlmeier Cc: Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19567ea59b2f0553c62b54" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 03:44:48 -0000 --94eb2c19567ea59b2f0553c62b54 Content-Type: text/plain; charset="UTF-8" The latter. During the interim it was mentioned that the modification wasnt clear. I have yet to update the draft but unless people are now all comfortable with the notion, which would make me very happy, I think it might be useful to go over this again. (And we still have to reach consensus on the ssrc issue) Emil On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier wrote: > On Jul 7, 2017, at 16:23, Emil Ivov wrote: > > Any chance we can add some time for RTX? > > > If you mean RTX in the context of double then I would expect that to be > part of the initial double discussion. > Or do you want to talk about your draft which modifies the OHB for RTX? > > Cheers > Nils > > > Also I still don't think we have consensus on SSRC rewriting. > > Emil > > On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar wrote: > >> >> Here is the correct link : >> https://datatracker.ietf.org/doc/agenda-99-perc/ >> >> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar >> wrote: >> >>> Hello All >>> >>> Here is the draft agenda for the PERC WG meeting to be held on Tuesday >>> (July 18th) >>> >>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>> >>> >>> https://datatracker.ietf.org/doc/agenda-99-perc/ >> >>> >>> Please let the chairs know if you have any comments/questions. We will >>> be publishing the final agenda by Monday EOD >>> >>> >>> Cheers >>> perc chairs >>> >>> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > -- > sent from my mobile > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > > -- sent from my mobile --94eb2c19567ea59b2f0553c62b54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The latter.

    During the interim it was mentioned that the modification wasnt = clear.

    I have yet to upd= ate the draft but unless people are now all comfortable with the notion, wh= ich would make me very happy, I think it might be useful to go over this ag= ain.

    (And we still have = to reach consensus on the ssrc issue)

    Emil

    On Fri, 7 Jul 2= 017 at 18:38, Nils Ohlmeier <no= hlmeier@mozilla.com> wrote:
    =
    On = Jul 7, 2017, at 16:23, Emil Ivov <emcho@jitsi.org> wrote:

    Any chanc= e we can add some time for RTX?=C2=A0
    If you mean RT= X in the context of double then I would expect that to be part of the initi= al double discussion.
    Or do you want to talk about your draft whi= ch modifies the OHB for RTX?

    Cheers
    =C2=A0 Nils


    Also I still don't think we have = consensus on SSRC rewriting.

    Emil

    On Fri, 7 Jul 2017 at 18= :20, Suhas Nandakumar <suhasietf@gmail.com> wrote:

    Here is the correct link :=C2= =A0https://datatracker.ietf.org/doc/agenda-99-perc/

    On Fri, Jul 7, 2017 at 4:19= PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
    Hello All

    Here is the draft agenda for the PERC WG meeting to be held on Tue= sday (July 18th)


    Please let the chairs know if you= have any comments/questions. We will be publishing the final agenda by Mon= day EOD


    Cheers
    perc chair= s


    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    sent from my mobile
    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://= www.ietf.org/mailman/listinfo/perc

    --
    sent from my mobile
    --94eb2c19567ea59b2f0553c62b54-- From nobody Sun Jul 9 21:35:53 2017 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 E4408126DED for ; Sun, 9 Jul 2017 21:35:51 -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 mNmGod6pe6Qz for ; Sun, 9 Jul 2017 21:35:50 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 B0BD31204DA for ; Sun, 9 Jul 2017 21:35:49 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p21so64336568qke.3 for ; Sun, 09 Jul 2017 21:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3RiPw6dFr5VKzdI9YiQikFIqW5iTcBxcLKU+yzRZwzM=; b=E3m2zjC+SJud5xqXuiF4/qKeiL84GmeZTFFxDzIodp3gHBqIwrtXBTZ0xOR/CBdcry HQt0eVo70SWhYsepV/op3zDcFV6EPT+GAcXLMlDZRCe+LE3f/HLGSGdezijRGT9iJkG0 PDlFjZ/ODM2lNw6Lok3cp6FYKJAtxoe7erTGYPjR7+AYQtsSPLxqLUnBJOsoq2IeuFkH JdqAigGVv/EuBpeugvpP45K6BTWAWq0J+yqls25MDq29/18mh4wZIEojV8RFbs2MBT/J yP77ByaV5OQgbP4cK1N+gdHzR9inNuGq6X7+HifBZOuuSirXQWz3lolPVjoT1PVkzpei US9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3RiPw6dFr5VKzdI9YiQikFIqW5iTcBxcLKU+yzRZwzM=; b=k03Mi+X+F+bf20UukKvtv9d0QUUN2b8tWR+mXHINOUimk1vS1iXc3/75teLVE7JxBr nKDBx3hVCDjClQSa0erZhnlcq8k1mHUThwf+8H2tJm95jbuWPwxV6s2lcoUhiOpcU0JL xOaSXCpDih1k1GDTIYkvc5WsfC3IIvBs40VVOY+9XMfYaBfIghNawB2D5iRRhecZ3T2H QUwzh3TbMnrQFkGoyyuwcUpUibcP0b+7Jy2WRZ62pwzSAmmBKqG0midNoaWzqeoUVzbF WkqLqjxuaGsgW+s8r5jzt+Iolk4C05Pv0tiRirYudsc+Tu+quYgV6WjPq0hCRK9pdlpO yCqg== X-Gm-Message-State: AIVw110S0QozwMQcZJAP/7NfzTV0Lb5wrOBZz9ba1tDFGnyK60XyxbbD /L+ikKuStRdDmpiAVOiQes/Z0D7q9A== X-Received: by 10.55.40.13 with SMTP id o13mr1748108qkh.116.1499661348892; Sun, 09 Jul 2017 21:35:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.6 with HTTP; Sun, 9 Jul 2017 21:35:48 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> From: Suhas Nandakumar Date: Sun, 9 Jul 2017 21:35:48 -0700 Message-ID: To: Emil Ivov Cc: Nils Ohlmeier , perc@ietf.org Content-Type: multipart/alternative; boundary="001a11441568fbf42c0553ef1d99" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 04:35:52 -0000 --001a11441568fbf42c0553ef1d99 Content-Type: text/plain; charset="UTF-8" Hello Emil and Percians From what i gather the sentiments at the IETF 98 was RTX for probing bandwidth (as implemented by chrome) was something that Chrome should fix it. Were you able to reach out to Chrome team on the same ? Also the latest double spec seems to indicate RTX in PERC is scoped only for HBH and not E2E. IIRC your draft had similar recommendations. please correct me If i am wrong in capturing the thoughts ? Thanks Suhas On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov wrote: > The latter. > > During the interim it was mentioned that the modification wasnt clear. > > I have yet to update the draft but unless people are now all comfortable > with the notion, which would make me very happy, I think it might be useful > to go over this again. > > (And we still have to reach consensus on the ssrc issue) > > Emil > > On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier wrote: > >> On Jul 7, 2017, at 16:23, Emil Ivov wrote: >> >> Any chance we can add some time for RTX? >> >> >> If you mean RTX in the context of double then I would expect that to be >> part of the initial double discussion. >> Or do you want to talk about your draft which modifies the OHB for RTX? >> >> Cheers >> Nils >> >> >> Also I still don't think we have consensus on SSRC rewriting. >> >> Emil >> >> On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar >> wrote: >> >>> >>> Here is the correct link : https://datatracker.ietf. >>> org/doc/agenda-99-perc/ >>> >>> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar >>> wrote: >>> >>>> Hello All >>>> >>>> Here is the draft agenda for the PERC WG meeting to be held on Tuesday >>>> (July 18th) >>>> >>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>> >>>> >>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>> >>>> >>>> Please let the chairs know if you have any comments/questions. We will >>>> be publishing the final agenda by Monday EOD >>>> >>>> >>>> Cheers >>>> perc chairs >>>> >>>> >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >> -- >> sent from my mobile >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> >> -- > sent from my mobile > --001a11441568fbf42c0553ef1d99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello Emil and Percians

    =C2=A0 From wha= t i gather the sentiments at the IETF 98 was RTX for probing bandwidth =C2= =A0(as implemented by chrome) was something that Chrome should fix it. Were= you able to reach out to Chrome team on the same ?

    Also the latest double spec seems to indicate RTX in PERC is scoped only = for HBH and not E2E. IIRC your draft had similar recommendations.=C2=A0

    please correct me If i am wrong in capturing the thou= ghts ?

    Thanks
    Suhas

    On Fri, Jul 7, 2017 at 8:4= 4 PM, Emil Ivov <emcho@jitsi.org> wrote:
    The latter.
    During the interim it was mentioned that the modif= ication wasnt clear.

    I h= ave yet to update the draft but unless people are now all comfortable with = the notion, which would make me very happy, I think it might be useful to g= o over this again.

    (And = we still have to reach consensus on the ssrc issue)

    = Emil

    On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:=
    On Jul 7, 2017, at 16:23, Emil Ivov &= lt;emcho@jitsi.org= > wrote:

    Any chance we can add= some time for RTX?=C2=A0

    If you mean RTX in the con= text of double then I would expect that to be part of the initial double di= scussion.
    Or do you want to talk about your draft which modifies = the OHB for RTX?

    Cheers
    =C2=A0 Nils

    Also I still don't think we have consensus on= SSRC rewriting.

    Emil
    On Fri, 7 Jul 2017 at 18:20, Suhas N= andakumar <suha= sietf@gmail.com> wrote:

    Here is the correct link :=C2=A0https:/= /datatracker.ietf.org/doc/agenda-99-perc/

    On Fri, Jul 7, 2017 at 4:19 PM, Suha= s Nandakumar <suhasietf@gmail.com> wrote:
    Hello A= ll

    = Here is the draft agenda for the PERC WG meeting to be held on Tuesday (July = 18th)

    https://datatracker.iet= f.org/doc/agenda-99-perc/


    Please let the chairs know if you= have any comments/questions. We will be publishing the final agenda by Mon= day EOD


    Cheers
    perc chair= s


    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    sent from my mobile
    _______________________________________________
    Perc mailing listPerc@ietf.org
    <= a href=3D"https://www.ietf.org/mailman/listinfo/perc" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/perc

    --
    sent from my mobile

    --001a11441568fbf42c0553ef1d99-- From nobody Wed Jul 12 19:12:50 2017 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 CAF5412EC1B for ; Wed, 12 Jul 2017 19:12:48 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 QCFntijsnXrM for ; Wed, 12 Jul 2017 19:12:46 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 036A3126B7F for ; Wed, 12 Jul 2017 19:12:45 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w126so9994539wme.0 for ; Wed, 12 Jul 2017 19:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=885apz+Fb+dRUOOBfDtrdrrnEd3tiSI/5Muz12jpchA=; b=gm6L1fY6V2Z4KHmVjiJxcWcWX97KpqgAifEJqLiFMxNKXPl2LwM8WGnMLJe73nUo4k JukL91WITevQwM32IgjBKyhaWTDm5Y29AHiBB9ti8/n/zIqfCwlqVbvqrfafP9t4gKMG KeozxeWqeh01y6Me023tJXeUvDR34e6gH+tS+UMeiVELQXK0dqHnnDVNdOy/D4bKqxlY x1PZ6n8CUFkqlB7LeeStkniF5V7Py9KdzyXiraks4xWwGC2EZWHCG8EH9nlPd1h67Qxp rHvk9JHg/QLIjrVUaIeZccyE1/PFfMhG9JU3bunV56INhYtj6pGVdaAHOEb63kSu33S5 Ea8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=885apz+Fb+dRUOOBfDtrdrrnEd3tiSI/5Muz12jpchA=; b=KALXpnislaCV/M/d9IRmFzWdLZybiM5R8DzKpIy2a7cR+QQ/ZPP+ocABhGgYsQAVh2 kMb4sGy2QVjGBkHGfsmntcgttQEb0n39+mq/gkpgzVr78mr6Ygz2WGkSp0IlOUqjbBGj InfJBdQq0hGAbtLwXunHnXVoOcMyQRGJbui7knFlaoPPnSzfABQ/PaBWO8huWpdkRFM+ ny0g6zKUZkAYh78pXOBtadTVqeSAocONv0ywZJAMuVzcPJcwCplSQYZfk7pwbJ8LhfpY pWUu9o5UIkzD6Bd4hSK0ZiHJojsub0iFu6mXafLu6FGqH8qhSbdz+izSHY60pJbjXBOi DGeA== X-Gm-Message-State: AIVw113OuqmvW0tVpB6Qnd1I37sgawamc2w0susvDpV/BqPeInqxACxu W6yU6q48cxhb9E04XG5LzHCSAnd5mWEH X-Received: by 10.80.209.195 with SMTP id i3mr1014749edg.70.1499911964407; Wed, 12 Jul 2017 19:12:44 -0700 (PDT) MIME-Version: 1.0 References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> In-Reply-To: From: Emil Ivov Date: Thu, 13 Jul 2017 02:12:33 +0000 Message-ID: To: Suhas Nandakumar Cc: Nils Ohlmeier , perc@ietf.org Content-Type: multipart/alternative; boundary="089e082162e0d54de605542977e9" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 02:12:49 -0000 --089e082162e0d54de605542977e9 Content-Type: text/plain; charset="UTF-8" Hey Suhas, I haven't had as much time as I would have liked for PERC so please excuse me if I am making a glaring omission but I don't believe there has been any resolution to the RTX issues discussed on the last virtual interim. Specifically exactly how RTX will coexist with PERC (and no, this doesn't really have anything to do with probing). The latest double draft doesn't seem to say anything specific on the subject unless if, again, I am actually missing something. If I have indeed slept through how this WG reached consensus then I am very happy to not have to prepare anything and please accept my appology. If however there is still doubt on how RTX wedging should would I'll follow up on my promise to update our RTX document. Cheers, Emil On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar wrote: > Hello Emil and Percians > > From what i gather the sentiments at the IETF 98 was RTX for probing > bandwidth (as implemented by chrome) was something that Chrome should fix > it. Were you able to reach out to Chrome team on the same ? > > Also the latest double spec seems to indicate RTX in PERC is scoped only > for HBH and not E2E. IIRC your draft had similar recommendations. > > please correct me If i am wrong in capturing the thoughts ? > > Thanks > Suhas > > On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov wrote: > >> The latter. >> >> During the interim it was mentioned that the modification wasnt clear. >> >> I have yet to update the draft but unless people are now all comfortable >> with the notion, which would make me very happy, I think it might be useful >> to go over this again. >> >> (And we still have to reach consensus on the ssrc issue) >> >> Emil >> >> On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier wrote: >> >>> On Jul 7, 2017, at 16:23, Emil Ivov wrote: >>> >>> Any chance we can add some time for RTX? >>> >>> >>> If you mean RTX in the context of double then I would expect that to be >>> part of the initial double discussion. >>> Or do you want to talk about your draft which modifies the OHB for RTX? >>> >>> Cheers >>> Nils >>> >>> >>> Also I still don't think we have consensus on SSRC rewriting. >>> >>> Emil >>> >>> On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar >>> wrote: >>> >>>> >>>> Here is the correct link : >>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>> >>>> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar >>>> wrote: >>>> >>>>> Hello All >>>>> >>>>> Here is the draft agenda for the PERC WG meeting to be held on >>>>> Tuesday (July 18th) >>>>> >>>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>> >>>>> >>>>> Please let the chairs know if you have any comments/questions. We will >>>>> be publishing the final agenda by Monday EOD >>>>> >>>>> >>>>> Cheers >>>>> perc chairs >>>>> >>>>> >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>> -- >>> sent from my mobile >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >>> >>> -- >> sent from my mobile >> > > -- sent from my mobile --089e082162e0d54de605542977e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hey Suhas,

    I haven't had as much time as I would have liked for PERC so = please excuse me if I am making a glaring omission but I don't believe = there has been any resolution to the RTX issues discussed on the last virtu= al interim.

    Specifically= exactly how RTX will coexist with PERC (and no, this doesn't really ha= ve anything to do with probing).

    The latest double draft doesn't seem to say anything specific= on the subject unless if, again, I am actually missing something.

    If I have indeed slept through h= ow this WG reached consensus then I am very happy to not have to prepare an= ything and please accept my appology.

    If however there is still doubt on how RTX wedging should wou= ld I'll follow up on my promise to update our RTX document.

    Cheers,
    Emil=

    On Sun, 9 Jul 2017 at 23:35, Suha= s Nandakumar <suhasietf@gmail.com= > wrote:
    Hello Emil and= Percians

    =C2=A0 From what i gather the sentiments at th= e IETF 98 was RTX for probing bandwidth =C2=A0(as implemented by chrome) wa= s something that Chrome should fix it. Were you able to reach out to Chrome= team on the same ?

    Also the latest double spec se= ems to indicate RTX in PERC is scoped only for HBH and not E2E. IIRC your d= raft had similar recommendations.=C2=A0

    please cor= rect me If i am wrong in capturing the thoughts ?

    = Thanks
    Suhas
    On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov <emcho@jitsi.org> wrote:
    The latter.

    During th= e interim it was mentioned that the modification wasnt clear.

    I have yet to update the draft but un= less people are now all comfortable with the notion, which would make me ve= ry happy, I think it might be useful to go over this again.

    (And we still have to reach consensus= on the ssrc issue)

    Emil
    =


    Any chance we can add some time for RTX?=C2=A0

    If you mean RTX in the context of double then I would expect that= to be part of the initial double discussion.
    Or do you want to t= alk about your draft which modifies the OHB for RTX?

    Cheers
    =C2=A0 Nils


    Also I still = don't think we have consensus on SSRC rewriting.

    Emil

    = On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar <suhasietf@gmail.com> wrote:

    Here is= the correct link :=C2=A0https://datatracker.ietf.org/doc/agenda-99-per= c/

    On Fr= i, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar <suhasietf@gmail.com> wrot= e:
    Hello All

    Here is the= draft agenda for the PERC WG meeti= ng to be held on Tuesday (July 18th)

    https://datatracker.ietf.org/doc/agenda-99-perc/=C2=A0

    Please let th= e chairs know if you have any comments/questions. We will be publishing the= final agenda by Monday EOD


    Cheers<= /div>
    perc chairs


    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    sent from my mobile
    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://= www.ietf.org/mailman/listinfo/perc

    --
    sent from my mobile

    --
    sent from my mobile
    --089e082162e0d54de605542977e9-- From nobody Wed Jul 12 19:17:23 2017 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 063C112EC1B for ; Wed, 12 Jul 2017 19:17:23 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 q1qICHtyjCC0 for ; Wed, 12 Jul 2017 19:17:20 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A109126B7F for ; Wed, 12 Jul 2017 19:17:20 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i127so11050514wma.0 for ; Wed, 12 Jul 2017 19:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aS8yZrwOcgFuheA+9CYbmV1mMBWqqCutLPbQCEKwoPE=; b=Wx2REAVRMZCmtKQlU6JybF2/o7PYs1LKVE+QDx6zd1Ret+jRCAzvDOumtH9pZvXZF8 IQ8KU4lSsnoXvoy8Cu3S8P5lVCuUVLCOMyqOWdseGsooXpq+iWUbtWaNPezeIzFD4jtL sUH8a8pJjrjgfn5R+vYiyK00zuWjq49lL8gO/4xN4Jiahg+THAE3OusJ7qahdY5Bhsjs UFhZf2D7CJaouRuxW23lhQ0OfKEkyVvbj3ZjVGuzgCitaxELkktGBEj3WBDt2K5kVEZO sptaFAFb2mERLQ3Wbtfk2RhUKEd2J/cpldrbtGlZSDeEuwCiHsOr3Q0VwWxYEm2lZoBO yaHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aS8yZrwOcgFuheA+9CYbmV1mMBWqqCutLPbQCEKwoPE=; b=RWwfC6se8mh/5BGe8IaObdN6hiK2lsNuwXee5YXxD9I2dNvO/Kt+kbzwkvbAlslq7Y KLeh46LHXGXtefYVDoZBV8w6Bfl24S/ErlvWfD3OjnXm8nfHebP9qr9sZmbdLQbCpJBN npDbVqXDgf4PwVROhz1PLWKNgT9cO7LcRZ5EVRmZT5kAxIrzDC4o2oyYdYT4Il1Cw29m kkda0dxxgWvza1I3qC3RX8jVy6aJEiDqNMKxuK2OmX2CUz6dSRMOQa2YOpkuu637GHXI gE6pp35bsEUJGwTw1P3G/VXKOJ0+3bz3Iygpt2+RAzWTVgJvwfE7dRVAJ586lBVkCKXO sj2A== X-Gm-Message-State: AIVw112axz4bqv2n9AwMoFCzXguQ9t8RzJoxiuYD7Yz6QBEkvpJq6fC+ gWKZi9EGhLAIwidl6JAf1gEEv//gPfCL X-Received: by 10.80.168.70 with SMTP id j64mr1003832edc.110.1499912238808; Wed, 12 Jul 2017 19:17:18 -0700 (PDT) MIME-Version: 1.0 References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> In-Reply-To: From: Emil Ivov Date: Thu, 13 Jul 2017 02:17:08 +0000 Message-ID: To: Suhas Nandakumar Cc: Nils Ohlmeier , perc@ietf.org Content-Type: multipart/alternative; boundary="f403045c2a343055a2055429888a" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 02:17:23 -0000 --f403045c2a343055a2055429888a Content-Type: text/plain; charset="UTF-8" Oh and I forgot to add: we still do not have consensus on rewriting SSRCs. Would be good to have a plan about what we are doing there. Emil On Wed, 12 Jul 2017 at 21:12, Emil Ivov wrote: > Hey Suhas, > > I haven't had as much time as I would have liked for PERC so please excuse > me if I am making a glaring omission but I don't believe there has been any > resolution to the RTX issues discussed on the last virtual interim. > > Specifically exactly how RTX will coexist with PERC (and no, this doesn't > really have anything to do with probing). > > The latest double draft doesn't seem to say anything specific on the > subject unless if, again, I am actually missing something. > > If I have indeed slept through how this WG reached consensus then I am > very happy to not have to prepare anything and please accept my appology. > > If however there is still doubt on how RTX wedging should would I'll > follow up on my promise to update our RTX document. > > Cheers, > Emil > > On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar wrote: > >> Hello Emil and Percians >> >> From what i gather the sentiments at the IETF 98 was RTX for probing >> bandwidth (as implemented by chrome) was something that Chrome should fix >> it. Were you able to reach out to Chrome team on the same ? >> >> Also the latest double spec seems to indicate RTX in PERC is scoped only >> for HBH and not E2E. IIRC your draft had similar recommendations. >> >> please correct me If i am wrong in capturing the thoughts ? >> >> Thanks >> Suhas >> >> On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov wrote: >> >>> The latter. >>> >>> During the interim it was mentioned that the modification wasnt clear. >>> >>> I have yet to update the draft but unless people are now all comfortable >>> with the notion, which would make me very happy, I think it might be useful >>> to go over this again. >>> >>> (And we still have to reach consensus on the ssrc issue) >>> >>> Emil >>> >>> On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier >>> wrote: >>> >>>> On Jul 7, 2017, at 16:23, Emil Ivov wrote: >>>> >>>> Any chance we can add some time for RTX? >>>> >>>> >>>> If you mean RTX in the context of double then I would expect that to be >>>> part of the initial double discussion. >>>> Or do you want to talk about your draft which modifies the OHB for RTX? >>>> >>>> Cheers >>>> Nils >>>> >>>> >>>> Also I still don't think we have consensus on SSRC rewriting. >>>> >>>> Emil >>>> >>>> On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar >>>> wrote: >>>> >>>>> >>>>> Here is the correct link : >>>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>>> >>>>> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar >>>>> wrote: >>>>> >>>>>> Hello All >>>>>> >>>>>> Here is the draft agenda for the PERC WG meeting to be held on >>>>>> Tuesday (July 18th) >>>>>> >>>>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>>>> >>>>>> >>>>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>>> >>>>>> >>>>>> Please let the chairs know if you have any comments/questions. We >>>>>> will be publishing the final agenda by Monday EOD >>>>>> >>>>>> >>>>>> Cheers >>>>>> perc chairs >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Perc mailing list >>>>> Perc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perc >>>>> >>>> -- >>>> sent from my mobile >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>>> >>>> -- >>> sent from my mobile >>> >> >> -- > sent from my mobile > -- sent from my mobile --f403045c2a343055a2055429888a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Oh and I forgot to add: we still do not have consens= us on rewriting SSRCs. Would be good to have a plan about what we are doing= there.

    Emil

    On Wed, 12 Jul 2017 at 21:12, Emil Ivov <<= a href=3D"mailto:emcho@jitsi.org">emcho@jitsi.org> wrote:
    <= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
    Hey Suhas,

    I haven't had as much time as I= would have liked for PERC so please excuse me if I am making a glaring omi= ssion but I don't believe there has been any resolution to the RTX issu= es discussed on the last virtual interim.

    =
    Specifically exactly how RTX will coexist with PERC (and = no, this doesn't really have anything to do with probing).

    The latest double draft doesn't = seem to say anything specific on the subject unless if, again, I am actuall= y missing something.

    If = I have indeed slept through how this WG reached consensus then I am very ha= ppy to not have to prepare anything and please accept my appology.

    If however there is still doubt = on how RTX wedging should would I'll follow up on my promise to update = our RTX document.

    Cheers= ,
    Emil

    On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar <suhasietf@gmail.com> wrote:
    Hello Emil and Percians
    =C2=A0 From what i gather the sentiments at the IETF 98 was RTX= for probing bandwidth =C2=A0(as implemented by chrome) was something that = Chrome should fix it. Were you able to reach out to Chrome team on the same= ?

    Also the latest double spec seems to indicate R= TX in PERC is scoped only for HBH and not E2E. IIRC your draft had similar = recommendations.=C2=A0

    please correct me If i am w= rong in capturing the thoughts ?

    Thanks
    Suhas

    On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov <emcho@jitsi.org> wro= te:
    The latter.

    During the interim it was = mentioned that the modification wasnt clear.

    I have yet to update the draft but unless people are n= ow all comfortable with the notion, which would make me very happy, I think= it might be useful to go over this again.

    (And we still have to reach consensus on the ssrc issue)=

    Emil

    On Fri, 7 Jul 2017 at 18:38, N= ils Ohlmeier <nohlmeier@mozilla.com> wrote:
    = On Jul 7, 2017, at 16:23, Emil Ivov <emcho@jitsi.org> wrote:

    Any chance we c= an add some time for RTX?=C2=A0

    If you mean RTX in t= he context of double then I would expect that to be part of the initial dou= ble discussion.
    Or do you want to talk about your draft which mod= ifies the OHB for RTX?

    Cheers
    =C2=A0 Nils


    Also I still don't think we have consen= sus on SSRC rewriting.

    E= mil

    On Fri, 7 Jul 2017 at 18:20, S= uhas Nandakumar <suhasietf@gmail.com> wrote:
    Here is the correct link :=C2=A0h= ttps://datatracker.ietf.org/doc/agenda-99-perc/

    On Fri, Jul 7, 2017 at 4:19 PM, Suh= as Nandakumar <suhasietf@gmail.com> wrote:
    Hello = All

    Here is the draft agenda for the PERC WG meeting to be held on Tuesday (July= 18th)

    <= div>https://datatracker.ie= tf.org/doc/agenda-99-perc/


    Please let the chairs know if you have any = comments/questions. We will be publishing the final agenda by Monday EOD


    Cheers
    perc chairs


    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    sent from my mobile
    _______________________________________________
    Perc mailing list
    Perc@ietf.org
    https://= www.ietf.org/mailman/listinfo/perc

    --
    = sent from my mobile

    --
    sent from my mobile
    = --
    sent from my mobile --f403045c2a343055a2055429888a-- From nobody Sat Jul 15 15:11:37 2017 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 0C26612ECB0 for ; Sat, 15 Jul 2017 15:11:35 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 wjZmL5cpCVfc for ; Sat, 15 Jul 2017 15:11:32 -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 A733212EC0B for ; Sat, 15 Jul 2017 15:11:32 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id p188so94861526oia.0 for ; Sat, 15 Jul 2017 15:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=W/n96VGbpEWXcNDS+sxWqinVWsRIybb56MHALuT87xQ=; b=LTMtgDc85xjZYao4YJfm+z7xmGeOwi2SkJCi4RR1lu38vvgc4tgH/7mMmtpQS7Q9wW YkTGzkyw4p+XBajgMuy3cCXCOM4Ol4tmpFxL+/Es0fQWKMLcWmCfdqcNLe2UB5VD/CdV NtIlXGvmWDYdEYcKGUm5Hdk7EON9sHGV5GnnFrhSCThD27ToALP6YMJRxbZy22OB7ii5 /y+DBj9TrZwnYooorCOVJlhN3KWtAAQYkNECgV+PFPLdGotVWgPlA41FQ8NXiOnRowWA 4E4ksZoR73Tr25IzB6QZy4USgiXhrdoVxcMEpVY/Ncw7iSwv+8XcwTS+nyX+6xBUBw76 YhnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=W/n96VGbpEWXcNDS+sxWqinVWsRIybb56MHALuT87xQ=; b=peZSPIerC1irxHvSbjBG8qzNpkJnFSrMbBouYH0R9r8fObAA5GdW2vQ5s35R7cJic1 qefETMGQrEbrAknW43gR/+kioYM7InDk2rnEbmUKfm9JhOAeD7vkfplDnnNgIUS+JV4h wk+F9cASbPjPPKdJS510wgRNaHCzuc4qzu7n5CNFKB6vHzpbXbL08RZlkvgldbkA8I/N dHoJWHmZ3QSMEJqD56MLgiWg6pIytNK7VNN5y8hXHN/7/lkCLS5V51TZhpxdMQ/VtOch VGtbygyhrmqiT7eHR6g8OGEW9GjieAyvIzkFqSzHdryi9RH90II8QwqkOpMVbB4FN0t5 SB6A== X-Gm-Message-State: AIVw113IxIvSnBrtlPHyKZChNqn+GR/qPHtmLFu4Wlc8HbvS+mDGeVLD P7yTNu2l92fwzWRWqPo8Ig== X-Received: by 10.202.53.195 with SMTP id c186mr10162235oia.46.1500156691214; Sat, 15 Jul 2017 15:11:31 -0700 (PDT) Received: from ?IPv6:2605:a601:4062:6900:477:ea25:1f2d:7ce1? ([2605:a601:4062:6900:477:ea25:1f2d:7ce1]) by smtp.googlemail.com with ESMTPSA id e67sm17441869oic.39.2017.07.15.15.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 15:11:29 -0700 (PDT) From: Emil Ivov To: Suhas Nandakumar Cc: Nils Ohlmeier , perc@ietf.org References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> Message-ID: Date: Sat, 15 Jul 2017 17:11:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jul 2017 22:11:35 -0000 Hey all, As promised on the last interim, the RTX draft is now updated: https://raw.githubusercontent.com/bgrozev/perc-rtx/master/draft-grozev-perc-double-rtx-01.txt Apologies for the delay. Hopefully we are going to have the time to discuss this in next week's meeting. Cheers, Emil On 7/12/17 9:12 PM, Emil Ivov wrote: > Hey Suhas, > > I haven't had as much time as I would have liked for PERC so please > excuse me if I am making a glaring omission but I don't believe there > has been any resolution to the RTX issues discussed on the last virtual > interim. > > Specifically exactly how RTX will coexist with PERC (and no, this > doesn't really have anything to do with probing). > > The latest double draft doesn't seem to say anything specific on the > subject unless if, again, I am actually missing something. > > If I have indeed slept through how this WG reached consensus then I am > very happy to not have to prepare anything and please accept my appology. > > If however there is still doubt on how RTX wedging should would I'll > follow up on my promise to update our RTX document. > > Cheers, > Emil > > On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar > wrote: > > Hello Emil and Percians > > From what i gather the sentiments at the IETF 98 was RTX for > probing bandwidth (as implemented by chrome) was something that > Chrome should fix it. Were you able to reach out to Chrome team on > the same ? > > Also the latest double spec seems to indicate RTX in PERC is scoped > only for HBH and not E2E. IIRC your draft had similar recommendations. > > please correct me If i am wrong in capturing the thoughts ? > > Thanks > Suhas > > On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov > wrote: > > The latter. > > During the interim it was mentioned that the modification wasnt > clear. > > I have yet to update the draft but unless people are now all > comfortable with the notion, which would make me very happy, I > think it might be useful to go over this again. > > (And we still have to reach consensus on the ssrc issue) > > Emil > > On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier > > wrote: > >> On Jul 7, 2017, at 16:23, Emil Ivov > > wrote: >> >> Any chance we can add some time for RTX? > > If you mean RTX in the context of double then I would expect > that to be part of the initial double discussion. > Or do you want to talk about your draft which modifies the > OHB for RTX? > > Cheers > Nils > >> >> Also I still don't think we have consensus on SSRC rewriting. >> >> Emil >> >> On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar >> > wrote: >> >> >> Here is the correct link : >> https://datatracker.ietf.org/doc/agenda-99-perc/ >> >> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar >> > wrote: >> >> Hello All >> >> Here is the draft agenda for the PERC WG meeting >> to be held on Tuesday (July 18th) >> >> https://datatracker.ietf.org/doc/agenda-99-perc/ >> >> >> https://datatracker.ietf.org/doc/agenda-99-perc/ >> >> >> Please let the chairs know if you have any >> comments/questions. We will be publishing the >> final agenda by Monday EOD >> >> >> Cheers >> perc chairs >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> -- >> sent from my mobile >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc > > -- > sent from my mobile > > > -- > sent from my mobile -- https://jitsi.org From nobody Sun Jul 16 06:42:51 2017 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 C583B1200FC for ; Sun, 16 Jul 2017 06:42:48 -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 lyfany8dUpep for ; Sun, 16 Jul 2017 06:42:46 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 55CD8129B35 for ; Sun, 16 Jul 2017 06:42:46 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p73so40982352qka.2 for ; Sun, 16 Jul 2017 06:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BCibonqSToN3FuUrt1bi3Pwwkea4GMeh1wLNE7gQ1Pc=; b=O8rAEfeSfvNcylC1iCTnrUfhPiplIo0ilFt04lFKzldwhfqfRZyu+Z4cCbKIumBgls h6OTG7Qj1Y7RjlY1GYt8zLb7b+ROHZNJYp0zE9WKhKte8fby2O7FUU7kxwMTM7FQTYH4 v4VwMoVrAl5laZiGdmf0ncm7mIVsDp0SRm0s722w/H3mUJgt+qX0N5q2qf93FOw6YC42 f43vtjUD3hujId+BWQXztkpBvTwCxmGP4902wfFv6y9fJp3iD7UOX7K9ww2BAY9ELqSJ DErQfC7q8WLb+vhKL+asl6N4XawozJJdF0NvenAYYu7EB9Xz9odB5bzGvICdN7eqLRlF 6tPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BCibonqSToN3FuUrt1bi3Pwwkea4GMeh1wLNE7gQ1Pc=; b=iFgfuUzjsPKpXwH4WHMnCk5dBRNTyY8AawnVC1xfuq9uXiTr5SVF0Qw4yrjpdpXXlR 7/cdDeeM7zEJGfFcnVYpC4hQYplhrlDgIT2/PqXuytxRnUaU5yBRFZd/4hUqB7Z9azJF SQiRGlCY2nLWbrYoZy51wuGeDgMOgzLEdp25TtsIzKZUuZ4cHqh/w/kwf554w6dM9KuI 9Bdcvc72MvFKHNFIHNzjJxEvb7RUsy9/4mCi8G+f2zq4kuxKWTeGaA7YZKxu07NyVYlF tbzS7ab6940h+51QGzX1eczG+Plzb3oNQjWOmaNYffGeQcP0OzBsZPnTxaTKbTNSGmr/ Z+ig== X-Gm-Message-State: AIVw113a7n8lvjPke5S7flsBQ11cykluDVLJQ5uim5epsQLcxRlR63G5 kSb7XqM+TdhmbgPO/tx4fmrpG79a2w== X-Received: by 10.55.114.1 with SMTP id n1mr22343809qkc.123.1500212565444; Sun, 16 Jul 2017 06:42:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.6 with HTTP; Sun, 16 Jul 2017 06:42:44 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> From: Suhas Nandakumar Date: Sun, 16 Jul 2017 06:42:44 -0700 Message-ID: To: Emil Ivov Cc: Nils Ohlmeier , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05a8380d143505546f758e" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 13:42:49 -0000 --94eb2c05a8380d143505546f758e Content-Type: text/plain; charset="UTF-8" Hello Emil Thanks for your draft. We expected you to have the draft submitted* before the deadline* to the IETF data tracker website to help everyone prepare for the meeting. Regarding RTX, I believe Cullen is addressing the alternate proposals in his slide deck - https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-00.pdf. We would encourage your participation and feedback on the same. Also can you and Cullen discuss to see if the points are covered sufficiently. Regarding SSRC rewriting, there has been a consensus to not rewrite the SSRC by the MDD due to the security implications/attacks as discussed in the earlier design meetings/virtual interims and IETF meetings (See https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) Please refer to https://www.ietf.org/proceedings/94/slides/slides-94-perc-5 .pdf for more information as the starting point on the various attacks. Please submit a draft to the mailing list for discussions that addresses the security concerns or invalidates them with an appropriate security analysis Cheers Perc Chairs On Sat, Jul 15, 2017 at 3:11 PM, Emil Ivov wrote: > Hey all, > > As promised on the last interim, the RTX draft is now updated: > > https://raw.githubusercontent.com/bgrozev/perc-rtx/master/dr > aft-grozev-perc-double-rtx-01.txt > > Apologies for the delay. > > Hopefully we are going to have the time to discuss this in next week's > meeting. > > Cheers, > Emil > > > > On 7/12/17 9:12 PM, Emil Ivov wrote: > >> Hey Suhas, >> >> I haven't had as much time as I would have liked for PERC so please >> excuse me if I am making a glaring omission but I don't believe there has >> been any resolution to the RTX issues discussed on the last virtual interim. >> >> Specifically exactly how RTX will coexist with PERC (and no, this doesn't >> really have anything to do with probing). >> >> The latest double draft doesn't seem to say anything specific on the >> subject unless if, again, I am actually missing something. >> >> If I have indeed slept through how this WG reached consensus then I am >> very happy to not have to prepare anything and please accept my appology. >> >> If however there is still doubt on how RTX wedging should would I'll >> follow up on my promise to update our RTX document. >> >> Cheers, >> Emil >> >> On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar > > wrote: >> >> Hello Emil and Percians >> >> From what i gather the sentiments at the IETF 98 was RTX for >> probing bandwidth (as implemented by chrome) was something that >> Chrome should fix it. Were you able to reach out to Chrome team on >> the same ? >> >> Also the latest double spec seems to indicate RTX in PERC is scoped >> only for HBH and not E2E. IIRC your draft had similar recommendations. >> >> please correct me If i am wrong in capturing the thoughts ? >> >> Thanks >> Suhas >> >> On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov > > wrote: >> >> The latter. >> >> During the interim it was mentioned that the modification wasnt >> clear. >> >> I have yet to update the draft but unless people are now all >> comfortable with the notion, which would make me very happy, I >> think it might be useful to go over this again. >> >> (And we still have to reach consensus on the ssrc issue) >> >> Emil >> >> On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier >> > wrote: >> >> On Jul 7, 2017, at 16:23, Emil Ivov >> > wrote: >>> >>> Any chance we can add some time for RTX? >>> >> >> If you mean RTX in the context of double then I would expect >> that to be part of the initial double discussion. >> Or do you want to talk about your draft which modifies the >> OHB for RTX? >> >> Cheers >> Nils >> >> >>> Also I still don't think we have consensus on SSRC rewriting. >>> >>> Emil >>> >>> On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar >>> > wrote: >>> >>> >>> Here is the correct link : >>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>> >>> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar >>> > >>> wrote: >>> >>> Hello All >>> >>> Here is the draft agenda for the PERC WG meeting >>> to be held on Tuesday (July 18th) >>> >>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>> >>> >>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>> >>> >>> Please let the chairs know if you have any >>> comments/questions. We will be publishing the >>> final agenda by Monday EOD >>> >>> >>> Cheers >>> perc chairs >>> >>> >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >>> -- sent from my mobile >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >> >> -- sent from my mobile >> >> >> -- >> sent from my mobile >> > > -- > https://jitsi.org > --94eb2c05a8380d143505546f758e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello Emil

    =C2=A0 Thanks for your draft= .

    We expected you to have the draft submitted= =C2=A0before the deadline to the IETF data tracker website to help ever= yone prepare for the meeting.

    Regarding RTX, =C2= =A0I believe Cullen is addressing the alternate proposals in his slide deck= =C2=A0
    <= br>
    We would encourage your participation and feedback on the sam= e. Also can you and Cullen discuss to see if the points are covered suffici= ently.

    Regarding SSRC rewriting, there has been a = consensus to not rewrite the SSRC by the MDD due to the security implicatio= ns/attacks as discussed in the earlier design meetings/virtual interims and= IETF meetings (See https://www.ietf.org/mail-arch= ive/web/perc/current/msg00231.html)

    Pleas= e refer to =C2=A0https://www.ietf.org/proceedings/= 94/slides/slides-94-perc-5.pdf=C2=A0for more information as the st= arting point on the various attacks. Please submit a draft to the mailing l= ist for discussions that addresses the security concerns or invalidates the= m with an appropriate security analysis


    =

    Cheers
    Perc Chairs

    <= br>

    On= Sat, Jul 15, 2017 at 3:11 PM, Emil Ivov <emcho@jitsi.org> wro= te:
    Hey all,

    As promised on the last interim, the RTX draft is now updated:

    https:/= /raw.githubusercontent.com/bgrozev/perc-rtx/master/draft-grozev-p= erc-double-rtx-01.txt

    Apologies for the delay.

    Hopefully we are going to have the time to discuss this in next week's = meeting.

    Cheers,
    Emil



    On 7/12/17 9:12 PM, Emil Ivov wrote:
    Hey Suhas,

    I haven't had as much time as I would have liked for PERC so please exc= use me if I am making a glaring omission but I don't believe there has = been any resolution to the RTX issues discussed on the last virtual interim= .

    Specifically exactly how RTX will coexist with PERC (and no, this doesn'= ;t really have anything to do with probing).

    The latest double draft doesn't seem to say anything specific on the su= bject unless if, again, I am actually missing something.

    If I have indeed slept through how this WG reached consensus then I am very= happy to not have to prepare anything and please accept my appology.

    If however there is still doubt on how RTX wedging should would I'll fo= llow up on my promise to update our RTX document.

    Cheers,
    Emil

     On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar <suhasietf@gmail.com <mailto:suhasietf@gmail.com&g= t;> wrote:

    =C2=A0 =C2=A0 Hello Emil and Percians

    =C2=A0 =C2=A0 =C2=A0 =C2=A0From what i gather the sentiments at the IETF 98= was RTX for
    =C2=A0 =C2=A0 probing bandwidth=C2=A0 (as implemented by chrome) was someth= ing that
    =C2=A0 =C2=A0 Chrome should fix it. Were you able to reach out to Chrome te= am on
    =C2=A0 =C2=A0 the same ?

    =C2=A0 =C2=A0 Also the latest double spec seems to indicate RTX in PERC is = scoped
    =C2=A0 =C2=A0 only for HBH and not E2E. IIRC your draft had similar recomme= ndations.

    =C2=A0 =C2=A0 please correct me If i am wrong in capturing the thoughts ?
    =C2=A0 =C2=A0 Thanks
    =C2=A0 =C2=A0 Suhas

    =C2=A0 =C2=A0 On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov <emcho@jitsi.org
     =C2=A0 =C2=A0 <mailto:emcho@jitsi.org>> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 The latter.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 During the interim it was mentioned that the mo= dification wasnt
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 clear.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 I have yet to update the draft but unless peopl= e are now all
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 comfortable with the notion, which would make m= e very happy, I
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 think it might be useful to go over this again.=

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 (And we still have to reach consensus on the ss= rc issue)

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 Emil

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier
    <= /span> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <nohlmeier@mozilla.com <mailto:nohlmeier@mozilla.com>>= wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Jul 7, 2017, at 16:23, Emil Iv= ov <emcho@jitsi.org=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org>> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Any chance we can add some time f= or RTX?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you mean RTX in the context of= double then I would expect
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that to be part of the initial do= uble discussion.
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Or do you want to talk about your= draft which modifies the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OHB for RTX?

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nils


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Also I still don't think we h= ave consensus on SSRC rewriting.

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Emil

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Fri, 7 Jul 2017 at 18:20, Suha= s Nandakumar
     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <suhasietf@gmail.com <mailto:suhasietf@gmail.com>>= ; wrote:


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here is the correct= link :
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/agenda-99-perc/

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Fri, Jul 7, 2017= at 4:19 PM, Suhas Nandakumar
     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <suhasietf@gmail.com <mailt= o:suhasietf@gmail.= com>> wrote:

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hello= All

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here = is the draft agenda for the PERC WG meeting
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to be= held on Tuesday (July 18th)

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/agenda-99-perc/=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"https://datatracker.ietf.org/doc/agenda-99-ice/" rel=3D"noreferre= r" target=3D"_blank">https://datatracker.ietf.org/doc/agenda-99-ice/>

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/agenda-99-perc/


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pleas= e let the chairs know if you have any
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 comme= nts/questions. We will be publishing the
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 final= agenda by Monday EOD


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheer= s
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 perc = chairs


    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ____________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Perc mailing list     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Perc@ietf.org <mailto:Perc@ietf.org>=
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://www.ietf.org/mailman/listinfo/perc

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0sent from my mobile
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Perc mailing list
     =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Perc@ietf.org <mailto:Perc@ietf.org>
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mailman/listinfo/perc

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sent from m= y mobile


    --
    sent from my mobile

    --
    https://= jitsi.org

    --94eb2c05a8380d143505546f758e-- From nobody Sun Jul 16 07:09:09 2017 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 6B53F126557 for ; Sun, 16 Jul 2017 07:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (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 KiAGFNTAqHBQ for ; Sun, 16 Jul 2017 07:09:06 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 F1BD61200FC for ; Sun, 16 Jul 2017 07:09:05 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id 70so17392815wmo.1 for ; Sun, 16 Jul 2017 07:09:05 -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=SHeGSsM60CNlS8k0+XTxJ86UuCof960e/RfzprY+fII=; b=hP11OAOEK4NFE42/x5HCPO2ztnGkVs5FYrhaETKBPm+FkHUCppRxQIsEXC2dWWlazl fIScqVGpbN0VkNpfrxs09C/dW5/L36x73V/57+8R0oYbS2dw2br/ujZoCiXq01g2J5pp x7RRotyl27yJ7T8Tg2Pgk9tg4Ovvb/CsLv99sbGlJNf2OhAoSiVFFmdo/5uXAc59rDSo V4jjOC0TOHO3PJuP9tx1Dw9X5UFRULbiVby0MkfEE0gQF+MNO7nKffn7/Ncn9ZzM5G4K GSuNmvT0YKpt/1uF4GREyZhWOyN6ZZjnGbWiYm2dANvUvWrq/gCbEAuZ7RcaOpawSmbe duLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SHeGSsM60CNlS8k0+XTxJ86UuCof960e/RfzprY+fII=; b=XiEa/7QhbzhnUtcy2uv3Nm9b/GhF0Y/QkMJCjmhltE4h3W34FGiEl1iA9LU6EQ635f Hw8jm5lIzWp7ntFPE7USvnuI/mNrqmfDf9GZ4XdfUy4Jo0dG3G0XagUJYc+/5QRiqGw1 TAfTqn8gibSGlC5FVqNnhtQbJbhUK+s2chLqGApRtYcv0pkiL9YICGgNpwDGwcZzqlmy artJEVNHYpaHtVMDyUK7vYU9FLdY7jTQ9xD57zWtT47MZy5aE2K43z9Ci959wVcYIv52 vtOnqiWbumGZQ9Gfg3SN/d2PYZbESAti4Hja8lkh1CwURILPXth0ciX0H1WiioSIAtZb B16A== X-Gm-Message-State: AIVw110KADx7/VyffKOfeMsGa9N2va9m6CqeJRy4j4Tw58XxOBScU3cA dUB0aohVOh6i4jFERaV/qPmqxMPvZZaL X-Received: by 10.80.180.207 with SMTP id x15mr14132347edd.117.1500214144316; Sun, 16 Jul 2017 07:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.177.122 with HTTP; Sun, 16 Jul 2017 07:08:43 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> From: Emil Ivov Date: Sun, 16 Jul 2017 09:08:43 -0500 Message-ID: To: Suhas Nandakumar Cc: Nils Ohlmeier , perc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Perc] PERC Draft Agenda - IETF99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 14:09:08 -0000 Hey Suhas, On Sun, Jul 16, 2017 at 8:42 AM, Suhas Nandakumar wrote: > Hello Emil > > Thanks for your draft. > > We expected you to have the draft submitted before the deadline to the IETF > data tracker website to help everyone prepare for the meeting. Indeed. I already apologised and I do again. Still, the gist of this is a couple of pages so if people a 2 page document, so if the request for this draft was indeed an honest attempt for understanding, the explanation is available here: https://raw.githubusercontent.com/bgrozev/perc-rtx/master/draft-grozev-perc-double-rtx-01.txt > Regarding RTX, I believe Cullen is addressing the alternate proposals in > his slide deck > - https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-00.pdf. > > We would encourage your participation and feedback on the same. Also can you > and Cullen discuss to see if the points are covered sufficiently. I hope that gets covered adequately then. > Regarding SSRC rewriting, there has been a consensus to not rewrite the SSRC > by the MDD This is factually wrong. We had a discussion on this was on IETF 96 (Berlin) where I was asked to describe how this works in a draft, which we did: https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 We then talked about it in Chicago. No decision was reached the topic was left open. > due to the security implications/attacks as discussed in the > earlier design meetings/virtual interims and IETF meetings (See > https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) > > Please refer to > https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more > information as the starting point on the various attacks. Please submit a > draft to the mailing list for discussions that addresses the security > concerns or invalidates them with an appropriate security analysis All of this was discussed subsequently. While there is a lot of hand waving about a possible SSRC splicing attack, to this date I am not aware of an actual description of how this thing could work. https://www.ietf.org/mail-archive/web/perc/current/msg00443.html Especially in light of the draft above. As long as the original SSRC is present and verifiable splicing is not possible. Emil > Cheers > Perc Chairs > > > > On Sat, Jul 15, 2017 at 3:11 PM, Emil Ivov wrote: >> >> Hey all, >> >> As promised on the last interim, the RTX draft is now updated: >> >> >> https://raw.githubusercontent.com/bgrozev/perc-rtx/master/draft-grozev-perc-double-rtx-01.txt >> >> Apologies for the delay. >> >> Hopefully we are going to have the time to discuss this in next week's >> meeting. >> >> Cheers, >> Emil >> >> >> >> On 7/12/17 9:12 PM, Emil Ivov wrote: >>> >>> Hey Suhas, >>> >>> I haven't had as much time as I would have liked for PERC so please >>> excuse me if I am making a glaring omission but I don't believe there has >>> been any resolution to the RTX issues discussed on the last virtual interim. >>> >>> Specifically exactly how RTX will coexist with PERC (and no, this doesn't >>> really have anything to do with probing). >>> >>> The latest double draft doesn't seem to say anything specific on the >>> subject unless if, again, I am actually missing something. >>> >>> If I have indeed slept through how this WG reached consensus then I am >>> very happy to not have to prepare anything and please accept my appology. >>> >>> If however there is still doubt on how RTX wedging should would I'll >>> follow up on my promise to update our RTX document. >>> >>> Cheers, >>> Emil >>> >>> On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar >> > wrote: >>> >>> Hello Emil and Percians >>> >>> From what i gather the sentiments at the IETF 98 was RTX for >>> probing bandwidth (as implemented by chrome) was something that >>> Chrome should fix it. Were you able to reach out to Chrome team on >>> the same ? >>> >>> Also the latest double spec seems to indicate RTX in PERC is scoped >>> only for HBH and not E2E. IIRC your draft had similar >>> recommendations. >>> >>> please correct me If i am wrong in capturing the thoughts ? >>> >>> Thanks >>> Suhas >>> >>> On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov >> > wrote: >>> >>> The latter. >>> >>> During the interim it was mentioned that the modification wasnt >>> clear. >>> >>> I have yet to update the draft but unless people are now all >>> comfortable with the notion, which would make me very happy, I >>> think it might be useful to go over this again. >>> >>> (And we still have to reach consensus on the ssrc issue) >>> >>> Emil >>> >>> On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier >>> > wrote: >>> >>>> On Jul 7, 2017, at 16:23, Emil Ivov >>> > wrote: >>>> >>>> Any chance we can add some time for RTX? >>> >>> >>> If you mean RTX in the context of double then I would expect >>> that to be part of the initial double discussion. >>> Or do you want to talk about your draft which modifies the >>> OHB for RTX? >>> >>> Cheers >>> Nils >>> >>>> >>>> Also I still don't think we have consensus on SSRC >>>> rewriting. >>>> >>>> Emil >>>> >>>> On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar >>>> > wrote: >>>> >>>> >>>> Here is the correct link : >>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>> >>>> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar >>>> > >>>> wrote: >>>> >>>> Hello All >>>> >>>> Here is the draft agenda for the PERC WG meeting >>>> to be held on Tuesday (July 18th) >>>> >>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>> >>>> >>>> https://datatracker.ietf.org/doc/agenda-99-perc/ >>>> >>>> >>>> Please let the chairs know if you have any >>>> comments/questions. We will be publishing the >>>> final agenda by Monday EOD >>>> >>>> >>>> Cheers >>>> perc chairs >>>> >>>> >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>>> -- sent from my mobile >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>> >>> >>> -- sent from my mobile >>> >>> >>> -- >>> sent from my mobile >> >> >> -- >> https://jitsi.org > > -- https://jitsi.org From nobody Sun Jul 16 14:50:15 2017 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 61543126CB6 for ; Sun, 16 Jul 2017 14:50:13 -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=mozilla.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 xbyLsNOCgUrq for ; Sun, 16 Jul 2017 14:50:11 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 CD4B0126BF3 for ; Sun, 16 Jul 2017 14:50:10 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id 70so18622897wmo.1 for ; Sun, 16 Jul 2017 14:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p1ND4bX9A3bubO8oD5xrlX3q7M8X1v8NZH/Xw+Qjzyc=; b=FhEECZdk2w3RlMkcbw1GCbS3pmBfngMmdVvSO9lLwC1btikYEJt9UVF7Lp+rUfhiqs mLNc2kL1IicITAAfUo5v4yp1VFA3L4/Bt4UzqK2f/dS1qG2OKVBVXKCt3HjKtwxAcRTk el7/8BiVXFdkpeFtujfKKUkdr4rrQHOagoYhg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p1ND4bX9A3bubO8oD5xrlX3q7M8X1v8NZH/Xw+Qjzyc=; b=Fbxh0qNEGhsLyRNRswBREsfbTeG4i3tQ7KiNUZd+I/3yYov5qN8qHVO04scaSPRtsb S4eosbS9u4oBb+l5UFnduNEVnV3IL8/grTjZ2S/pFVFc0yCEaRI8r5jKvh+cNzlrH3s/ /N320D2ZN9DpY4cIxq3GEAwMSpJAjjuTaHLoqcSIjzrlQDa/T6JNU8yv0ICPwYZOwLm/ GHArKnStTaFbi9oK3lvmpRfprkjRNDIaorZkjXbsEPAiYb+WJCusULVXD0cc0M4ZGbpQ 8wY6t5iqsroYrLfSK6PeKrYgsrBb42nu/KDOFb5Pn2+m9ArjNSB/epb67RJbM7mznk/q EN+A== X-Gm-Message-State: AIVw112uT27/SHAARt/p0p4spvwTJdMIVNc2L90CwtfioIRB2Cgt3RTM lMGFKErPjH5LaYj7KgVp7Q== X-Received: by 10.28.154.17 with SMTP id c17mr2448866wme.35.1500241809228; Sun, 16 Jul 2017 14:50:09 -0700 (PDT) Received: from [10.96.3.195] (94-74-228-155.client.rionet.cz. [94.74.228.155]) by smtp.gmail.com with ESMTPSA id p23sm249239wrc.35.2017.07.16.14.50.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 14:50:07 -0700 (PDT) From: Nils Ohlmeier Message-Id: <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B30ADF3C-79D1-48F0-8BF5-8004311C6523"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 16 Jul 2017 23:50:05 +0200 In-Reply-To: Cc: Suhas Nandakumar , perc@ietf.org To: Emil Ivov References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 21:50:13 -0000 --Apple-Mail=_B30ADF3C-79D1-48F0-8BF5-8004311C6523 Content-Type: multipart/alternative; boundary="Apple-Mail=_F5F834C1-0007-48D3-A21D-506375CEB0C4" --Apple-Mail=_F5F834C1-0007-48D3-A21D-506375CEB0C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 16, 2017, at 16:08, Emil Ivov wrote: >=20 >> Regarding SSRC rewriting, there has been a consensus to not rewrite = the SSRC >> by the MDD >=20 > This is factually wrong. >=20 > We had a discussion on this was on IETF 96 (Berlin) where I was asked > to describe how this works in a draft, which we did: >=20 > https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 = >=20 > We then talked about it in Chicago. No decision was reached the topic > was left open. >=20 >> due to the security implications/attacks as discussed in the >> earlier design meetings/virtual interims and IETF meetings (See >> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html = ) >>=20 >> Please refer to >> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf = for = more >> information as the starting point on the various attacks. Please = submit a >> draft to the mailing list for discussions that addresses the security >> concerns or invalidates them with an appropriate security analysis >=20 > All of this was discussed subsequently. While there is a lot of hand > waving about a possible SSRC splicing attack, to this date I am not > aware of an actual description of how this thing could work. >=20 So here is the attack I=E2=80=99m concerned about: We have an MD which is allowed to rewrite SSRC (even with including the = original into the OHB). Now an endpoint in a conference receives a RTP packet from that MD where = the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint = itself is using for sending. The endpoint needs to change it's SSRC to avoid the collision. So the = endpoint chooses another SSRC B for sending. And the MD happens to choose another SSRC B as its re-written SSRC. So endpoint changes the SSRC again to C. Which then happens to be the same as the SSRC used by another endpoint = in the conference. Now the MD receives two incoming RTP streams with identical SSRCs from = two different endpoints and can choose to recombine the RTP headers from = client #1 with the payload from client #2. I think this attack plus it=E2=80=99s possible mitigations need to be = described in the draft draft-grozev-perc-ssrc-00. Best regards Nils Ohlmeier --Apple-Mail=_F5F834C1-0007-48D3-A21D-506375CEB0C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Jul 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> = wrote:

    Regarding SSRC rewriting, = there has been a consensus to not rewrite the SSRC
    by the = MDD

    This is factually = wrong.

    We had a discussion = on this was on IETF 96 (Berlin) where I was asked
    to describe how this works in a draft, which we = did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. No = decision was reached the topic
    was left = open.

    due to the security = implications/attacks as discussed in the
    earlier design = meetings/virtual interims and IETF meetings (See
    https://www.ietf.org/mail-archive/web/perc/current/msg00231.htm= l)

    Please refer to
    https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf=  for more
    information as the starting point on the various attacks. = Please submit a
    draft to the mailing list for discussions = that addresses the security
    concerns or invalidates them = with an appropriate security analysis

    All of this was discussed subsequently. While = there is a lot of hand
    waving about a = possible SSRC splicing attack, to this date I am not
    aware of an actual description of how this thing = could work.


    So here is the = attack I=E2=80=99m concerned about:

    We have an MD which is = allowed to rewrite SSRC (even with including the original into the = OHB).
    Now an endpoint in a = conference receives a RTP packet from that MD where the re-written SSRC = (outer SSRC) matches exactly the SSRC A the endpoint itself is using for = sending.
    The endpoint needs to = change it's SSRC to avoid the collision. So the endpoint chooses another = SSRC B for sending.
    And the MD = happens to choose another SSRC B as its re-written = SSRC.
    So endpoint changes the = SSRC again to C.
    Which then = happens to be the same as the SSRC used by another endpoint in the = conference.
    Now the MD receives = two incoming RTP streams with identical SSRCs from two different = endpoints and can choose to recombine the RTP headers from client #1 = with the payload from client #2.

    I think this attack = plus it=E2=80=99s possible mitigations need to be described in the = draft draft-grozev-perc-ssrc-00.

    Best regards
      Nils = Ohlmeier

    = --Apple-Mail=_F5F834C1-0007-48D3-A21D-506375CEB0C4-- --Apple-Mail=_B30ADF3C-79D1-48F0-8BF5-8004311C6523 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZa9+OAAoJEJ3NnGfOORkk/vkQAKB0I+6BK2LWpOydU0LZOUdg pNsz9RmEZcp7qhGINmQO8Pk8AMrN4h7aK3msmCb65kDd2HJ+gBSjl2ra2rDeu2Z6 Srzi0w9r4I+KL17U11odB3m08vc/+Cj6JGc5mSaodjmHoZ0EwHcWeQ/ZtUk1NX6Y SqgkNoRvujkcAmWzqQV6CQHRzt4T3ZqVM7csruuzrscPDg+dENdNovZ8rWKuDagt 8xHSupqeJGLBxJ6yfr2vDlv3Xu9GfhjvCkuObbYKjEpyvGybeAvtIWS3P3hjpCJW bPAmRSZixtIdjDYKFJw5aMXMKo35NOH9ucMmoSNobBa/EB054bmWsljZr8UGyEjL qUvawCOr/K19G1DoBxXT7T3beIm6+HipX2+zMuWjX4Tb2M0E4/sJ/BDBU9croSMk p4P4cSbnYUYpEV/NdaYGSmYcNVq4XchjSWp590+CeALbj2ycbZUt+dIKeJbcQysj qWueJdePPMlKdThBWYWaPmTHDMyZZEdM05yfrqUdMe/qvOOvvULwpzxzPBrPdRxH ep+X5O1UmQc+7ug3P/EuY63LgMJTZdfNLqLxGyjwA/t1IGCFynZwGbc1tFOkp9Q+ /n0p4hCEonn5rbiYprVCzFpiUO0rEWsxx6EXQWuS3C2FsFIXfNlAvzasvgdKSJn9 hue4kLexS5jPrnzEb5mw =ErUJ -----END PGP SIGNATURE----- --Apple-Mail=_B30ADF3C-79D1-48F0-8BF5-8004311C6523-- From nobody Sun Jul 16 15:01:22 2017 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 9295612969E for ; Sun, 16 Jul 2017 15:01:20 -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 8cOcfuI5a7Hz for ; Sun, 16 Jul 2017 15:01:19 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 085BD126BF3 for ; Sun, 16 Jul 2017 15:01:19 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w126so60849279wme.0 for ; Sun, 16 Jul 2017 15:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=X7I7+xP9zGcgl+YM60BDYc2WstWbD4wpq35gL2dfCSI=; b=YJfB9yeoimPXc/XhTJIm071/JGmxq1AcY7uGKDhiDFJw7cXfYELykQlB9/A1IXxT2e Oqc+R+gg26W8DqfpejUoI4hHtrXWDtIIZlK8fs9TTjmPIbBDm18X1dk2ff0Ub5a4oDsx 0adKjCY2fU/b0RsfoTeqRIYoTNI/7XNqh5SLvQSvpZf22qnHxLlEMMxHSokj1XjxBSiP dkXeMbGWvrPQukn7K57J4TLZW7J6FsJPB7E79ofAbXp80LA8FWGo7l3nfhHe3a4nory+ D+Xeen6VDtkmOV8WgkvdRwzCwJq0/NTo0fR2rtvjJUSxTYTEE4U1t6VD6otMHqdwbMAw 0LBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=X7I7+xP9zGcgl+YM60BDYc2WstWbD4wpq35gL2dfCSI=; b=lIVQHNQq8989uT3e+cQLFMAkBZCi2dpgR388B0bTCGb9d/GI4BaCTd4l80chdaCToU FN45gkqtbzxA0VvdbhzJHhwG2x0Cb5pgDfAulpfNy+yqmydTyZ+85GE+LhW2ZmBq3P3L BY1sNoJRyF/8hmoiGrl13xD1ACYbwC44ZxnJSZz8pmNBZaLRM9rdhxDyXlIG42hAGDgT nuInuxU7w02nSr8/bPPoQ8ZTg4dZyBDKZRSDlkCRvBvCw53XgqPgAoMolHNxV1xDZETk jQybH6lqbw26xSR7XwrvEcrTA+JnxKWfLft52qdo1QFWfk2II2FvkUiQpNYBHAX2v2KH sdPg== X-Gm-Message-State: AIVw1118V4eZxoTIunp2r5J5+zFaqDcnYiuE0TWk2lyijerSvxds7Xll HhnGO89rsIXjBi5wXAg= X-Received: by 10.28.145.12 with SMTP id t12mr2147327wmd.107.1500242477354; Sun, 16 Jul 2017 15:01:17 -0700 (PDT) Received: from ?IPv6:2a00:1028:8387:2ed6:31ed:d1a0:daf9:8bf9? (dynamic-2a00-1028-8387-2ed6-31ed-d1a0-daf9-8bf9.ipv6.broadband.iol.cz. [2a00:1028:8387:2ed6:31ed:d1a0:daf9:8bf9]) by smtp.googlemail.com with ESMTPSA id i15sm253718wmd.13.2017.07.16.15.01.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 15:01:16 -0700 (PDT) To: perc@ietf.org References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Sergio Garcia Murillo Message-ID: <7f2a68c7-7ac4-be65-6554-76a6e9d7d962@gmail.com> Date: Mon, 17 Jul 2017 00:01:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> Content-Type: multipart/alternative; boundary="------------57ACFA52A3F57C000E291738" Content-Language: en-US Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:01:20 -0000 This is a multi-part message in MIME format. --------------57ACFA52A3F57C000E291738 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 16/07/2017 23:50, Nils Ohlmeier wrote: > Now the MD receives two incoming RTP streams with identical SSRCs from > two different endpoints and can choose to recombine the RTP headers > from client #1 with the payload from client #2. > Shouldn't the SRTP authentication fail in that recombined packet? Best regards Sergio --------------57ACFA52A3F57C000E291738 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
    On 16/07/2017 23:50, Nils Ohlmeier wrote:

    Now the MD receives two incoming RTP streams with identical SSRCs from two different endpoints and can choose to recombine the RTP headers from client #1 with the payload from client #2.

    Shouldn't the SRTP authentication fail in that recombined packet?

    Best regards
    Sergio
    --------------57ACFA52A3F57C000E291738-- From nobody Sun Jul 16 15:32:17 2017 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 F3422129B06 for ; Sun, 16 Jul 2017 15:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oY-lxPacC_ew for ; Sun, 16 Jul 2017 15:32:14 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 33D7412441E for ; Sun, 16 Jul 2017 15:32:14 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id b64so7110299uab.0 for ; Sun, 16 Jul 2017 15:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lb18KDejdFTu6wYBnS06STQARkHgzwrDWOrlanukbwc=; b=GKnVxB+uOPk1RbD/WzzdR9r4zpJO/5R4HZTCTjWY223O86sWJTKE6BRCdEXSkJZDFn P1fsPYopcDuQRI+aD/4VCw/AKEKqleSz2VArm4zXVqgijRHXYjoWK0gF9JZcJwipReeK PdTipASMsUAnEDV+8TmHQt54pRfsMvY+6ZgXDIoLRlrkZJWmGHmJnCWOGa1OQuaAk/qm kgjhEcBB0b0FA+dYxRXIOb6BI/xXwE4hkeK8KlAvb8CcYHssGE4A1+9zJ16YYlrlJHSX Uh7hoxuLZnbOm3Gmp4rEoGajXJOr/nwF0SzB0jvRNOOL7RTTy/aJZXBVVCTMIV8oCMOh rmrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lb18KDejdFTu6wYBnS06STQARkHgzwrDWOrlanukbwc=; b=McSLd3VNvgUT2JW9FS1cmDnUxnDWU4PutKk/XIJp1H7VNLYA/xaOSkb9eatFdukGgz w5oXEB/NV1xTbabWOJnDiucFuq4k8wxajR2tzl1ERNB6NpLOWfF1yTixeiQoZUAPtH23 ph2Z32BeiRGbsvjEqY1FZEATl234fckG2EKt6Y7HJ9O68v/9IFpudY+ug5QoJt6G4hIp S7UFM+aVCyRqQ47yoRBWFziJdNoG01unwWgi0oUr/Ud+UmZVx84ySSlLJaVt2lF3/DMr ynzM7Z1FUW9HWiwTfpevMufccGGAxSnom5kuawUv4onHehD5mI5ZZ09nbn7cH7fP62Ck 48zQ== X-Gm-Message-State: AIVw112ZPShTKGIgaSLBavpJx7wzRsyNWu1wVVtA9hhKovU+xg3mUWly nxxoxO2U94SukeaScTnoG/t4YPTv6w== X-Received: by 10.31.131.19 with SMTP id f19mr10690935vkd.9.1500244333143; Sun, 16 Jul 2017 15:32:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.80 with HTTP; Sun, 16 Jul 2017 15:31:52 -0700 (PDT) In-Reply-To: <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Bernard Aboba Date: Sun, 16 Jul 2017 15:31:52 -0700 Message-ID: To: Nils Ohlmeier Cc: Emil Ivov , Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="001a1145787c8dad35055476dafc" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:32:17 -0000 --001a1145787c8dad35055476dafc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nils said: "So here is the attack I=E2=80=99m concerned about:" [BA] What you are describing relates to the process for detecting and resolving an SSRC conflict between RTP streams in the same RTP session within PERC. Whether the MDD modifies SSRCs or not, in PERC all conference participants are effectively within the same RTP session, so that conflicts can occur between participants (not just between a participant and the MDD as would normally be the case with a non-PERC SSRC-modifying MDD). RFC 3550 and 3711 indicate that responsibility for collision resolution lies with the endpoints, so a PERC endpoint needs to be prepared to handle this, regardless of whether the MDD modifies SSRC. >From RFC 3550 Section 8.2: Although the probability of SSRC identifier collision is low, all RTP implementations MUST be prepared to detect collisions and take the appropriate actions to resolve them. If a source discovers at any time that another source is using the same SSRC identifier as its own, it MUST send an RTCP BYE packet for the old identifier and choose another random one. (As explained below, this step is taken only once in case of a loop.) If a receiver discovers that two other sources are colliding, it MAY keep the packets from one and discard the packets from the other when this can be detected by different source transport addresses or CNAMEs. The two sources are expected to resolve the collision so that the situation doesn't last. >From RFC 3711, Section 9.1: Thus, the SSRC MUST be unique between all the RTP streams within the same RTP session that share the same master key. RTP itself provides an algorithm for detecting SSRC collisions within the same RTP session. Thus, temporary collisions could lead to temporary two-time pad, in the unfortunate event that SSRCs collide at a point in time when the streams also have identical sequence numbers (occurring with probability roughly 2^(-48)). Therefore, the key management SHOULD take care of avoiding such SSRC collisions by including the SSRCs to be used in the session as negotiation parameters, proactively assuring their uniqueness. This is a strong requirements in scenarios where for example, there are multiple senders that can start to transmit simultaneously, before SSRC collision are detected at the RTP level. On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier wrote: > > On Jul 16, 2017, at 16:08, Emil Ivov wrote: > > Regarding SSRC rewriting, there has been a consensus to not rewrite the > SSRC > by the MDD > > > This is factually wrong. > > We had a discussion on this was on IETF 96 (Berlin) where I was asked > to describe how this works in a draft, which we did: > > https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 > > We then talked about it in Chicago. No decision was reached the topic > was left open. > > due to the security implications/attacks as discussed in the > earlier design meetings/virtual interims and IETF meetings (See > https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) > > Please refer to > https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more > information as the starting point on the various attacks. Please submit a > draft to the mailing list for discussions that addresses the security > concerns or invalidates them with an appropriate security analysis > > > All of this was discussed subsequently. While there is a lot of hand > waving about a possible SSRC splicing attack, to this date I am not > aware of an actual description of how this thing could work. > > > So here is the attack I=E2=80=99m concerned about: > > We have an MD which is allowed to rewrite SSRC (even with including the > original into the OHB). > Now an endpoint in a conference receives a RTP packet from that MD where > the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint > itself is using for sending. > The endpoint needs to change it's SSRC to avoid the collision. So the > endpoint chooses another SSRC B for sending. > And the MD happens to choose another SSRC B as its re-written SSRC. > So endpoint changes the SSRC again to C. > Which then happens to be the same as the SSRC used by another endpoint in > the conference. > Now the MD receives two incoming RTP streams with identical SSRCs from tw= o > different endpoints and can choose to recombine the RTP headers from clie= nt > #1 with the payload from client #2. > > I think this attack plus it=E2=80=99s possible mitigations need to be des= cribed in > the draft draft-grozev-perc-ssrc-00. > > Best regards > Nils Ohlmeier > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --001a1145787c8dad35055476dafc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Nils said:=C2=A0

    "So here is the attack I=E2=80=99m concerned about:"

    [BA] What you are describing relates to the pr= ocess for detecting and resolving an SSRC conflict between RTP streams in t= he same RTP session within PERC.=C2=A0 Whether the MDD modifies SSRCs or no= t, in PERC all conference participants are effectively within the same RTP = session, so that conflicts can occur between participants =C2=A0(not just between a participant and the MDD as= would normally be the case with a non-PERC SSRC-modifying MDD).=C2=A0

    RFC 3550 and 3711 indicate that responsibility fo= r collision resolution lies with the endpoints, so a PERC endpoint needs to= be prepared to handle this, regardless of whether the MDD modifies SSRC.= =C2=A0

    <= div>From RFC 3550 Section 8.2:
       Although the probability of SSRC=
 identifier collision is low, all RTP
   implementations MUST be prepared to detect collisions and take the
   appropriate actions to resolve them.  If a source discovers at any
   time that another source is using the same SSRC identifier as its
   own, it MUST send an RTCP BYE packet for the old identifier and
   choose another random one.  (As explained below, this step is taken
   only once in case of a loop.)  If a receiver discovers that two other
   sources are colliding, it MAY keep the packets from one and discard
   the packets from the other when this can be detected by different
   source transport addresses or CNAMEs.  The two sources are expected
   to resolve the collision so that the situation doesn't last.

    From RFC 3711, Section 9.1: 

       Thus, the SSRC MU=
ST be unique between all the RTP streams within the
   same RTP session that share the same master key.  RTP itself provides
   an algorithm for detecting SSRC collisions within the same RTP
   session.  Thus, temporary collisions could lead to temporary two-time
   pad, in the unfortunate event that SSRCs collide at a point in time
   when the streams also have identical sequence numbers (occurring with
   probability roughly 2^(-48)).  Therefore, the key management SHOULD
   take care of avoiding such SSRC collisions by including the SSRCs to
   be used in the session as negotiation parameters, proactively
   assuring their uniqueness.  This is a strong requirements in
   scenarios where for example, there are multiple senders that can
   start to transmit simultaneously, before SSRC collision are detected
   at the RTP level.


    On S= un, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.com&= gt; wrote:

    On Jul 16, 2017, at 16= :08, Emil Ivov <emc= ho@jitsi.org> wrote:

    Regarding= SSRC rewriting, there has been a consensus to not rewrite the SSRC
    by t= he MDD

    This is = factually wrong.

    We ha= d a discussion on this was on IETF 96 (Berlin) where I was asked
    <= span style=3D"font-family:Menlo-Regular;font-size:11px;font-style:normal;fo= nt-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:= start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0= px;float:none;display:inline!important">to describe how this works in a dra= ft, which we did:

    https://tools.ietf.org/html/draf= t-grozev-perc-ssrc-00

    We = then talked about it in Chicago. No decision was reached the topicwas left open.

    due to the security implications/attacks as discussed in= the
    earlier design meetings/virtual interims and IETF meetings (See
    = https://www.ietf.org/mail-archive/web/perc/current= /msg00231.html)

    Please refer to
    https= ://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf=C2=A0for mo= re
    information as the starting point on the various attacks. Please subm= it a
    draft to the mailing list for discussions that addresses the securi= ty
    concerns or invalidates them with an appropriate security analysis

    All of this was d= iscussed subsequently. While there is a lot of hand
    waving about a possible SSRC splicing attack, to= this date I am not
    aware= of an actual description of how this thing could work.

    =

    So here is the attack I=E2=80=99m concerned abo= ut:

    We = have an MD which is allowed to rewrite SSRC (even with including the origin= al into the OHB).
    Now an endpoint in a conference receives a RTP packet from that MD where= the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint i= tself is using for sending.
    The endpoint needs to change it's SSRC to avoid the collis= ion. So the endpoint chooses another SSRC B for sending.
    <= span class=3D"m_3038968040479256685_5yl5">And the MD happens to choose anot= her SSRC B as its re-written SSRC.
    So endpoint changes the SSRC again to C.
    Which then happens to be the = same as the SSRC used by another endpoint in the conference.
    Now the MD receives two incom= ing RTP streams with identical SSRCs from two different endpoints and can c= hoose to recombine the RTP headers from client #1 with the payload from cli= ent #2.

    I think this attack plus it=E2=80=99s possible mitigations n= eed to be described in the draft=C2=A0draft-grozev-perc-ssrc-00.
    =

    Best regards
    =C2=A0 Nils Ohlmeier


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


    --001a1145787c8dad35055476dafc-- From nobody Sun Jul 16 15:42:18 2017 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 6DC381289B0 for ; Sun, 16 Jul 2017 15:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 wI1IlC2lHi_r for ; Sun, 16 Jul 2017 15:42:14 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 BE05E127369 for ; Sun, 16 Jul 2017 15:42:13 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id 77so88626753wrb.1 for ; Sun, 16 Jul 2017 15:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HE+f6pSVMmGF4+KjE2eFmbMg0izqnCPiIW4HfDIzvLk=; b=Tt8GICnT3nieSGB4dlHqEYFcga4cNXNTg2tJ8cO/uPnGw4mRzENOiCKXL17ZCgeUDr uEOgUBnz8EBcR2Sz7v3MzvNZAChlaMSTD1fi4bkibzc7B2yz3d9og29PRZUl0nfOx7fe MsWEmQP31iZt0lYgF27w9mwA/qg5IfyCtNUzw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HE+f6pSVMmGF4+KjE2eFmbMg0izqnCPiIW4HfDIzvLk=; b=lyXTKJOnUsWQF/AEFd0USv/r+2HqEu8CrDHV5lH2g+V3Njy+PfS8CsQera9c9ISNgg Zm6oGOEK6lXhC9fXUi3v4jYrm6DdGQUdUi/G6JlnFXj4Av7xjGLNcUxEIe2GKafiTgB3 OUAyqllkFm3GQRRdiyKEvTeeHD+9jvi/ElcQ5c1k8O5WfvJ/FelELKn+DvE9KGL2G10p Z+FZINRxmQh3ASj3ZGREAL3qQ4+JsxJKkBsZfgDaq4Xf9pgLBWbYpbMrNsf86EPtXfs5 7MOar1KglT4lxab5MuL2Rh1icOudWFL3uuysG4d5olMUlmjKbPKl5ZCwtCiipQRgF7ZR QooQ== X-Gm-Message-State: AIVw1100uhoK8vf2cfzaonXTR5SUm0AcemKW1Qi5MNlSVX0DgbzZaiS+ L9Te7hu2Z54J0lVt X-Received: by 10.223.128.209 with SMTP id 75mr8599403wrl.99.1500244932169; Sun, 16 Jul 2017 15:42:12 -0700 (PDT) Received: from [10.96.3.195] (94-74-228-155.client.rionet.cz. [94.74.228.155]) by smtp.gmail.com with ESMTPSA id z108sm21774742wrb.41.2017.07.16.15.42.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Jul 2017 15:42:11 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_248DA77D-6E1B-4AB3-B517-839EC23D090E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 00:42:09 +0200 In-Reply-To: Cc: Emil Ivov , Suhas Nandakumar , perc@ietf.org To: Bernard Aboba References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:42:16 -0000 --Apple-Mail=_248DA77D-6E1B-4AB3-B517-839EC23D090E Content-Type: multipart/alternative; boundary="Apple-Mail=_AF25269E-7916-4BBD-BE7C-425330ECC8D2" --Apple-Mail=_AF25269E-7916-4BBD-BE7C-425330ECC8D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 17, 2017, at 00:31, Bernard Aboba = wrote: >=20 > Nils said: >=20 > "So here is the attack I=E2=80=99m concerned about:" >=20 > [BA] What you are describing relates to the process for detecting and = resolving an SSRC conflict between RTP streams in the same RTP session = within PERC. Whether the MDD modifies SSRCs or not, in PERC all = conference participants are effectively within the same RTP session, so = that conflicts can occur between participants (not just between a = participant and the MDD as would normally be the case with a non-PERC = SSRC-modifying MDD). >=20 Yes absolutely. That=E2=80=99s why the text further down includes = statements like "So endpoint changes the SSRC again to C." The important difference in my opinion is: - If the MD is NOT allowed to re-write SSRCs only another endpoint can = cause a SSRC collision. As endpoints are trusted in PERC the assumptions = is that collisions will only happen in case of accidents but not = intentionally. - If the MD is allowed to re-write SSRCs it gives a malicious MD the = possibility to cause SSRC collisions on purpose to create the situation = where a splicing attack becomes possible. Best Nils Ohlmeier > RFC 3550 and 3711 indicate that responsibility for collision = resolution lies with the endpoints, so a PERC endpoint needs to be = prepared to handle this, regardless of whether the MDD modifies SSRC. >=20 > =46rom RFC 3550 Section 8.2: > Although the probability of SSRC identifier collision is low, all = RTP > implementations MUST be prepared to detect collisions and take the > appropriate actions to resolve them. If a source discovers at any > time that another source is using the same SSRC identifier as its > own, it MUST send an RTCP BYE packet for the old identifier and > choose another random one. (As explained below, this step is taken > only once in case of a loop.) If a receiver discovers that two = other > sources are colliding, it MAY keep the packets from one and discard > the packets from the other when this can be detected by different > source transport addresses or CNAMEs. The two sources are expected > to resolve the collision so that the situation doesn't last. >=20 > =46rom RFC 3711, Section 9.1: >=20 > Thus, the SSRC MUST be unique between all the RTP streams within = the > same RTP session that share the same master key. RTP itself = provides > an algorithm for detecting SSRC collisions within the same RTP > session. Thus, temporary collisions could lead to temporary = two-time > pad, in the unfortunate event that SSRCs collide at a point in time > when the streams also have identical sequence numbers (occurring = with > probability roughly 2^(-48)). Therefore, the key management SHOULD > take care of avoiding such SSRC collisions by including the SSRCs = to > be used in the session as negotiation parameters, proactively > assuring their uniqueness. This is a strong requirements in > scenarios where for example, there are multiple senders that can > start to transmit simultaneously, before SSRC collision are = detected > at the RTP level. >=20 >=20 > On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: >=20 >> On Jul 16, 2017, at 16:08, Emil Ivov > wrote: >>=20 >>> Regarding SSRC rewriting, there has been a consensus to not rewrite = the SSRC >>> by the MDD >>=20 >> This is factually wrong. >>=20 >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >>=20 >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 = >>=20 >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >>=20 >>> due to the security implications/attacks as discussed in the >>> earlier design meetings/virtual interims and IETF meetings (See >>> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html = ) >>>=20 >>> Please refer to >>> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf = for = more >>> information as the starting point on the various attacks. Please = submit a >>> draft to the mailing list for discussions that addresses the = security >>> concerns or invalidates them with an appropriate security analysis >>=20 >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >>=20 >=20 > So here is the attack I=E2=80=99m concerned about: >=20 > We have an MD which is allowed to rewrite SSRC (even with including = the original into the OHB). > Now an endpoint in a conference receives a RTP packet from that MD = where the re-written SSRC (outer SSRC) matches exactly the SSRC A the = endpoint itself is using for sending. > The endpoint needs to change it's SSRC to avoid the collision. So the = endpoint chooses another SSRC B for sending. > And the MD happens to choose another SSRC B as its re-written SSRC. > So endpoint changes the SSRC again to C. > Which then happens to be the same as the SSRC used by another endpoint = in the conference. > Now the MD receives two incoming RTP streams with identical SSRCs from = two different endpoints and can choose to recombine the RTP headers from = client #1 with the payload from client #2. >=20 > I think this attack plus it=E2=80=99s possible mitigations need to be = described in the draft draft-grozev-perc-ssrc-00. >=20 > Best regards > Nils Ohlmeier >=20 >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc = >=20 >=20 --Apple-Mail=_AF25269E-7916-4BBD-BE7C-425330ECC8D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Jul 17, 2017, at 00:31, Bernard Aboba <bernard.aboba@gmail.com> wrote:

    Nils said: 

    "So here is the = attack I=E2=80=99m concerned about:"

    [BA] What you are = describing relates to the process for detecting and resolving an SSRC = conflict between RTP streams in the same RTP session within PERC.  = Whether the MDD modifies SSRCs or not, in PERC all conference = participants are effectively within the same RTP session, so that = conflicts can occur between participants  (not just between a participant = and the MDD as would normally be the case with a non-PERC SSRC-modifying = MDD). 


    Yes absolutely. That=E2=80=99s why the text further = down includes statements like "So endpoint changes the SSRC again to = C."

    The important difference in my = opinion is:
    - If the MD is NOT allowed to re-write SSRCs only = another endpoint can cause a SSRC collision. As endpoints are trusted in = PERC the assumptions is that collisions will only happen in case of = accidents but not intentionally.
    - If the MD is allowed to = re-write SSRCs it gives a malicious MD the possibility to cause SSRC = collisions on purpose to create the situation where a splicing attack = becomes possible.

    Best
     Nils Ohlmeier

    RFC 3550 and 3711 indicate that responsibility for collision = resolution lies with the endpoints, so a PERC endpoint needs to be = prepared to handle this, regardless of whether the MDD modifies = SSRC. 

    =46rom RFC 3550 Section = 8.2:
       =
Although the probability of SSRC identifier collision is low, all RTP
   implementations MUST be prepared to detect collisions and take the
   appropriate actions to resolve them.  If a source discovers at any
   time that another source is using the same SSRC identifier as its
   own, it MUST send an RTCP BYE packet for the old identifier and
   choose another random one.  (As explained below, this step is taken
   only once in case of a loop.)  If a receiver discovers that two other
   sources are colliding, it MAY keep the packets from one and discard
   the packets from the other when this can be detected by different
   source transport addresses or CNAMEs.  The two sources are expected
   to resolve the collision so that the situation doesn't =
last.

    =46rom RFC 3711, Section 9.1: 

       Thus, =
the SSRC MUST be unique between all the RTP streams within the
   same RTP session that share the same master key.  RTP itself provides
   an algorithm for detecting SSRC collisions within the same RTP
   session.  Thus, temporary collisions could lead to temporary two-time
   pad, in the unfortunate event that SSRCs collide at a point in time
   when the streams also have identical sequence numbers (occurring with
   probability roughly 2^(-48)).  Therefore, the key management SHOULD
   take care of avoiding such SSRC collisions by including the SSRCs to
   be used in the session as negotiation parameters, proactively
   assuring their uniqueness.  This is a strong requirements in
   scenarios where for example, there are multiple senders that can
   start to transmit simultaneously, before SSRC collision are detected
   at the RTP level.


    On Sun, Jul 16, 2017 at 2:50 PM, = Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

    On Jul = 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> wrote:

    Regarding SSRC rewriting, there has been a consensus to not = rewrite the SSRC
    by the MDD

    This is factually = wrong.

    We had a discussion on = this was on IETF 96 (Berlin) where I was asked
    to describe how this = works in a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it = in Chicago. No decision was reached the topic
    was left = open.

    due to the security implications/attacks as discussed in = the
    earlier design meetings/virtual interims and IETF = meetings (See
    https://www.ietf.org/mail-archive/web/perc/current/msg00231.html)

    Please refer to
    https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for = more
    information as the starting point on the various = attacks. Please submit a
    draft to the mailing list for = discussions that addresses the security
    concerns or = invalidates them with an appropriate security analysis

    All of this was = discussed subsequently. While there is a lot of hand
    waving about a possible = SSRC splicing attack, to this date I am not
    aware of an actual = description of how this thing could work.


    So = here is the attack I=E2=80=99m concerned about:

    We have an MD which is allowed to = rewrite SSRC (even with including the original into the = OHB).
    Now an endpoint in a conference = receives a RTP packet from that MD where the re-written SSRC (outer = SSRC) matches exactly the SSRC A the endpoint itself is using for = sending.
    The endpoint needs to change it's = SSRC to avoid the collision. So the endpoint chooses another SSRC B for = sending.
    And the MD happens to choose = another SSRC B as its re-written SSRC.
    So endpoint changes the SSRC again = to C.
    Which then happens to be the same = as the SSRC used by another endpoint in the conference.
    Now the MD = receives two incoming RTP streams with identical SSRCs from two = different endpoints and can choose to recombine the RTP headers from = client #1 with the payload from client #2.

    I think this attack plus it=E2=80=99= s possible mitigations need to be described in the = draft draft-grozev-perc-ssrc-00.

    Best regards
     = Nils Ohlmeier


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



    = --Apple-Mail=_AF25269E-7916-4BBD-BE7C-425330ECC8D2-- --Apple-Mail=_248DA77D-6E1B-4AB3-B517-839EC23D090E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZa+vCAAoJEJ3NnGfOORkkeYAP/iAsTVXB7nq0tRAw1SdjoLjJ Qy+fXK97jgt9gcpX87pQNXxaK7xfY+ADyoRIcTfLwdVT8h7FfqwlgWcJnBrCKiEJ OrAeszUd6KC+J3mRQ2CN6x5cz3CkkoWcKxNwZWmtp4gJhL4Vj7cHrsDxg9cwZEuR AkJ3k9lH4SE83fHYfm8LoAJF7Gtfvbf1IrIffr7G2vGk1O6pacGmtND4eA6smEde w5QVHSV/4k0JIjpEOSFAswecZ/MEmGkTGEPzjjvKPyV+o8wqzD3CPF6xrFQUuAwW eOTSrwK8YTJK2OpthsSJ5vT7jF8P/BopgelHIyKmhWP2e/6C2mnX3k+G204dJ595 7mnfEEbI2TJ+GSIxvn0F8boVoZ4icsDZTRSOIpr59XtkMFkvTFbgEvibrZe9J+LX jjFFjADz9aQ6/zA6qV4NAukV6Ek0ZtKA+iy6kqN3P9he8EUFZYsdugm+lTjsEg9F dznf5XGtw1OddK/6O7S4piymYVovvm/0wvjVEQz+0rrMGEyp+vWwnVxqs7/LXHxy fjyXLqwALbmkGtgKDh1G2qz6+tzrHTxqBX119R9fZaiIEWmm6I9YTzv/2ohiVBmr makJxCxQJmrJPto3VkgDee14TtxKQHLN3/QzGOtJVg14dzlKNothZd7EoE2BX3da f9Fu7FBv1cS/UJ6Keq0a =fLxF -----END PGP SIGNATURE----- --Apple-Mail=_248DA77D-6E1B-4AB3-B517-839EC23D090E-- From nobody Sun Jul 16 15:47:53 2017 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 D0D7412441E for ; Sun, 16 Jul 2017 15:47: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, 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 1gtV4LV7y82I for ; Sun, 16 Jul 2017 15:47:49 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6123112009C for ; Sun, 16 Jul 2017 15:47:49 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id b134so31491008wma.0 for ; Sun, 16 Jul 2017 15:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bkRTCfp7ZpxC1cD1zodY6AJnd7URVjj8hSumlVyk3YY=; b=jkGJqaONWMytrjqWc0rTtNb5xGLbiVWW9qLIXx44aB/4k+Ogce2nRXNfq0v3Sm3HxP F7a3TQ3WE+i8N18TI+u74pCr4dv8mGLwWoReOo163oMZhU5nk2ISKmPU2CNLeH540UYz vy8Mwh3lpokOh5GcbIqlomDeW7mxM1YvD1/n1yzcFQiF7yiu4li635ZitELuVfhl4hz0 ZeaEn5/pN8y+KsUBXl3Ef940/g911soBi4/ByHlY1zUReQFGZZTIVOyEOL2ZTm2Hpw5R rmGGysr+TeehQbqPcbECvWC5uLzqazBJNiBh99eebmMr05mv2AIRkU4SSYLiAD6Vpepx Brig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bkRTCfp7ZpxC1cD1zodY6AJnd7URVjj8hSumlVyk3YY=; b=eVnHXfj8142tmN2PvutHtvs8S/k0wufqJqWeInVVV94fg0PccUvBcAVBMY8ZQjfcTv a6FLhuvKtPL7dmix3FUzw1aIV/QzX2dm4RzSa/y7V89kE26hPQlyijQl5cyrW/JUUKcI diNtaL1ANxEIMLaqt/OamszIbSyuFvPcl0S+YdAHUNf2/z2vDgx8fgY+id2XJqYUmCZ4 CuXi9OOCzTuTHbXeKTLUk1CFEN87FDusaQQbG0fn4ltM3nP0I+2xZ1l5bjYGFdlE8OW6 OqGAcVON2Tq4x6HydKyqa5rhNaXdZ2fBdRaarSpYjDSi05IU4iV5k9szQBRfej66Zl71 vXTw== X-Gm-Message-State: AIVw1102LhnpLlwjSjdIFE8WNh3cgp0Xh7BXvz6B4tkhMQxjh1xfhLxC 3R6RqETKJ+GSO/ju+izq/GpKQOl+5n10eD8= X-Received: by 10.80.205.86 with SMTP id d22mr14836081edj.74.1500245267895; Sun, 16 Jul 2017 15:47:47 -0700 (PDT) MIME-Version: 1.0 References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> In-Reply-To: <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Emil Ivov Date: Sun, 16 Jul 2017 22:47:36 +0000 Message-ID: To: Nils Ohlmeier Cc: Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1af85044edf4055477125c" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 22:47:52 -0000 --94eb2c1af85044edf4055477125c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is the first time I see someone take the pain to actually describe the dreaded SSRC splicing on this list and for that I am very grateful. Thanks Nils. As an answer though: At best (and after what would likely be A LOT of retries) this would allow the SFU to let one participant to impersonate another. We already established that this is a know property of PERC that doesn't bother us: https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 I believe Bernard was making a similar point. If for some reason we do absolutely want to solve this specific scenario (but not other kinds of intra conference impersonation) then it would be trivially easy to do so. We could: A. Specify that collision detection should be performed on the e2e ssrc and not on the hop by hop one or simply B. Limit the number of allowed retries to, say, 3 And again, I don't see why we would do either given that easier kinds of impersonationthat dont involve the MD would remain possible. Would love to hear your thoughts. Emil On Sun, 16 Jul 2017 at 16:50, Nils Ohlmeier wrote: > > On Jul 16, 2017, at 16:08, Emil Ivov wrote: > > Regarding SSRC rewriting, there has been a consensus to not rewrite the > SSRC > by the MDD > > > This is factually wrong. > > We had a discussion on this was on IETF 96 (Berlin) where I was asked > to describe how this works in a draft, which we did: > > https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 > > We then talked about it in Chicago. No decision was reached the topic > was left open. > > due to the security implications/attacks as discussed in the > earlier design meetings/virtual interims and IETF meetings (See > https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) > > Please refer to > https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more > information as the starting point on the various attacks. Please submit a > draft to the mailing list for discussions that addresses the security > concerns or invalidates them with an appropriate security analysis > > > All of this was discussed subsequently. While there is a lot of hand > waving about a possible SSRC splicing attack, to this date I am not > aware of an actual description of how this thing could work. > > > So here is the attack I=E2=80=99m concerned about: > > We have an MD which is allowed to rewrite SSRC (even with including the > original into the OHB). > Now an endpoint in a conference receives a RTP packet from that MD where > the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint > itself is using for sending. > The endpoint needs to change it's SSRC to avoid the collision. So the > endpoint chooses another SSRC B for sending. > And the MD happens to choose another SSRC B as its re-written SSRC. > So endpoint changes the SSRC again to C. > Which then happens to be the same as the SSRC used by another endpoint in > the conference. > Now the MD receives two incoming RTP streams with identical SSRCs from tw= o > different endpoints and can choose to recombine the RTP headers from clie= nt > #1 with the payload from client #2. > > I think this attack plus it=E2=80=99s possible mitigations need to be des= cribed in > the draft draft-grozev-perc-ssrc-00. > > Best regards > Nils Ohlmeier > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --=20 sent from my mobile --94eb2c1af85044edf4055477125c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    This is the first time I see someone take the pain t= o actually describe the dreaded SSRC splicing on this list and for that I a= m very grateful. Thanks Nils.

    As an answer though:

    At best (and after what would likely be A LOT of retries) this would all= ow the SFU to let one participant to impersonate another.=C2=A0

    We already established that this is= a know property of PERC that doesn't bother us:






    And again, I don't see why we would do either given that eas= ier kinds of impersonationthat dont involve the MD would remain possible.

    Would love to hear your t= houghts.

    Emil



    On Jul 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> wrote= :

    Regarding SSRC rewriting, there has= been a consensus to not rewrite the SSRC
    by the MDD
    = This is factually wrong.=
    We had a discussion on this was= on IETF 96 (Berlin) where I was asked
    to describe how this works in a draft, which we did:
    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00
    = We then talked about it in Chicago= . No decision was reached the topic
    was left open.

    due to the s= ecurity implications/attacks as discussed in the
    earlier design meetings= /virtual interims and IETF meetings (See
    https://www= .ietf.org/mail-archive/web/perc/current/msg00231.html)

    Please re= fer to
    https://www.ietf.org/proceedings/94/slides/sli= des-94-perc-5.pdf=C2=A0for more
    information as the starting point on the vari= ous attacks. Please submit a
    draft to the mailing list for discussions t= hat addresses the security
    concerns or invalidates them with an appropri= ate security analysis

    All of this was discussed subsequently. While there is a lot of hand=
    waving about a possible = SSRC splicing attack, to this date I am not
    aware of an actual description of how this thing could w= ork.


    So here is the attack I= =E2=80=99m concerned about:

    We have an MD which is allowed to rewrite SSRC (even w= ith including the original into the OHB).
    Now an endpoint in a conference receives a RTP p= acket from that MD where the re-written SSRC (outer SSRC) matches exactly t= he SSRC A the endpoint itself is using for sending.
    The endpoint needs to change it's = SSRC to avoid the collision. So the endpoint chooses another SSRC B for sen= ding.
    And the M= D happens to choose another SSRC B as its re-written SSRC.
    So endpoint changes the SSRC ag= ain to C.
    Which= then happens to be the same as the SSRC used by another endpoint in the co= nference.
    Now t= he MD receives two incoming RTP streams with identical SSRCs from two diffe= rent endpoints and can choose to recombine the RTP headers from client #1 w= ith the payload from client #2.

    I think this attack plus it=E2=80=99= s possible mitigations need to be described in the draft=C2=A0draft-grozev-= perc-ssrc-00.

    Best regards
    =C2=A0 Nils O= hlmeier

    _________________________________________= ______
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    sent from my mobile
    --94eb2c1af85044edf4055477125c-- From nobody Sun Jul 16 16:00:55 2017 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 D8BEC129562 for ; Sun, 16 Jul 2017 16:00: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, 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 Rp9KBvUDgjOH for ; Sun, 16 Jul 2017 16:00:51 -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 A81BA1200C1 for ; Sun, 16 Jul 2017 16:00:50 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id b134so31624813wma.0 for ; Sun, 16 Jul 2017 16:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Ft26Uj08HM+DGP85hG6RZ3oVADy6tQOdh9hXpZKgpc=; b=ljMlQFABfXJ0J0d7y6ziRr6wVnOgt488NLrVDUluOyaMjuS35Ok0QWHZ2iz7x4wDea w5lgwo6Xr2/Ie9YSVXPQF+f+sP951pihYIiupPp/ccLETav6sNflbXdZwEpY2wEnCcBw do8IHNh5Nvg6BoLTfX+ieQskqb3HL+IcS7wIpHheah9gB06HNolAdLSAlwq+sUuw3USx iDOnd4Xro/O9jZ/jUQeKaoi985GeUyNvqQiHHZaZkGxRm2atClsEuN5f3QbSfz+JP/yO 1eeu/MEfbXFZpSKMcGymqfNHLwKZj+TTvDFTchXqBeOT0jJTZHNIQW5Fz+U9wHtV+dZM d7rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Ft26Uj08HM+DGP85hG6RZ3oVADy6tQOdh9hXpZKgpc=; b=AIFUZrBK7Cxv+EBI2xY8qTWYvLC1dsAO48+fPESdAYxdwZjKOAu8wjkoTgGwQyYqPW oz8v0/vVUz8o6i5U476Di91Qcx5l2r2XB12vsF4zGbsgWX4s40o+NgRnxvuuyk4vWwop K2LNQG3/gd39+i96wjUztH55ZKJ8ITNtPQEQFuDaAl1LzeOFZ2MF6glmfZGRcky0sO7d e8zkvBHEWVKOX9NRF/sqJABjwvNmSfKoL14E5zNqQku+kcamCZOa6erulMZr/OQd8Gfz La+l2qGpgRtK9JV9+yXxDwx8DYukTcntozneV38x1aS42layHlglLRBvohCHdQ4gHc5R sOZA== X-Gm-Message-State: AIVw1116TBhCNaGOvOX/ze2aKZqJcEwTpsvcI17+gUxsmvT5I77bklAG Q8dqW+9F6WH842Hf+C7kagmv3vbTetPNELw= X-Received: by 10.80.205.86 with SMTP id d22mr14859119edj.74.1500246049215; Sun, 16 Jul 2017 16:00:49 -0700 (PDT) MIME-Version: 1.0 References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> In-Reply-To: From: Emil Ivov Date: Sun, 16 Jul 2017 23:00:38 +0000 Message-ID: To: Bernard Aboba , Nils Ohlmeier Cc: Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1af850d6dcd60554774015" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:00:54 -0000 --94eb2c1af850d6dcd60554774015 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 16 Jul 2017 at 17:42, Nils Ohlmeier wrote: > On Jul 17, 2017, at 00:31, Bernard Aboba wrote: > > Nils said: > > "So here is the attack I=E2=80=99m concerned about:" > > [BA] What you are describing relates to the process for detecting and > resolving an SSRC conflict between RTP streams in the same RTP session > within PERC. Whether the MDD modifies SSRCs or not, in PERC all conferen= ce > participants are effectively within the same RTP session, so that conflic= ts > can occur between participants (not just between a participant and the > MDD as would normally be the case with a non-PERC SSRC-modifying MDD). > > > Yes absolutely. That=E2=80=99s why the text further down includes stateme= nts like > "So endpoint changes the SSRC again to C." > > The important difference in my opinion is: > - If the MD is NOT allowed to re-write SSRCs only another endpoint can > cause a SSRC collision. As endpoints are trusted in PERC the assumptions = is > that collisions will only happen in case of accidents but not intentional= ly. > - If the MD is allowed to re-write SSRCs it gives a malicious MD the > possibility to cause SSRC collisions on purpose to create the situation > where a splicing attack becomes possible. > The collision alone could only result in a DoS, which the MD can already do, or impersonation from one endpoint to another, which is already possible and accepted. I fail to see how this creates a new vector. Emil > > Best > Nils Ohlmeier > > RFC 3550 and 3711 indicate that responsibility for collision resolution > lies with the endpoints, so a PERC endpoint needs to be prepared to handl= e > this, regardless of whether the MDD modifies SSRC. > > From RFC 3550 Section 8.2: > > Although the probability of SSRC identifier collision is low, all RTP > implementations MUST be prepared to detect collisions and take the > appropriate actions to resolve them. If a source discovers at any > time that another source is using the same SSRC identifier as its > own, it MUST send an RTCP BYE packet for the old identifier and > choose another random one. (As explained below, this step is taken > only once in case of a loop.) If a receiver discovers that two other > sources are colliding, it MAY keep the packets from one and discard > the packets from the other when this can be detected by different > source transport addresses or CNAMEs. The two sources are expected > to resolve the collision so that the situation doesn't last. > > > From RFC 3711, Section 9.1: > > > Thus, the SSRC MUST be unique between all the RTP streams within the > same RTP session that share the same master key. RTP itself provides > an algorithm for detecting SSRC collisions within the same RTP > session. Thus, temporary collisions could lead to temporary two-time > pad, in the unfortunate event that SSRCs collide at a point in time > when the streams also have identical sequence numbers (occurring with > probability roughly 2^(-48)). Therefore, the key management SHOULD > take care of avoiding such SSRC collisions by including the SSRCs to > be used in the session as negotiation parameters, proactively > assuring their uniqueness. This is a strong requirements in > scenarios where for example, there are multiple senders that can > start to transmit simultaneously, before SSRC collision are detected > at the RTP level. > > > > On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: > >> >> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >> >> Regarding SSRC rewriting, there has been a consensus to not rewrite the >> SSRC >> by the MDD >> >> >> This is factually wrong. >> >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >> >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >> >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >> >> due to the security implications/attacks as discussed in the >> earlier design meetings/virtual interims and IETF meetings (See >> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >> >> Please refer to >> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more >> information as the starting point on the various attacks. Please submit = a >> draft to the mailing list for discussions that addresses the security >> concerns or invalidates them with an appropriate security analysis >> >> >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >> >> >> So here is the attack I=E2=80=99m concerned about: >> >> We have an MD which is allowed to rewrite SSRC (even with including the >> original into the OHB). >> Now an endpoint in a conference receives a RTP packet from that MD where >> the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint >> itself is using for sending. >> The endpoint needs to change it's SSRC to avoid the collision. So the >> endpoint chooses another SSRC B for sending. >> And the MD happens to choose another SSRC B as its re-written SSRC. >> So endpoint changes the SSRC again to C. >> Which then happens to be the same as the SSRC used by another endpoint i= n >> the conference. >> Now the MD receives two incoming RTP streams with identical SSRCs from >> two different endpoints and can choose to recombine the RTP headers from >> client #1 with the payload from client #2. >> >> I think this attack plus it=E2=80=99s possible mitigations need to be de= scribed >> in the draft draft-grozev-perc-ssrc-00. >> >> Best regards >> Nils Ohlmeier >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> > > -- sent from my mobile --94eb2c1af850d6dcd60554774015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    On Sun, 16 Jul 2017 a= t 17:42, Nils Ohlmeier <nohlmei= er@mozilla.com> wrote:
    On Jul 1= 7, 2017, at 00:31, Bernard Aboba <bernard.aboba@gmail.com> wrote:

    Nils said:=C2= =A0

    "So here is th= e attack I=E2=80=99m concerned about:"

    [= BA] What you are describing relates to the process for detecting and resolv= ing an SSRC conflict between RTP streams in the same RTP session within PER= C.=C2=A0 Whether the MDD modifies SSRCs or not, in PERC all conference part= icipants are effectively within the same RTP session, so that conflicts can= occur between participants =C2=A0(= not just between a participant and the MDD as would normally be the case wi= th a non-PERC SSRC-modifying MDD).=C2=A0


    Yes absolutely. That=E2= =80=99s why the text further down includes statements like "So endpoin= t changes the SSRC again to C."

    The important= difference in my opinion is:
    - If the MD is NOT allowed to re-wr= ite SSRCs only another endpoint can cause a SSRC collision. As endpoints ar= e trusted in PERC the assumptions is that collisions will only happen in ca= se of accidents but not intentionally.
    - If= the MD is allowed to re-write SSRCs it gives a malicious MD the possibilit= y to cause SSRC collisions on purpose to create the situation where a splic= ing attack becomes possible.

    =
    The collision alone could only result in a DoS, whi= ch the MD can already do, or impersonation from one endpoint to another, wh= ich is already possible and accepted. I fail to see how this creates a new = vector.

    Emil

    Best
    = =C2=A0Nils Ohlmeier
    = RFC 3550 and 3711 indicate that responsibility for collision resolution lie= s with the endpoints, so a PERC endpoint needs to be prepared to handle thi= s, regardless of whether the MDD modifies SSRC.=C2=A0

    From RFC 3550 Section 8.2:
       Although the probability of SSRC identifier collision is =
low, all RTP
   implementations MUST be prepared to detect collisions and take the
   appropriate actions to resolve them.  If a source discovers at any
   time that another source is using the same SSRC identifier as its
   own, it MUST send an RTCP BYE packet for the old identifier and
   choose another random one.  (As explained below, this step is taken
   only once in case of a loop.)  If a receiver discovers that two other
   sources are colliding, it MAY keep the packets from one and discard
   the packets from the other when this can be detected by different
   source transport addresses or CNAMEs.  The two sources are expected
   to resolve the collision so that the situation doesn't last.

    From RFC 3711, Section 9.1: 

       Thus, the SSRC MUST be unique between all the RTP streams wi=
thin the
   same RTP session that share the same master key.  RTP itself provides
   an algorithm for detecting SSRC collisions within the same RTP
   session.  Thus, temporary collisions could lead to temporary two-time
   pad, in the unfortunate event that SSRCs collide at a point in time
   when the streams also have identical sequence numbers (occurring with
   probability roughly 2^(-48)).  Therefore, the key management SHOULD
   take care of avoiding such SSRC collisions by including the SSRCs to
   be used in the session as negotiation parameters, proactively
   assuring their uniqueness.  This is a strong requirements in
   scenarios where for example, there are multiple senders that can
   start to transmit simultaneously, before SSRC collision are detected
   at the RTP level.


    O= n Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

    On Jul 16, 2017, at 16:08, Emil= Ivov <emcho@jitsi.= org> wrote:

    Regarding SSRC rew= riting, there has been a consensus to not rewrite the SSRC
    by the MDD

    This is factually= wrong.

    We had a discu= ssion on this was on IETF 96 (Berlin) where I was asked
    to describe how this works in a draft, which= we did:

    https://tools.ietf.org/html/draft-grozev-perc-= ssrc-00

    We then talked ab= out it in Chicago. No decision was reached the topic
    was left open.

    due to the security implications/attacks as discussed in the
    ea= rlier design meetings/virtual interims and IETF meetings (See
    https://www.ietf.org/mail-archive/web/perc/current/msg00231.htm= l)

    Please refer to
    https://www.ietf.org/pr= oceedings/94/slides/slides-94-perc-5.pdf=C2=A0for more
    in= formation as the starting point on the various attacks. Please submit a
    = draft to the mailing list for discussions that addresses the security
    co= ncerns or invalidates them with an appropriate security analysis

    All of this was discussed= subsequently. While there is a lot of hand
    waving about a possible SSRC splicing attack, to this da= te I am not
    aware of an a= ctual description of how this thing could work.


    So here is the attack I=E2=80=99m concerned about:
    =

    We have an MD which is allowed to rewrite SSRC (even with including= the original into the OHB).
    Now an endpoint in a conference receives = a RTP packet from that MD where the re-written SSRC (outer SSRC) matches ex= actly the SSRC A the endpoint itself is using for sending.
    The endpoin= t needs to change it's SSRC to avoid the collision. So the endpoint cho= oses another SSRC B for sending.
    And the MD happens to choose another = SSRC B as its re-written SSRC.
    So endpoint changes the SSRC again to C= .
    Which then happens to be the same as the SSRC used by another endpoi= nt in the conference.
    Now the MD receives two incoming RTP streams wit= h identical SSRCs from two different endpoints and can choose to recombine = the RTP headers from client #1 with the payload from client #2.

    I think this attack plus it=E2=80=99s possible mitigations = need to be described in the draft=C2=A0draft-grozev-perc-ssrc-00.

    Best regards
    =C2=A0 Nils Ohlmeier


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



    --
    sent from my mobile<= /div> --94eb2c1af850d6dcd60554774015-- From nobody Sun Jul 16 16:34:35 2017 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 D38B312426E for ; Sun, 16 Jul 2017 16:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XGldag9sFqiY for ; Sun, 16 Jul 2017 16:34:31 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 3D3CF1200C1 for ; Sun, 16 Jul 2017 16:34:31 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id z22so78186917uah.1 for ; Sun, 16 Jul 2017 16:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FD8p8gWTF2+vxMzTUOiYdV7TTpHCuRvQoNtShVYZlVc=; b=NDhwIbfe46i2NWDMaknQAwcLZGyDFHvpvpivJ/Y918PvYWb9P/3kNuI4OWmtKq9iJz GeWtUWGV8qKpm5/NeZPQ5iZvozakp67O1N9H6sgFZ0bIsMfAc/1Hltt9+lEvoVsQVL5l J7AYSgOsO36PnfWhLd07O0+zlwIUpXSGKjGLIDp/2LOIcIXC2Fhmoodqt9bS3kybrFhm +GQgpi1cNo/JDHL636YDfZO5hpjDsZlpBQ8h9MwarlKBt2ry8UEYzL6bzrhLr3ynmS3Q hEFwbcTFPOhPFuCD8DUhpfWqZE/RF1Yd6CqjpFECp5VGPxEsBqbloDDJTH/uwYKSzMHX t71g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FD8p8gWTF2+vxMzTUOiYdV7TTpHCuRvQoNtShVYZlVc=; b=eKtejNxJytsWV7FMFkuNf3bTrwPJc5ccpEfmDOT/nRAOZSPeUeywllwMS6myt+07VI G7/Uvvjpzzc87TqgF0YdETlvTAFDnF2tAoJaChfSjgRLhvxQda3sUnAsa7oTsxEtO7AT fjv77LvxEcnJoNuTafyUamjlTcDkO36EJaBAliDkXjjEWD2x0P/c8s7L10cQtYreq9fh D94m8lTpmwFWXXThWO1bXbmd6VMLusT7nlbgm6lDO82ASWp8Ns6iGSmzDMhvz7Lb+Qou RFKTSIlDWad6VqCuvhltQa+ASLOhXMxoEf6/M8RflGD7pmhUMcX1lx95OtqPX29xQHmf UuPg== X-Gm-Message-State: AIVw110eJBrqToviRdvpB6CSP10Q+PBXHRotBYv/4GtTg/gEl1f4vk15 zLby7VgYDU/guHus3BJPjbIfP0Y7NA== X-Received: by 10.31.165.69 with SMTP id o66mr3409478vke.133.1500248070146; Sun, 16 Jul 2017 16:34:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.80 with HTTP; Sun, 16 Jul 2017 16:34:09 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Bernard Aboba Date: Sun, 16 Jul 2017 16:34:09 -0700 Message-ID: To: Nils Ohlmeier Cc: Emil Ivov , Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="001a114158644bd073055477b9fb" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:34:34 -0000 --001a114158644bd073055477b9fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nils said: "The important difference in my opinion is: - If the MD is NOT allowed to re-write SSRCs only another endpoint can cause a SSRC collision" [BA] If the MD can handle hop-by-hop repair (e.g. RED, RTX and FEC) can't it cause an SSRC collision? Also, can't an MD send RTCP packets (e.g. feedback, SDES, etc.) that could cause a collision? On Sun, Jul 16, 2017 at 3:42 PM, Nils Ohlmeier wrote: > > On Jul 17, 2017, at 00:31, Bernard Aboba wrote: > > Nils said: > > "So here is the attack I=E2=80=99m concerned about:" > > [BA] What you are describing relates to the process for detecting and > resolving an SSRC conflict between RTP streams in the same RTP session > within PERC. Whether the MDD modifies SSRCs or not, in PERC all conferen= ce > participants are effectively within the same RTP session, so that conflic= ts > can occur between participants (not just between a participant and the > MDD as would normally be the case with a non-PERC SSRC-modifying MDD). > > > Yes absolutely. That=E2=80=99s why the text further down includes stateme= nts like > "So endpoint changes the SSRC again to C." > > The important difference in my opinion is: > - If the MD is NOT allowed to re-write SSRCs only another endpoint can > cause a SSRC collision. As endpoints are trusted in PERC the assumptions = is > that collisions will only happen in case of accidents but not intentional= ly. > - If the MD is allowed to re-write SSRCs it gives a malicious MD the > possibility to cause SSRC collisions on purpose to create the situation > where a splicing attack becomes possible. > > Best > Nils Ohlmeier > > RFC 3550 and 3711 indicate that responsibility for collision resolution > lies with the endpoints, so a PERC endpoint needs to be prepared to handl= e > this, regardless of whether the MDD modifies SSRC. > > From RFC 3550 Section 8.2: > > Although the probability of SSRC identifier collision is low, all RTP > implementations MUST be prepared to detect collisions and take the > appropriate actions to resolve them. If a source discovers at any > time that another source is using the same SSRC identifier as its > own, it MUST send an RTCP BYE packet for the old identifier and > choose another random one. (As explained below, this step is taken > only once in case of a loop.) If a receiver discovers that two other > sources are colliding, it MAY keep the packets from one and discard > the packets from the other when this can be detected by different > source transport addresses or CNAMEs. The two sources are expected > to resolve the collision so that the situation doesn't last. > > > From RFC 3711, Section 9.1: > > > Thus, the SSRC MUST be unique between all the RTP streams within the > same RTP session that share the same master key. RTP itself provides > an algorithm for detecting SSRC collisions within the same RTP > session. Thus, temporary collisions could lead to temporary two-time > pad, in the unfortunate event that SSRCs collide at a point in time > when the streams also have identical sequence numbers (occurring with > probability roughly 2^(-48)). Therefore, the key management SHOULD > take care of avoiding such SSRC collisions by including the SSRCs to > be used in the session as negotiation parameters, proactively > assuring their uniqueness. This is a strong requirements in > scenarios where for example, there are multiple senders that can > start to transmit simultaneously, before SSRC collision are detected > at the RTP level. > > > > On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: > >> >> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >> >> Regarding SSRC rewriting, there has been a consensus to not rewrite the >> SSRC >> by the MDD >> >> >> This is factually wrong. >> >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >> >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >> >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >> >> due to the security implications/attacks as discussed in the >> earlier design meetings/virtual interims and IETF meetings (See >> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >> >> Please refer to >> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more >> information as the starting point on the various attacks. Please submit = a >> draft to the mailing list for discussions that addresses the security >> concerns or invalidates them with an appropriate security analysis >> >> >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >> >> >> So here is the attack I=E2=80=99m concerned about: >> >> We have an MD which is allowed to rewrite SSRC (even with including the >> original into the OHB). >> Now an endpoint in a conference receives a RTP packet from that MD where >> the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint >> itself is using for sending. >> The endpoint needs to change it's SSRC to avoid the collision. So the >> endpoint chooses another SSRC B for sending. >> And the MD happens to choose another SSRC B as its re-written SSRC. >> So endpoint changes the SSRC again to C. >> Which then happens to be the same as the SSRC used by another endpoint i= n >> the conference. >> Now the MD receives two incoming RTP streams with identical SSRCs from >> two different endpoints and can choose to recombine the RTP headers from >> client #1 with the payload from client #2. >> >> I think this attack plus it=E2=80=99s possible mitigations need to be de= scribed >> in the draft draft-grozev-perc-ssrc-00. >> >> Best regards >> Nils Ohlmeier >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> > > --001a114158644bd073055477b9fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Nils said:=C2=A0

    "The important difference in my opinion is:
    - If the MD is NOT allowed to re-write SSRCs o= nly another endpoint can cause a SSRC collision"

    [BA] =C2=A0If the= MD can handle hop-by-hop repair (e.g. RED, RTX and FEC) can't it cause= an SSRC collision? Also, can't an MD send RTCP packets (e.g. feedback,= SDES, etc.) that could cause a collision?

    On Sun, Jul 16, 2017 at 3:42 PM, Nils = Ohlmeier <nohlmeier@mozilla.com> wrote:

    On Jul 17, 2017, at 00:31, Bernard Abo= ba <bernard= .aboba@gmail.com> wrote:

    Nils said:=C2=A0

    "So here is the attack I=E2=80= =99m concerned about:"

    [BA] What you are= describing relates to the process for detecting and resolving an SSRC conf= lict between RTP streams in the same RTP session within PERC.=C2=A0 Whether= the MDD modifies SSRCs or not, in PERC all conference participants are eff= ectively within the same RTP session, so that conflicts can occur between p= articipants =C2=A0(not just between= a participant and the MDD as would normally be the case with a non-PERC SS= RC-modifying MDD).=C2=A0
    =

    Yes absolut= ely. That=E2=80=99s why the text further down includes statements like &quo= t;So endpoint changes the SSRC again to C."

    T= he important difference in my opinion is:
    - If the MD is NOT allo= wed to re-write SSRCs only another endpoint can cause a SSRC collision. As = endpoints are trusted in PERC the assumptions is that collisions will only = happen in case of accidents but not intentionally.
    - If the MD is= allowed to re-write SSRCs it gives a malicious MD the possibility to cause= SSRC collisions on purpose to create the situation where a splicing attack= becomes possible.

    Best
    =C2=A0Nils Ohlmeier
    =

    =
    RFC 3550 and 3711 indicate that respo= nsibility for collision resolution lies with the endpoints, so a PERC endpo= int needs to be prepared to handle this, regardless of whether the MDD modi= fies SSRC.=C2=A0

    From RFC 3550 Section 8.2:
       Although the prob=
ability of SSRC identifier collision is low, all RTP
   implementations MUST be prepared to detect collisions and take the
   appropriate actions to resolve them.  If a source discovers at any
   time that another source is using the same SSRC identifier as its
   own, it MUST send an RTCP BYE packet for the old identifier and
   choose another random one.  (As explained below, this step is taken
   only once in case of a loop.)  If a receiver discovers that two other
   sources are colliding, it MAY keep the packets from one and discard
   the packets from the other when this can be detected by different
   source transport addresses or CNAMEs.  The two sources are expected
   to resolve the collision so that the situation doesn't last.

    From RFC 3711, Section 9.1: 

       Thus, the SSRC MUST be unique between all the RTP =
streams within the
   same RTP session that share the same master key.  RTP itself provides
   an algorithm for detecting SSRC collisions within the same RTP
   session.  Thus, temporary collisions could lead to temporary two-time
   pad, in the unfortunate event that SSRCs collide at a point in time
   when the streams also have identical sequence numbers (occurring with
   probability roughly 2^(-48)).  Therefore, the key management SHOULD
   take care of avoiding such SSRC collisions by including the SSRCs to
   be used in the session as negotiation parameters, proactively
   assuring their uniqueness.  This is a strong requirements in
   scenarios where for example, there are multiple senders that can
   start to transmit simultaneously, before SSRC collision are detected
   at the RTP level.

    =

    On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.com= > wrote:

    On Jul 16, 2017, = at 16:08, Emil Ivov <emcho@jitsi.org> wrote:

    Rega= rding SSRC rewriting, there has been a consensus to not rewrite the SSRCby the MDD

    Thi= s is factually wrong.

    = We had a discussion on this was on IETF 96 (Berlin) where I was asked
    to describe how this works in = a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    was left open.

    <= blockquote type=3D"cite" style=3D"font-family:Menlo-Regular;font-size:11px;= font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacin= g:normal;text-align:start;text-indent:0px;text-transform:none;white-space:n= ormal;word-spacing:0px">due to the security implications/attacks as discuss= ed in the
    earlier design meetings/virtual interims and IETF meetings (Se= e
    https://www.ietf.org/mail-archive/web/perc/cu= rrent/msg00231.html)

    Please refer to
    = https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf=C2=A0for more
    information as the starting point on the v= arious attacks. Please submit a
    draft to the mailing list for discussion= s that addresses the security
    concerns or invalidates them with an appro= priate security analysis

    All of this was discussed subsequently. While there is a lot of h= and
    waving about a possib= le SSRC splicing attack, to this date I am not
    aware of an actual description of how this thing coul= d work.


    So here is the attack= I=E2=80=99m concerned about:

    We have an MD which is allowed= to rewrite SSRC (even with including the original into the OHB).
    No= w an endpoint in a conference receives a RTP packet from that MD where the = re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint itself= is using for sending.
    The endpoint needs to change it's SSRC to= avoid the collision. So the endpoint chooses another SSRC B for sending.
    And the MD happens to choose another SSRC B as its re-written SSRC.
    So endpoint changes the SSRC again to C.
    Which then happens to= be the same as the SSRC used by another endpoint in the conference.=
    Now the MD receives two incoming RTP streams with identical SSRCs from two= different endpoints and can choose to recombine the RTP headers from clien= t #1 with the payload from client #2.

    I think = this attack plus it=E2=80=99s possible mitigations need to be described in = the draft=C2=A0draft-grozev-perc-ssrc-00.

    Bes= t regards
    =C2=A0 Nils Ohlmeier

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




    --001a114158644bd073055477b9fb-- From nobody Sun Jul 16 16:38:42 2017 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 C2E37129AA8 for ; Sun, 16 Jul 2017 16:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 IfJH0f8UXuj5 for ; Sun, 16 Jul 2017 16:38:36 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 53B291200C1 for ; Sun, 16 Jul 2017 16:38:36 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id b64so7765418uab.0 for ; Sun, 16 Jul 2017 16:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5NyWygSFFvvtQI/U0fCIXtoRTOIjI/ZAe9t6vGOJH88=; b=VHTOTvqi8H4QGoTbbLn7PtYjPJ6BT+wPLwX1+ynpyWZoRka6UpV7PGDJL+4cSG2yvs WEv57r7GMWmMb03ZOyXl2aJY9FokBrxkioPK36F5sl/V2xLDsGzVBMzFkA/p4n/jqdL7 XS5WL50w5/KkMLEk06C3Ax6XuSiYKAMgm1HYvQGqjavUWZNHoPfvYRRnrOQxsXE/G6Yt Pq+bJ27JK93okXt/AqB0T+nVqJrJSaT1iJdmJnTNttRbEoW7NxEyEsgGjAhQ4yX2yg0U ZCVZ3SyHRnLAskR1ET2Xroelimoydyr7r5SMZplHapOu52Y1Gz47RrXIodTPyWCj3Ajb HuBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5NyWygSFFvvtQI/U0fCIXtoRTOIjI/ZAe9t6vGOJH88=; b=AwxY4PYHu6GfXyo3I/F6ZKKuct1IPxNHXoIMQc4jCAsf0vA2+Lx9ymZ//1aMLaWsBj EFGIgfSV3B3fa8Yv07nX8TNP9D1RWv9HUDrbXpLPMmCikBBC/rWCI2KUtNP9KNHqHerq ukyI75vQfELLZL4RsmmZbvq3aOlOex61FheZOpoPi3lpFcO/BUvEyK7BOYRdj0r0fUZ6 dAaSqXtUGHmwMPmGVm9eX9aJqeAVYp16RyyYPEEOyInsbUuRJhZ48Y5a1uLwNTsoAV/j mz341rE790DqAfn351QmdvulF9miVbRJWDa6hZVEJVT/GcfAGeBCSvEn/EXmxtYwIJ9u C44A== X-Gm-Message-State: AIVw110VsgoXi9yAHYOm9taJ8voxYx5BJRXMlryaXdwsOQECQ9qBNtvt Alea0fvRxJKwLzEmVVS9nSPXCfPwaQ== X-Received: by 10.31.115.206 with SMTP id o197mr10788403vkc.27.1500248315230; Sun, 16 Jul 2017 16:38:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.80 with HTTP; Sun, 16 Jul 2017 16:38:14 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Bernard Aboba Date: Sun, 16 Jul 2017 16:38:14 -0700 Message-ID: To: Emil Ivov Cc: Nils Ohlmeier , Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c14990ee77f23055477c7e7" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 23:38:41 -0000 --94eb2c14990ee77f23055477c7e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Emil said: "A. Specify that collision detection should be performed on the e2e ssrc and not on the hop by hop one or simply" [BA] Specifying how collision detection works in PERC is necessary, regardless of what the MDD does. I think it makes sense to detect collisions based on the e2e SSRC, but there will be tricky aspects, such as how to deal with packets that aren't e2e authenticated (e.g. RTCP). On Sun, Jul 16, 2017 at 3:47 PM, Emil Ivov wrote: > This is the first time I see someone take the pain to actually describe > the dreaded SSRC splicing on this list and for that I am very grateful. > Thanks Nils. > > As an answer though: > > At best (and after what would likely be A LOT of retries) this would allo= w > the SFU to let one participant to impersonate another. > > We already established that this is a know property of PERC that doesn't > bother us: > > https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 > > I believe Bernard was making a similar point. > > If for some reason we do absolutely want to solve this specific scenario > (but not other kinds of intra conference impersonation) then it would be > trivially easy to do so. We could: > > A. Specify that collision detection should be performed on the e2e ssrc > and not on the hop by hop one or simply > > B. Limit the number of allowed retries to, say, 3 > > > And again, I don't see why we would do either given that easier kinds of > impersonationthat dont involve the MD would remain possible. > > Would love to hear your thoughts. > > Emil > > > On Sun, 16 Jul 2017 at 16:50, Nils Ohlmeier wrote= : > >> >> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >> >> Regarding SSRC rewriting, there has been a consensus to not rewrite the >> SSRC >> by the MDD >> >> >> This is factually wrong. >> >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >> >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >> >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >> >> due to the security implications/attacks as discussed in the >> earlier design meetings/virtual interims and IETF meetings (See >> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >> >> Please refer to >> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more >> information as the starting point on the various attacks. Please submit = a >> draft to the mailing list for discussions that addresses the security >> concerns or invalidates them with an appropriate security analysis >> >> >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >> >> >> So here is the attack I=E2=80=99m concerned about: >> >> We have an MD which is allowed to rewrite SSRC (even with including the >> original into the OHB). >> Now an endpoint in a conference receives a RTP packet from that MD where >> the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint >> itself is using for sending. >> The endpoint needs to change it's SSRC to avoid the collision. So the >> endpoint chooses another SSRC B for sending. >> And the MD happens to choose another SSRC B as its re-written SSRC. >> So endpoint changes the SSRC again to C. >> Which then happens to be the same as the SSRC used by another endpoint i= n >> the conference. >> Now the MD receives two incoming RTP streams with identical SSRCs from >> two different endpoints and can choose to recombine the RTP headers from >> client #1 with the payload from client #2. >> >> I think this attack plus it=E2=80=99s possible mitigations need to be de= scribed >> in the draft draft-grozev-perc-ssrc-00. >> >> Best regards >> Nils Ohlmeier >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > -- > sent from my mobile > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --94eb2c14990ee77f23055477c7e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Emil said:=C2=A0

    "A. Specify that collision detection should be performed on= the e2e ssrc and not on the hop by hop one or simply"

    [BA] Specifying how collision detection works in PERC is n= ecessary, regardless of what the MDD does.=C2=A0 I think it makes sense to = detect collisions based on the e2e SSRC, but there will be tricky aspects, = such as how to deal with packets that aren't e2e authenticated (e.g. RT= CP).=C2=A0

    On Sun, Jul 16, 2017 at 3:47 PM, Emil Ivov <emcho@jitsi.org> wrote:
    This is= the first time I see someone take the pain to actually describe the dreade= d SSRC splicing on this list and for that I am very grateful. Thanks Nils.<= /div>

    As an answer though:

    At best (and after what wou= ld likely be A LOT of retries) this would allow the SFU to let one particip= ant to impersonate another.=C2=A0

    We already established that this is a know property of PERC that = doesn't bother us:

    <= a href=3D"https://tools.ietf.org/html/draft-grozev-perc-ssrc-00" target=3D"= _blank">https://tools.ietf.org/html/draft-grozev-perc-ssrc-00
    <= /div>

    I believe Bernard was ma= king a similar point.

    If= for some reason we do absolutely want to solve this specific scenario (but= not other kinds of intra conference impersonation) then it would be trivia= lly easy to do so. We could:

    A. Specify that collision detection should be performed on the e2e ssr= c and not on the hop by hop one or simply

    =
    B. Limit the number of allowed retries to, say, 3=C2=A0


    And again, I don't see why we would do either given that easier kind= s of impersonationthat dont involve the MD would remain possible.

    Would love to hear your thoughts.=

    Emil


    =
    On Sun, 16 Jul 2017 at 16:50, Nils Ohlmeier <nohlmeier@mozilla.co= m> wrote:
    <= div class=3D"h5">

    On Jul 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> wrote:

    Regarding SSRC rewriting, there has been a c= onsensus to not rewrite the SSRC
    by the MDD

    This is factually wrong.

    We had a discussion on this was on IETF = 96 (Berlin) where I was asked
    to describe how this works in a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. = No decision was reached the topic
    was left open.

    due to the sec= urity implications/attacks as discussed in the
    earlier design meetings/v= irtual interims and IETF meetings (See
    https://www.i= etf.org/mail-archive/web/perc/current/msg00231.html)

    P= lease refer to
    https://www.ietf.org/proceedings/= 94/slides/slides-94-perc-5.pdf=C2=A0for more
    infor= mation as the starting point on the various attacks. Please submit a
    dra= ft to the mailing list for discussions that addresses the security
    conce= rns or invalidates them with an appropriate security analysis

    All of this was discussed su= bsequently. While there is a lot of hand
    waving about a possible SSRC splicing attack, to this date = I am not
    aware of an actu= al description of how this thing could work.


    So here is the attack I=E2=80=99m concerned about:

    We have an MD which is allowed to rewrite SSRC (even with including = the original into the OHB).
    Now an endpoint in a conference receives= a RTP packet from that MD where the re-written SSRC (outer SSRC) matches e= xactly the SSRC A the endpoint itself is using for sending.
    The endp= oint needs to change it's SSRC to avoid the collision. So the endpoint = chooses another SSRC B for sending.
    And the MD happens to choose ano= ther SSRC B as its re-written SSRC.
    So endpoint changes the SSRC aga= in to C.
    Which then happens to be the same as the SSRC used by anoth= er endpoint in the conference.
    Now the MD receives two incoming RTP = streams with identical SSRCs from two different endpoints and can choose to= recombine the RTP headers from client #1 with the payload from client #2.<= /span>

    I think this attack plus it=E2=80=99s possible= mitigations need to be described in the draft=C2=A0draft-grozev-perc-ssrc-= 00.

    Best regards
    =C2=A0 Nils Ohlmei= er

    _________________= ______________________________
    Perc mailing list
    Perc@ietf.org
    https://www.ietf.org/mailman/listinfo/perc
    --
    s= ent from my mobile

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


    --94eb2c14990ee77f23055477c7e7-- From nobody Mon Jul 17 01:08:38 2017 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 2237B1317A1 for ; Mon, 17 Jul 2017 01:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9DqxSpAU2y6J for ; Mon, 17 Jul 2017 01:08:35 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247AC13179D for ; Mon, 17 Jul 2017 01:08:35 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 21so24847271qtx.3 for ; Mon, 17 Jul 2017 01:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WZS5D3Ej03I6q+rHZuBplMSdbi94CwZXKLId1Hz6Ryw=; b=XfSbJFluOJI7E+4Xyatn+MkBPm84jG5mlhOULZTtOVisTegSSD7zngeD62bjC0n6Mp UvzjAxRnxQGlV2PBkxc8aqpQNUaGpxVP6JEIawDp/jLsfz8cATc4FVpVZUjRMInb858a swbAZewY5o1C7P5UTi3C2SANjTDVnMggCWwBJYAqDvFZiBHOjN9VJZt0Clw9JhVLJl/b WA6Rky1sn0iJfnViTlpdW62KlRcSHaNl8osM0VkGYdfcJZeZczxWyqn2CY2Ws412pdF+ UH0KqDxjSNk4SyUhiMfBI4CfY21UsV8ydpvK09Gf9XVjWEiQzqg5mOqzG8Je002YvxS6 WpxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WZS5D3Ej03I6q+rHZuBplMSdbi94CwZXKLId1Hz6Ryw=; b=stDmivk8Dij83y95tV19JvidLQxqB5WdgySZe6akZYNEeNiR/NX29HuPKoPgZyB1J8 rvPtQgywvff+g/JJodYng73Hpurht3kJ3NsArx8egesB7imOJPlp+kixkYkmOyGfxfFh Y61ThER8njqLy5Ag3cNigBg2TQxps6IE1PaaYDlOyf3hKJI4pXe/NxbAPLhzwvIpp10n r3VZGr9VkVbgKSriBhD8ZUwaI5lGTiMYOrkhQyOl1UZPzvr5mL1MQiwTGQVjrdhY99/k r3872IETaZw4ZS4syQ+ZZMKfUXKqJeQn7dLWcKbDjaaTEzewZnEyKbjOeQ6FNWF9QT/5 7aeA== X-Gm-Message-State: AIVw111xj3M36l3Xa5h9AZKzowl9yW/c9I6WaahTk+aSWDKW848Bs+Ww 7hLh0aEuD9OrXoCW26QJtpVPuykeNA== X-Received: by 10.237.46.99 with SMTP id j90mr27940160qtd.76.1500278914226; Mon, 17 Jul 2017 01:08:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.6 with HTTP; Mon, 17 Jul 2017 01:08:33 -0700 (PDT) In-Reply-To: <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Suhas Nandakumar Date: Mon, 17 Jul 2017 01:08:33 -0700 Message-ID: To: Nils Ohlmeier Cc: Emil Ivov , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c060094bf1d9405547ee7ec" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:08:37 -0000 --94eb2c060094bf1d9405547ee7ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier wrote: > > On Jul 16, 2017, at 16:08, Emil Ivov wrote: > > Regarding SSRC rewriting, there has been a consensus to not rewrite the > SSRC > by the MDD > > > This is factually wrong. > > We had a discussion on this was on IETF 96 (Berlin) where I was asked > to describe how this works in a draft, which we did: > > https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 > > We then talked about it in Chicago. No decision was reached the topic > was left open. > > due to the security implications/attacks as discussed in the > earlier design meetings/virtual interims and IETF meetings (See > https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) > > Please refer to > https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more > information as the starting point on the various attacks. Please submit a > draft to the mailing list for discussions that addresses the security > concerns or invalidates them with an appropriate security analysis > > > All of this was discussed subsequently. While there is a lot of hand > waving about a possible SSRC splicing attack, to this date I am not > aware of an actual description of how this thing could work. > > > So here is the attack I=E2=80=99m concerned about: > > We have an MD which is allowed to rewrite SSRC (even with including the > original into the OHB). > Now an endpoint in a conference receives a RTP packet from that MD where > the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint > itself is using for sending. > The endpoint needs to change it's SSRC to avoid the collision. So the > endpoint chooses another SSRC B for sending. > And the MD happens to choose another SSRC B as its re-written SSRC. > So endpoint changes the SSRC again to C. > Which then happens to be the same as the SSRC used by another endpoint in > the conference. > Now the MD receives two incoming RTP streams with identical SSRCs from tw= o > different endpoints and can choose to recombine the RTP headers from clie= nt > #1 with the payload from client #2. > > I think this attack plus it=E2=80=99s possible mitigations need to be des= cribed in > the draft draft-grozev-perc-ssrc-00. > > IIRC correctly from the presentation that Jan Mattson gave on these attacks, the cause for splicing attack happens when the MDD hides the fact that collision has happened and rewrites the SSRC. So if MDD sees a collision from endpoint B to be using same SSRC as endpoint A, it hides that fact and rewrites the SSRC. This causes the endpoints not to be aware of SSRC collisions and can end up in a state where multiple endpoints having the same SSRCs. Now, at a right point it time (combining with the delay attack and storing the packets for appropriate time), the MDD can splice the stream from A to B and send it to whomever it wants. The one approach to mitigate this was to allow a topology where the rewriting was not allowed. If rewriting is allowed, then there needs to be a clearly defined mitigation procedures on handling/disallowing the above to happen Cheers Suhas (as individual) > Best regards > Nils Ohlmeier > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --94eb2c060094bf1d9405547ee7ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.= com> wrote:

    On Jul 16, 201= 7, at 16:08, Emil Ivov <emcho@jitsi.org> wrote:

    R= egarding SSRC rewriting, there has been a consensus to not rewrite the SSRC=
    by the MDD

    = This is factually wrong.

    We had a discussion on this was on IETF 96 (Berlin) where I was asked
    to describe how this works = in a draft, which we did:

    https://tools.ietf.org/html/<= wbr>draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. No decision was reached the topic<= /span>
    was left open.
    <= br style=3D"font-family:Menlo-Regular;font-size:11px;font-style:normal;font= -variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:st= art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px= ">
    due to the security implications/attacks as disc= ussed in the
    earlier design meetings/virtual interims and IETF meetings = (See
    https://www.ietf.org/mail-archive/web/perc= /current/msg00231.html)

    Please refer to
    https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pd= f=C2=A0for more
    information as the starting point on the various attacks. Ple= ase submit a
    draft to the mailing list for discussions that addresses th= e security
    concerns or invalidates them with an appropriate security ana= lysis

    All of th= is was discussed subsequently. While there is a lot of hand
    waving about a possible SSRC splicing at= tack, to this date I am not
    aware of an actual description of how this thing could work.

    So here is the attack I=E2=80=99m concer= ned about:

    We have an MD which is allowed to rewrite SSRC (even with including the= original into the OHB).
    Now an endpoint in a conference receives a RTP packet from that M= D where the re-written SSRC (outer SSRC) matches exactly the SSRC A the end= point itself is using for sending.
    The endpoint needs to change it's SSRC to avoid the= collision. So the endpoint chooses another SSRC B for sending.
    And the MD happens to choo= se another SSRC B as its re-written SSRC.
    So endpoint changes the SSRC again to C.<= /div>
    Which then happens to = be the same as the SSRC used by another endpoint in the conference.<= /div>
    Now the MD receives tw= o incoming RTP streams with identical SSRCs from two different endpoints an= d can choose to recombine the RTP headers from client #1 with the payload f= rom client #2.
    =
    I think this attack plus it=E2=80=99s possible mitiga= tions need to be described in the draft=C2=A0draft-grozev-perc-ssrc-00= .


    IIRC correctly= from the presentation that Jan Mattson gave on these attacks, the cause fo= r splicing attack happens =C2=A0when the MDD hides the fact that collision = has happened and rewrites the SSRC.=C2=A0
    So if MDD sees a collis= ion from endpoint B to be using same SSRC as endpoint A, it hides that fact= and rewrites the SSRC. This causes the endpoints not to be aware of SSRC c= ollisions and can end up in a state where multiple endpoints having the sam= e SSRCs.=C2=A0 Now, at a right point it time (combining with the delay atta= ck and storing the packets for appropriate time), the MDD can =C2=A0splice = the stream from A to B and send it to whomever it wants.=C2=A0
    The one approach to mitigate this was to allow a topology wher= e the rewriting was not allowed. If rewriting is allowed, then there needs = to be a clearly defined mitigation procedures on handling/disallowing the a= bove to happen

    Cheers
    Suhas (as individu= al)
    =C2=A0
    Best regards
    =
    =C2=A0 Nils Ohlmeier


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


    --94eb2c060094bf1d9405547ee7ec-- From nobody Mon Jul 17 01:27:14 2017 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 6FCA4131A88 for ; Mon, 17 Jul 2017 01:27:13 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 rgc2L972Z-7I for ; Mon, 17 Jul 2017 01:27:11 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d: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 F1498131AD7 for ; Mon, 17 Jul 2017 01:27:06 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d136so1883235qkg.3 for ; Mon, 17 Jul 2017 01:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DiVeN0z3vBtn9dx8S11S7glT0uX/YwCYNOjcBxhSQr0=; b=p1VWK6+Y2HX3vfODyaItr2cpbN3lOSO3So39dBj49hwYvxZRvALg22Aaf7PS2t2i7O nPaVqLRkUsEoHxp8DWbkzgstivR2edTyeM95Hua6Jk7drZVfEEw/2tXe/cMLiw0qjRvQ M7ixbBLXqrMAPH7nuONYHqN+QFgFAzi6HnurIu5b0GFGeRS4xtgllzIrcbJW1NCrwLht KRWvO31+wyUuJSHlnjNxmLW8+a3AMoQzBSUgbYHDEHSyzoFLazFj6TbcsD4HeEuX/enW QcUyNqlVhd9Eofl15hiSTfaC8etIh6xRhZCsbI3VaRnJtkVwSAJhNJSMRBwIJlyqqKs7 K4eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DiVeN0z3vBtn9dx8S11S7glT0uX/YwCYNOjcBxhSQr0=; b=iP1DPrNfrMnpfur+N43h6hu7whsFwaL0w+HFDUC9PjwP61JrdeTJWVM2IScoKqY+8p SMEn50lqigGo92fk38azpc1r6Xehho62xwUjdTgCccqLC2LhwFP5KZMrI0VXI/EoK5Qv 8FXMFSAUVM4A/gAiCZ/pge6SelwEiwjb3mSp9zbD5+CwkJV6DDPnsb2N65p76AC2vABl NZNFrjvby9U404VY6hcWQpKI2Dgc5aO+jHTX2OdgVbrlXqhLYVfyJ84AVw5I2pXTPsnZ h6l8g9GXnPH/ee9T0FoC2VOrrH7B+hiBbpcTYkhrt7wpBTQ/rQwwn4NAGh+q6aGWciHJ GjNw== X-Gm-Message-State: AIVw112HnA/6R9IqhVsx4jJSElVHxEPnHu+aRC+VqLi1LH+U9WUWuBCL vBQHi2AyqlSUNqpiXtieeHSbNlqEzg== X-Received: by 10.55.97.13 with SMTP id v13mr23933161qkb.107.1500280026084; Mon, 17 Jul 2017 01:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.6 with HTTP; Mon, 17 Jul 2017 01:27:05 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Suhas Nandakumar Date: Mon, 17 Jul 2017 01:27:05 -0700 Message-ID: To: Nils Ohlmeier Cc: Emil Ivov , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05760604b99005547f2aa4" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 08:27:13 -0000 --94eb2c05760604b99005547f2aa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2017 at 1:08 AM, Suhas Nandakumar wrote: > > > On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: > >> >> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >> >> Regarding SSRC rewriting, there has been a consensus to not rewrite the >> SSRC >> by the MDD >> >> >> This is factually wrong. >> >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >> >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >> >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >> >> due to the security implications/attacks as discussed in the >> earlier design meetings/virtual interims and IETF meetings (See >> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >> >> Please refer to >> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more >> information as the starting point on the various attacks. Please submit = a >> draft to the mailing list for discussions that addresses the security >> concerns or invalidates them with an appropriate security analysis >> >> >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >> >> >> So here is the attack I=E2=80=99m concerned about: >> >> We have an MD which is allowed to rewrite SSRC (even with including the >> original into the OHB). >> Now an endpoint in a conference receives a RTP packet from that MD where >> the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint >> itself is using for sending. >> The endpoint needs to change it's SSRC to avoid the collision. So the >> endpoint chooses another SSRC B for sending. >> And the MD happens to choose another SSRC B as its re-written SSRC. >> So endpoint changes the SSRC again to C. >> Which then happens to be the same as the SSRC used by another endpoint i= n >> the conference. >> Now the MD receives two incoming RTP streams with identical SSRCs from >> two different endpoints and can choose to recombine the RTP headers from >> client #1 with the payload from client #2. >> >> I think this attack plus it=E2=80=99s possible mitigations need to be de= scribed >> in the draft draft-grozev-perc-ssrc-00. >> >> > IIRC correctly from the presentation that Jan Mattson gave on these > attacks, the cause for splicing attack happens when the MDD hides the fa= ct > that collision has happened and rewrites the SSRC. > So if MDD sees a collision from endpoint B to be using same SSRC as > endpoint A, it hides that fact and rewrites the SSRC. This causes the > endpoints not to be aware of SSRC collisions and can end up in a state > where multiple endpoints having the same SSRCs. Now, at a right point it > time (combining with the delay attack and storing the packets for > appropriate time), the MDD can splice the stream from A to B and send it > to whomever it wants. > > The one approach to mitigate this was to allow a topology where the > rewriting was not allowed. If rewriting is allowed, then there needs to b= e > a clearly defined mitigation procedures on handling/disallowing the above > to happen > > Cheers > Suhas (as individual) > again a possibility that the MDD "can induce and hides collisions" at the same time is more challenging to protect against, if I am not wrong in thinking it > >> Best regards >> Nils Ohlmeier >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> > --94eb2c05760604b99005547f2aa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Mon, Jul 17, 2017 at 1:08 AM, Suhas Nandakumar <= ;suhasietf@gmail.c= om> wrote:


    On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <= nohlmeier@mozill= a.com> wrote:

    On Jul 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> wrote:

    Regarding SSRC rewriting, there has been a c= onsensus to not rewrite the SSRC
    by the MDD

    This is factually wrong.

    We had a discussion on this was on IETF = 96 (Berlin) where I was asked
    to describe how this works in a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. = No decision was reached the topic
    was left open.

    due to the sec= urity implications/attacks as discussed in the
    earlier design meetings/v= irtual interims and IETF meetings (See
    https://www.i= etf.org/mail-archive/web/perc/current/msg00231.html)

    P= lease refer to
    https://www.ietf.org/proceedings/= 94/slides/slides-94-perc-5.pdf=C2=A0for more
    inform= ation as the starting point on the various attacks. Please submit a
    draf= t to the mailing list for discussions that addresses the security
    concer= ns or invalidates them with an appropriate security analysis

    All of this was discussed sub= sequently. While there is a lot of hand
    waving about a possible SSRC splicing attack, to this date I= am not
    aware of an actua= l description of how this thing could work.

    =

    So here is the attack I=E2=80=99m concerned about:

    We have an MD which is allowed to rewrite SSRC (even with including th= e original into the OHB).
    Now an endpoint in a conference receives a = RTP packet from that MD where the re-written SSRC (outer SSRC) matches exac= tly the SSRC A the endpoint itself is using for sending.
    <= span class=3D"m_1060072774005845031m_6283022983401134871_5yl5">The endpoint= needs to change it's SSRC to avoid the collision. So the endpoint choo= ses another SSRC B for sending.
    And the MD happens to choose another = SSRC B as its re-written SSRC.
    So endpoint changes the SSRC again to = C.
    Which then happens to be the same as the SSRC used by another endp= oint in the conference.
    Now the MD receives two incoming RTP streams = with identical SSRCs from two different endpoints and can choose to recombi= ne the RTP headers from client #1 with the payload from client #2.
    I think this attack plus it=E2=80=99s possible mitigati= ons need to be described in the draft=C2=A0draft-grozev-perc-ssrc-00.<= /div>


    IIRC= correctly from the presentation that Jan Mattson gave on these attacks, th= e cause for splicing attack happens =C2=A0when the MDD hides the fact that = collision has happened and rewrites the SSRC.=C2=A0
    So if MDD see= s a collision from endpoint B to be using same SSRC as endpoint A, it hides= that fact and rewrites the SSRC. This causes the endpoints not to be aware= of SSRC collisions and can end up in a state where multiple endpoints havi= ng the same SSRCs.=C2=A0 Now, at a right point it time (combining with the = delay attack and storing the packets for appropriate time), the MDD can =C2= =A0splice the stream from A to B and send it to whomever it wants.=C2=A0

    The one approach to mitigate this was to allow a top= ology where the rewriting was not allowed. If rewriting is allowed, then th= ere needs to be a clearly defined mitigation procedures on handling/disallo= wing the above to happen

    Cheers
    Suhas (a= s individual)


    <= /div>
    again a possibility that the MDD "can induce and hides colli= sions" at the same time is more challenging to protect against, if I a= m not wrong in thinking it=C2=A0

    =C2=A0
    Best regards
    =C2=A0 Nils = Ohlmeier


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



    --94eb2c05760604b99005547f2aa4-- From nobody Mon Jul 17 05:51:01 2017 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 BF2B0131B62 for ; Mon, 17 Jul 2017 05:50:45 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 tHulDw0dwkql for ; Mon, 17 Jul 2017 05:50:43 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3115D131B5E for ; Mon, 17 Jul 2017 05:50:39 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f67so82752212wmh.1 for ; Mon, 17 Jul 2017 05:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e11EE+2CYkbDe9FjPh3hqQKiWDgAZXvsPNTKxfDjzG0=; b=NKunzkbxuoYJ9Ozw6dwTbiDdSUoLGXHIGHA8cTF7KnPZXteSSPIhJVoxUXhrj3bmnd uNj3BVkX1WHEGZ9zHOT4EsiIfq0pWETbVy9ECvd2P5fz98rFRoRBd/exXuptmrblCID5 Ti9N7+1RhJMeV7I8n4uKHcHGyCr+ZQpaTTGVL1tNPhiu47Z3vNMr62Mq77nUzEzEDa+/ 4ZRaYiMZDHnTX/HJui/mxb4g6Lbz8bx9dvqRBJoTI0axUKOP7kZs899nWW2faLHntZU5 dsSQ5W7ztUuLY07gO1FAjR14MyqImQ2xeWDDwpCTQIXcQ3ccQ3IwBIeDk8bxaUBgQ+JD jIJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e11EE+2CYkbDe9FjPh3hqQKiWDgAZXvsPNTKxfDjzG0=; b=i04xMLZ9T4HNqQodmPYA1eX8mZqRB/RCoJ2swohpfu8+eD2xIAJzxRFKZsSbwW+2HZ K9v4ejxVZ/pwROaGUDJpeEFrOUgIK5k3SjnJJFmriEtProiDfiNrLcTxIU3SkGaDK8KF a7xxBas9qhmLMWRPKfuevRTcAwqZJ7xftS27JgYv3p5ZCKeBAH3NUuLTxhyhHh1nYrEC 97NJT0hMY4eepZon0ij1wAc/VOVB494SCB8EZMr3tug+UB+17EZ5hYPWGPOQ+bZXYTiX b1imr/Fdom+fLml9G/bgsX5vrgdQyWmo98qtJAfZBuJseXG/0EC7dayCLEFzhYKhhYF/ I7BA== X-Gm-Message-State: AIVw1110JXsXyYKlV3GnzWZu89vcOn6NPd+NqGN9z1Max+kDHHwtLT+c 5z6Smr2V2uzqyUK7JuvP4NWVaa54FTo/ X-Received: by 10.80.168.70 with SMTP id j64mr17222665edc.110.1500295837546; Mon, 17 Jul 2017 05:50:37 -0700 (PDT) MIME-Version: 1.0 References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> In-Reply-To: From: Emil Ivov Date: Mon, 17 Jul 2017 12:50:27 +0000 Message-ID: To: Nils Ohlmeier , Suhas Nandakumar Cc: perc@ietf.org Content-Type: multipart/alternative; boundary="f403045c2a34749816055482d8ef" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:50:46 -0000 --f403045c2a34749816055482d8ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar wrote: > On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: > >> >> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >> >> Regarding SSRC rewriting, there has been a consensus to not rewrite the >> SSRC >> by the MDD >> >> >> This is factually wrong. >> >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >> >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >> >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >> >> due to the security implications/attacks as discussed in the >> earlier design meetings/virtual interims and IETF meetings (See >> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >> >> Please refer to >> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more >> information as the starting point on the various attacks. Please submit = a >> draft to the mailing list for discussions that addresses the security >> concerns or invalidates them with an appropriate security analysis >> >> >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >> >> >> So here is the attack I=E2=80=99m concerned about: >> >> We have an MD which is allowed to rewrite SSRC (even with including the >> original into the OHB). >> Now an endpoint in a conference receives a RTP packet from that MD where >> the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint >> itself is using for sending. >> The endpoint needs to change it's SSRC to avoid the collision. So the >> endpoint chooses another SSRC B for sending. >> And the MD happens to choose another SSRC B as its re-written SSRC. >> So endpoint changes the SSRC again to C. >> Which then happens to be the same as the SSRC used by another endpoint i= n >> the conference. >> Now the MD receives two incoming RTP streams with identical SSRCs from >> two different endpoints and can choose to recombine the RTP headers from >> client #1 with the payload from client #2. >> >> I think this attack plus it=E2=80=99s possible mitigations need to be de= scribed >> in the draft draft-grozev-perc-ssrc-00. >> >> > IIRC correctly from the presentation that Jan Mattson gave on these > attacks, the cause for splicing attack happens when the MDD hides the fa= ct > that collision has happened and rewrites the SSRC. > So if MDD sees a collision from endpoint B to be using same SSRC as > endpoint A, it hides that fact and rewrites the SSRC. > Hides it? Could you please be a little bit more specific? Are you assuming the the original SSRC does not reach the receivers? Emil This causes the endpoints not to be aware of SSRC collisions and can end up > in a state where multiple endpoints having the same SSRCs. Now, at a rig= ht > point it time (combining with the delay attack and storing the packets fo= r > appropriate time), the MDD can splice the stream from A to B and send it > to whomever it wants. > > The one approach to mitigate this was to allow a topology where the > rewriting was not allowed. If rewriting is allowed, then there needs to b= e > a clearly defined mitigation procedures on handling/disallowing the above > to happen > > Cheers > Suhas (as individual) > > >> Best regards >> Nils Ohlmeier >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> -- sent from my mobile --f403045c2a34749816055482d8ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    On Mon, 17 Jul 2017 a= t 03:08, Suhas Nandakumar <suhasi= etf@gmail.com> wrote:
    <= div class=3D"gmail_extra">
    On Sun, Jul 16, 2017 a= t 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

    On Jul 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> wrote= :

    Regarding SSRC rewriting, there has= been a consensus to not rewrite the SSRC
    by the MDD
    = This is factually wrong.=
    We had a discussion on this was= on IETF 96 (Berlin) where I was asked
    to describe how this works in a draft, which we did:
    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00
    = We then talked about it in Chicago= . No decision was reached the topic
    was left open.

    due to the s= ecurity implications/attacks as discussed in the
    earlier design meetings= /virtual interims and IETF meetings (See
    https://www= .ietf.org/mail-archive/web/perc/current/msg00231.html)

    Please re= fer to
    https://www.ietf.org/proceedings/94/slides/sli= des-94-perc-5.pdf=C2=A0for more
    information as the star= ting point on the various attacks. Please submit a
    draft to the mailing = list for discussions that addresses the security
    concerns or invalidates= them with an appropriate security analysis

    All of this was discussed subsequently. While= there is a lot of hand
    w= aving about a possible SSRC splicing attack, to this date I am notaware of an actual description of= how this thing could work.


    S= o here is the attack I=E2=80=99m concerned about:

    = We have an= MD which is allowed to rewrite SSRC (even with including the original into= the OHB).
    Now an endpoint in a conference receives a RTP packet fro= m that MD where the re-written SSRC (outer SSRC) matches exactly the SSRC A= the endpoint itself is using for sending.
    The endpoint needs to cha= nge it's SSRC to avoid the collision. So the endpoint chooses another S= SRC B for sending.
    And the MD happens to choose another SSRC B as it= s re-written SSRC.
    So endpoint changes the SSRC again to C.
    W= hich then happens to be the same as the SSRC used by another endpoint in th= e conference.
    Now the MD receives two incoming RTP streams with iden= tical SSRCs from two different endpoints and can choose to recombine the RT= P headers from client #1 with the payload from client #2.
    =
    I think this attack plus it=E2=80=99s possible mitigations need= to be described in the draft=C2=A0draft-grozev-perc-ssrc-00.

    IIRC correctly from the pr= esentation that Jan Mattson gave on these attacks, the cause for splicing a= ttack happens =C2=A0when the MDD hides the fact that collision has happened= and rewrites the SSRC.=C2=A0
    So if MDD sees a collision from end= point B to be using same SSRC as endpoint A, it hides that fact and rewrite= s the SSRC.

    Hides it? Could you please be a little bit more specifi= c? Are you assuming the the original SSRC does not reach the receivers?

    Emil

    <= div class=3D"gmail_quote">
    This causes the endpoints not to be aware of= SSRC collisions and can end up in a state where multiple endpoints having = the same SSRCs.=C2=A0 Now, at a right point it time (combining with the del= ay attack and storing the packets for appropriate time), the MDD can =C2=A0= splice the stream from A to B and send it to whomever it wants.=C2=A0
    =

    The one approach to mitigate this was to allow a topolo= gy where the rewriting was not allowed. If rewriting is allowed, then there= needs to be a clearly defined mitigation procedures on handling/disallowin= g the above to happen

    Cheers
    Suhas (as i= ndividual)
    =C2=A0
    Best regards
    =C2=A0 Nils = Ohlmeier


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

    --
    sent from my mobile<= /div> --f403045c2a34749816055482d8ef-- From nobody Mon Jul 17 05:59:04 2017 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 94016131B5E for ; Mon, 17 Jul 2017 05:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BwT-rQADQ3G8 for ; Mon, 17 Jul 2017 05:58:55 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 2AC54131B5D for ; Mon, 17 Jul 2017 05:58:55 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id b40so105038573qtb.2 for ; Mon, 17 Jul 2017 05:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bja9hXvHS7I4xZXaWJCaNuOyc5HHOesQt6Ob7BHSC/c=; b=gJQTqEtZyXzpTnqXwjAC8RUL2wPjm0zN7aWXfbl+Qe/0D8yMVtudMd3kf42Qf/OV7j TwUIet9GBBDQwx5KvwIVrdaLqMMpfbPc7OgPrrUzdVEmOOXctgGW03YJKeeDIvcjbG4L kGxOVJBeLuo/gFXVHq488goFsGTZfl59qOlynLSWtP0YiUV92U2GaG9OjnyYDrCRhlCb yZ3/jsyeeVcW4Dwa3mmFq2FSjUE/Gq2MTrVh6R+ghYi/D+mZv2MbN0No2xj6uA9+EFa1 flDNooeAWg/qu7gczaiut9hOVv8NquMzseuzO0iEB6hfk/dbsTQlXhke1JqSqfMqYYaB 0jjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bja9hXvHS7I4xZXaWJCaNuOyc5HHOesQt6Ob7BHSC/c=; b=uQtkUMWc2a1g9K8MqgjswyYd8HLHmoV3WBnAage42oj5hnlIoItnSqdB6I20tp+MkR v43VozSWpLsnmKBIm/oIVHSn6ux8jwvIV6dv8hVW8uVzCCrR+sfNG8Nvw4w45SoOo2+N yqq9doDNwh9J43inJzGgFn3UGM8DjWt0rM/PJcMkX4vra92E3o4IrG//omXOi4KPZkBA PV3AAFEg/YIpaoYGlh+QVkN3E4LOP1kfxlTtHa8GT+yifHSd3WutgbH+/LYAPocMgtYI P968VwzfsV+9W8VwBmRTnuKzQOzbOQ1yEEM8tRFUSPHr4bggceBwT+tAfHOFfieB9g/X 4+DA== X-Gm-Message-State: AIVw1133qdCZElYxcRLMJXXzy0Gnt6pfGJJP/UhQWmF/LHcRJ2hZJHu1 PueOj0VUoYS9UbLFQyugseAf4VDuCA== X-Received: by 10.200.56.207 with SMTP id g15mr28310012qtc.79.1500296334253; Mon, 17 Jul 2017 05:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.189.6 with HTTP; Mon, 17 Jul 2017 05:58:53 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Suhas Nandakumar Date: Mon, 17 Jul 2017 05:58:53 -0700 Message-ID: To: Emil Ivov Cc: Nils Ohlmeier , perc@ietf.org Content-Type: multipart/alternative; boundary="001a1147f4660fa0e6055482f653" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:58:57 -0000 --001a1147f4660fa0e6055482f653 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov wrote: > > On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar > wrote: > >> On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier >> wrote: >> >>> >>> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >>> >>> Regarding SSRC rewriting, there has been a consensus to not rewrite the >>> SSRC >>> by the MDD >>> >>> >>> This is factually wrong. >>> >>> We had a discussion on this was on IETF 96 (Berlin) where I was asked >>> to describe how this works in a draft, which we did: >>> >>> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >>> >>> We then talked about it in Chicago. No decision was reached the topic >>> was left open. >>> >>> due to the security implications/attacks as discussed in the >>> earlier design meetings/virtual interims and IETF meetings (See >>> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >>> >>> Please refer to >>> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for mor= e >>> information as the starting point on the various attacks. Please submit= a >>> draft to the mailing list for discussions that addresses the security >>> concerns or invalidates them with an appropriate security analysis >>> >>> >>> All of this was discussed subsequently. While there is a lot of hand >>> waving about a possible SSRC splicing attack, to this date I am not >>> aware of an actual description of how this thing could work. >>> >>> >>> So here is the attack I=E2=80=99m concerned about: >>> >>> We have an MD which is allowed to rewrite SSRC (even with including the >>> original into the OHB). >>> Now an endpoint in a conference receives a RTP packet from that MD wher= e >>> the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoin= t >>> itself is using for sending. >>> The endpoint needs to change it's SSRC to avoid the collision. So the >>> endpoint chooses another SSRC B for sending. >>> And the MD happens to choose another SSRC B as its re-written SSRC. >>> So endpoint changes the SSRC again to C. >>> Which then happens to be the same as the SSRC used by another endpoint >>> in the conference. >>> Now the MD receives two incoming RTP streams with identical SSRCs from >>> two different endpoints and can choose to recombine the RTP headers fro= m >>> client #1 with the payload from client #2. >>> >>> I think this attack plus it=E2=80=99s possible mitigations need to be d= escribed >>> in the draft draft-grozev-perc-ssrc-00. >>> >>> >> IIRC correctly from the presentation that Jan Mattson gave on these >> attacks, the cause for splicing attack happens when the MDD hides the f= act >> that collision has happened and rewrites the SSRC. >> So if MDD sees a collision from endpoint B to be using same SSRC as >> endpoint A, it hides that fact and rewrites the SSRC. >> > > Hides it? Could you please be a little bit more specific? Are you assumin= g > the the original SSRC does not reach the receivers? > That's what SSRC rewriting means I presume ? > > Emil > > This causes the endpoints not to be aware of SSRC collisions and can end >> up in a state where multiple endpoints having the same SSRCs. Now, at a >> right point it time (combining with the delay attack and storing the >> packets for appropriate time), the MDD can splice the stream from A to = B >> and send it to whomever it wants. >> >> The one approach to mitigate this was to allow a topology where the >> rewriting was not allowed. If rewriting is allowed, then there needs to = be >> a clearly defined mitigation procedures on handling/disallowing the abov= e >> to happen >> >> Cheers >> Suhas (as individual) >> >> >>> Best regards >>> Nils Ohlmeier >>> >>> >>> _______________________________________________ >>> Perc mailing list >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >>> >>> -- > sent from my mobile > --001a1147f4660fa0e6055482f653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov <emcho@jitsi.org> wrote:

    On Mon, 17 Jul 2017 at 03:08,= Suhas Nandakumar <suhasietf@gmail.com> wrote:
    On Sun, Jul = 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

    <= div>
    On Jul 16, 2017, at 16:08, Emil Ivov <= ;emcho@jitsi.org&g= t; wrote:

    Regarding SSRC rewriting, t= here has been a consensus to not rewrite the SSRC
    by the MDD

    This is factually wrong.

    We had a discussion on = this was on IETF 96 (Berlin) where I was asked
    to describe how this works in a draft, which we did:<= /span>

    https://tools.ietf.org/html/draft-grozev-perc-ssrc= -00

    We then talked about = it in Chicago. No decision was reached the topic
    was left open.

    due to the security implications/attacks as discussed in the
    earlier de= sign meetings/virtual interims and IETF meetings (See
    https://www.ietf.org/mail-archive/web/perc/current/msg00231.htm= l)

    Please refer to
    https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf=C2=A0for more
    information as the starting point on the var= ious attacks. Please submit a
    draft to the mailing list for discussions = that addresses the security
    concerns or invalidates them with an appropr= iate security analysis

    All of this was discussed subsequently. While there is a lot of han= d
    waving about a possible= SSRC splicing attack, to this date I am not
    aware of an actual description of how this thing could = work.


    So here is the attack I= =E2=80=99m concerned about:

    We have an = MD which is allowed to rewrite SSRC (even with including the original into = the OHB).
    Now an endpoint in a conference recei= ves a RTP packet from that MD where the re-written SSRC (outer SSRC) matche= s exactly the SSRC A the endpoint itself is using for sending.
    =
    The endpoint needs to change it's SSRC to avoid the col= lision. So the endpoint chooses another SSRC B for sending.
    And the MD happens to choose another SSRC B as its re-written = SSRC.
    So endpoint changes the SSRC again to C.<= /span>
    Which then happens to be the same as the SSRC u= sed by another endpoint in the conference.
    Now = the MD receives two incoming RTP streams with identical SSRCs from two diff= erent endpoints and can choose to recombine the RTP headers from client #1 = with the payload from client #2.

    I think this attack plus it=E2=80=99s possible mitigations need to = be described in the draft=C2=A0draft-grozev-perc-ssrc-00.

    IIRC correctly from the pr= esentation that Jan Mattson gave on these attacks, the cause for splicing a= ttack happens =C2=A0when the MDD hides the fact that collision has happened= and rewrites the SSRC.=C2=A0
    So if MDD sees a collision from end= point B to be using same SSRC as endpoint A, it hides that fact and rewrite= s the SSRC.

    Hides it? Could you please be a little bit = more specific? Are you assuming the the original SSRC does not reach the re= ceivers?

    =C2=A0 =C2=A0Tha= t's what SSRC rewriting means I presume ?
    =C2=A0

    Emil

    This causes the endpoints not to be aware of SSRC collisio= ns and can end up in a state where multiple endpoints having the same SSRCs= .=C2=A0 Now, at a right point it time (combining with the delay attack and = storing the packets for appropriate time), the MDD can =C2=A0splice the str= eam from A to B and send it to whomever it wants.=C2=A0

    The one approach to mitigate this was to allow a topology where the r= ewriting was not allowed. If rewriting is allowed, then there needs to be a= clearly defined mitigation procedures on handling/disallowing the above to= happen

    Cheers
    Suhas (as individual)
    =C2=A0
    Best regards
    =C2=A0 N= ils Ohlmeier


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

    --
    sent from my mobile

    --001a1147f4660fa0e6055482f653-- From nobody Mon Jul 17 06:00:11 2017 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 D220E131B76 for ; Mon, 17 Jul 2017 05:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 Y5SePHwXYDnq for ; Mon, 17 Jul 2017 05:59:56 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 7F1B7131B71 for ; Mon, 17 Jul 2017 05:59:55 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id y43so465817wrd.3 for ; Mon, 17 Jul 2017 05:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DE3V5Z3VE2CmzqHKnM7p3fPFZhy4X3oB/j7QIRCbtJA=; b=Z/FlCYYbDBwLKo2c6xnD96Qkdse1fkC/7uVVz5XmhcvvIMPnNEBP+u+xMNEcT31mN/ 1vn1Gg/pEEuFz1B5UQ9HN+bk8zD+Bezr+1FNTgGrkp64ALKpCA3L2a/zUlP4Ec9pHth5 xm9hCr89BLj8fMOYH6D/bWan0QYv2gLeOKYZY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DE3V5Z3VE2CmzqHKnM7p3fPFZhy4X3oB/j7QIRCbtJA=; b=BuRAqtM7ADDtHDlW8RP4BR6nFJoeHQTmQgX830OKkJw2W1OtK4dyioG3iw/9bU7dwQ tE0ANBy4b5LXmle92EOcEpmhHCDkKV5vnLQ63j5F4KmBcpljgH3o3wcP9vfedIF8zf1l PDzP56umh6+Ad5Uo69sm6UI/7rLOAHrImJDtduTFumbEe42LY2AuMPGZu6Jmb+wGav5I 0f4Xur4VQRTxq15jGeGZ1NR33L7w5iHuaGPeONc2wn7d6IkEBv7mkKDkLAwNfahxSTD7 jMOIFx0/lvkQcSsGvtluI47BczVD/brsySybGYX0YQCuzW8xBIGYe4Vi0S2T5012LXXS pGcA== X-Gm-Message-State: AIVw111fmLxFlMclzBUlyNufyDmcOEXDWcMj2+uWbVm/mJQALvzEenoo A3mSUgosZnEgzU7T X-Received: by 10.223.150.10 with SMTP id b10mr3524878wra.85.1500296393901; Mon, 17 Jul 2017 05:59:53 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:4980:918f:b39f:6362? ([2001:67c:370:128:4980:918f:b39f:6362]) by smtp.gmail.com with ESMTPSA id y35sm18385017wrc.51.2017.07.17.05.59.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 05:59:52 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7F842F18-EA74-4AD0-A0A5-430C7B331225"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 14:59:51 +0200 In-Reply-To: Cc: Suhas Nandakumar , perc@ietf.org To: Emil Ivov References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 12:59:58 -0000 --Apple-Mail=_7F842F18-EA74-4AD0-A0A5-430C7B331225 Content-Type: multipart/alternative; boundary="Apple-Mail=_D9CAE436-8035-417E-8927-5F0B80DC36A9" --Apple-Mail=_D9CAE436-8035-417E-8927-5F0B80DC36A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 17, 2017, at 14:50, Emil Ivov wrote: >=20 >=20 > On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar > wrote: > On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: >=20 >> On Jul 16, 2017, at 16:08, Emil Ivov > wrote: >>=20 >>> Regarding SSRC rewriting, there has been a consensus to not rewrite = the SSRC >>> by the MDD >>=20 >> This is factually wrong. >>=20 >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >>=20 >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 = >>=20 >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >>=20 >>> due to the security implications/attacks as discussed in the >>> earlier design meetings/virtual interims and IETF meetings (See >>> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html = ) >>>=20 >>> Please refer to >>> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf = for = more >>> information as the starting point on the various attacks. Please = submit a >>> draft to the mailing list for discussions that addresses the = security >>> concerns or invalidates them with an appropriate security analysis >>=20 >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >>=20 >=20 > So here is the attack I=E2=80=99m concerned about: >=20 > We have an MD which is allowed to rewrite SSRC (even with including = the original into the OHB). > Now an endpoint in a conference receives a RTP packet from that MD = where the re-written SSRC (outer SSRC) matches exactly the SSRC A the = endpoint itself is using for sending. > The endpoint needs to change it's SSRC to avoid the collision. So the = endpoint chooses another SSRC B for sending. > And the MD happens to choose another SSRC B as its re-written SSRC. > So endpoint changes the SSRC again to C. > Which then happens to be the same as the SSRC used by another endpoint = in the conference. > Now the MD receives two incoming RTP streams with identical SSRCs from = two different endpoints and can choose to recombine the RTP headers from = client #1 with the payload from client #2. >=20 > I think this attack plus it=E2=80=99s possible mitigations need to be = described in the draft draft-grozev-perc-ssrc-00. >=20 >=20 > IIRC correctly from the presentation that Jan Mattson gave on these = attacks, the cause for splicing attack happens when the MDD hides the = fact that collision has happened and rewrites the SSRC. > So if MDD sees a collision from endpoint B to be using same SSRC as = endpoint A, it hides that fact and rewrites the SSRC. >=20 > Hides it? Could you please be a little bit more specific? Are you = assuming the the original SSRC does not reach the receivers? I think quite a bit of the discussion here circles around assumptions of = what kind of verifications a receiving endpoint does. For example if SSRC is permitted and done by the MDD does the receiver = need to apply SSRC collision detection only onto the re-written, outer = SSRC, only the original, inner SSRC, or on both SSRCs? My guess is that would be the safest to do all verifications on original = and re-written values. But that should be discussed in the draft. Best Nils Ohlmeier (as individual) --Apple-Mail=_D9CAE436-8035-417E-8927-5F0B80DC36A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Jul 17, 2017, at 14:50, Emil Ivov <emcho@jitsi.org> = wrote:


    On Mon, 17 Jul 2017 at 03:08, Suhas = Nandakumar <suhasietf@gmail.com> wrote:
    On Sun, = Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

    On Jul 16, 2017, at 16:08, Emil = Ivov <emcho@jitsi.org> wrote:

    Regarding SSRC rewriting, there has been a consensus to not = rewrite the SSRC
    by the MDD

    This is factually wrong.

    We had a discussion on this was on IETF 96 = (Berlin) where I was asked
    to= describe how this works in a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. No decision = was reached the topic
    was left open.

    due to the security = implications/attacks as discussed in the
    earlier design = meetings/virtual interims and IETF meetings (See
    https://www.ietf.org/mail-archive/web/perc/current/msg00231.htm= l)

    Please refer to
    https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf=  for more
    information as the starting point = on the various attacks. Please submit a
    draft to the = mailing list for discussions that addresses the security
    concerns or invalidates them with an appropriate security = analysis

    All of this was discussed subsequently. While there is a lot = of hand
    waving about a possible = SSRC splicing attack, to this date I am not
    aware of an actual description of how this thing = could work.


    So = here is the attack I=E2=80=99m concerned about:

    We have an MD = which is allowed to rewrite SSRC (even with including the original into = the OHB).
    Now an = endpoint in a conference receives a RTP packet from that MD where the = re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint = itself is using for sending.
    The endpoint = needs to change it's SSRC to avoid the collision. So the endpoint = chooses another SSRC B for sending.
    And the MD = happens to choose another SSRC B as its re-written = SSRC.
    So endpoint = changes the SSRC again to C.
    Which then = happens to be the same as the SSRC used by another endpoint in the = conference.
    Now the MD = receives two incoming RTP streams with identical SSRCs from two = different endpoints and can choose to recombine the RTP headers from = client #1 with the payload from client #2.

    I think this attack plus it=E2=80=99= s possible mitigations need to be described in the = draft draft-grozev-perc-ssrc-00.


    IIRC = correctly from the presentation that Jan Mattson gave on these attacks, = the cause for splicing attack happens  when the MDD hides the fact = that collision has happened and rewrites the SSRC. 
    So if MDD sees a collision from endpoint B to be using same = SSRC as endpoint A, it hides that fact and rewrites the = SSRC.
    Hides it? Could you = please be a little bit more specific? Are you assuming the the original = SSRC does not reach the = receivers?

    I= think quite a bit of the discussion here circles around assumptions of = what kind of verifications a receiving endpoint does.

    For example if SSRC is permitted and done by the = MDD does the receiver need to apply SSRC collision detection only onto = the re-written, outer SSRC, only the original, inner SSRC, or on both = SSRCs?

    My guess is that would be the = safest to do all verifications on original and re-written values. But = that should be discussed in the draft.

    Best
      Nils Ohlmeier (as = individual)



    = --Apple-Mail=_D9CAE436-8035-417E-8927-5F0B80DC36A9-- --Apple-Mail=_7F842F18-EA74-4AD0-A0A5-430C7B331225 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZbLTIAAoJEJ3NnGfOORkkPN0P/09gyxr98a8U2/ZKE3oh+XAl u0ZnLO4RUPOB7HIbyhjUdbfeZLlSuTlTRs1q0GxzXhTzYeWVN23GM7uHpg0/kgfB OQqMICtKPWwJ+Fw3r55UrGncOJmPSABvdohAw84yDdo6GstoDLLcvwOBuRKprkWv HHy27n4F8jukH4V5a7oAMPrwX0D6Q6ovXq6JwGLoX0F3h/rk3fDq7mRCdUdj611Y immypnoAZoxbXRA2wMMuPNTq2QJE/SAhHLsoN/J9nZZC51+oI6Hqdk8y+oOdKDfj fQGqTDUJj+lWrplp1S9i2BQ62WeuuyjbHExvYljpc8EkAjn5VIc89xV15x4OmtWd HJahWwLCF9R212KL8cerdxnCN4iGRSeLNAw+8jazUYPcnTB/NhXH7oiS3DOK/EEA hBz5pPPN8LEXcJQWRcy8//IJ1Hr1Oo0AeRE0Ob3hMba1LQ2o9ionXCLU1r6eiOSV 9ZjHYtCq6R+HbqKVNAllatCHpGDySDlcYZGstr2Z+lAZzCA951GW8T+8cL543gp8 l3GMH/1upxIelfrQSLTR3hWxnBVSxg3E1Q3lK0h0HgrDVAb4seb1hLz7N50pXHNj nCybmgZ/RLoIYVd+irjZ+nMpJXzisNDs1YL+FQxNi3QxN+vMWhJilLJR365lE/wI EfmysOUSHpR8hgCjB+5m =WnrH -----END PGP SIGNATURE----- --Apple-Mail=_7F842F18-EA74-4AD0-A0A5-430C7B331225-- From nobody Mon Jul 17 06:01:24 2017 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 AE0BA131B5E for ; Mon, 17 Jul 2017 06:01:22 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 uuA4m9h2Tneo for ; Mon, 17 Jul 2017 06:01:11 -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 25AB7131B71 for ; Mon, 17 Jul 2017 06:01:11 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t70so14718868wmt.1 for ; Mon, 17 Jul 2017 06:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=od3lacp+T1zkIFjvp4natmkc5g857XB3HTvi1qLw1ps=; b=cuGi58gSSZWhFfY0r6agwSmt39QdNcezP+ojfE7CLoChD1eZqQ2qJ6gaWEK+3YNJbH lQHepBWmokDK6e22ZNVaG6OVsb3sfiu4ffzppHJlZzEYPc257TGJrf4HSeUjLpN5aLNU 1rK4E7klnB4MzVKiYm9UZZzBAaVvqflc/QTO+6RgM/JICBP0t/6/1Ue708ccpbTDTug8 w2T354C+NLNYlm6m7bp2g3pUjl1cYgX4Dbni2fYau1+TkX7jWP12uSz+CxLHOCyuiKue Xb8AEKATaJjEexjdAL4YjpXt8keEKGFN7vzQB9oCMPwKfHZISrmFzDxvQvYfLM2RTbsu X/IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=od3lacp+T1zkIFjvp4natmkc5g857XB3HTvi1qLw1ps=; b=qp7YQlZgZxn0NZkVXPcXHN6iGfYQhCEMWKAMeJx7bDWqhUlrviOl8Dn4KjZzpA+wQg KiqJnhN1RAUFlcGeVj81jS53/JuQteShvIRnuqdXMqltPDlyHtkUlY6PP+zFxhVV1O6U x4eT6L3sQsF+9KvFtaTwjMiYj9SeFwo0hVSropripq08LHpKTd2pw6mTYXUZ+QK1vsI7 mPzadSVrGTplQQ0fpKYmO5o0Npxtn71Wyh6kmb3+8G4fkxUghVlouKhszQkyqdvMoND1 uVqoXxyrd2n0KOL/87WcisiveUTULKYKBho39Xn8pObxvzFW7WeIeDuqQ+FEEnf9pk1l qG3w== X-Gm-Message-State: AIVw1103aSnt6fGloOAiDwpCRGkROKC5hrapMKhwKY7kVeJjNSptBMEY NG3H92LPVEFsS0B/K/DAMtcZd7z2asXzfsk= X-Received: by 10.80.180.207 with SMTP id x15mr17536258edd.117.1500296469684; Mon, 17 Jul 2017 06:01:09 -0700 (PDT) MIME-Version: 1.0 References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> In-Reply-To: From: Emil Ivov Date: Mon, 17 Jul 2017 13:00:59 +0000 Message-ID: To: Suhas Nandakumar Cc: Nils Ohlmeier , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0dfd00223b54055482fee5" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:01:23 -0000 --94eb2c0dfd00223b54055482fee5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar wrote: > On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov wrote: > >> >> On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar >> wrote: >> >>> On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier >>> wrote: >>> >>>> >>>> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >>>> >>>> Regarding SSRC rewriting, there has been a consensus to not rewrite th= e >>>> SSRC >>>> by the MDD >>>> >>>> >>>> This is factually wrong. >>>> >>>> We had a discussion on this was on IETF 96 (Berlin) where I was asked >>>> to describe how this works in a draft, which we did: >>>> >>>> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >>>> >>>> We then talked about it in Chicago. No decision was reached the topic >>>> was left open. >>>> >>>> due to the security implications/attacks as discussed in the >>>> earlier design meetings/virtual interims and IETF meetings (See >>>> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >>>> >>>> Please refer to >>>> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for >>>> more >>>> information as the starting point on the various attacks. Please submi= t >>>> a >>>> draft to the mailing list for discussions that addresses the security >>>> concerns or invalidates them with an appropriate security analysis >>>> >>>> >>>> All of this was discussed subsequently. While there is a lot of hand >>>> waving about a possible SSRC splicing attack, to this date I am not >>>> aware of an actual description of how this thing could work. >>>> >>>> >>>> So here is the attack I=E2=80=99m concerned about: >>>> >>>> We have an MD which is allowed to rewrite SSRC (even with including th= e >>>> original into the OHB). >>>> Now an endpoint in a conference receives a RTP packet from that MD >>>> where the re-written SSRC (outer SSRC) matches exactly the SSRC A the >>>> endpoint itself is using for sending. >>>> The endpoint needs to change it's SSRC to avoid the collision. So the >>>> endpoint chooses another SSRC B for sending. >>>> And the MD happens to choose another SSRC B as its re-written SSRC. >>>> So endpoint changes the SSRC again to C. >>>> Which then happens to be the same as the SSRC used by another endpoint >>>> in the conference. >>>> Now the MD receives two incoming RTP streams with identical SSRCs from >>>> two different endpoints and can choose to recombine the RTP headers fr= om >>>> client #1 with the payload from client #2. >>>> >>>> I think this attack plus it=E2=80=99s possible mitigations need to be = described >>>> in the draft draft-grozev-perc-ssrc-00. >>>> >>>> >>> IIRC correctly from the presentation that Jan Mattson gave on these >>> attacks, the cause for splicing attack happens when the MDD hides the = fact >>> that collision has happened and rewrites the SSRC. >>> So if MDD sees a collision from endpoint B to be using same SSRC as >>> endpoint A, it hides that fact and rewrites the SSRC. >>> >> >> Hides it? Could you please be a little bit more specific? Are you >> assuming the the original SSRC does not reach the receivers? >> > > That's what SSRC rewriting means I presume ? > The one solution that was discussed in Berlin and then in Chicago includes preservation of the original SSRC in the OHB: https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 Emil > >> >> Emil >> >> This causes the endpoints not to be aware of SSRC collisions and can end >>> up in a state where multiple endpoints having the same SSRCs. Now, at = a >>> right point it time (combining with the delay attack and storing the >>> packets for appropriate time), the MDD can splice the stream from A to= B >>> and send it to whomever it wants. >>> >>> The one approach to mitigate this was to allow a topology where the >>> rewriting was not allowed. If rewriting is allowed, then there needs to= be >>> a clearly defined mitigation procedures on handling/disallowing the abo= ve >>> to happen >>> >>> Cheers >>> Suhas (as individual) >>> >>> >>>> Best regards >>>> Nils Ohlmeier >>>> >>>> >>>> _______________________________________________ >>>> Perc mailing list >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>>> -- >> sent from my mobile >> > -- sent from my mobile --94eb2c0dfd00223b54055482fee5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    On Mon, 17 Jul 2017 a= t 07:58, Suhas Nandakumar <suhasi= etf@gmail.com> wrote:
    <= div class=3D"gmail_extra">
    On Mon, Jul 17, 2017 a= t 5:50 AM, Emil Ivov <emcho@jitsi.org> wrote:

    On Mon, 17 Jul 2017 at 03:08, Suhas Nandakuma= r <suhasietf@gm= ail.com> wrote:
    On Sun, Jul 16, 2017 at 2:50= PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

    On Jul 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> wrote:
    <= div>
    Regarding SSRC rewriting, there has been a = consensus to not rewrite the SSRC
    by the MDD

    This is factually wrong.

    We had a discussion on this was on IE= TF 96 (Berlin) where I was asked
    to describe how this works in a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. No d= ecision was reached the topic
    was left open.

    due to the securit= y implications/attacks as discussed in the
    earlier design meetings/virtu= al interims and IETF meetings (See
    https://www.ietf.= org/mail-archive/web/perc/current/msg00231.html)

    Please refer to=
    https://www.ietf.org/proceedings/94/slides/slides-94= -perc-5.pdf=C2=A0for more
    information as the starting point on the various attacks. Ple= ase submit a
    draft to the mailing list for discussions that addresses th= e security
    concerns or invalidates them with an appropriate security ana= lysis

    All of th= is was discussed subsequently. While there is a lot of hand
    waving about a possible SSRC splicing at= tack, to this date I am not
    aware of an actual description of how this thing could work.

    So here is the attack I=E2=80=99m concer= ned about:

    We hav= e an MD which is allowed to rewrite SSRC (even with including the original = into the OHB).
    Now an end= point in a conference receives a RTP packet from that MD where the re-writt= en SSRC (outer SSRC) matches exactly the SSRC A the endpoint itself is usin= g for sending.
    The endpoi= nt needs to change it's SSRC to avoid the collision. So the endpoint ch= ooses another SSRC B for sending.
    And the MD happens to choose another SSRC B as its re-written SSRC= .
    So endpoint changes the= SSRC again to C.
    Which t= hen happens to be the same as the SSRC used by another endpoint in the conf= erence.
    Now the MD receiv= es two incoming RTP streams with identical SSRCs from two different endpoin= ts and can choose to recombine the RTP headers from client #1 with the payl= oad from client #2.

    <= /span>
    I think this attack plus it=E2=80=99s possible mitigations= need to be described in the draft=C2=A0draft-grozev-perc-ssrc-00.


    IIRC correctly from th= e presentation that Jan Mattson gave on these attacks, the cause for splici= ng attack happens =C2=A0when the MDD hides the fact that collision has happ= ened and rewrites the SSRC.=C2=A0
    So if MDD sees a collision from= endpoint B to be using same SSRC as endpoint A, it hides that fact and rew= rites the SSRC.

    =
    Hides it? Could you please be a little = bit more specific? Are you assuming the the original SSRC does not reach th= e receivers?

    =C2=A0 =C2= =A0That's what SSRC rewriting means I presume ?
    =

    The one solution= that was discussed in Berlin and then in Chicago includes preservation of = the original SSRC in the OHB:


    Emil

    <= div class=3D"gmail_quote">
    =C2=A0

    = Emil

    This causes the endpoints not to be aware of SSRC collisions and can end= up in a state where multiple endpoints having the same SSRCs.=C2=A0 Now, a= t a right point it time (combining with the delay attack and storing the pa= ckets for appropriate time), the MDD can =C2=A0splice the stream from A to = B and send it to whomever it wants.=C2=A0

    The one = approach to mitigate this was to allow a topology where the rewriting was n= ot allowed. If rewriting is allowed, then there needs to be a clearly defin= ed mitigation procedures on handling/disallowing the above to happen
    <= div>
    Cheers
    Suhas (as individual)
    =
    =C2= =A0
    Best regards
    =C2=A0 Nils Ohlmeier


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

    --
    sent from my mob= ile
    --
    sent from my= mobile
    --94eb2c0dfd00223b54055482fee5-- From nobody Mon Jul 17 06:02:16 2017 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 1F035131B69 for ; Mon, 17 Jul 2017 06:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 t5gHDJ4uew-f for ; Mon, 17 Jul 2017 06:02:11 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 03BCC131B5E for ; Mon, 17 Jul 2017 06:02:11 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id a10so11384559wrd.0 for ; Mon, 17 Jul 2017 06:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vz8k/0vlCVofBPbczGmS8lTnRZV/DaY4ig8qJfMXSiQ=; b=PmdFUINz6IGcctlNXEIUKiEZN2vq/HqxBFKmiOauuI5EyKgm2CwJoFnlO6SKc7fKC2 2e7rR9OhdOFHMIzOdCsVHKlRXGXAKa5j2vBWzgJMl7XkqWa0rHjB/DqG4Fgl0FvARfXc lGFw41cV/3PS4PhmauNfTjmGhe9crJDzzYgtI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vz8k/0vlCVofBPbczGmS8lTnRZV/DaY4ig8qJfMXSiQ=; b=BNtZ24KjfGsQddTfGXoFr8LwgpGnUbB4hdq/VkJ9gWUh4EWTL7fj4vbCLQAcE+MqJs RrBQmJC2+H8kOw/06lG92TU2idjSO0fAecVSJz/3sVhucHG7eVuDJWFYvKmDmHwm8rcq bvNnAhcF5DhWO1wXYdO+d5kptvhrWGMGxStDrIPYGIj1ylTT9DEQvY5h27ZR/Xyjbmlk lyHjjccXcX6DSkp8qB1TzZ+zkP0M1xKp1Mj3HuUoQpSuL05+9sb2SMW+A6iqBl1z815x Zz0KB1Zc7gB4zkJQhhk/sEJG0H0RW3MLx/2MFbjbfgb2NQmnGRLPc9iWmtRTBtb2FP3j l33A== X-Gm-Message-State: AIVw112kG2olb1aDtLYKkPzfzQxHBc3E+XFTrqm//HmWe7tCl9tQOw3E LNAefGTNECihl4c0 X-Received: by 10.223.176.247 with SMTP id j52mr13175982wra.192.1500296529454; Mon, 17 Jul 2017 06:02:09 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:4980:918f:b39f:6362? ([2001:67c:370:128:4980:918f:b39f:6362]) by smtp.gmail.com with ESMTPSA id 5sm11910030wrq.60.2017.07.17.06.02.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 06:02:08 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6E77A51D-6FB5-41CB-9D67-CCA16850918D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 17 Jul 2017 15:02:07 +0200 In-Reply-To: Cc: Suhas Nandakumar , perc@ietf.org To: Emil Ivov References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 13:02:14 -0000 --Apple-Mail=_6E77A51D-6FB5-41CB-9D67-CCA16850918D Content-Type: multipart/alternative; boundary="Apple-Mail=_07C73A15-68BB-4690-B83B-B7C57AA319A8" --Apple-Mail=_07C73A15-68BB-4690-B83B-B7C57AA319A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 17, 2017, at 15:00, Emil Ivov wrote: >=20 >=20 > On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar > wrote: > On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov > wrote: >=20 > On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar > wrote: > On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: >=20 >> On Jul 16, 2017, at 16:08, Emil Ivov > wrote: >>=20 >>> Regarding SSRC rewriting, there has been a consensus to not rewrite = the SSRC >>> by the MDD >>=20 >> This is factually wrong. >>=20 >> We had a discussion on this was on IETF 96 (Berlin) where I was asked >> to describe how this works in a draft, which we did: >>=20 >> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 = >>=20 >> We then talked about it in Chicago. No decision was reached the topic >> was left open. >>=20 >>> due to the security implications/attacks as discussed in the >>> earlier design meetings/virtual interims and IETF meetings (See >>> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html = ) >>>=20 >>> Please refer to >>> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf = for = more >>> information as the starting point on the various attacks. Please = submit a >>> draft to the mailing list for discussions that addresses the = security >>> concerns or invalidates them with an appropriate security analysis >>=20 >> All of this was discussed subsequently. While there is a lot of hand >> waving about a possible SSRC splicing attack, to this date I am not >> aware of an actual description of how this thing could work. >>=20 >=20 > So here is the attack I=E2=80=99m concerned about: >=20 > We have an MD which is allowed to rewrite SSRC (even with including = the original into the OHB). > Now an endpoint in a conference receives a RTP packet from that MD = where the re-written SSRC (outer SSRC) matches exactly the SSRC A the = endpoint itself is using for sending. > The endpoint needs to change it's SSRC to avoid the collision. So the = endpoint chooses another SSRC B for sending. > And the MD happens to choose another SSRC B as its re-written SSRC. > So endpoint changes the SSRC again to C. > Which then happens to be the same as the SSRC used by another endpoint = in the conference. > Now the MD receives two incoming RTP streams with identical SSRCs from = two different endpoints and can choose to recombine the RTP headers from = client #1 with the payload from client #2. >=20 > I think this attack plus it=E2=80=99s possible mitigations need to be = described in the draft draft-grozev-perc-ssrc-00. >=20 >=20 > IIRC correctly from the presentation that Jan Mattson gave on these = attacks, the cause for splicing attack happens when the MDD hides the = fact that collision has happened and rewrites the SSRC. > So if MDD sees a collision from endpoint B to be using same SSRC as = endpoint A, it hides that fact and rewrites the SSRC. >=20 > Hides it? Could you please be a little bit more specific? Are you = assuming the the original SSRC does not reach the receivers? >=20 > That's what SSRC rewriting means I presume ? >=20 > The one solution that was discussed in Berlin and then in Chicago = includes preservation of the original SSRC in the OHB: >=20 > https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 = >=20 But on which of these two SSRCs do you do collision detection? Nils --Apple-Mail=_07C73A15-68BB-4690-B83B-B7C57AA319A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    On Jul 17, 2017, at 15:00, Emil Ivov <emcho@jitsi.org> = wrote:


    On Mon, 17 Jul 2017 at 07:58, Suhas = Nandakumar <suhasietf@gmail.com> wrote:
    On Mon, = Jul 17, 2017 at 5:50 AM, Emil Ivov <emcho@jitsi.org> wrote:

    On Mon, = 17 Jul 2017 at 03:08, Suhas Nandakumar <suhasietf@gmail.com> wrote:
    On Sun, = Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

    On Jul 16, 2017, at 16:08, Emil = Ivov <emcho@jitsi.org> wrote:

    Regarding SSRC rewriting, there has been a consensus to not = rewrite the SSRC
    by the MDD

    This is factually wrong.

    We had a discussion on this was on IETF 96 = (Berlin) where I was asked
    to= describe how this works in a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. No decision = was reached the topic
    was left open.

    due to the security = implications/attacks as discussed in the
    earlier design = meetings/virtual interims and IETF meetings (See
    https://www.ietf.org/mail-archive/web/perc/current/msg00231.htm= l)

    Please refer to
    https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf=  for more
    information as the starting point on the various attacks. = Please submit a
    draft to the mailing list for discussions = that addresses the security
    concerns or invalidates them = with an appropriate security analysis

    All of this was discussed subsequently. While = there is a lot of hand
    waving about a possible SSRC splicing attack, to this date I = am not
    aware of an actual = description of how this thing could work.


    So here is the attack I=E2=80=99m concerned = about:

    We have an MD which is allowed to rewrite = SSRC (even with including the original into the OHB).
    Now an endpoint in a conference receives a = RTP packet from that MD where the re-written SSRC (outer SSRC) matches = exactly the SSRC A the endpoint itself is using for = sending.
    The endpoint needs to change it's SSRC to = avoid the collision. So the endpoint chooses another SSRC B for = sending.
    And the MD happens to choose another SSRC B = as its re-written SSRC.
    So endpoint changes the SSRC again to = C.
    Which then happens to be the same as the = SSRC used by another endpoint in the conference.
    Now the MD receives two incoming RTP streams = with identical SSRCs from two different endpoints and can choose to = recombine the RTP headers from client #1 with the payload from client = #2.

    I = think this attack plus it=E2=80=99s possible mitigations need to be = described in the draft draft-grozev-perc-ssrc-00.


    IIRC = correctly from the presentation that Jan Mattson gave on these attacks, = the cause for splicing attack happens  when the MDD hides the fact = that collision has happened and rewrites the SSRC. 
    So if MDD sees a collision from endpoint B to be using same = SSRC as endpoint A, it hides that fact and rewrites the = SSRC.
    Hides it? = Could you please be a little bit more specific? Are you assuming the the = original SSRC does not reach the = receivers?

      =  That's what SSRC rewriting means I presume = ?

    The one solution that was = discussed in Berlin and then in Chicago includes preservation of the = original SSRC in the OHB:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00


    But on which of these two SSRCs do you do = collision detection?

      = Nils


    = --Apple-Mail=_07C73A15-68BB-4690-B83B-B7C57AA319A8-- --Apple-Mail=_6E77A51D-6FB5-41CB-9D67-CCA16850918D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZbLVPAAoJEJ3NnGfOORkkrnoP/0kCIiK162ryHKc3xosQDXUe 3YOrDOUcV++1DS6q2l+h3TVZAI0G02k4j2yUvm5FJ3x2rMOGepSCeBn9JQDIaEqd /1DzbVONYy3H8rrxdhlqtyOHfbRI5DV40NbpsHXCRH/M9COhvslD/VRpYc73pZqW gqFfTzckrXgmHA9eFPUdQmfwj6uhHdcH6ws5Oss/bcMebXn7gLuen+Xv80xlkslT d71nr/GMizwBVCbA2XCR2Ie/Q50QemctJF90Qk39fF8fcQV6PT882KuyvAkzlZYQ yS5Wf4+9o3lgYzFah7frIO6kx85qk3f5gUzYFeSHLgp9vzQa4ZSc/QZNV0YJEv6B dAI443ZoRO4jN7rAaU2U5tP9EEjn6uOxxKabM9jBP+741SOAvAOMB9dhdDZ9aWXE hFIPKT81p4/R/OBsh8R2jSbSZ6FhQVGwU5kVzHUABb74oUXO12xl3ns4Bmly2ZKF GvP0470UepJ+YYdmfcRsuzaBCNQqLxAmgbSyZ/gHMCYZriv+c26ULxp14PskPHQD bFr/lNxZyPwrcMjmSfkGMQHXPkWM140wg1eCdYIA9io8EyyBZeJl2mABhDOcZUW3 jKwKAu44gbbBJBaYiOorDTzCHeNbFfXhd9apuXxZTE9tvDuQvnoXhICMb79BDVoQ T3C4RUcNvrL2B16jY7q1 =VstC -----END PGP SIGNATURE----- --Apple-Mail=_6E77A51D-6FB5-41CB-9D67-CCA16850918D-- From nobody Mon Jul 17 10:50:51 2017 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 7B0CB131B73 for ; Mon, 17 Jul 2017 10:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 IR21vVmV8TQx for ; Mon, 17 Jul 2017 10:50:47 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 4CA7E131C43 for ; Mon, 17 Jul 2017 10:50:47 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so57445699uax.3 for ; Mon, 17 Jul 2017 10:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OJII47sfpl/skEMC5cgTqzWyjR8dnsk8CHskqfTuslA=; b=SmQR45eDeJd75VwtPj3RXfmeZsy1FJMn8D3kUxh0zlxD65qqiD3/KndwKPbdmcoK14 UZuMUwScuo5u8lEqoTMwjOGBMDoXDto7ARH6Ik66mpiky7o+Q0K/0VyW/A6k2hLPjvJX 3fHih0+2zQiOdrRk+ywxvUW21FsWTTrJByTUgksFgRM15NfssreRBYGj2PMIAkuJISZt ciKHd9QkR2oZGQdoJ0Nv2wx7N/e1Ean29LIVV567aQpZ4lPQwTpGpBEompthR20Wv+ik vGKcUHUndxYzcnqg/6HNPj/TffsH/qHqiLa867NLkY4UKwS3DEKOS2+elys1lUvF/Y8R Wn8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OJII47sfpl/skEMC5cgTqzWyjR8dnsk8CHskqfTuslA=; b=jAn2XPvTYuHhC+Vj5rO+TvHKsK3uoTygrAR2jISFNdfyyEo86sq1pnzhgOagwF+kpG LAj12BVXsRmfbXquTcISbiYb88HVXsANH3EQ9quwR3eKZk+MO9kgfFbsS3JnEaBxcZKB m9HGyxzpd8m1nKNSrsvPqp9kLawpgno26xzmq2Z7L/d6eUbYWJFSPM7gu1PZ6ZbgmmEE 1zop72Tq0U1wg8H8DRgGYZixOBmDHPWfLoosfh2cPz7uzSzeof3mNmTBnE/Mjth8WOTI 3XBcDJqm6DzXBO0dyf+C9A0de4Qk0EMLZyTKb9ZXT/3Sl12Bp3bbWy/IXEGjbZOmPFED 09RA== X-Gm-Message-State: AIVw112Ti0mPF3lz9/vCWpPny5K2TkA8MgAakpX/jaBYgWnb9rMuPIMn uScN4H42IdiHJdpGokjjielzBEt0xg== X-Received: by 10.31.204.135 with SMTP id c129mr12923705vkg.49.1500313846044; Mon, 17 Jul 2017 10:50:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.80 with HTTP; Mon, 17 Jul 2017 10:50:25 -0700 (PDT) In-Reply-To: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> From: Bernard Aboba Date: Mon, 17 Jul 2017 10:50:25 -0700 Message-ID: To: Nils Ohlmeier Cc: Emil Ivov , Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="001a114e0056d85bec055487092b" Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 17:50:49 -0000 --001a114e0056d85bec055487092b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nils said: "But on which of these two SSRCs do you do collision detection?" [BA] Answering that question requires an understanding of the RTP topology that is being created when the MDD modifies the SSRC. PERC appears to require that all participant SSRCs need to be unique (implying that they are all within the same RTP session in an "RTP translator" topology). This would seem to imply to me that the SSRC in the OHB should be used for collision detection. If the MDD forwards RTCP packets, rather than terminating and originating them, then the collision detection algorithm will operate on the "original" SSRCs in RTP packets (contained in the OHB) as well as "original" SSRCs in RTCP packets (unmodified by the MDD). It seems to me that things get tricky if a PERC MDD attempts to terminate and originate RTCP packets. In a non-PERC scenario where the MDD modifies the SSRC in RTP packets, the MDD also typically terminates and originates RTCP packets, which causes each participant to have a distinct RTP session with the MDD. This works because the session scope in RTP and RTCP is consistent. However in PERC, it seems to me that this consistency breaks down if the MDD attempts to terminate and originate RTCP packets. For example, if a participant detects a conflict based on the SSRC in the OHB and sends an RTCP "BYE" packet, and the MDD consumes the "BYE" packet, how does it reach the other participants? Similarly, if a participant sends an RTCP SDES packet that would notify other participants of a conflict in a future SSRC contained in the OHB and the MDD consumes that packet, collision detection would be delayed. On Mon, Jul 17, 2017 at 6:02 AM, Nils Ohlmeier wrote: > > On Jul 17, 2017, at 15:00, Emil Ivov wrote: > > > On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar > wrote: > >> On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov wrote: >> >>> >>> On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar >>> wrote: >>> >>>> On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier >>>> wrote: >>>> >>>>> >>>>> On Jul 16, 2017, at 16:08, Emil Ivov wrote: >>>>> >>>>> Regarding SSRC rewriting, there has been a consensus to not rewrite >>>>> the SSRC >>>>> by the MDD >>>>> >>>>> >>>>> This is factually wrong. >>>>> >>>>> We had a discussion on this was on IETF 96 (Berlin) where I was asked >>>>> to describe how this works in a draft, which we did: >>>>> >>>>> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 >>>>> >>>>> We then talked about it in Chicago. No decision was reached the topic >>>>> was left open. >>>>> >>>>> due to the security implications/attacks as discussed in the >>>>> earlier design meetings/virtual interims and IETF meetings (See >>>>> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) >>>>> >>>>> Please refer to >>>>> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for >>>>> more >>>>> information as the starting point on the various attacks. Please >>>>> submit a >>>>> draft to the mailing list for discussions that addresses the security >>>>> concerns or invalidates them with an appropriate security analysis >>>>> >>>>> >>>>> All of this was discussed subsequently. While there is a lot of hand >>>>> waving about a possible SSRC splicing attack, to this date I am not >>>>> aware of an actual description of how this thing could work. >>>>> >>>>> >>>>> So here is the attack I=E2=80=99m concerned about: >>>>> >>>>> We have an MD which is allowed to rewrite SSRC (even with including >>>>> the original into the OHB). >>>>> Now an endpoint in a conference receives a RTP packet from that MD >>>>> where the re-written SSRC (outer SSRC) matches exactly the SSRC A the >>>>> endpoint itself is using for sending. >>>>> The endpoint needs to change it's SSRC to avoid the collision. So the >>>>> endpoint chooses another SSRC B for sending. >>>>> And the MD happens to choose another SSRC B as its re-written SSRC. >>>>> So endpoint changes the SSRC again to C. >>>>> Which then happens to be the same as the SSRC used by another endpoin= t >>>>> in the conference. >>>>> Now the MD receives two incoming RTP streams with identical SSRCs fro= m >>>>> two different endpoints and can choose to recombine the RTP headers f= rom >>>>> client #1 with the payload from client #2. >>>>> >>>>> I think this attack plus it=E2=80=99s possible mitigations need to be >>>>> described in the draft draft-grozev-perc-ssrc-00. >>>>> >>>>> >>>> IIRC correctly from the presentation that Jan Mattson gave on these >>>> attacks, the cause for splicing attack happens when the MDD hides the= fact >>>> that collision has happened and rewrites the SSRC. >>>> So if MDD sees a collision from endpoint B to be using same SSRC as >>>> endpoint A, it hides that fact and rewrites the SSRC. >>>> >>> >>> Hides it? Could you please be a little bit more specific? Are you >>> assuming the the original SSRC does not reach the receivers? >>> >> >> That's what SSRC rewriting means I presume ? >> > > The one solution that was discussed in Berlin and then in Chicago include= s > preservation of the original SSRC in the OHB: > > https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 > > > But on which of these two SSRCs do you do collision detection? > > Nils > > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --001a114e0056d85bec055487092b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Nils said:=C2=A0

    "But on which of these two SSRCs do you do collision detect= ion?"

    [BA] =C2=A0Answering that questi= on requires an understanding of the RTP topology that is being created when= the MDD modifies the SSRC.=C2=A0

    PERC appears to = require that all participant SSRCs need to be unique (implying that they ar= e all within the same RTP session in an "RTP translator" topology= ).=C2=A0

    This would seem to imply to me that the S= SRC in the OHB should be used for collision detection.=C2=A0

    =
    If the MDD forwards RTCP packets, rather than terminating and or= iginating them, then the collision detection algorithm will operate on the = "original" SSRCs in RTP packets (contained in the OHB) as well as= "original" SSRCs in RTCP packets (unmodified by the MDD).=C2=A0<= /div>

    It seems to me that things get tricky if a PERC MD= D attempts to terminate and originate RTCP packets. =C2=A0

    In a non-PERC scenario where the MDD modifies the SSRC in RTP pack= ets, the MDD also typically terminates and originates RTCP packets, which c= auses each participant to have a distinct RTP session with the MDD. This wo= rks because the session scope in RTP and RTCP is consistent.=C2=A0

    However in PERC, it seems to me that this consistency = breaks down if the MDD attempts to terminate and originate RTCP packets. Fo= r example, if a participant detects a conflict based on the SSRC in the OHB= and sends an RTCP "BYE" packet, and the MDD consumes the "B= YE" packet, how does it reach the other participants?=C2=A0 Similarly,= if a participant sends an RTCP SDES packet that would notify other partici= pants of a conflict in a future SSRC contained in the OHB and the MDD consu= mes that packet, collision detection would be delayed.

    =




    On Mon, Jul 17, 2017 at 6:02 AM, Nils Ohl= meier <nohlmeier@mozilla.com> wrote:
    <= br>
    On Jul 17, 2017, at 15:00, Emil Ivov= <emcho@jitsi.org> wrote:

    On Mon, Jul 17, 2017 at 5:50 AM= , Emil Ivov=C2= =A0<em= cho@jitsi.org>=C2=A0wrote:

    On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar <<= a href=3D"mailto:suhasietf@gmail.com" target=3D"_blank">suhasietf@gmail.com= > wrote:
    <= div class=3D"gmail_quote">On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier=C2=A0= <nohlmeier@mo= zilla.com>=C2=A0wrote:

    On Jul 16, 2017, at= 16:08, Emil Ivov <= emcho@jitsi.org> wrote:

    Regard= ing SSRC rewriting, there has been a consensus to not rewrite the SSRC
    b= y the MDD

    This = is factually wrong.

    We= had a discussion on this was on IETF 96 (Berlin) where I was asked<= br style=3D"font-family:Menlo-Regular;font-size:11px;font-style:normal;font= -variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:st= art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px= ">to describe how this works in a = draft, which we did:

    https://tools.ietf.org/html/d= raft-grozev-perc-ssrc-00

    = We then talked about it in Chicago. No decision was reached the topic
    was left open.

    due to the security implications/attacks as discussed= in the
    earlier design meetings/virtual interims and IETF meetings (See<= br>https://www.ietf.org/mail-archive/web/perc/curr= ent/msg00231.html)

    Please refer to
    ht= tps://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf= =C2= =A0for more
    information as the starting point on the various atta= cks. Please submit a
    draft to the mailing list for discussions that addr= esses the security
    concerns or invalidates them with an appropriate secu= rity analysis

    A= ll of this was discussed subsequently. While there is a lot of hand<= br style=3D"font-family:Menlo-Regular;font-size:11px;font-style:normal;font= -variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:st= art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px= ">waving about a possible SSRC spl= icing attack, to this date I am not
    aware of an actual description of how this thing could work.


    So here is the attack I=E2=80=99= m concerned about:

    We have an MD which is allowed to rewrite SSRC (even= with including the original into the OHB).
    Now an endpoint in a conference rec= eives a RTP packet from that MD where the re-written SSRC (outer SSRC) matc= hes exactly the SSRC A the endpoint itself is using for sending.
    The endpoint n= eeds to change it's SSRC to avoid the collision. So the endpoint choose= s another SSRC B for sending.
    And the MD happens to choose another SSRC B as it= s re-written SSRC.
    So endpoint changes the SSRC again to C.
    Which then happens to b= e the same as the SSRC used by another endpoint in the conference.
    Now the MD r= eceives two incoming RTP streams with identical SSRCs from two different en= dpoints and can choose to recombine the RTP headers from client #1 with the= payload from client #2.

    I think this attack plus it=E2= =80=99s possible mitigations need to be described in the draft=C2=A0draft-g= rozev-perc-ssrc-00.


    IIRC correctly from the presentation that Jan Mattson gave on th= ese attacks, the cause for splicing attack happens =C2=A0when the MDD hides= the fact that collision has happened and rewrites the SSRC.=C2=A0
    So if MDD sees a collision from endpoint B to be using same SSRC as endpo= int A, it hides that fact and rewrites the SSRC.

    Hides i= t? Could you please be a little bit more specific? Are you assuming the the= original SSRC does not reach the receivers?
    =

    =C2=A0 =C2=A0That's what SSRC rewriting means I p= resume ?

    The one solution that was discussed in Berlin and then in C= hicago includes preservation of the original SSRC in the OHB:



    But on which of thes= e two SSRCs do you do collision detection?

    =C2=A0 Nils


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


    --001a114e0056d85bec055487092b-- From nobody Mon Jul 17 19:07:58 2017 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 AFD31127010 for ; Mon, 17 Jul 2017 19:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 V9p9SmrlmpsO for ; Mon, 17 Jul 2017 19:07:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6D912EC44 for ; Mon, 17 Jul 2017 19:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28185; q=dns/txt; s=iport; t=1500343673; x=1501553273; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CHSMoMhxHHN1Sk2VKtD+AwEJH68EBi+6Pr34hKKfcvk=; b=N3Jf0ZZq2kzskFvhZNnDM1od4kjqQTQ51LgBw4GgTIbW53bQWCjm8Vl9 p/QefUkjsNCDzy0KjT9NEj4rteua+t0iyfiE/A1PSPZ8gwaRZLg0ks3EE HBB7NeyWoAFmUsvAPfdbq2KWtSLYCZuyU0rbfyX0eQ69OOQC1FvZH2FZF Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAAAZbW1Z/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEUB44EkWKILo1WghEhAQqFGwKDRz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQEBAgEBZgYLEAIBCBEDAQIhBwchBgsUCQgCBAENBRuJMEwDFRCxaoc6D?= =?us-ascii?q?YNGAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDJASDTYFhgySCV4FwBgEBO4VUBZE?= =?us-ascii?q?fhiOHNzsCh0iHXIRwggyFT4pUjAqJTAEfOIEKdRVJhFo5HBmBTnYBhhkOF4EMg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.40,376,1496102400"; d="scan'208,217";a="271272041" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2017 02:07:47 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6I27lkS002249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Jul 2017 02:07:47 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 21:07:46 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1210.000; Mon, 17 Jul 2017 21:07:46 -0500 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba , Nils Ohlmeier CC: Suhas Nandakumar , Emil Ivov , "perc@ietf.org" Thread-Topic: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) Thread-Index: AQHS/2qmt6z1M2HBuUOUAkXHiZ+ElA== Date: Tue, 18 Jul 2017 02:07:46 +0000 Message-ID: References: <4B250A3D-8E56-4D15-8D20-30856872CFE7@mozilla.com> <45C1DD64-7E9D-4051-93C2-AF348C7DE8F8@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.195.47] Content-Type: multipart/alternative; boundary="_000_D592E09F70487mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 02:07:57 -0000 --_000_D592E09F70487mzanatyciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RTP requires SSRC collisions to be detected wherever SSRCs are used, not ju= st the SSRC field in the RTP header. For example, collisions must also be d= etected in the CSRC list. PERC does not alter those basic rules of RTP. If all participants and the M= D are in the same RTP session, SSRC collision must be detected everywhere S= SRCs are used in that single RTP session. If the RTP session boundaries are= narrower, the collision detection domain is correspondingly narrower, but = collision must still be detected everywhere SSRCs are used within each RTP = session. We can't limit PERC collision detection rules to a few select fiel= ds containing SSRCs. It must apply to all fields containing SSRCs within th= e same RTP session. Mo From: Perc > on behalf = of Bernard Aboba > Date: Monday, July 17, 2017 at 1:50 PM To: Nils Ohlmeier > Cc: Suhas Nandakumar >, Emi= l Ivov >, "perc@ietf.org" > Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft = Agenda - IETF99) Nils said: "But on which of these two SSRCs do you do collision detection?" [BA] Answering that question requires an understanding of the RTP topology= that is being created when the MDD modifies the SSRC. PERC appears to require that all participant SSRCs need to be unique (imply= ing that they are all within the same RTP session in an "RTP translator" to= pology). This would seem to imply to me that the SSRC in the OHB should be used for = collision detection. If the MDD forwards RTCP packets, rather than terminating and originating t= hem, then the collision detection algorithm will operate on the "original" = SSRCs in RTP packets (contained in the OHB) as well as "original" SSRCs in = RTCP packets (unmodified by the MDD). It seems to me that things get tricky if a PERC MDD attempts to terminate a= nd originate RTCP packets. In a non-PERC scenario where the MDD modifies the SSRC in RTP packets, the = MDD also typically terminates and originates RTCP packets, which causes eac= h participant to have a distinct RTP session with the MDD. This works becau= se the session scope in RTP and RTCP is consistent. However in PERC, it seems to me that this consistency breaks down if the MD= D attempts to terminate and originate RTCP packets. For example, if a parti= cipant detects a conflict based on the SSRC in the OHB and sends an RTCP "B= YE" packet, and the MDD consumes the "BYE" packet, how does it reach the ot= her participants? Similarly, if a participant sends an RTCP SDES packet th= at would notify other participants of a conflict in a future SSRC contained= in the OHB and the MDD consumes that packet, collision detection would be = delayed. On Mon, Jul 17, 2017 at 6:02 AM, Nils Ohlmeier > wrote: On Jul 17, 2017, at 15:00, Emil Ivov > wrote: On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar > wrote: On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov > wrote: On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar > wrote: On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier > wrote: On Jul 16, 2017, at 16:08, Emil Ivov > wrote: Regarding SSRC rewriting, there has been a consensus to not rewrite the SSR= C by the MDD This is factually wrong. We had a discussion on this was on IETF 96 (Berlin) where I was asked to describe how this works in a draft, which we did: https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 We then talked about it in Chicago. No decision was reached the topic was left open. due to the security implications/attacks as discussed in the earlier design meetings/virtual interims and IETF meetings (See https://www.ietf.org/mail-archive/web/perc/current/msg00231.html) Please refer to https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more information as the starting point on the various attacks. Please submit a draft to the mailing list for discussions that addresses the security concerns or invalidates them with an appropriate security analysis All of this was discussed subsequently. While there is a lot of hand waving about a possible SSRC splicing attack, to this date I am not aware of an actual description of how this thing could work. So here is the attack I'm concerned about: We have an MD which is allowed to rewrite SSRC (even with including the ori= ginal into the OHB). Now an endpoint in a conference receives a RTP packet from that MD where th= e re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint itse= lf is using for sending. The endpoint needs to change it's SSRC to avoid the collision. So the endpo= int chooses another SSRC B for sending. And the MD happens to choose another SSRC B as its re-written SSRC. So endpoint changes the SSRC again to C. Which then happens to be the same as the SSRC used by another endpoint in t= he conference. Now the MD receives two incoming RTP streams with identical SSRCs from two = different endpoints and can choose to recombine the RTP headers from client= #1 with the payload from client #2. I think this attack plus it's possible mitigations need to be described in = the draft draft-grozev-perc-ssrc-00. IIRC correctly from the presentation that Jan Mattson gave on these attacks= , the cause for splicing attack happens when the MDD hides the fact that c= ollision has happened and rewrites the SSRC. So if MDD sees a collision from endpoint B to be using same SSRC as endpoin= t A, it hides that fact and rewrites the SSRC. Hides it? Could you please be a little bit more specific? Are you assuming = the the original SSRC does not reach the receivers? That's what SSRC rewriting means I presume ? The one solution that was discussed in Berlin and then in Chicago includes = preservation of the original SSRC in the OHB: https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 But on which of these two SSRCs do you do collision detection? Nils _______________________________________________ Perc mailing list Perc@ietf.org https://www.ietf.org/mailman/listinfo/perc --_000_D592E09F70487mzanatyciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    RTP requires SSRC collisions to be detected wherever SSRCs are used, n= ot just the SSRC field in the RTP header. For example, collisions must also= be detected in the CSRC list.

    PERC does not alter those basic rules of RTP. If all participants and = the MD are in the same RTP session, SSRC collision must be detected everywh= ere SSRCs are used in that single RTP session. If the RTP session boundarie= s are narrower, the collision detection domain is correspondingly narrower, but collision must still be detected e= verywhere SSRCs are used within each RTP session. We can't limit PERC colli= sion detection rules to a few select fields containing SSRCs. It must apply= to all fields containing SSRCs within the same RTP session.

    Mo


    From: Perc <perc-bounces@ietf.org> on behalf of Bernard Abo= ba <bernard.aboba@gmail.com>
    Date: Monday, July 17, 2017 at 1:50= PM
    To: Nils Ohlmeier <    nohlmeier@mozilla.com>
    Cc: Suhas Nandakumar <suhasietf@gmail.com>, Emil Ivov <emcho@jitsi.org>, "perc@ietf.org" <perc@ietf.org>
    Subject: Re: [Perc] Splicing attack= with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99)

    Nils said: 

    "But on which of these two SSRCs= do you do collision detection?"

    [BA]  Answering that question requires an understanding of the RT= P topology that is being created when the MDD modifies the SSRC. 

    PERC appears to require that all participant SSRCs need to be unique (= implying that they are all within the same RTP session in an "RTP tran= slator" topology). 

    This would seem to imply to me that the SSRC in the OHB should be used= for collision detection. 

    If the MDD forwards RTCP packets, rather than terminating and originat= ing them, then the collision detection algorithm will operate on the "= original" SSRCs in RTP packets (contained in the OHB) as well as "= ;original" SSRCs in RTCP packets (unmodified by the MDD). 

    It seems to me that things get tricky if a PERC MDD attempts to termin= ate and originate RTCP packets.  

    In a non-PERC scenario where the MDD modifies the SSRC in RTP packets,= the MDD also typically terminates and originates RTCP packets, which cause= s each participant to have a distinct RTP session with the MDD. This works = because the session scope in RTP and RTCP is consistent. 

    However in PERC, it seems to me that this consistency breaks down if t= he MDD attempts to terminate and originate RTCP packets. For example, if a = participant detects a conflict based on the SSRC in the OHB and sends an RT= CP "BYE" packet, and the MDD consumes the "BYE" packet, how does it reach the other participants? = ; Similarly, if a participant sends an RTCP SDES packet that would notify o= ther participants of a conflict in a future SSRC contained in the OHB and t= he MDD consumes that packet, collision detection would be delayed.





    On Mon, Jul 17, 2017 at 6:02 AM, Nils Ohlmeier <= span dir=3D"ltr"> <nohlmeier@mo= zilla.com> wrote:

    On Jul 17, 2017, at 15:00, Emil Ivov <emcho@jitsi.org> wrote:


    On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar <suhasietf@gmail.com> wrote:
    On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov <= ;emcho@jitsi.org&g= t; <= /span>wrote:

    On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar <suhasietf@gmail.com&= gt; wrote:
    On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <nohlmeier@m= ozilla.com> wrote:

    On Jul 16, 2017, at 16:08, Emil Ivov <emcho@jitsi.org> wrote:

    Regarding SSRC rewriting, there has been a consensus to not rewrite the SSR= C
    by the MDD

    This is factually wrong.

    We had a discussion on this was on IETF 96 (Berlin) where I was asked<= br style=3D"font-family:Menlo-Regular;font-size:11px;font-style:normal;font= -variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:st= art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px= "> to describe how this works in a draft, which we did:

    https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

    We then talked about it in Chicago. No decision was reached the topic<= br style=3D"font-family:Menlo-Regular;font-size:11px;font-style:normal;font= -variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:st= art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px= "> was left open.

    due to the security implications/attacks as discussed in the
    earlier design meetings/virtual interims and IETF meetings (See
    https://www.ietf.org/mail-archive/web/perc/current= /msg00231.html)

    Please refer to
    https://www.ietf.org/proceedings/94/slides/slides-<= wbr>94-perc-5.pdf for more
    information as the starting point on the various attacks. Please submit a draft to the mailing list for discussions that addresses the security
    concerns or invalidates them with an appropriate security analysis

    All of this was discussed subsequently. While there is a lot of hand waving about a possible SSRC splicing attack, to this date I am not
    aware of an actual description of how this thing could work.


    So here is the attack I’m concerned about:

    We have an MD wh= ich is allowed to rewrite SSRC (even with including the original into the O= HB).
    Now an endpoint = in a conference receives a RTP packet from that MD where the re-written SSR= C (outer SSRC) matches exactly the SSRC A the endpoint itself is using for sending.
    The endpoint nee= ds to change it's SSRC to avoid the collision. So the endpoint chooses anot= her SSRC B for sending.
    And the MD happe= ns to choose another SSRC B as its re-written SSRC.
    So endpoint chan= ges the SSRC again to C.
    Which then happe= ns to be the same as the SSRC used by another endpoint in the conference.
    Now the MD recei= ves two incoming RTP streams with identical SSRCs from two different endpoi= nts and can choose to recombine the RTP headers from client #1 with the payload from client #2.

    I think this attack plus it’s possible mitigations need to be de= scribed in the draft draft-grozev-perc-ssrc-00.


    IIRC correctly from the presentation that Jan Mattson gave on these at= tacks, the cause for splicing attack happens  when the MDD hides the f= act that collision has happened and rewrites the SSRC. 
    So if MDD sees a collision from endpoint B to be using same SSRC as en= dpoint A, it hides that fact and rewrites the SSRC.

    Hides it? Could you please be a little bit more specific?= Are you assuming the the original SSRC does not reach the receivers?

       That's what SSRC rewriting means I presume ?

    The one solution that was discussed in Berlin and then in= Chicago includes preservation of the original SSRC in the OHB:



    But on which of these two SSRCs do you do collision detection?

      Nils



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


    --_000_D592E09F70487mzanatyciscocom_-- From nobody Tue Jul 18 11:02:08 2017 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 F0DF0131BA9 for ; Tue, 18 Jul 2017 11:02:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040092698.11320.8443524426346156369.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 11:02:06 -0700 From: IETF Secretariat Archived-At: Subject: [Perc] Milestones changed for perc WG X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:02:07 -0000 Changed milestone "Submit SRTP protocol extension specification to IESG (Standards Track)", set due date to December 2017 from June 2017. URL: https://datatracker.ietf.org/wg/perc/about/ From nobody Tue Jul 18 11:02:32 2017 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 597B2131BB1 for ; Tue, 18 Jul 2017 11:02:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040094436.11316.8336476525217645831.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 11:02:24 -0700 From: IETF Secretariat Archived-At: Subject: [Perc] Milestones changed for perc WG X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:02:24 -0000 Changed milestone "Submit encrypted key transport specification to IESG (Standards Track)", set due date to December 2017 from June 2017. URL: https://datatracker.ietf.org/wg/perc/about/ From nobody Tue Jul 18 11:03:00 2017 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 C3D6B131B3B for ; Tue, 18 Jul 2017 11:02:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040097779.11316.336055506554680261.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 11:02:57 -0700 From: IETF Secretariat Archived-At: Subject: [Perc] Milestones changed for perc WG X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:02:58 -0000 Changed milestone "Submit Key-management protocol specification to IESG (Standards Track)", set due date to March 2018 from June 2017. URL: https://datatracker.ietf.org/wg/perc/about/ From nobody Tue Jul 18 11:03:12 2017 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 CDDAA127180 for ; Tue, 18 Jul 2017 11:03:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040098984.11409.2533450167692294614.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 11:03:09 -0700 From: IETF Secretariat Archived-At: Subject: [Perc] Milestones changed for perc WG X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:03:10 -0000 Changed milestone "Submit architecture or framework specification to IESG (Standards Track)", set due date to March 2018 from June 2017. URL: https://datatracker.ietf.org/wg/perc/about/ From nobody Tue Jul 18 11:03:34 2017 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 A54D4131B66 for ; Tue, 18 Jul 2017 11:03:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040101167.11336.12891800509869109947.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 11:03:31 -0700 From: IETF Secretariat Archived-At: Subject: [Perc] Milestones changed for perc WG X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:03:32 -0000 Changed milestone "Submit documentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (Informational)", set due date to March 2018 from June 2017. URL: https://datatracker.ietf.org/wg/perc/about/ From nobody Tue Jul 18 11:04:14 2017 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 DCA1C131BB1 for ; Tue, 18 Jul 2017 11:04:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150040105189.11280.4611539348115284801.idtracker@ietfa.amsl.com> Date: Tue, 18 Jul 2017 11:04:11 -0700 From: IETF Secretariat Archived-At: Subject: [Perc] Milestones changed for perc WG X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:04:12 -0000 Changed milestone "Submit Key-management protocol specification to IESG (Standards Track)", set due date to December 2017 from March 2018. URL: https://datatracker.ietf.org/wg/perc/about/ From nobody Tue Jul 18 11:08:41 2017 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 D142A129AD3 for ; Tue, 18 Jul 2017 11:08:38 -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 V8DD80cFXZsO for ; Tue, 18 Jul 2017 11:08:37 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 029F2128AB0 for ; Tue, 18 Jul 2017 11:08:36 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id d136so23350950qkg.3 for ; Tue, 18 Jul 2017 11:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OU824ckBiKdaf33LBiAjzT/q2Lhlcdy7bSoT4sbGTGc=; b=pyrelk2dIP+Sa8UgS3U7ocXXLSrI+lu/OziNSW0TbznV+g5V+ugqfnOfzjET6CfwLU e1MfgCsZn78M23En8T2bbgsMOg1Rq629uARi6OYtAEzvFbsebuHfUAOMZpD3hKZsQUC3 Ny7kaqLGl78ljsCIgoWen9nsBjFjYTG128XkwAprkeXSKypC9Lnxzdb86MEHzsUMV04I dVAyiIwM66fluWLoXb1/Z/LE1I/3VuQC4mg64+JEyBAnkKt2yDlaTfoJo3Qc8Bch8gLM PN4biUGQwB4VIYJfHm/CsyY5X941qacOjbEzj1F9tkzRBt4WzaevyRxluPw7pkydzjX3 1zLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OU824ckBiKdaf33LBiAjzT/q2Lhlcdy7bSoT4sbGTGc=; b=unZvJ+GRbqvZnXA87R8P+FAhSQAyqczjsyMj45gAn4fGEJWOoRERnJUIoND/a7Tlqa +I+8wRGQOavVBlfknFMnPpuBsx85BmK9h/T2KXU0bVNIvoBqmH17MirtilnWz5Z4Nti3 jeTNtCiTfRqo4YzBYrjU3igmmwSR8DCjsgLZUhiuFs/1jIb6YyWBSIJoyXIPLNXXlNMg hTy/YOrWJn1ktx6w37sOOKqt+5cBiKb70dFya4MBsJEblKQF7IXLX0jDRdDy9VVItxzT DVhXxNSqltUgJux+abRBUlUSTgGZxSQEhL9WA0BSUF9bLeUmVCsvowXK9JP3pg5wEOq1 LC5Q== X-Gm-Message-State: AIVw113imm2URyvaMQ3km/AT4Br6fzci6kDqSNL/4nAMb2whWPeCKewR DmIBnBwEj4RJYO3aK58N4QuwkA/dqL/L X-Received: by 10.55.181.71 with SMTP id e68mr3429065qkf.91.1500401315846; Tue, 18 Jul 2017 11:08:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.154.237 with HTTP; Tue, 18 Jul 2017 11:08:35 -0700 (PDT) From: Suhas Nandakumar Date: Tue, 18 Jul 2017 20:08:35 +0200 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c06e96873a1fd05549b67f7" Archived-At: Subject: [Perc] Milestones Updated X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 18:08:39 -0000 --94eb2c06e96873a1fd05549b67f7 Content-Type: text/plain; charset="UTF-8" Hello All, As discussed during our session today, here are the updated milestones : Dec 2017 - Submit SRTP protocol extension specification to IESG (Standards Track) Dec 2017 - Submit encrypted key transport specification to IESG (Standards Track) Dec 2017 - Submit Key-management protocol specification to IESG (Standards Track) Mar 2018 - Submit architecture or framework specification to IESG (Standards Track) Mar 2018 - Submit documentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (Informational) Link : https://datatracker.ietf.org/wg/perc/milestones/ Cheers Perc Chairs --94eb2c06e96873a1fd05549b67f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hello All,

    =C2=A0 As dis= cussed during our session today, here are the updated milestones :

    Dec 2017 - Submit SRTP protocol extension specification to= IESG (Standards Track)

    Dec 2017 - Submit encrypted key t= ransport specification to IESG (Standards Track)

    Dec 2017 - Submit Key-management protocol specification to IESG (Standar= ds Track)

    Mar 2018 - Submit architecture or framework spe= cification to IESG (Standards Track)

    Mar 2018 - Submit do= cumentation of how to integrate solution in SIP, WebRTC and CLUE to IESG (I= nformational)




    Che= ers
    Perc Chairs
    --94eb2c06e96873a1fd05549b67f7-- From nobody Wed Jul 26 17:26:36 2017 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 23F20131F10 for ; Wed, 26 Jul 2017 17:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PLHn4OqB3Dfi for ; Wed, 26 Jul 2017 17:26:33 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 5792E131F0A for ; Wed, 26 Jul 2017 17:26:33 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id t37so59656287qtg.5 for ; Wed, 26 Jul 2017 17:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Vf7i2FDDha54R1tVC7v/uiR9j/aKY3lmi9w/pXxmB1E=; b=YdH/mBjXk9ICp15TX+vZfWV+mhwL4coeXkVu/opL+IubYfpYRDOrPjvnwkT7+b7aFE gEpIWS7We6Kl9TkK1K9vUtA+UkEkKhjMW3JBBfgh9/9csk8axDjFKjQfgqhAN5KetQei TkJF6eR3l/bulm4NY4hfR13J64ChZ/N4lFm3x4oolBcoZrRcyAAU1TKRHFS2LZskSkgW t/BCkyy6XZdZp6SsWpYlO6V4Z1B+mD3NiIBvPZR+5OkCUwhV2zWkgHFkjr4ji5ByfZf9 RjnPgjsyj7i/VKn/FTDac4PWoFInWAlps8gUDFPQ9ehzUqF4Nsj6KpEjYCECj+NhVre9 UYPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Vf7i2FDDha54R1tVC7v/uiR9j/aKY3lmi9w/pXxmB1E=; b=nJAL5pW2WaDDxKReFujrg9mfow4Ohy5seoGvWGs5nKKMVa2MZvQDzs+5BUh5N0THMA KdCc6nkGU+GHu/gwA5mQgL0dIJbWBpKc72drsCJmcVOQAeoTCbF8V1JhoI0YFJM+oUVb 4EDbZqvfwRB/WXqIwiardybOj1hE2NjZ7J2w+O/L0XZkpqvkkE6a5XVNTAmnUs7Y1LK2 YYpheJGAwehl1MQnIPLCv2XszFA/iooyGBk9ZyGb0Rshwrv5zg2NvfRwaDZyTsXY3G7j e7PNpGMb91GUfHCtDzemflSeLz1xX+Dbi8iBEZRR4PtUWe0Bzf92fwRegWweYDgKiJmC qicQ== X-Gm-Message-State: AIVw110op3lv0ySwDUPeKzDRqUMnQOA7y19Lh5NXu0Z0Zvq6HIjeHqgJ GVrhoZahC5kr0EEIfQBHf9B1jYV61KWH X-Received: by 10.200.3.135 with SMTP id t7mr3640043qtg.216.1501115192199; Wed, 26 Jul 2017 17:26:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.130.196 with HTTP; Wed, 26 Jul 2017 17:26:31 -0700 (PDT) From: Suhas Nandakumar Date: Wed, 26 Jul 2017 17:26:31 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="f4030435c300cc4fda0555419db4" Archived-At: Subject: [Perc] IETF99 Perc Minutes X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 00:26:35 -0000 --f4030435c300cc4fda0555419db4 Content-Type: text/plain; charset="UTF-8" Hello All Please find the minutes for our session at IETF 99 here: https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-00.txt Please let us know if there are any questions. Thanks to Roni for taking notes and to Matt Miller for being the Jabber Scribe Cheers Perc Chairs --f4030435c300cc4fda0555419db4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello All

    =C2=A0 Please find the minute= s for our session at IETF 99 here:
    <= br>
    Please let us know if there are any questions.=C2=A0

    Thanks to Roni for taking notes and to Matt Miller for bei= ng the Jabber Scribe

    Cheers
    Perc Chairs<= /div>

    --f4030435c300cc4fda0555419db4-- From nobody Thu Jul 27 10:14:40 2017 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 27F1213201F for ; Thu, 27 Jul 2017 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 whGleQ1L9ppM for ; Thu, 27 Jul 2017 10:14:21 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 DC41E131CEE for ; Thu, 27 Jul 2017 10:14:20 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id v29so46079287qtv.3 for ; Thu, 27 Jul 2017 10:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yUaBsnPAlkUfsyb0x4048iI2SKbt3uFIdmexVvblgOQ=; b=ciy8PQMhAu+2/Q7+QMUozj7E9Id2RWCrW8PfLA9Rx7Wj+e1Z5foJpax8mQbhzTHJoJ FaXOgvPh4Xh2nKE/I7j9v9lbDOq0u4mZce0CzMOTE+fgFOYr/fgbXc/uQRdOySGvY45X oNsQjSuZTSFIh5cKFiwsvdJthn+SMUpmkiS7MOGflfyP3m4yLGcLF9DbC9mVvjjbwCtN QeS6VTwscPdEvC3pNaKYJIl3d28bm/1ulu7sj4BE7CBooWk4VxfkH+5QjQlUHPXdwRLp EWtibg4B5Ojq2GjbHuG3yu4sGXxGCjNCWsv1VsP64YY0/BAaXcckGOON5e7llsKyZEm3 ESuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yUaBsnPAlkUfsyb0x4048iI2SKbt3uFIdmexVvblgOQ=; b=NwsjhZPD5orK+TbDhoexYsfAqFAZl+wcU1/puKVgCYL/7ZkZePp6siCi9HpUYKxeYH c3o9ovN05jpvUyJCZk0LCmzekXOp282Fsk9Wo14qxHjDrasvkw8xFyxHulB8jEK4fbYB MDjtPnWJTE0Ow9Gd+3nZFAs5a0R5E8BL5Vm9ScRmz5+9Wgtgj2zMM+8rGOC1DfgcTF4t WczcHVkcJWSMikEhp/Ca5QBJUoCTzYd+z8w4Wfy+Sgu31v0dKt8BC8mx3oRjGD3COFke U6yIKmsdYogFjDQNKdTH99LuRIrd2kbIAZP3lfm2PSBwvvqroATDEWz8D+DJkLwWsYHa PH5g== X-Gm-Message-State: AIVw111PDeI+Kd21k7oZD9+XNDB2D7ox2Ep5k4LqmlJpHVVKGFiJZFcO 2v20tuozFXeIJ8YRf9tvmx+xij3zh8XQ X-Received: by 10.200.3.135 with SMTP id t7mr6659567qtg.216.1501175659643; Thu, 27 Jul 2017 10:14:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.130.196 with HTTP; Thu, 27 Jul 2017 10:14:19 -0700 (PDT) From: Suhas Nandakumar Date: Thu, 27 Jul 2017 10:14:19 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary="f4030435c300f0481905554fb1c8" Archived-At: Subject: [Perc] Confirmation of Consensus on PERC Double from IETF 99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 17:14:23 -0000 --f4030435c300f0481905554fb1c8 Content-Type: text/plain; charset="UTF-8" Hi All, At the IETF 99 meeting, we took hum on the following proposals and there was a strong consensus in the room in their favor, but we wish to gather any additional inputs on the list. So, if there are any additional inputs that was not expressed in the room, please send them to the list by *4th August.* First Consensus Call: Allow MD to modify the 'M' (marker) bit. Second Consensus called made includes all the following 3 proposals as a singleton: - Move the OHB information from header extension to payload - RTX, RED and FlexFEC ordering : use the ordering of applying repair on the double-encrypted packet. (Option 'A' in the slides) - DTMF : PERC will only support E2E DTMF and MD will not be able to read DTMF info sent as media Here are the notes from the meeting: https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-01.txt Here are the slides corresponding to the above proposals : https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-01.pdf Thanks Perc Chairs --f4030435c300f0481905554fb1c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi All,

    =
    At the IETF 99 meeting, we took hum on the following prop= osals and there was a strong consensus in the room in their favor, but we w= ish to gather any additional inputs on the list.=C2=A0
    So, if there are any additional inputs that was not expres= sed in the room, please send them to the list by 4th August.<= br>

    First Consensus Call:
    = =C2=A0 =C2=A0Allow MD to modify the 'M' (marker) bit.
    <= div style=3D"color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-seri= f;font-size:16px">
    Second Consensus called made includes all the fol= lowing 3 proposals as a singleton:
    =C2=A0 =C2=A0 - Move th= e OHB information from header extension to payload
    =C2= =A0 =C2=A0 - RTX, RED and FlexFEC ordering : use the ordering of applying r= epair on the double-encrypted packet. (Option 'A' in the slides)
    =C2=A0 =C2=A0 - DTMF :=C2=A0PERC will only s= upport E2E DTMF and MD will not be able to read DTMF info sent as media=C2=A0=C2=A0

    Here are the not= es from the meeting:=C2=A0
    Here are the slides corresponding to the above proposal= s :=C2=A0

    Thanks
    Perc Chairs
    --f4030435c300f0481905554fb1c8-- From nobody Thu Jul 27 11:04:37 2017 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 A0353132093 for ; Thu, 27 Jul 2017 11:04:36 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 mvJUvR4Zj77Y for ; Thu, 27 Jul 2017 11:04:35 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DE6131D6F for ; Thu, 27 Jul 2017 11:04:34 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id t201so106297216wmt.1 for ; Thu, 27 Jul 2017 11:04:34 -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=T1Kussh2zmIslW3bT4yJy+Fn2UydF/SXe5B4a400pvg=; b=JiXXa5AzqtCf5G6qNdVxMVV9e9QluSJUB+PC6k88v7B4QAsdbXVUEkWAx2uMAKHk1W BH65KRgqb4KXhL/iUYarr4vypxOz04kIxilJ67t9Xek1W4jIJqJw6pm7nmTrhgfBTpIE T6bHOEV+P+A2+f1PGneWP+zs48GWJxsx9bcF0GKlsT/c+AcjyobPBCsOYZcrZOFbgL0I SoiPrGifgRDQFAl9ILJLyMQXAcpvB8Esk7shWr/ZgMmYoVYg6fVGVkkey5d87u4+G6f/ IgEaYpmaxl+wPtef/7VOh1VWsjoUgq9yOGg8Krfd+Yx41fMUFTG8VybInbmEGVjCyCF2 hK2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T1Kussh2zmIslW3bT4yJy+Fn2UydF/SXe5B4a400pvg=; b=S85858pE/LmQ+ZR0TPGus33f6ezhPj5uRxWikF1PNeItROz8s3YcEgDyRLa1J0gT4x vQMFXpUs5ObbJNc00/QkI29hHcVi3TwgRDIQziRsG7ZzGUwSIasIkUIzndHfPVbFD7C7 3DFXVFCAJLime9QcXu5+SrU2NkPv5jlVg/NcFIqbBmTwYg/dZng7q/JpIzRS5vuuJdcE 99a6QDI2UVMnGJlqkDKMBu/JvQustxh3JF9JbYw0dCp6euYTcP5yfCGhEiJ6/Cf5s1Ed bMegC+LZQze2QIeO59n0IaThPCuy5t39+ukRr6U+Y4bnDAqls20RaSa8bRUMIBr49QG0 DuKw== X-Gm-Message-State: AIVw112jKQEykDe51unxaTaL8xU/i4FNHUeeMjbJ/MeUKMcA0S6eucaU UZzV09teoheUW9an+Ae/Sy6ZQDsrZ5oa X-Received: by 10.80.166.197 with SMTP id f5mr2605782edc.244.1501178673208; Thu, 27 Jul 2017 11:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.168.69 with HTTP; Thu, 27 Jul 2017 11:04:12 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Thu, 27 Jul 2017 13:04:12 -0500 Message-ID: To: Suhas Nandakumar Cc: perc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 18:04:36 -0000 Because I assume this is also a call for consensus on the list (and that you are not just informing us of something that happened off list as if it were a done deal): > - RTX, RED and FlexFEC ordering : use the ordering of applying repair on > the double-encrypted packet. (Option 'A' in the slides) No, this makes no sense. It would be embarrassing to have IETFs name associated with this. Emil On Thu, Jul 27, 2017 at 12:14 PM, Suhas Nandakumar wrote: > > Hi All, > > At the IETF 99 meeting, we took hum on the following proposals and there was > a strong consensus in the room in their favor, but we wish to gather any > additional inputs on the list. > So, if there are any additional inputs that was not expressed in the room, > please send them to the list by 4th August. > > First Consensus Call: > Allow MD to modify the 'M' (marker) bit. > > Second Consensus called made includes all the following 3 proposals as a > singleton: > - Move the OHB information from header extension to payload > - RTX, RED and FlexFEC ordering : use the ordering of applying repair on > the double-encrypted packet. (Option 'A' in the slides) > - DTMF : PERC will only support E2E DTMF and MD will not be able to read > DTMF info sent as media > > Here are the notes from the meeting: > https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-01.txt > > Here are the slides corresponding to the above proposals : > https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-01.pdf > > > Thanks > Perc Chairs > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > -- https://jitsi.org From nobody Thu Jul 27 11:10:33 2017 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 80F6813209B for ; Thu, 27 Jul 2017 11:10: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 QUtAdawiHigJ for ; Thu, 27 Jul 2017 11:10:30 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 8818013209C for ; Thu, 27 Jul 2017 11:10:30 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id e199so671368wmd.0 for ; Thu, 27 Jul 2017 11:10:30 -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=vto5oyFvxcOvO/20ENOfoj4VNYTW62KStgKtSwMm7tU=; b=xjT1fLKay297cnRqiVQ7+zO1O+4JMofTP9CvcPK+xLapootYSpDurJuYNZuwrF4gHp NEhWrmMthJw3mTecrPKOB2MLU4t/2F39UXy92fq2mvCDmqT9mDAvKyo2ZAsdJLMjxtR7 WCwTTCu2vHEBle/C8LNLVoNeT4sjA21yOPte5BhwqdkvBaQTNg+qAJcZt6g3DHdcvqCs XpdLNGEytX8EX7CFRRgu4qSOuWdM2F5mjp/+L7TNzhx5eJJ0tts+7c9sHDmK/IFv31kL +rDbTdjqtuBYLaGHxZHZNFwGpFspOTUDBPIsufxzjO3dDzI4daN/qe0E39Hx0JLyJDx7 FugA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vto5oyFvxcOvO/20ENOfoj4VNYTW62KStgKtSwMm7tU=; b=EDLGnS0SS8mqn1MGcAR8zZS36jDObF0nGffl09aiS3yQaPwEBBZIYAb2OAz6m8t8qp O6NIE880ztghAhtc1CTXkieQ4YbVtfaxq5bzyvZDJEd6NKL/s9yIxh8lUk4FzP4bYl7h MwDvJWs8k00hDOhf0WjLyUmuT34YrziAyClZVjY7Drms9HcwRARPdKW2anD8qhk3p0C+ RrgVOKO35cYh2lJlEdxVFrObnZSCw2mkNK0/40sfmT2kOLxCUV9ENgPgt+/CvgjcUQD5 lyD6fdPCZaPDlGd3HWL5R7l9AYplYGYzEnNPxbJ60K1yt6hp6u89ukTAsiNEuJPye+iE gxAQ== X-Gm-Message-State: AIVw112yRO657u4zbPBxSP0HXko69Nyrkf0ysiqvQHk7jgCw+A5lzD9Z zGT9ZLZIujZr5SFTb5+8ogVFOtC3lkyK X-Received: by 10.80.216.75 with SMTP id v11mr4494893edj.234.1501179029076; Thu, 27 Jul 2017 11:10:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.168.69 with HTTP; Thu, 27 Jul 2017 11:10:08 -0700 (PDT) In-Reply-To: References: From: Emil Ivov Date: Thu, 27 Jul 2017 13:10:08 -0500 Message-ID: To: Suhas Nandakumar Cc: perc@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 18:10:32 -0000 On a different note. The slides you quote seem to say this: > Exciting and awesome joint proposal from Sergio, Cullen, Emil, & Alex that none of us like and all of us can live with (ietf bumpy consensus) I am not sure how my name ended up in this list. The two PERC points I am concerned about (wedging double SRTP for RTX and FEC and overwriting SSRCs) still seem to be in debate and I have yet to see something that represents consensus there. Emil On Thu, Jul 27, 2017 at 12:14 PM, Suhas Nandakumar wrote: > > Hi All, > > At the IETF 99 meeting, we took hum on the following proposals and there was > a strong consensus in the room in their favor, but we wish to gather any > additional inputs on the list. > So, if there are any additional inputs that was not expressed in the room, > please send them to the list by 4th August. > > First Consensus Call: > Allow MD to modify the 'M' (marker) bit. > > Second Consensus called made includes all the following 3 proposals as a > singleton: > - Move the OHB information from header extension to payload > - RTX, RED and FlexFEC ordering : use the ordering of applying repair on > the double-encrypted packet. (Option 'A' in the slides) > - DTMF : PERC will only support E2E DTMF and MD will not be able to read > DTMF info sent as media > > Here are the notes from the meeting: > https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-01.txt > > Here are the slides corresponding to the above proposals : > https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-01.pdf > > > Thanks > Perc Chairs > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > -- https://jitsi.org From nobody Thu Jul 27 11:26:44 2017 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 218FC1320B5 for ; Thu, 27 Jul 2017 11:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BAXLtyoQPrBD for ; Thu, 27 Jul 2017 11:26:41 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 BFA6A1320AF for ; Thu, 27 Jul 2017 11:26:40 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id k43so110653585uaf.3 for ; Thu, 27 Jul 2017 11:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1EfkIj7r1MhX0OKku9OvFeQbPPJqw8uj2DAYk6B6xzU=; b=qhSpChy4M/CL/OmavicbcBdHiZv1kHXcB/eHn8RaDG6qfnr7RfFT2XG7cC46jg7la4 kvyB8F/9jETTlaSsxmrzpE8cSpw8gn9Pof55mymt5i1d7OP5TPHySW/l6aFc6KzxCLDz 450U0sLJbB4oZheiUkgZ47JIGqaFKnEsGax4965XGydn9MTnjh/2SZ4giWqyo/Ya80qK E5hOoyN2FC+1JCS06+dx/cSdWy1IOPxVi2MNOldEC5DJ9wSn2xo8LQZqFo5PgNea6YkH kIsye/8c494CfxKwuf77okf0XsS2YJha9eJ6atSrG0gu6AXvsWXbdrpqaClJghfa0tCL l2Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1EfkIj7r1MhX0OKku9OvFeQbPPJqw8uj2DAYk6B6xzU=; b=tr9ygur8apGCGB+525DJ6eXCEBJ7dGCQJeFwQ3UbQYGl+yKDBpvY41NlMBf20bL+9V 1n1VKKCWA+IwPRMmuj4Uy2EkxGsCJVwpuAxQH8GQg1a1WNtKIEBNdBazvTC7e8ldVoc+ u2x3pO+n5cFAKgg3P7lT4heNd6/SfTsMhXbhqdRPzbitpYadQqxZC8tC0jTP167U8wT/ s7YBGDfqGfJ57ovlHExHYaZkzvhYUtrHwd8BCS36r2QjxF42l5zkiQcysADbviZ2Ewgl xKu7PTYwtn/keZ18A034jxz+9jq3jA1r4L+ggFq/T2OtVmlC8v5B+SOluW1HFdNr2yL0 Sf5Q== X-Gm-Message-State: AIVw110JbZp7fR26qJ+ieLgwlJpDcRRONlratyS1/EQIPSXSn9+y4sKo 5xTo2QyO+WsDyuUdAr4//rNk8nuPRA== X-Received: by 10.31.99.5 with SMTP id x5mr2772028vkb.62.1501179999741; Thu, 27 Jul 2017 11:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.111 with HTTP; Thu, 27 Jul 2017 11:26:19 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Thu, 27 Jul 2017 11:26:19 -0700 Message-ID: To: Emil Ivov Cc: Suhas Nandakumar , perc@ietf.org Content-Type: multipart/alternative; boundary="94eb2c07c8dea0ede5055550b4c6" Archived-At: Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 18:26:43 -0000 --94eb2c07c8dea0ede5055550b4c6 Content-Type: text/plain; charset="UTF-8" I am ok with putting the OHB in the payload and E2E DTMF. However, I would prefer the "lite" Option to Option A. Emil said: "No, this makes no sense" [BA] Seems to me that the "lite" option is more likely to be implemented than "Option A". On Thu, Jul 27, 2017 at 11:04 AM, Emil Ivov wrote: > Because I assume this is also a call for consensus on the list (and > that you are not just informing us of something that happened off list > as if it were a done deal): > > > - RTX, RED and FlexFEC ordering : use the ordering of applying > repair on > > the double-encrypted packet. (Option 'A' in the slides) > > No, this makes no sense. It would be embarrassing to have IETFs name > associated with this. > > Emil > > On Thu, Jul 27, 2017 at 12:14 PM, Suhas Nandakumar > wrote: > > > > Hi All, > > > > At the IETF 99 meeting, we took hum on the following proposals and there > was > > a strong consensus in the room in their favor, but we wish to gather any > > additional inputs on the list. > > So, if there are any additional inputs that was not expressed in the > room, > > please send them to the list by 4th August. > > > > First Consensus Call: > > Allow MD to modify the 'M' (marker) bit. > > > > Second Consensus called made includes all the following 3 proposals as a > > singleton: > > - Move the OHB information from header extension to payload > > - RTX, RED and FlexFEC ordering : use the ordering of applying > repair on > > the double-encrypted packet. (Option 'A' in the slides) > > - DTMF : PERC will only support E2E DTMF and MD will not be able to > read > > DTMF info sent as media > > > > Here are the notes from the meeting: > > https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-01.txt > > > > Here are the slides corresponding to the above proposals : > > https://www.ietf.org/proceedings/99/slides/slides- > 99-perc-double-01.pdf > > > > > > Thanks > > Perc Chairs > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > > > > > -- > https://jitsi.org > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --94eb2c07c8dea0ede5055550b4c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I am ok with putting the OHB in the payload and E2E DTMF.= =C2=A0

    However, I would prefer the "lite" Opti= on to Option A.=C2=A0


    Emil said:=C2= =A0

    "No, this makes no sense"

    [BA] Seems to me that the "lite" option is more likely t= o be implemented than "Option A".=C2=A0

    On Thu, Jul 27, 201= 7 at 11:04 AM, Emil Ivov <emcho@jitsi.org> wrote:
    Because I assume this is also a call for consensus on= the list (and
    that you are not just informing us of something that happened off list
    as if it were a done deal):

    >=C2=A0 =C2=A0 =C2=A0- RTX, RED and FlexFEC ordering : use the ordering = of applying repair on
    > the double-encrypted packet. (Option 'A' in the slides)

    No, this makes no sense. It would be embarrassing to have IETFs name=
    associated with this.

    Emil

    On Thu, Jul 27, 2017 at 12:14 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
    >
    > Hi All,
    >
    > At the IETF 99 meeting, we took hum on the following proposals and the= re was
    > a strong consensus in the room in their favor, but we wish to gather a= ny
    > additional inputs on the list.
    > So, if there are any additional inputs that was not expressed in the r= oom,
    > please send them to the list by 4th August.
    >
    > First Consensus Call:
    >=C2=A0 =C2=A0 Allow MD to modify the 'M' (marker) bit.
    >
    > Second Consensus called made includes all the following 3 proposals as= a
    > singleton:
    >=C2=A0 =C2=A0 =C2=A0- Move the OHB information from header extension to= payload
    >=C2=A0 =C2=A0 =C2=A0- RTX, RED and FlexFEC ordering : use the ordering = of applying repair on
    > the double-encrypted packet. (Option 'A' in the slides)
    >=C2=A0 =C2=A0 =C2=A0- DTMF : PERC will only support E2E DTMF and MD wil= l not be able to read
    > DTMF info sent as media
    >
    > Here are the notes from the meeting:
    >=C2=A0 =C2=A0https://www.ietf.= org/proceedings/99/minutes/minutes-99-perc-01.txt
    >
    > Here are the slides corresponding to the above proposals :
    >=C2=A0 =C2=A0https://www.= ietf.org/proceedings/99/slides/slides-99-perc-double-01.pdf >
    >
    > Thanks
    > Perc Chairs
    >
    > _______________________________________________
    > Perc mailing list
    > Perc@ietf.org
    > https://www.ietf.org/mailman/listinfo/perc >



    --
    https://= jitsi.org

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

    --94eb2c07c8dea0ede5055550b4c6-- From nobody Thu Jul 27 11:27:26 2017 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 1A94A131D2E for ; Thu, 27 Jul 2017 11:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FNTQMorL5PHb for ; Thu, 27 Jul 2017 11:27:23 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 E485D126B6E for ; Thu, 27 Jul 2017 11:20:33 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id t37so71941386qtg.5 for ; Thu, 27 Jul 2017 11:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VRjUhooOHcGEiDx8FsDnidJJpx0o2Jl5CZt402EL+Rk=; b=ZathXDdlpNUi29WqGRwU5x7ldTtldsTeOYZZL7izZ0HumB/1Hm2VE2iKH+hg3A9WnH 3B1OwGVEj+yoIv5sx7n7t8XgHKyHWgPcZizyjRdjWXs/8E98rd96VOxhSO2Ix0BgUI82 3GZUkEn2IJSZHJCGPYBkbmKGKjQVvEuR0ehil9WdQjotI2ya6KmTtJzTnz7yVjvieeMg tUW8kMhpt1HxUVxX9KPpqwPXe1hWrAn+CBntjwJ+awiqZuXH5OGEJqXQXNJ43s9D44fH 2Sa/idiHB4pedlIUOfcY/qylR0/ETg0P9JycQX/1ObOJ6NSkNOPm+QF5zXt3cacLrXOW FJhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VRjUhooOHcGEiDx8FsDnidJJpx0o2Jl5CZt402EL+Rk=; b=HRwOqpTnKgvpjzfq4el6cEKL8BML0hgG/P4rYODzy31Nrl8D5rx2o+qHtNIsn2lPXj 23YNL52iXTtFKLXDe/GyzHGCtR0LmUtrV7dKwal2m4X+QBTmuC0SnQl2sN7I5HmA/x49 iddXhrxdccSBT1QqeL9CqeIB49gIckp/oCzGI9ZQnx9RNFpKh8aJ5LzKPT/JZGYacWUK KkgnA0r+69t4vN5sXa91ktiJ8nwNUmjjvDpp1sRAiUjPGVMpypacIs4EPGw8raAJbzOS tG85vp4wR3bErqJX1BkumR/q+SN4TaLZ9YOrYeF2wiu+kc36VbfXsVO7MeBxy9+NDtAm vqjg== X-Gm-Message-State: AIVw113rVEGVI+ZKb38nHiM8CnnDW8PXu7LUC5O7H0zZ2VaHMRNOCyXN tktORnGBxtYUT451oCGueHkSUXdppQ== X-Received: by 10.200.35.215 with SMTP id r23mr7919418qtr.229.1501179632857; Thu, 27 Jul 2017 11:20:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.130.196 with HTTP; Thu, 27 Jul 2017 11:20:32 -0700 (PDT) In-Reply-To: References: From: Suhas Nandakumar Date: Thu, 27 Jul 2017 11:20:32 -0700 Message-ID: To: Emil Ivov Cc: perc@ietf.org Content-Type: multipart/alternative; boundary="001a1135a908c2b6c90555509e57" Archived-At: Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 18:27:25 -0000 --001a1135a908c2b6c90555509e57 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 27, 2017 at 11:10 AM, Emil Ivov wrote: > On a different note. The slides you quote seem to say this: > > > Exciting and awesome joint proposal from Sergio, Cullen, Emil, & Alex > that none of us like and all of us can live with (ietf bumpy consensus) > > I am not sure how my name ended up in this list. The two PERC points I > am concerned about (wedging double SRTP for RTX and FEC and > overwriting SSRCs) still seem to be in debate and I have yet to see > something that represents consensus there. > Hello Emil Sorry for the confusion on the slide deck. We did get an update request from the double presenters that your name be removed from that list in the slide deck. Nils has the copy of the modified slide deck and he will upload that version once he is back from the vacation. Here is the video link for the same that has the updated slide deck: https://youtu.be/PK4yunnH364?list=PLC86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=375 Cheers Suhas > > Emil > > On Thu, Jul 27, 2017 at 12:14 PM, Suhas Nandakumar > wrote: > > > > Hi All, > > > > At the IETF 99 meeting, we took hum on the following proposals and there > was > > a strong consensus in the room in their favor, but we wish to gather any > > additional inputs on the list. > > So, if there are any additional inputs that was not expressed in the > room, > > please send them to the list by 4th August. > > > > First Consensus Call: > > Allow MD to modify the 'M' (marker) bit. > > > > Second Consensus called made includes all the following 3 proposals as a > > singleton: > > - Move the OHB information from header extension to payload > > - RTX, RED and FlexFEC ordering : use the ordering of applying > repair on > > the double-encrypted packet. (Option 'A' in the slides) > > - DTMF : PERC will only support E2E DTMF and MD will not be able to > read > > DTMF info sent as media > > > > Here are the notes from the meeting: > > https://www.ietf.org/proceedings/99/minutes/minutes-99-perc-01.txt > > > > Here are the slides corresponding to the above proposals : > > https://www.ietf.org/proceedings/99/slides/slides- > 99-perc-double-01.pdf > > > > > > Thanks > > Perc Chairs > > > > _______________________________________________ > > Perc mailing list > > Perc@ietf.org > > https://www.ietf.org/mailman/listinfo/perc > > > > > > -- > https://jitsi.org > --001a1135a908c2b6c90555509e57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Thu, Jul 27, 2017 at 11:10 AM, Emil Ivov <emcho@jitsi.org> wrote:
    On a differ= ent note. The slides you quote seem to say this:

    > Exciting and awesome joint proposal from Sergio, Cullen, Emil, & A= lex that none of us like and all of us can live with (ietf bumpy consensus)=

    I am not sure how my name ended up in this list. The two PERC points I
    am concerned about (wedging double SRTP for RTX and FEC and
    overwriting SSRCs) still seem to be in debate and I have yet to see
    something that represents consensus there.

    <= div>=C2=A0Hello Emil

    =C2=A0 =C2=A0 Sorry for the c= onfusion on the slide deck. We did get an update request from the double pr= esenters that your name be removed from that list in the slide deck. Nils h= as the copy of the modified slide deck and he will upload that version once= he is back from the vacation.

    Here is the video l= ink for the same that has the updated slide deck:


    Cheers=
    Suhas
    =C2=A0

    Emil

    On Thu, Jul 27, 2017 at 12:14 PM, Suhas Nandakumar <suhasietf@gmail.com> wrote:
    >
    > Hi All,
    >
    > At the IETF 99 meeting, we took hum on the following proposals and the= re was
    > a strong consensus in the room in their favor, but we wish to gather a= ny
    > additional inputs on the list.
    > So, if there are any additional inputs that was not expressed in the r= oom,
    > please send them to the list by 4th August.
    >
    > First Consensus Call:
    >=C2=A0 =C2=A0 Allow MD to modify the 'M' (marker) bit.
    >
    > Second Consensus called made includes all the following 3 proposals as= a
    > singleton:
    >=C2=A0 =C2=A0 =C2=A0- Move the OHB information from header extension to= payload
    >=C2=A0 =C2=A0 =C2=A0- RTX, RED and FlexFEC ordering : use the ordering = of applying repair on
    > the double-encrypted packet. (Option 'A' in the slides)
    >=C2=A0 =C2=A0 =C2=A0- DTMF : PERC will only support E2E DTMF and MD wil= l not be able to read
    > DTMF info sent as media
    >
    > Here are the notes from the meeting:
    >=C2=A0 =C2=A0https://www.ietf.= org/proceedings/99/minutes/minutes-99-perc-01.txt
    >
    > Here are the slides corresponding to the above proposals :
    >=C2=A0 =C2=A0https://www.= ietf.org/proceedings/99/slides/slides-99-perc-double-01.pdf >
    >
    > Thanks
    > Perc Chairs
    >
    > ______= _________________________________________
    > Perc mailing list
    > Perc@ietf.org
    > https://www.ietf.org/mailman/listinfo/perc >



    --
    https://= jitsi.org

    --001a1135a908c2b6c90555509e57-- From nobody Fri Jul 28 08:19:14 2017 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 07430131D9F for ; Fri, 28 Jul 2017 08:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 BR1pESi4z5xh for ; Fri, 28 Jul 2017 08:19:03 -0700 (PDT) Received: from smtp77.iad3a.emailsrvr.com (smtp77.iad3a.emailsrvr.com [173.203.187.77]) (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 81310131EAA for ; Fri, 28 Jul 2017 08:19:01 -0700 (PDT) Received: from smtp18.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8218B23096; Fri, 28 Jul 2017 11:18:58 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp18.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 234AC253B5; Fri, 28 Jul 2017 11:18:58 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 28 Jul 2017 11:18:58 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 28 Jul 2017 09:18:56 -0600 Cc: Suhas Nandakumar , perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Emil Ivov X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Perc] Confirmation of Consensus on PERC Double from IETF 99 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 15:19:05 -0000 > On Jul 27, 2017, at 12:10 PM, Emil Ivov wrote: >=20 > On a different note. The slides you quote seem to say this: >=20 >> Exciting and awesome joint proposal from Sergio, Cullen, Emil, & Alex = that none of us like and all of us can live with (ietf bumpy consensus) >=20 > I am not sure how my name ended up in this list.=20 Emil, just to be clear, the version presented and the meeting did not = have your name on that list. I'm sure the chairs will get the correct = one sin the minutes.=20