Subject: [Perc] Conference ID for the tunnel protocol follow up

From: Nils Ohlmeier <[email-masked]>
Date: Wed, 16 Nov 2016 15:11:52 -0800

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

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Nov 2016 09:00:33 +0900

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:
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 20 Nov 2016 02:04:09 +0000

Adam,

Perhaps the explanation sounds more complex than it is, but there is a 
problem to solve: if Alice attempts to join two conferences 
simultaneously, how does the KD know which key to provide to which of 
two incoming DTLS associations?

I'll present the options differently, as some are slightly different and 
I have my views on why some are better than others.

One idea was to use distinct certificates for each parallel call.  The 
certificate fingerprints would be signaled in SDP, which would allow the 
KD to know which DTLS association is which.  (Like Nils, I also 
understood that people did not want to require unique certificates for 
calls placed in parallel.  That's unfortunate, as it would have been 
pretty clean, IHMO.)

We could signal a conference identifier in the DTLS-SRTP-EKT extension.  
For example, we could introduce a field that contains the focus URI.  If 
we take this path, we need to make a change to the EKT draft.  I don't 
favor this option too much, since it fattens the CLientHello message.

A third option is for the MD to indicate the conference identifier to 
the KD via the tunnel protocol.  We introduced a field for this in this 
latest tunnel draft, but it's unfortunate we have to do that since this 
requires the MD to know this piece of information it would not otherwise 
need to know.  (I will assert that there is no need for a media 
switching / mixing function to know this information today, though other 
conference control functions residing outside of this device would need 
to know it.  We could push a conference correlation identifier down to 
the MD that would somehow be known to the KD, but I'd prefer to keep 
this information out of the MD.)

In any case, there is a problem to be solved that is brought about by 
the use of a separate KD function that cannot (independently) correlate 
incoming DTLS associations with a conference key.  We would have the 
same issue if we used an OOB keying approach (e.g., a REST call to a key 
server from the endpoint).  Though the DTLS-SRTP is in-band from the 
client's perspective, it's OOB from the KD's perspective.

Paul

------ Original Message ------
From: "Adam Roach" <[email-masked]>
To: "Nils Ohlmeier" <[email-masked]>; [email-masked]
Sent: 11/16/2016 7:00:33 PM
Subject: Re: [Perc] Conference ID for the tunnel protocol follow up

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

---

From: Adam Roach <[email-masked]>
Date: Sun, 20 Nov 2016 05:27:51 -0600

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: "Paul E. Jones" <[email-masked]>
Date: Sun, 20 Nov 2016 13:56:37 -0500

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 <[email-masked]>
Sent: November 20, 2016 6:27:51 AM EST
To: "Paul E. Jones" <[email-masked]>, Nils Ohlmeier <[email-masked]>, [email-masked]
Subject: Re: [Perc] Conference ID for the tunnel protocol follow up

/a

---

From: Adam Roach <[email-masked]>
Date: Sun, 20 Nov 2016 14:54:54 -0600

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 <[email-masked]>
> *Sent:* November 20, 2016 6:27:51 AM EST
> *To:* "Paul E. Jones" <[email-masked]>, Nils Ohlmeier 
> <[email-masked]>, [email-masked]
> *Subject:* Re: [Perc] Conference ID for the tunnel protocol follow up
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 20 Nov 2016 22:46:39 +0000

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" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "Nils Ohlmeier" 
<[email-masked]>; [email-masked]
Sent: 11/20/2016 3:54:54 PM
Subject: Re: [Perc] Conference ID for the tunnel protocol follow up

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