Subject: Re: [pntaw] TURN over websockets

From: <[email-masked]>
Date: Mon, 2 Sep 2013 08:30:36 +0000

Hi,

Melinda Shore wrote:
> 
> On 8/31/13 9:33 AM, Martin Thomson wrote:
> > I'm glad someone raised this point.  It's core to the discussion.
> > What, if any, visibility will a firewall or proxy be given into the
> > purpose of this exchange?   HTTP CONNECT followed by TLS doesn't give
> > the intermediary much of a chance to enforce policy.
> 
> Well, arguably NAT is not really a policy enforcement mechanism.
> But yes, if you're using firewall/nat traversal technologies to get around
> firewall policy enforcement, there's a huge problem.
> For what it's worth we've been trying to have *that* discussion for years.
> 
> One of the advantages of using a mechanism that signals the firewall directly
> (say, midcom, pcp, etc.) is that it allows the firewall to accept or deny the
> request based on policy.
>

I suppose a request (by, e.g. PCP PEER method) to establish a firewall binding does not by itself tell more about its intended use than a HTTP CONNECT to a certain URI. So the firewall control mechanism would need to include some kind of authorization "layer", perhaps similar to what is proposed in <http://datatracker.ietf.org/doc/draft-wing-pcp-third-party-authz/> to be really useful in an actual policy enforcement. 

I believe WebRTC is going to make real-time communications related policy enforcement harder in any case. 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. 

On the other hand, the security model starts with the assumption that the browser is trusted, and it will prevent the app from doing anything bad... So things will be safer with using a single browser to use 10 WebRTC services than installing a separate app for each service? Or? :-)

Markus

---

From: Simon Perreault <[email-masked]>
Date: Mon, 02 Sep 2013 11:12:44 +0200

Le 2013-09-02 10:30, [email-masked] 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