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

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

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DAB21F849B for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.83
X-Spam-Level:
X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMDwK52CM27N for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:51:00 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0EF21F8452 for <rtcweb@ietf.org>; Wed, 2 May 2012 09:50:59 -0700 (PDT)
Received: by werb10 with SMTP id b10so700757wer.31 for <rtcweb@ietf.org>; Wed, 02 May 2012 09:50:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=9iQZ8+ktYyac7z53GB1j3phE0+GCw8wI0CwBfacRSNM=; b=Ie6Qzjb+wd2GWxy2W5SB8l37qR88fQVnTAFv/RosQFgKKjFx6DLC1nHovmd5KQOYo0 o6LT0lHLMWEqJJQznGIsaaVzIW2XItXkPgbhD1BH8fr9pz/3i78zWtqNx3+BG0yX8HPl 8uSlnMupx7HkqlcHBy5OwUv3pa25MODNRQgqI0YxcUFQYoOURolgDoXkAa1KDv6nFayb NmT4duIRaXG6BjNokFJRXzjEOWbPMHEBoKPlTrv7ysGWbmpZZ/05MSzAfV4PXeMUiTHc MMm4jN1MkQXZ/pPwd7iY+g4q4IKGFmwpFzxmpwdKhIUschZxhbLhkOdvfLpVNSsdATFY uCbg==
Received: by 10.216.132.6 with SMTP id n6mr16389407wei.26.1335977456541; Wed, 02 May 2012 09:50:56 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id gg2sm8256080wib.7.2012.05.02.09.50.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 09:50:55 -0700 (PDT)
Received: by bkty8 with SMTP id y8so793106bkt.31 for <rtcweb@ietf.org>; Wed, 02 May 2012 09:50:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.141.13 with SMTP id k13mr3728222bku.51.1335977454486; Wed, 02 May 2012 09:50:54 -0700 (PDT)
Received: by 10.205.117.146 with HTTP; Wed, 2 May 2012 09:50:54 -0700 (PDT)
Date: Wed, 2 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
X-Gm-Message-State: ALoCoQk9WoDB1zMoilzMa6Hv89H+xZiQH71tEuDW2nsVAzYoKjtC+UTnhSRFGHcUe23aI9dsPN+I
Subject: Re: [rtcweb] Use Case draft -- Enterprise Policies
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 May 2012 16:51:02 -0000

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