Hi,

An interesting variant of Stefan's use case is when the central media 
node is provided by an untrusted 3rd-party. The application provider and 
the users trust the 3rd party to deliver the media as expected, but they 
do not necessarily trust it with cleartext media, be that audio, video 
or data.

The benefit is that the application provider can be less picky when 
selecting the 3rd-party provider(s). Having a large pool to choose from 
makes it easier to switch provider or select the cheapest or 
geographically closest one.

         +---+      +------------+      +---+
         | A |<---->|            |<---->| B |
         +---+      | Translator |      +---+
         +---+      |(untrusted) |      +---+
         | C |<---->|            |<---->| D |
         +---+      +------------+      +---+


A requirement for this to work is that group keys are supported. This 
allows the central media node to simply forward the media without 
decrypting and re-encrypting it for each recipient. The fact that the 
central media node becomes less complex and can achieve higher 
throughput is of course beneficial, but it's not the main purpose.

Another requirement is that the group key can be distributed by the 
application provider (or some other trusted party) without the central 
media node learning its value. This can easily be achieved in 
DTLS-SRTP + EKT by using the a=dtls-srtp-host attribute. The host 
specified in the attribute performs an initial DTLS-SRTP handshake with 
each party and transmits the shared EKT key (i.e. the group key).

                    +------------+ 
                    | Key Server |
   |-----EKTkey---- | (trusted)  | ----EKTkey-----|
   |                |            |                |
   |                +------------+                |
   |                                              |
   |     +---+      +------------+      +---+     |
   |---> | A |<---->|            |<---->| B | <---|
   |     +---+      | Translator |      +---+     |
   |     +---+      |(untrusted) |      +---+     |
   |---> | C |<---->|            |<---->| D | <---|
         +---+      +------------+      +---+


Is the above something that this group would like to support or 
investigate further?

Best regards,

Oscar Ohlsson

> -----Original Message-----
> From: rtcweb-bounces@ietf.org 
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Stefan Hakansson LK
> Sent: Friday, May 11, 2012 3:01 PM
> To: rtcweb@ietf.org
> Subject: [rtcweb] New use-case proposed
> 
> I've been sketching on a new use-case. The use-case is 
> intended to derive requirements that enable low complex 
> central nodes for multi party sessions, which in turn leads 
> to requirements regarding
> (essentially) keying solution for SRTP and the possibility 
> for the app to control/set things in the media configuration 
> (in other words, for JSEP):
> 
> 
> Multi-party with low complexity central node 
> ==============================================
> 
> A geographically spread (charity, non-profit, school) 
> organization offers its members multi-party video 
> communication via a shared virtual room that participants can 
> enter and leave at any time. At times there are many persons 
> in the virtual room (20+), at other times very few (3-5, or even 0-1).
> 
> The application will control if few participants (a subset) 
> are shown at a higher fidelity or if many (all) are shown at 
> a lower fidelity or a mix of some few at high fidelity and 
> the rest at much lower fidelity given the existing bandwidth 
> limitations between participants.
> 
> Since there are at times many persons in the virtual room, it 
> is not feasible to set up a mesh. The bandwidth needed by a 
> participant exceeds what many members have access to, 
> especially in their uplinks, so instead a central media node 
> is deployed. In addition, the organization does not have 
> access to much funds, but has to rely on cheap hardware 
> (often donated) operated by volunteers.
> 
>   From this use-case a high level requirement saying something like
> 
> "It must be possible to set up media streams and encryption 
> in such a way that processing in a central node is minimized 
> (no transcoding required, no RTP packet rewriting, no 
> decryption/re-encryption for every outgoing flow - just 
> simple forwarding)."
> 
> can be derived. This can in turn be broken down into more 
> detailed requirements such as:
> 
> - The keying solution must allow each participants to encrypt 
> to multiple receivers without any decryption+encryption in 
> the middle node
> 
> - RTP sessions that have SSRCs from multiple PeerConnections 
> being interconneted must be supported. From a given end-point 
> all SSRCs will come over one PC, but the full path will be 
> different towards different sets of SSRCs.
> 
> - Signalling must be capable of establishing a common set of 
> receiver configurations over all participants.
> 
> - The API must allow for the above, i.e.:
> -- The app must be able to chose a keying solution that 
> enables encryption to multiple receivers (if the app can have 
> any control over keying method used)
> -- The app must be able to control SSRCs to use for outgoing streams
> -- The app must be able to control the receiver configuration 
> the browser uses
> 
> Is this something we should consider adding to the use-case document?
> 
> Br,
> Stefan
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>