From nobody Thu Nov 3 13:22:08 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A944F12967F for ; Thu, 3 Nov 2016 13:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VADG6UpHeBIZ for ; Thu, 3 Nov 2016 13:22:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DDF12964F for ; Thu, 3 Nov 2016 13:22:03 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id uA3KM25S029659 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Nov 2016 16:22:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1478204522; bh=9dyi5YjVL9uQxpCRslhZQMCtyF7+2oU0zsjzhSiWp+E=; h=From:To:Subject:Date:Reply-To; b=RArM5imfrboUGusZNN8NRz8AkP6QZHvz/chYx+CYGrXpt5XQZAZLACV6z8/DYi3sY CC49tW4kPrHpByzztFunPOYdUpQVv5WRkmXpLyTL92dqUxM3aHT1Arwd9CmerNqNxx hwvTnuh8DKThqNFyX8yry28RsnYLRdZq1UhH+5yo= From: "Paul E. Jones" To: "perc@ietf.org" Date: Thu, 03 Nov 2016 20:22:02 +0000 Message-Id: User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Thu, 03 Nov 2016 16:22:02 -0400 (EDT) Archived-At: Subject: [Perc] Fw: I-D Action: draft-jones-perc-dtls-tunnel-04.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 20:22:05 -0000 Folks, Just as an FYI, a revised version of the "tunnel" spec was published. =20 At a high-level, this is what has changed: - Minor title change - Switched syntax to be TLS-like (per WG request at the last meeting) - Switched transport to TCP/TLS (per WG request at the last meeting) - Changed key field names to align with RFC 5764 - Introduced a conference identifier field - Minor editorial issues Paul ------ Forwarded Message ------ From: internet-drafts@ietf.org To: i-d-announce@ietf.org Sent: 10/31/2016 6:13:28 PM Subject: I-D Action: draft-jones-perc-dtls-tunnel-04.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : DTLS Tunnel between a Media Distributor and=20 Key Distributor to Facilitate Key Exchange Authors : Paul E. Jones Paul M. Ellenbogen Nils H. Ohlmeier Filename : draft-jones-perc-dtls-tunnel-04.txt Pages : 15 Date : 2016-10-31 Abstract: This document defines a DTLS tunneling protocol for use in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the Key Distributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the media distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to the media distributor. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jones-perc-dtls-tunnel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-jones-perc-dtls-tunnel-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-jones-perc-dtls-tunnel-04 Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 16 15:11:58 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6E21295D7 for ; Wed, 16 Nov 2016 15:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wnQDIp0x4WKt for ; Wed, 16 Nov 2016 15:11:55 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829B51295C9 for ; Wed, 16 Nov 2016 15:11:55 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id f188so83795633pgc.3 for ; Wed, 16 Nov 2016 15:11:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=cZDjvL4lbI8cJIPxOk2bZIMQ4MKB6g62O4MeTl1vWD8=; b=SGMXNNm3QMSczw4n+OU66IpLwEpR5ggqrGLSCb2j/tbJkACA2EbzQwIp2d6cLhvy1J Wg/wMNYrLYT95/rAT8beLrJlGm7e3J8Ov1CPu/wKNRRf71fXrEES9c4bJwP1VvIWqgXS smKblLgfXohIc75OLrHYIHmasKO/PTbw86LgQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=cZDjvL4lbI8cJIPxOk2bZIMQ4MKB6g62O4MeTl1vWD8=; b=B3sZ0Nqw2z8xgX0twTJc2KRAvolKKVIQ7QFpyRwwN85yaauMfVQyvbKO1TOKEO8ttV ZPpX3LlXZJ0NZC8jwSNuVXD+DFnbmayaprxdf2+0TT1/Lx5qzYOtyyw8vuP50IGUtAje 0ui0BbgjqKKeQ5v8LNtoa0lJJtKRSPU6i2DJvt4ULbA3sa6T2elC/1uMkJaN4EI8hARA 5bwmAPFQyk2eZ1DXnbW6gg6NZwkrOmXD/d49c9+9QL4XtMjalLyynWoRXf6a0AGAv9Im 106UalYVj8pkdHGDwjjMxTUDu8nCUKGs9fHQqaAw+msjPsecK1UnC5t+zYWWsxCLULnU Qglg== X-Gm-Message-State: ABUngvfwsO3G74by+2kZXITdIKA1fIx+sOtobZZL0wVHscR+iEr7qKIUus6c4d/62TD9UXc8 X-Received: by 10.99.38.3 with SMTP id m3mr119828pgm.113.1479337914552; Wed, 16 Nov 2016 15:11:54 -0800 (PST) Received: from [10.252.25.187] (corp.mtv2.mozilla.com. [63.245.221.32]) by smtp.gmail.com with ESMTPSA id a7sm89644pfl.87.2016.11.16.15.11.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 15:11:53 -0800 (PST) From: Nils Ohlmeier Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Wed, 16 Nov 2016 15:11:52 -0800 To: perc@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [Perc] Conference ID for the tunnel protocol follow up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 23:11:58 -0000 Hello, After watching the recording of the PERC meeting again it appears that I = failed to explain the topic of the conference ID properly. So I=E2=80=99ll= try again, this time in writing. Assumption #1: there is some signaling system which talks to the MD, the = KD and the clients to setup a conference. And this signaling system = obviously knows which participants belong into which conference. Assumption #2: the KD needs to be informed by the signaling system about = the certificate fingerprints to be able to verify that the expected = participants join a given conference (this need to happen no matter if = the KD is running in a browser or somewhere else). Further if I=E2=80=99m not mis-taken I heard in the meeting that we = can=E2=80=99t make it a requirement that each client uses a new, = distinct cert for each conference it wants to join. Lets assume Alice is already in a conference A which is hosted by KD X = and MD Y. Now while still being in conference A she also wants to join = conference B. Since KD X and MD Y are hosting already conference A we can assume they = have established a TLS connection already. Now as a minimum the signaling system needs to contact the MD Y to let = it know that Alice wants to join conference B for which KD X is also = going to be gatekeeper. This is needed so that the MD knows where to = forward Alice new incoming DTLS packets to. Obviously the signaling system also talks to the KD X to tell it that is = going to be a conference B with Alice plus some other participants in = it. Alice sends her DTLS client hello to MD Y, which then forwards it to KD = X through the already established TLS connection. At this point KD X has a problem. Since it already has a DTLS connection = with Alice and Alice re-uses her cert it can not distinguish Alice in = conf A from Alice in conf B, unless the MD sends the unique conference = ID as part of the Tunneled DTLS message (which I tried to explain as = Option #1 during the meeting). Option #2 (the KD sends the conf ID as part of the Media Keys message to = the MD) and option #3 (no conf ID=E2=80=99s in the tunneling protocol at = all) won=E2=80=99t work, if we can=E2=80=99t make the requirement that = Alice needs to use distinguished certs for each conference she wants to = join. The only other option I see, which was not presented or discussed during = the meeting, would be that the KD actually opens another TLS connection = to the MD for every new conference. If there is then a way for the = signaling system to instruct the MD to forward Alice DTLS packets from = the new connection to the given TLS connection #2 (which would be the = connection for conf B - assuming TLS connection #1 is for conf A), that = would allow the KD to distinguish Alice in conf A from Alice in conf B = via it=E2=80=99s TLS connections #1 and #2 it holds to MD Y. But if we require a new TLS connection per conference it would only feel = natural to me to send an initial message announcing the conference ID = for which this TLS is going to used for. Rather than the alternative of = trying distinguish TLS connections via transport 5 tuples or something = like that. Question 1: do we all agree that we can=E2=80=99t make it a requirement = of the over all PERC spec to require distinguished certs per conference? Question 2: assuming the answer to Q1 is yes, do we all agree that at a = minimum the MD needs to send a conf ID to the KD as part of the Tunneled = DTLS messages? Question 3: should we postpone the whole conf ID topic until we have a = basic understanding if the required signaling? Thank you Nils Ohlmeier= From nobody Wed Nov 16 16:00:39 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDB312946F for ; Wed, 16 Nov 2016 16:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 3YxcL4Bt-YUz for ; Wed, 16 Nov 2016 16:00:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B084129429 for ; Wed, 16 Nov 2016 16:00:36 -0800 (PST) Received: from dhcp-978a.meeting.ietf.org (dhcp-978a.meeting.ietf.org [31.133.151.138]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAH00YFg000272 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Nov 2016 18:00:35 -0600 (CST) (envelope-from adam@nostrum.com) To: Nils Ohlmeier , perc@ietf.org References: From: Adam Roach Message-ID: Date: Thu, 17 Nov 2016 09:00:33 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Perc] Conference ID for the tunnel protocol follow up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 00:00:38 -0000 I think we're making this a bit more complicated than it needs to be. Rather than starting from first principles, I'd encourage you to consider how conferencing correlation is done presently. SIP, for example, uses conference identifiers at the signaling layer, and the uses distinct ports in the SDP for each conference in order to tell which incoming connection is associated with which conference. I presume most or all WebRTC conference services do the same thing. We're not going to want to reinvent any of the existing techniques for setting up conferences -- including participant correlation -- we just want to enhance them enough to get the KD involved, and to get the security information properly distributed and authenticated. RFC4353 and the documents it references are a good starting point for refreshing our collective memories on the topic. /a On 11/17/16 08:11, Nils Ohlmeier wrote: > Hello, > > After watching the recording of the PERC meeting again it appears that I failed to explain the topic of the conference ID properly. So I’ll try again, this time in writing. > > Assumption #1: there is some signaling system which talks to the MD, the KD and the clients to setup a conference. And this signaling system obviously knows which participants belong into which conference. > > Assumption #2: the KD needs to be informed by the signaling system about the certificate fingerprints to be able to verify that the expected participants join a given conference (this need to happen no matter if the KD is running in a browser or somewhere else). > > Further if I’m not mis-taken I heard in the meeting that we can’t make it a requirement that each client uses a new, distinct cert for each conference it wants to join. > > Lets assume Alice is already in a conference A which is hosted by KD X and MD Y. Now while still being in conference A she also wants to join conference B. > Since KD X and MD Y are hosting already conference A we can assume they have established a TLS connection already. > > Now as a minimum the signaling system needs to contact the MD Y to let it know that Alice wants to join conference B for which KD X is also going to be gatekeeper. This is needed so that the MD knows where to forward Alice new incoming DTLS packets to. > Obviously the signaling system also talks to the KD X to tell it that is going to be a conference B with Alice plus some other participants in it. > > Alice sends her DTLS client hello to MD Y, which then forwards it to KD X through the already established TLS connection. > > At this point KD X has a problem. Since it already has a DTLS connection with Alice and Alice re-uses her cert it can not distinguish Alice in conf A from Alice in conf B, unless the MD sends the unique conference ID as part of the Tunneled DTLS message (which I tried to explain as Option #1 during the meeting). > > Option #2 (the KD sends the conf ID as part of the Media Keys message to the MD) and option #3 (no conf ID’s in the tunneling protocol at all) won’t work, if we can’t make the requirement that Alice needs to use distinguished certs for each conference she wants to join. > > The only other option I see, which was not presented or discussed during the meeting, would be that the KD actually opens another TLS connection to the MD for every new conference. If there is then a way for the signaling system to instruct the MD to forward Alice DTLS packets from the new connection to the given TLS connection #2 (which would be the connection for conf B - assuming TLS connection #1 is for conf A), that would allow the KD to distinguish Alice in conf A from Alice in conf B via it’s TLS connections #1 and #2 it holds to MD Y. > But if we require a new TLS connection per conference it would only feel natural to me to send an initial message announcing the conference ID for which this TLS is going to used for. Rather than the alternative of trying distinguish TLS connections via transport 5 tuples or something like that. > > Question 1: do we all agree that we can’t make it a requirement of the over all PERC spec to require distinguished certs per conference? > > Question 2: assuming the answer to Q1 is yes, do we all agree that at a minimum the MD needs to send a conf ID to the KD as part of the Tunneled DTLS messages? > > Question 3: should we postpone the whole conf ID topic until we have a basic understanding if the required signaling? > > Thank you > Nils Ohlmeier > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Sat Nov 19 18:04:08 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E570F1293FF for ; Sat, 19 Nov 2016 18:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAsXglCT_4z4 for ; Sat, 19 Nov 2016 18:04:05 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2532F1294E6 for ; Sat, 19 Nov 2016 18:04:05 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id uAK242SO016206 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 19 Nov 2016 21:04:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1479607444; bh=tS+Uo3SkuB07BlxUKU7k2cVuRpDa5HsiIyJhwd+W0kw=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=NdMcuo4lnQ2gNuR+xJdLbt47Q9DNUy4NJ55KKGcbIYWVLHZNh/L+2sa6dH/TuR51y QfdLI+FxY757+dAPJ42/DH/K4q0ZpBeWnplaMWB+mIVYEWqYobUkVbpgcgUGXSl/Te tUrvywA+j+Rf922aOBqjxSR4BwQtdEYUBsSgEifQ= From: "Paul E. Jones" To: "Adam Roach" , "Nils Ohlmeier" , perc@ietf.org Date: Sun, 20 Nov 2016 02:04:09 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Sat, 19 Nov 2016 21:04:04 -0500 (EST) Archived-At: Subject: Re: [Perc] Conference ID for the tunnel protocol follow up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 02:04:07 -0000 Adam, Perhaps the explanation sounds more complex than it is, but there is a=20 problem to solve: if Alice attempts to join two conferences=20 simultaneously, how does the KD know which key to provide to which of=20 two incoming DTLS associations? I'll present the options differently, as some are slightly different and= =20 I have my views on why some are better than others. One idea was to use distinct certificates for each parallel call. The=20 certificate fingerprints would be signaled in SDP, which would allow the= =20 KD to know which DTLS association is which. (Like Nils, I also=20 understood that people did not want to require unique certificates for=20 calls placed in parallel. That's unfortunate, as it would have been=20 pretty clean, IHMO.) We could signal a conference identifier in the DTLS-SRTP-EKT extension. = =20 For example, we could introduce a field that contains the focus URI. If= =20 we take this path, we need to make a change to the EKT draft. I don't=20 favor this option too much, since it fattens the CLientHello message. A third option is for the MD to indicate the conference identifier to=20 the KD via the tunnel protocol. We introduced a field for this in this=20 latest tunnel draft, but it's unfortunate we have to do that since this=20 requires the MD to know this piece of information it would not otherwise= =20 need to know. (I will assert that there is no need for a media=20 switching / mixing function to know this information today, though other= =20 conference control functions residing outside of this device would need=20 to know it. We could push a conference correlation identifier down to=20 the MD that would somehow be known to the KD, but I'd prefer to keep=20 this information out of the MD.) In any case, there is a problem to be solved that is brought about by=20 the use of a separate KD function that cannot (independently) correlate=20 incoming DTLS associations with a conference key. We would have the=20 same issue if we used an OOB keying approach (e.g., a REST call to a key= =20 server from the endpoint). Though the DTLS-SRTP is in-band from the=20 client's perspective, it's OOB from the KD's perspective. Paul ------ Original Message ------ From: "Adam Roach" To: "Nils Ohlmeier" ; perc@ietf.org Sent: 11/16/2016 7:00:33 PM Subject: Re: [Perc] Conference ID for the tunnel protocol follow up >I think we're making this a bit more complicated than it needs to be.=20 >Rather than starting from first principles, I'd encourage you to=20 >consider how conferencing correlation is done presently. SIP, for=20 >example, uses conference identifiers at the signaling layer, and the=20 >uses distinct ports in the SDP for each conference in order to tell=20 >which incoming connection is associated with which conference. I=20 >presume most or all WebRTC conference services do the same thing. We're= =20 >not going to want to reinvent any of the existing techniques for=20 >setting up conferences -- including participant correlation -- we just=20 >want to enhance them enough to get the KD involved, and to get the=20 >security information properly distributed and authenticated. > >RFC4353 and the documents it references are a good starting point for=20 >refreshing our collective memories on the topic. > >/a > >On 11/17/16 08:11, Nils Ohlmeier wrote: >>Hello, >> >>After watching the recording of the PERC meeting again it appears that= =20 >>I failed to explain the topic of the conference ID properly. So I=E2=80= =99ll=20 >>try again, this time in writing. >> >>Assumption #1: there is some signaling system which talks to the MD,=20 >>the KD and the clients to setup a conference. And this signaling=20 >>system obviously knows which participants belong into which=20 >>conference. >> >>Assumption #2: the KD needs to be informed by the signaling system=20 >>about the certificate fingerprints to be able to verify that the=20 >>expected participants join a given conference (this need to happen no=20 >>matter if the KD is running in a browser or somewhere else). >> >>Further if I=E2=80=99m not mis-taken I heard in the meeting that we can= =E2=80=99t make=20 >>it a requirement that each client uses a new, distinct cert for each=20 >>conference it wants to join. >> >>Lets assume Alice is already in a conference A which is hosted by KD X= =20 >>and MD Y. Now while still being in conference A she also wants to join= =20 >>conference B. >>Since KD X and MD Y are hosting already conference A we can assume=20 >>they have established a TLS connection already. >> >>Now as a minimum the signaling system needs to contact the MD Y to let= =20 >>it know that Alice wants to join conference B for which KD X is also=20 >>going to be gatekeeper. This is needed so that the MD knows where to=20 >>forward Alice new incoming DTLS packets to. >>Obviously the signaling system also talks to the KD X to tell it that=20 >>is going to be a conference B with Alice plus some other participants=20 >>in it. >> >>Alice sends her DTLS client hello to MD Y, which then forwards it to=20 >>KD X through the already established TLS connection. >> >>At this point KD X has a problem. Since it already has a DTLS=20 >>connection with Alice and Alice re-uses her cert it can not=20 >>distinguish Alice in conf A from Alice in conf B, unless the MD sends=20 >>the unique conference ID as part of the Tunneled DTLS message (which I= =20 >>tried to explain as Option #1 during the meeting). >> >>Option #2 (the KD sends the conf ID as part of the Media Keys message=20 >>to the MD) and option #3 (no conf ID=E2=80=99s in the tunneling protocol= at=20 >>all) won=E2=80=99t work, if we can=E2=80=99t make the requirement that= Alice needs to=20 >>use distinguished certs for each conference she wants to join. >> >>The only other option I see, which was not presented or discussed=20 >>during the meeting, would be that the KD actually opens another TLS=20 >>connection to the MD for every new conference. If there is then a way=20 >>for the signaling system to instruct the MD to forward Alice DTLS=20 >>packets from the new connection to the given TLS connection #2 (which=20 >>would be the connection for conf B - assuming TLS connection #1 is for= =20 >>conf A), that would allow the KD to distinguish Alice in conf A from=20 >>Alice in conf B via it=E2=80=99s TLS connections #1 and #2 it holds to= MD Y. >>But if we require a new TLS connection per conference it would only=20 >>feel natural to me to send an initial message announcing the=20 >>conference ID for which this TLS is going to used for. Rather than the= =20 >>alternative of trying distinguish TLS connections via transport 5=20 >>tuples or something like that. >> >>Question 1: do we all agree that we can=E2=80=99t make it a requirement= of the=20 >>over all PERC spec to require distinguished certs per conference? >> >>Question 2: assuming the answer to Q1 is yes, do we all agree that at=20 >>a minimum the MD needs to send a conf ID to the KD as part of the=20 >>Tunneled DTLS messages? >> >>Question 3: should we postpone the whole conf ID topic until we have a= =20 >>basic understanding if the required signaling? >> >>Thank you >> Nils Ohlmeier >>_______________________________________________ >>Perc mailing list >>Perc@ietf.org >>https://www.ietf.org/mailman/listinfo/perc > > >_______________________________________________ >Perc mailing list >Perc@ietf.org >https://www.ietf.org/mailman/listinfo/perc From nobody Sun Nov 20 03:27:57 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A26129631 for ; Sun, 20 Nov 2016 03:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 jSFXQMfrqfsd for ; Sun, 20 Nov 2016 03:27:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FC8129604 for ; Sun, 20 Nov 2016 03:27:54 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAKBRp26082655 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 20 Nov 2016 05:27:52 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Paul E. Jones" , Nils Ohlmeier , perc@ietf.org References: From: Adam Roach Message-ID: Date: Sun, 20 Nov 2016 05:27:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] Conference ID for the tunnel protocol follow up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 11:27:55 -0000 On 11/19/16 20:04, Paul E. Jones wrote: > I will assert that there is no need for a media switching / mixing > function to know this information today It's not clear why you think that is true. If a mixer is running 3 conferences and receiving 10 streams, how does it know which streams to mix together? /a From nobody Sun Nov 20 10:56:44 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26C8129784 for ; Sun, 20 Nov 2016 10:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kpj_bu6Z97D for ; Sun, 20 Nov 2016 10:56:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F6012978B for ; Sun, 20 Nov 2016 10:56:41 -0800 (PST) Received: from dyn-167.arid.us (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id uAKIucda018724 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2016 13:56:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1479668200; bh=3ysu85OzYV/eAsinkT+PZFJ3GmUUUX78xDLc/ws8tgs=; h=In-Reply-To:References:Subject:From:Date:To; b=Dg1g+CDUiTqlMGGh2Fz/zK0thGEENNxBaf+vSAJ+mB9ZBjNheLtfJ8+UJG306IrH8 djwphma7Ib/fMtdZrzFBi+JfB+CobTWj2I8t6nMJLt/Z5djN/6NfYXACWcw5Bgv2Gq qC5fyMzO0/ZjzNgAk3Mcct03OB95A/jiN+m09zCg= User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----D16GHL2J2H4VW84KTXO1HQ9MUV3JU5" Content-Transfer-Encoding: 8bit From: "Paul E. Jones" Date: Sun, 20 Nov 2016 13:56:37 -0500 To: Adam Roach , Nils Ohlmeier , perc@ietf.org Message-ID: <66AE9ABB-CAD1-457F-8632-A65F30D14B9A@packetizer.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Sun, 20 Nov 2016 13:56:40 -0500 (EST) Archived-At: Subject: Re: [Perc] Conference ID for the tunnel protocol follow up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 18:56:43 -0000 ------D16GHL2J2H4VW84KTXO1HQ9MUV3JU5 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Adam, Distributed conferencing systems have been built this way for years, decades even. The call processing exists in one device and media processing in another. The media processing function is told how to associate media flows, but doesn't have to have any notion of a conference identifier. As far back as 1995, H.323 systems defined logical fictions of media controller (MC) and media processor (MP). The same concept carried over into MGCP and H.248, where call control and media processing are separated. It's unnecessary to tell a media processor about a conference identifier or to understand who is and isn't in a conference. Minimal device control to the MPs is all that's required. Modern systems use this same model, including Cisco's newest product. This separation exists for scalability. It's possible to build a call signaling function that is optimized for signaling. The controller can then control a large number of separate media processors, increasing the overall scale of the conference. The cloud is a perfect use case for such separation, as spinning up new media processors is very dynamic. Paul -------- Original Message -------- From: Adam Roach Sent: November 20, 2016 6:27:51 AM EST To: "Paul E. Jones" , Nils Ohlmeier , perc@ietf.org Subject: Re: [Perc] Conference ID for the tunnel protocol follow up On 11/19/16 20:04, Paul E. Jones wrote: > I will assert that there is no need for a media switching / mixing > function to know this information today It's not clear why you think that is true. If a mixer is running 3 conferences and receiving 10 streams, how does it know which streams to mix together? /a ------D16GHL2J2H4VW84KTXO1HQ9MUV3JU5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Adam,

Distributed conferencing systems have been built this way for years, decades even. The call processing exists in one device and media processing in another. The media processing function is told how to associate media flows, but doesn't have to have any notion of a conference identifier.

As far back as 1995, H.323 systems defined logical fictions of media controller (MC) and media processor (MP). The same concept carried over into MGCP and H.248, where call control and media processing are separated.

It's unnecessary to tell a media processor about a conference identifier or to understand who is and isn't in a conference. Minimal device control to the MPs is all that's required.

Modern systems use this same model, including Cisco's newest product. This separation exists for scalability. It's possible to build a call signaling function that is optimized for signaling. The controller can then control a large number of separate media processors, increasing the overall scale of the conference. The cloud is a perfect use case for such separation, as spinning up new media processors is very dynamic.

Paul

From: Adam Roach <adam@nostrum.com>
Sent: November 20, 2016 6:27:51 AM EST
To: "Paul E. Jones" <paulej@packetizer.com>, Nils Ohlmeier <nohlmeier@mozilla.com>, perc@ietf.org
Subject: Re: [Perc] Conference ID for the tunnel protocol follow up

On 11/19/16 20:04, Paul E. Jones wrote:
 I will assert that there is no need for a media switching / mixing 
 function to know this information today


It's not clear why you think that is true. If a mixer is running 3 
conferences and receiving 10 streams, how does it know which streams to 
mix together?

/a

------D16GHL2J2H4VW84KTXO1HQ9MUV3JU5-- From nobody Sun Nov 20 12:54:58 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919B1129639 for ; Sun, 20 Nov 2016 12:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] 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 wixLIhaRoVlT for ; Sun, 20 Nov 2016 12:54:56 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1874129600 for ; Sun, 20 Nov 2016 12:54:55 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uAKKss9T028979 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 20 Nov 2016 14:54:55 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Paul E. Jones" , Nils Ohlmeier , perc@ietf.org References: <66AE9ABB-CAD1-457F-8632-A65F30D14B9A@packetizer.com> From: Adam Roach Message-ID: <878d6448-8c38-cdd6-935f-392a20a4d077@nostrum.com> Date: Sun, 20 Nov 2016 14:54:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <66AE9ABB-CAD1-457F-8632-A65F30D14B9A@packetizer.com> Content-Type: multipart/alternative; boundary="------------710F1EC842C7CAF6A92C6AE9" Archived-At: Subject: Re: [Perc] Conference ID for the tunnel protocol follow up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 20:54:57 -0000 This is a multi-part message in MIME format. --------------710F1EC842C7CAF6A92C6AE9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit You're missing my point. There is some logical construct in the mixer that represents the conference, and some identifier the controller uses to talk about that construct. Yes? /a On 11/20/16 12:56, Paul E. Jones wrote: > Adam, > > Distributed conferencing systems have been built this way for years, > decades even. The call processing exists in one device and media > processing in another. The media processing function is told how to > associate media flows, but doesn't have to have any notion of a > conference identifier. > > As far back as 1995, H.323 systems defined logical fictions of media > controller (MC) and media processor (MP). The same concept carried > over into MGCP and H.248, where call control and media processing are > separated. > > It's unnecessary to tell a media processor about a conference > identifier or to understand who is and isn't in a conference. Minimal > device control to the MPs is all that's required. > > Modern systems use this same model, including Cisco's newest product. > This separation exists for scalability. It's possible to build a call > signaling function that is optimized for signaling. The controller can > then control a large number of separate media processors, increasing > the overall scale of the conference. The cloud is a perfect use case > for such separation, as spinning up new media processors is very dynamic. > > Paul > > ------------------------------------------------------------------------ > *From:* Adam Roach > *Sent:* November 20, 2016 6:27:51 AM EST > *To:* "Paul E. Jones" , Nils Ohlmeier > , perc@ietf.org > *Subject:* Re: [Perc] Conference ID for the tunnel protocol follow up > > On 11/19/16 20:04, Paul E. Jones wrote: > > I will assert that there is no need for a media switching / mixing > function to know this information today > > > > It's not clear why you think that is true. If a mixer is running 3 > conferences and receiving 10 streams, how does it know which streams to > mix together? > > /a > --------------710F1EC842C7CAF6A92C6AE9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
You're missing my point. There is some logical construct in the mixer that represents the conference, and some identifier the controller uses to talk about that construct. Yes?

/a

On 11/20/16 12:56, Paul E. Jones wrote:
Adam,

Distributed conferencing systems have been built this way for years, decades even. The call processing exists in one device and media processing in another. The media processing function is told how to associate media flows, but doesn't have to have any notion of a conference identifier.

As far back as 1995, H.323 systems defined logical fictions of media controller (MC) and media processor (MP). The same concept carried over into MGCP and H.248, where call control and media processing are separated.

It's unnecessary to tell a media processor about a conference identifier or to understand who is and isn't in a conference. Minimal device control to the MPs is all that's required.

Modern systems use this same model, including Cisco's newest product. This separation exists for scalability. It's possible to build a call signaling function that is optimized for signaling. The controller can then control a large number of separate media processors, increasing the overall scale of the conference. The cloud is a perfect use case for such separation, as spinning up new media processors is very dynamic.

Paul

From: Adam Roach <adam@nostrum.com>
Sent: November 20, 2016 6:27:51 AM EST
To: "Paul E. Jones" <paulej@packetizer.com>, Nils Ohlmeier <nohlmeier@mozilla.com>, perc@ietf.org
Subject: Re: [Perc] Conference ID for the tunnel protocol follow up

On 11/19/16 20:04, Paul E. Jones wrote:

 I will assert that there is no need for a media switching / mixing 
 function to know this information today



It's not clear why you think that is true. If a mixer is running 3 
conferences and receiving 10 streams, how does it know which streams to 
mix together?

/a


--------------710F1EC842C7CAF6A92C6AE9-- From nobody Sun Nov 20 14:46:36 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52111294B4 for ; Sun, 20 Nov 2016 14:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljyIbQQ5fi6L for ; Sun, 20 Nov 2016 14:46:33 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D2C12946D for ; Sun, 20 Nov 2016 14:46:33 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-167-029.nc.res.rr.com [98.122.167.29] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id uAKMkVKT002031 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Nov 2016 17:46:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1479681992; bh=zFI3PunJ99EQ/5k6BfwGflfqRTw90uVCHtF6rEx6kkM=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=XXVLI0MLjeZdHYo6B/jDw7B9kcmP+hPrGHtQdRDcuXulnTwSwP43i7ceoqb4WiAis IEBnxUq267D07MvuQJ9XqTeSAQDg1KX5uRYKuly3+oeMtU23GAQDvD64aD7hOF2mya L6IpC2GsOd0eXoYt3FW+PNAf0jclImWItYcsvaRw= From: "Paul E. Jones" To: "Adam Roach" , "Nils Ohlmeier" , perc@ietf.org Date: Sun, 20 Nov 2016 22:46:39 +0000 Message-Id: In-Reply-To: <878d6448-8c38-cdd6-935f-392a20a4d077@nostrum.com> References: <66AE9ABB-CAD1-457F-8632-A65F30D14B9A@packetizer.com> <878d6448-8c38-cdd6-935f-392a20a4d077@nostrum.com> User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB8FEB08F7-0C42-432A-AABF-E308354B75E9" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Sun, 20 Nov 2016 17:46:32 -0500 (EST) Archived-At: Subject: Re: [Perc] Conference ID for the tunnel protocol follow up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 22:46:35 -0000 --------=_MB8FEB08F7-0C42-432A-AABF-E308354B75E9 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Adam, Yes, the media controller knows a conference identifier via call control= =20 signaling. And, yes, there is some means through which the controller=20 tells the media processor to conference flows (including cascading=20 through multiple media processors), thus some abstract notion of a=20 conference distributed over one or more media processors. Importantly,=20 how a media processor understands to relate media flows is divorced from= =20 call control signaling, and my argument is that we should not take a=20 protocol-specific conference identifier and push it down to the media=20 processor. So how am I missing your point? Paul ------ Original Message ------ From: "Adam Roach" To: "Paul E. Jones" ; "Nils Ohlmeier"=20 ; perc@ietf.org Sent: 11/20/2016 3:54:54 PM Subject: Re: [Perc] Conference ID for the tunnel protocol follow up >You're missing my point. There is some logical construct in the mixer=20 >that represents the conference, and some identifier the controller uses= =20 >to talk about that construct. Yes? > >/a > >On 11/20/16 12:56, Paul E. Jones wrote: >>Adam, >> >>Distributed conferencing systems have been built this way for years,=20 >>decades even. The call processing exists in one device and media=20 >>processing in another. The media processing function is told how to=20 >>associate media flows, but doesn't have to have any notion of a=20 >>conference identifier. >> >>As far back as 1995, H.323 systems defined logical fictions of media=20 >>controller (MC) and media processor (MP). The same concept carried=20 >>over into MGCP and H.248, where call control and media processing are=20 >>separated. >> >>It's unnecessary to tell a media processor about a conference=20 >>identifier or to understand who is and isn't in a conference. Minimal=20 >>device control to the MPs is all that's required. >> >>Modern systems use this same model, including Cisco's newest product.=20 >>This separation exists for scalability. It's possible to build a call=20 >>signaling function that is optimized for signaling. The controller can= =20 >>then control a large number of separate media processors, increasing=20 >>the overall scale of the conference. The cloud is a perfect use case=20 >>for such separation, as spinning up new media processors is very=20 >>dynamic. >> >>Paul >> >>-------------------------------------------------------------------------= ------- >>From: Adam Roach >>Sent: November 20, 2016 6:27:51 AM EST >>To: "Paul E. Jones" , Nils Ohlmeier=20 >>, perc@ietf.org >>Subject: Re: [Perc] Conference ID for the tunnel protocol follow up >> >>On 11/19/16 20:04, Paul E. Jones wrote: >> >>I will assert that there is no need for a media switching / mixing=20 >>function to know this information today It's not clear why you think=20 >>that is true. If a mixer is running 3 conferences and receiving 10=20 >>streams, how does it know which streams to mix together? /a > > --------=_MB8FEB08F7-0C42-432A-AABF-E308354B75E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20
Adam,

Yes, the media= controller knows a conference identifier via call control signaling.  = ;And, yes, there is some means through which the controller tells the media= processor to conference flows (including cascading through multiple media= processors), thus some abstract notion of a conference distributed over= one or more media processors.  Importantly, how a media processor = understands to relate media flows is divorced from call control signaling,= and my argument is that we should not take a protocol-specific conference= identifier and push it down to the media processor.

So how am I missing your point?

Paul
=
------ Original Message ------
From: "Adam Roach" <adam@nostru= m.com>
To: "Paul E. Jones" <paule= j@packetizer.com>; "Nils Ohlmeier" <nohlmeier@mozilla.com>; perc@ietf.org
Sent: 11/20/2016 3:54:54 PM
Subject: Re: [Perc] Conference ID for the tunnel protocol follow up

You're missing my point. There is some logical construct in the mixer that represents the conference, and some identifier the controller uses to talk about that construct. Yes?

/a

On 11/20/16 12:56, Paul E. Jones wrote:
Adam,

Distributed conferencing systems have been built this way for years, decades even. The call processing exists in one device and media processing in another. The media processing function is told how to associate media flows, but doesn't have to have any notion of a conference identifier.

As far back as 1995, H.323 systems defined logical fictions of media controller (MC) and media processor (MP). The same concept carried over into MGCP and H.248, where call control and media processing are separated.

It's unnecessary to tell a media processor about a conference identifier or to understand who is and isn't in a conference. Minimal device control to the MPs is all that's required.

Modern systems use this same model, including Cisco's newest product. This separation exists for scalability. It's possible to build a call signaling function that is optimized for signaling. The controller can then control a large number of separate media processors, increasing the overall scale of the conference. The cloud is a perfect use case for such separation, as spinning up new media processors is very dynamic.

Paul

From: Adam Roach <adam@nostrum.com>
Sent: November 20, 2016 6:27:51 AM EST
To: "Paul E. Jones" <paulej@packetizer.com>, Nils Ohlmeier <nohlmeier@mozilla.com>, perc@ietf.org
Subject: Re: [Perc] Conference ID for the tunnel protocol follow up

On 11/19/16 20:04, Paul E. Jones wrote:

 I will assert that there=
 is no need for a media switching / mixing=20
 function to know this information today



It's not clear why you think that is true. If a mixer is running 3=20
conferences and receiving 10 streams, how does it know which streams to=20
mix together?

/a


--------=_MB8FEB08F7-0C42-432A-AABF-E308354B75E9--