Subject: [rtcweb] Comments on draft-ietf-rtcweb-use-cases-and-requirements-07

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 May 2012 19:31:18 -0600

Cone and symmetric nat are probably not what exactly what we mean here - perhaps just refer to it as the various types of NATs described in RFC 4787. 

Might want to add to some use case that when A calls B, and B does not reveal their IP address to A.

Like to add Alice calls Bob with an encrypted media. Bob can tell the that the encrypted media is from Alice and not from an MITM

Like to add ability to make a call in a situation where even small sounds from microphone should be sent to the other side and not filtered out. Emergency calls are examples of this as are some games and "jam session"

Like to add case where application has one two video streams but one is far more important than the other. Should be a way to make sure that preferential treatment is given the the important stream over the less important streams. 

In F22, "the IVR" -> "an DTMF based IVR"

I have a hard time deciding what level the requirements should be at. It seems likely that given the level they are currently at, the requirements are somewhat incomplete. As long as we treat these as partial set of requirements derived from the use cases, I'm fine with that. 

New use case:

Imagine a service like webex that facilitates collaboration between two companies called A and B. Webex has no need to see the content of the communication from A to B. So webex might run the web server that helps set up a RTCWeb session between A and B, but webex needs to be able to write it's code such that it does not get the keying material used to encrypt the media from A to B and the companies need to be able to verify that webex did not get the keys. Webex has no need to see the media from A to B and if it can provide this sort of promise that it does not get the media, it makes it much easier for a customer (say Juniper) to use webex and know the contents of their calls are not being sold or used by a competitor. Given how much WebRTC will be used by cloud services, this is an important feature. When installing the "webex" application in the browser and granting permissions to the application, it would be good to have one of the permissions be if the JS got access to the media or keying material for it to enforce this promise. 

Note this use case is not phrase to say this is the only way it can work. This is not mutually exclusive with they type of use cases described by Skype folks where there is an explicitly desire to make sure the calling service does have the keys to decrypt the media.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 18 May 2012 14:13:48 +0200

On 05/16/2012 03:31 AM, Cullen Jennings wrote:
...
>
> New use case:
>
> Imagine a service like webex that facilitates collaboration between
> two companies called A and B. Webex has no need to see the content of
> the communication from A to B. So webex might run the web server that
> helps set up a RTCWeb session between A and B, but webex needs to be
> able to write it's code such that it does not get the keying material
> used to encrypt the media from A to B and the companies need to be
> able to verify that webex did not get the keys. Webex has no need to
> see the media from A to B and if it can provide this sort of promise
> that it does not get the media, it makes it much easier for a
> customer (say Juniper) to use webex and know the contents of their
> calls are not being sold or used by a competitor. Given how much
> WebRTC will be used by cloud services, this is an important feature.

At least on the surface, this seems to have a lot in common with what 
Oscar proposed the other day ([1]), at least if the WebEx session has 
more than one concurrent user.

[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg04457.html

> When installing the "webex" application in the browser and granting
> permissions to the application, it would be good to have one of the
> permissions be if the JS got access to the media or keying material
> for it to enforce this promise.
>
> Note this use case is not phrase to say this is the only way it can
> work. This is not mutually exclusive with they type of use cases
> described by Skype folks where there is an explicitly desire to make
> sure the calling service does have the keys to decrypt the media.
>
>
>
>
>
>
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Hakansson LK <[email-masked]>
Date: Fri, 25 May 2012 11:07:10 +0200

On 05/16/2012 03:31 AM, Cullen Jennings wrote:
>
> Cone and symmetric nat are probably not what exactly what we mean
> here - perhaps just refer to it as the various types of NATs
> described in RFC 4787.

The text was just lifted in (I have close to zero knowledge); referring 
to RFC 4787 sounds like a good idea to me.

> not reveal their IP address to A.

Based on the discussion so far, I agree that this should be added somehow.

>
> Like to add Alice calls Bob with an encrypted media. Bob can tell the
> that the encrypted media is from Alice and not from an MITM

Sounds non controversial to add to me.

>
> Like to add ability to make a call in a situation where even small
> sounds from microphone should be sent to the other side and not
> filtered out. Emergency calls are examples of this as are some games
> and "jam session"

I think this is already covered in the "Distr. music band" , with req A17.

>
> Like to add case where application has one two video streams but one
> is far more important than the other. Should be a way to make sure
> that preferential treatment is given the the important stream over
> the less important streams.

What is there now is F24: The browser MUST be able to take advantage of
                    capabilities to prioritize voice and video
                    appropriately.
This talks only about priority of audio and video relative to other 
traffic, perhaps we should add something about prioritizing between 
different audio/video flows as well.

> In F22, "the IVR" ->  "an DTMF based IVR"

Agree.

>
> I have a hard time deciding what level the requirements should be at.
> It seems likely that given the level they are currently at, the
> requirements are somewhat incomplete. As long as we treat these as
> partial set of requirements derived from the use cases, I'm fine with
> that.
>
>
> New use case:
>

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 30 May 2012 14:06:54 +0200

Hi Cullen

Inline.

Göran 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: den 16 maj 2012 03:31
> To: [email-masked]
> Subject: [rtcweb] Comments on 
> draft-ietf-rtcweb-use-cases-and-requirements-07
> 
> 
> Cone and symmetric nat are probably not what exactly what we 
> mean here - perhaps just refer to it as the various types of 
> NATs described in RFC 4787. 
> 
> Like to add Alice calls Bob with an encrypted media. Bob can 
> tell the that the encrypted media is from Alice and not from an MITM
> 
> Like to add ability to make a call in a situation where even 
> small sounds from microphone should be sent to the other side 
> and not filtered out. Emergency calls are examples of this as 
> are some games and "jam session"
> 
> Like to add case where application has one two video streams 
> but one is far more important than the other. Should be a way 
> to make sure that preferential treatment is given the the 
> important stream over the less important streams. 

I agree that this is a relevant area to address to secure that WebRTC is competitive compared to
apps done in native OS's, especiallin in enterprise context.

The current use case document states something like "being able to use priority functions in network nodes".
This is vague since it touches many matters such as whether to put audio and video on the same IP-flow or have them in different
ones, which is essential when considering mapping on LTE radio channels; the potential use of DS to identify flows, which
may be relevant in enterprise context, etc, how to cater for treament of stuff on the datagram channel, multihoming consequences, etc.

I am not sure however how far into such matters we should go in this WG, but given the importance of making a
good solution working across OS's and browser vendors and access technologies, I am leaning towards support a discussions about such
details in this WG for instance using the use case document.

What is Your take of this? 

> I have a hard time deciding what level the requirements 
> should be at. It seems likely that given the level they are 
> currently at, the requirements are somewhat incomplete. As 
> long as we treat these as partial set of requirements derived 
> from the use cases, I'm fine with that. 
> 
> 
> New use case:
> 
> Imagine a service like webex that facilitates collaboration 
> between two companies called A and B. Webex has no need to 
> see the content of the communication from A to B. So webex 
> might run the web server that helps set up a RTCWeb session 
> between A and B, but webex needs to be able to write it's 
> code such that it does not get the keying material used to 
> encrypt the media from A to B and the companies need to be 
> able to verify that webex did not get the keys. Webex has no 
> need to see the media from A to B and if it can provide this 
> sort of promise that it does not get the media, it makes it 
> much easier for a customer (say Juniper) to use webex and 
> know the contents of their calls are not being sold or used 
> by a competitor. Given how much WebRTC will be used by cloud 
> services, this is an important feature. When installing the 
> "webex" application in the browser and granting permissions 
> to the application, it would be good to have one of the 
> permissions be if the JS got access to  the media or keying 
> material for it to enforce this promise. 
> 
> Note this use case is not phrase to say this is the only way 
> it can work. This is not mutually exclusive with they type of 
> use cases described by Skype folks where there is an 
> explicitly desire to make sure the calling service does have 
> the keys to decrypt the media. 
> 
> 
> 
> 
> 
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>