Subject: [rtcweb] New use-case proposed

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 11 May 2012 15:01:00 +0200

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

---

From: Justin Uberti <[email-masked]>
Date: Fri, 11 May 2012 10:24:12 -0400

SRTP encryption is cheap, practically free on today's CPUs. I agree with
the general use case but I don't agree with the conclusion that we need to
require that the middlebox does not rewrite packets or perform crypto,
mainly since it will increase system complexity (and the system is already
quite complex).

On Fri, May 11, 2012 at 9:01 AM, Stefan Hakansson LK <
[email-masked]> wrote:

> ==============================**================
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 11 May 2012 17:54:56 +0200

11 maj 2012 kl. 16:24 skrev "Justin Uberti" <[email-masked]<mailto:[email-masked]>>:

SRTP encryption is cheap, practically free on today's CPUs. I agree with the general use case but I don't agree with the conclusion that we need to require that the middlebox does not rewrite packets or perform crypto, mainly since it will increase system complexity (and the system is already quite complex).

Just to make sure I understand Your point- which system are U referring to: the browser UA; the media processing support node or the whole lot?

Regards
Göran

On Fri, May 11, 2012 at 9:01 AM, Stefan Hakansson LK <[email-masked]<mailto:[email-masked]>> wrote:

Br,
Stefan
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 May 2012 18:21:27 +0200

I propose to reject this use case because it requires yet another 
security redesign.

> multiple receivers without any decryption+encryption in the middle node

This means that each participant must use the same encryption keys to 
all other participants; this in turn means that when someone leaves the 
group, all participants must change their encryption keys; it also means 
that as long as shared keys are used for authentication, all 
participants can impersonate all other participants.

In fact, this solution has most of the issues (except for the network 
layer deployment issue) that leads me to strongly advocate leaving 
multicast out of scope for this effort.

                Harald

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 May 2012 12:26:24 -0400

+1

I have provided the CPU requirements for doing SRTP re-encryption before.
Bottom line, on the real conferencing service encryption adds about 10%
extra CPU load. There is no benefit in compromising security to avoid
re-encrypting.
_____________
Roman Shpount

On Fri, May 11, 2012 at 12:21 PM, Harald Alvestrand <[email-masked]>wrote:

> I propose to reject this use case because it requires yet another security
> redesign.
> The clue is here:
>
>
> This means that each participant must use the same encryption keys to all
> other participants; this in turn means that when someone leaves the group,
> all participants must change their encryption keys; it also means that as
> long as shared keys are used for authentication, all participants can
> impersonate all other participants.
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 11 May 2012 18:38:35 +0200

> multicast out of scope for this effort.

You mean for this phase of webrtc std efforts or for ever?

Regards
Göran

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 11 May 2012 10:26:30 -0700

I agree as well since based on our testing for a simple media bridge
that SRTP re-encryption adds a similar amount of CPU load (around 10%). 

Henry

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roman Shpount
Sent: May-11-12 12:26 PM
To: Harald Alvestrand
Cc: [email-masked]
Subject: Re: [rtcweb] New use-case proposed

+1

I have provided the CPU requirements for doing SRTP re-encryption
before. Bottom line, on the real conferencing service encryption adds
about 10% extra CPU load. There is no benefit in compromising security
to avoid re-encrypting.
_____________
Roman Shpount

On Fri, May 11, 2012 at 12:21 PM, Harald Alvestrand
<[email-masked]> wrote:

              Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 May 2012 22:52:14 +0200

On 05/11/2012 06:38 PM, Göran Eriksson AP wrote:
>
> 11 maj 2012 kl. 18:21 skrev "Harald Alvestrand"<[email-masked]>:
>
Until we've got an usage scenario with a deployment story that I find 
credible.

The point I'm pretty vehement on - that lack of multicast support should 
not be a blocker for finalizing the specs we are working on.

               Harald

---

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 11 May 2012 23:31:22 +0200

> not be a blocker for finalizing the specs we are working on.

I am pretty sensitive to such consequence as well! Having said that, enabling innovation in this kind of application category is important  for the long term evolution of the web platform.

Personally, I would like to us to ensure we have at least have a good foundation for multicast later.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 May 2012 15:24:57 -0700

> foundation for multicast later.

EKT, draft-ietf-avt-srtp-ekt, does that, and works with the initial
keying being Security Descriptions (should we allow that in RTCWEB) 
and with DTLS-SRTP.

-d

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 11 May 2012 21:11:39 -0400

> keying being Security Descriptions (should we allow that in RTCWEB)

Note : This draft expired last week. I presume that is not truly
indicative of its status.

Regards
Marshall

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 May 2012 18:41:13 -0700

> -----Original Message-----
> From: Marshall Eubanks [mailto:[email-masked]]
> Sent: Friday, May 11, 2012 6:12 PM
> To: Dan Wing
> Cc: Göran Eriksson AP; Harald Alvestrand; [email-masked]
> >> Personally, I would like to us to ensure we have at least have a
> good
> >> foundation for multicast later.
> >

We are integrating the changes described in 
http://www.ietf.org/mail-archive/web/avt/current/msg15232.html,
which I summarized in my RTCWEB presentation, starting on
slide 28 of http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-3.pdf

In that deck, slide 28 shows the problem of interworking DTLS-SRTP
with Security Descriptions -- namely, that something needs to 
decrypt and re-encrypt SRTP packets in one direction.  This is shown
with flames coming out of that box.  (Its CPU is on fire.)

Slide 31 explains how EKT helps that interoperation.

Slide 33 shows how the interoperation, where the box no longer
has to decrypt/re-encrypt SRTP packets.

It was asked if we can do that interworking, between Security
Descriptions and DTLS-SRTP-EKT, without the media flowing through
a box.  Yes, we can -- except for EKT key changes (that is, key
changes from the WEBRTC side).  I have a design that will 
handle that.  But folks still need to digest the interop model
and decide if allowing SDESC on the WEBRTC side is worth the
permanent interoperation burden (on all WEBRTC endpoints) and
worth the permanent reduction of identity and of media 
encryption security.

-d

---

From: Michael Welzl <[email-masked]>
Date: Sat, 12 May 2012 10:58:05 +0200

On May 11, 2012, at 11:31 PM, Göran Eriksson AP wrote:

> I am pretty sensitive to such consequence as well! Having said that,  
> enabling innovation in this kind of application category is  
> important  for the long term evolution of the web platform.
>
> good foundation for multicast later.

+1 (to both parts of this)

Cheers
Michael

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 May 2012 09:49:50 +0200

> participants can impersonate all other participants.

Actually EKT solves this in a very reasonable way. Each participant
announces his key using EKT. When a participant leaves all the other
participants uses EKT to provide a new key for the media they send. Thus
no need for synchronized key roll over anything.

When it comes to the security aspect this I would say it is part of the
model. SRTP uses symmetric keys, thus anyone can spoof anyone that are
inside the session and having access to the crypt context. In
centralized conferencing it is the central node that enforces the
relation between each other. That can be done both using independent
crypto contexts and having shared one.

And the arguments around the complexity is not that it on a per stream
individual basis is horrible expensive. It is the argument about needing
to have the functionality doing decryption and N-1 encryptions for each
packet being forwarded to all the others in a N number of participants
conference. The argument is to have no need for any media flow
encryption and decryption only be part of the key-management.

> multicast out of scope for this effort.

I am not arguing for including IP multicast support. The issue this use
case brings up is that one of RTP support for multi-party sessions. This
use case makes it clear that a particular level of RTP functionality
support is needed. I think almost the same is needed for centralized RTP
mixer topologies where the middle node uses its own SSRCs to forward
other participants media streams and transfer RTCP feedback messages
when not possible to handle in the mixer.

Another aspect that we need to bring up here is if there is going to be
any support for a WebRTC browser to receive a media stream from A and be
capable of forwarding it to B. Without the same features as needed for
this use case we must mandate that a browser doing this supports media
transcoding. Otherwise congestion control and media control aspects will
not be supported enabling media to be delivered. Transcoding obviously
gives a significant hit on quality unless the media bit-rate is
significantly higher than without transcoding.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 May 2012 10:48:29 +0200

> no need for synchronized key roll over anything.

To make it clear, there are two levels of security here. A first one of
each participant changing keys after a participant has left and no
longer gets the traffic. If that is done without changing the EKT key
then that participant could decrypt the key, but then the attacker must
get to the media which no longer is being forwarded to it.

The second level which is recommend is to have the central node change
the EKT key by triggering DTLS based rekeying of the EKT. Then it is
impossible for the participant that left to eavesdrop on the conference.

cheers

Magnus Westerlund

---

From: Oscar Ohlsson <[email-masked]>
Date: Tue, 15 May 2012 20:27:27 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Hakansson LK
> Sent: Friday, May 11, 2012 3:01 PM
> To: [email-masked]
> 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):
> 
> 
> 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 
> "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 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 the receiver configuration 
> the browser uses
>