Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Apr 2012 11:44:08 +0200

On 2012-03-29 08:20, Roman Shpount wrote:
> 
> On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     __
>     It seems to me that you are arguing that the scenarios in section
>     4.1 of the use cases document do not cover that specific case, and I
>     think you are right in that; the list is:
> 
>        The following considerations are applicable to all use cases:
>        o  Clients can be on IPv4-only
>        o  Clients can be on IPv6-only
>        o  Clients can be on dual-stack
>        o  Clients can be on wideband (10s of Mbits/sec)
>        o  Clients can be on narrowband (10s to 100s of Kbits/sec)
>        o  Clients can be on variable-media-quality networks (wireless)
>        o  Clients can be on congested networks
>        o  Clients can be on firewalled networks with no UDP allowed
>        o  Clients can be on networks with cone NAT
>        o  Clients can be on networks with symmetric NAT
> 
>     Now, there are two ways to interpret this omission:
> 
>     - The WG did not think of that use case when the list was created
>     - The WG does not want that use case on the list because it
>     constrains the solution space too much
> 
>     If (re)opening this issue, I think I'd find myself in the "do not
>     want that use case" camp.
> 
> 
> I do not recall this use case ever being discussed on the working group,
> so I would assume the current situation is due to WG not thinking about
> this case when the list was created.

Hi,

If I followed this thread I do believe that we do have a use case
description that puts in requirements for controlling how the media
traffic flows in and out of an enterprise when using WebRTC:

4.2.4.  Simple Video Communication Service, enterprise aspects

4.2.4.1.  Description

   This use-case is similar to the Simple Video Communication Service
   use-case (Section 4.2.1).

   What is added is aspects when using the service in enterprises.  ICE
   is assumed in the further description of this use-case.

   An enterprise that uses a RTCWEB based web application for
   communication desires to audit all RTCWEB based application session
   used from inside the company towards any external peer.  To be able
   to do this they deploy a TURN server that straddle the boundary
   between the internal network and the external.

   The firewall will block all attempts to use STUN with an external
   destination unless they go to the enterprise auditing TURN server.
   In cases where employees are using RTCWEB applications provided by an
   external service provider they still want to have the traffic to stay
   inside their internal network and in addition not load the straddling
   TURN server, thus they deploy a STUN server allowing the RTCWEB
   client to determine its server reflexive address on the internal
   side.  Thus enabling cases where peers are both on the internal side
   to connect without the traffic leaving the internal network.  It must
   be possibele to configure the browsers used in the enterprise with
   network specific STUN and TURN servers.  This should be possible to
   achieve by autoconfiguration methods.  The RTCWEB functionality will
   need to utilize both network specific STUN and TURN resources and
   STUN and TURN servers provisioned by the web application.

My interpretation of this and the discussion I can remember is that an
enterprise would configure the browsers for their internal computers
with a TURN server sitting on the border between the inside and outside.
That way one can at least log and audit which communication that occurs
using WebRTC from the inside to the outside. The enterprise can also
select to record media flows in the TURN server.

This still leaves the question if one can get to the keys. That will
depend on the mechanism used for keying and its transport and what
methods have been put in place to capture such traffic.

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: Roman Shpount <[email-masked]>
Date: Tue, 10 Apr 2012 14:22:22 -0400

> methods have been put in place to capture such traffic.

I thought about customer provided TURN servers and I do not think they will
be sufficient, due to the fact that no information describing the media
(URL of the application that initiated this media call, codec,any codec
related parameters, keys). I think some sort of network based hook that
will allow browser to send all the signaling information to some sort of
WebRTC signaling proxy server would be required to enable any type of
managed corporate use. Since we gave up the standard signaling protocol we
gave up a lot of functionality enterprise customers expect from real time
communications. In case of SIP enterprise can deploy some sort of proxy
server and enforce any type of enterprise specific policy. The only way to
fill this gap is to provide an ability to modify signaling coming from and
being sent via WebRTC API in a manner independent of the application code,
by configuring a policy enforcement server in web browser. The protocol
used to communicate with the policy enforcement server can be something as
simple as HTTP post with SDP data with response being policy server
modified SDP.  Any additional requirements such as authentication and
encryption of communications between WebRTC client and WebRTC policy server
will be provided via standard HTTP means (HTTPS, and Digest authentication).
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 Apr 2012 20:39:34 +0200

On 04/10/2012 08:22 PM, Roman Shpount wrote:
> I thought about customer provided TURN servers and I do not think they 
> will be sufficient, due to the fact that no information describing the 
> media (URL of the application that initiated this media call, 
> codec,any codec related parameters, keys). I think some sort of 
> network based hook that will allow browser to send all the signaling 
> information to some sort of WebRTC signaling proxy server would be 
> required to enable any type of managed corporate use. Since we gave up 
> the standard signaling protocol we gave up a lot of functionality 
> enterprise customers expect from real time communications. In case of 
> SIP enterprise can deploy some sort of proxy server and enforce any 
> type of enterprise specific policy. The only way to fill this gap is 
> to provide an ability to modify signaling coming from and being sent 
> via WebRTC API in a manner independent of the application code, by 
> configuring a policy enforcement server in web browser. The protocol 
> used to communicate with the policy enforcement server can be 
> something as simple as HTTP post with SDP data with response being 
> policy server modified SDP.  Any additional requirements such as 
> authentication and encryption of communications between WebRTC client 
> and WebRTC policy server will be provided via standard HTTP means 
> (HTTPS, and Digest authentication).

This requires the code that sends the SDP to the policy server to be 
part of the browser, since you obviously can't trust the Javascript to 
do the call-out to the server. (If you could trust the Javascript, you 
could also trust it to enforce policy.)

In that case, why don't you just require that the browser do the 
wiretapping for you by copying the media? Much simpler, and you don't 
have to worry about interpreting the SIP.

                           Harald

---

From: Roman Shpount <[email-masked]>
Date: Tue, 10 Apr 2012 15:06:37 -0400

On Tue, Apr 10, 2012 at 2:39 PM, Harald Alvestrand <[email-masked]>wrote:

>
> This requires the code that sends the SDP to the policy server to be part
> of the browser, since you obviously can't trust the Javascript to do the
> call-out to the server. (If you could trust the Javascript, you could also
> trust it to enforce policy.)
>
> wiretapping for you by copying the media? Much simpler, and you don't have
> to worry about interpreting the SIP.
>

I do think this should be part of the browser, but I am not sure why you
insist on limiting this to wiretapping. Wiretapping is just one of the use
cases. Other use cases can be supported are things like:

1. Allocate only certain amount of bandwidth to WebRTC, disallow WebRTC
calls when bandwidth is exausted
2. Disable video calling from my network. Voice calling would still be
non-monitored encrypted and allowed
3. Force certain codec preference from my network (disable anything above
16KB/s)
4. Allow WebRTC communications outside of my network only when SDP
descriptions are signed by certain white listed companies.

There is a reason why proxy servers, both SIP and HTTP, exist. What I am
trying to explain is that in a lot of environments user network experience
is managed. This management requires tools. WebRTC, due to its consumer
oriented user rights focus and prioritization of security, provides none,
which, I believe, will create a barrier to its deployment in enterprise
environments.

_____________
Roman Shpount