Re: [rtcweb] Use Case draft -- Enterprise Policies

Roman Shpount <roman@telurix.com> Wed, 02 May 2012 16:51 UTC

MIME-Version: 1.0
Date: Wed, 02 May 2012 12:50:54 -0400
Message-ID: <CAD5OKxu5fdcfSyBNS8d0uGY-AT1syyAxBh1E3v8ihGsboHWveg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="0015175d67b49a44b904bf107d46"
Subject: Re: [rtcweb] Use Case draft -- Enterprise Policies
Precedence: list

Couple more use cases that I've mentioned on this least before had to do
with enforcing enterprise policies on  Web RTC clients at the enterprise
location. Keep in mind that I am not looking for a way to disable WebRTC in
the location completely, but to restrict its use of functionality. I see
the following scenarios:

1. Enterprise would like to limit the amount of bandwidth available for
WebRTC communications per location and per user.

This can be addressed by setting up enterprise network not to route to a
public internet, setting up an HTTP proxy and TURN server on the enterprise
network, and allowing to overwrite TURN server settings for enterprise
users. This way no unauthorized WebRTC communications would be allowed and
bandwidth restrictions can be enforced by the TURN server. TURN user
credentials can be used to restrict bandwidth per user or to assign user
bandwidth quotas. This provides an additional requirements that TURN server
configuration provided in the browser overwrites TURN/STUN configuration
provided by WebRTC API.

2. Enterprise would like to limit WebRTC communications (but not the other
communications such as HTTP)  to particular networks.

This can be addressed using the premise based TURN server, as in 1.

3. Enterprise would like to limit certain types of communications, ie
enable audio, but disable video and data for all the WebRTC applications on
its premises.

This currently has no solution, since there is no consistent way to know
which remote IP/port/SSRC is used for what type of communication. To enable
this, some sort of centralized SDP monitoring/modification service needs to
be deployed. Proposed solution of using HTTP proxy to modify WebRTC
application does not seem to be very stable and can be easily circumvented.

4. Enterprise would like to limit external communications only to
destinations signed by a specified list of identity providers, ie users are
allowed to communicate with anybody with identity at acme.com, but not with
user with identity at socialnetwork.com

This currently has no solution, since there is no consistent way to know
which remote IP/port is used by what remote identity. To enable this, some
sort of centralized SDP monitoring/modification service needs to be
deployed as in 3.

5. Enterprise would like to enable only communications that are recorded to
leave its premises.

This currently has no solution, since there is no consistent way to know if
communication with particular remote IP/port is recorded. This does not
fall under RAVEN since it is consensual by the user. Using solutions such
as SIP recording or installing some sort of desktop based recording
solutions does not solve this scenario since it provides no way to enforce
that only recorded communications are allowed to leave the premises. Also
note that on premise communications do not have to be recorded. Once again,
some sort for SDP monitoring/modification service needs to be implemented
to support this.
_____________
Roman Shpount

Re: [rtcweb] Use Case draft -- Enterprise Policies Roman Shpount
Re: [rtcweb] Use Case draft -- Enterprise Policies Ted Hardie
Re: [rtcweb] Use Case draft -- Enterprise Policies Roman Shpount