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, 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"
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
- 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