IETF Logo Mail Archive

Re: [pntaw] TURN over websockets

Simon Perreault <simon.perreault@viagenie.ca> Mon, 02 September 2013 09:12 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7BD11E81D2 for <pntaw@ietfa.amsl.com>; Mon, 2 Sep 2013 02:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Level:
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 ak0qYBi3uzL8 for <pntaw@ietfa.amsl.com>; Mon, 2 Sep 2013 02:12:43 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E148511E8125 for <pntaw@ietf.org>; Mon, 2 Sep 2013 02:12:42 -0700 (PDT)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:804a:3155:d42a:4a6]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 51C954044E for <pntaw@ietf.org>; Mon, 2 Sep 2013 05:12:42 -0400 (EDT)
Message-ID: <5224568C.5080506@viagenie.ca>
Date: Mon, 02 Sep 2013 11:12:44 +0200
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: pntaw@ietf.org
References: <52205AE1.9010807@gmail.com> <F81CEE99482EFE438DAE2A652361EE12179BF94B@MCHP04MSX.global-ad.net> <5220968E.2050708@gmail.com> <004e01cea666$98e9b090$cabd11b0$@co.in> <CABkgnnVt-VscwN4r_FovqCYqARxz2YmnBihwvzf6FXPcKcTz1Q@mail.gmail.com> <52222B4B.7000900@gmail.com> <E44893DD4E290745BB608EB23FDDB7620A095311@008-AM1MPN1-041.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620A095311@008-AM1MPN1-041.mgdnok.nokia.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [pntaw] TURN over websockets
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2013 09:12:54 -0000

Le 2013-09-02 10:30, Markus.Isomaki@nokia.com a écrit :
> I believe WebRTC is going to make real-time communications related
> policy enforcement harder in any case.

+1

Lots of people are happy about this. But not the sysadmins. ;)

> In my corporate environment
> the most effective enforcement was IT telling which apps the users
> were allowed to install on their endpoints. So even if they would or
> could not block Skype at their firewalls, they could tell if it was
> allowed to install it or not. How well they were able to control what
> people installed varied to a great extent of course, but in the
> extreme cases the users could not install anything on their own. But
> when the browser becomes the only client needed, even that won't be
> possible.

And the logical extension to that is for the sysadmin to block access
URLs, not WebRTC itself. For example, a sysadmin would add "appear.in"
to an HTTP proxy's domain blacklist and wouldn't care about actual
WebRTC traffic. I can see tons of cases where that would be "good enough".

Simon

v2.23.0 | Report a Bug | By Email