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

[Magnus Westerlund <[e-mail]>]

On 2012-03-29 08:20, Roman Shpount wrote:
> 
> On Fri, Mar 23, 2012 at 2:39 PM, Harald Alvestrand <[e-mail]
> <mailto:[e-mail]>> 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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------