Re: [pntaw] TURN over websockets

<Markus.Isomaki@nokia.com> Mon, 02 September 2013 08:35 UTC

Return-Path: <Markus.Isomaki@nokia.com>
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 927BD21E80A1 for <pntaw@ietfa.amsl.com>; Mon, 2 Sep 2013 01:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.512
X-Spam-Level:
X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 me5qKyHMlKPs for <pntaw@ietfa.amsl.com>; Mon, 2 Sep 2013 01:35:18 -0700 (PDT)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 53DD121F844D for <pntaw@ietf.org>; Mon, 2 Sep 2013 01:32:20 -0700 (PDT)
Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r828UbM0025537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 2 Sep 2013 11:30:38 +0300
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.88]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0136.001; Mon, 2 Sep 2013 08:30:37 +0000
From: <Markus.Isomaki@nokia.com>
To: <melinda.shore@gmail.com>, <pntaw@ietf.org>
Thread-Topic: [pntaw] TURN over websockets
Thread-Index: AQHOpVzYQo/k4hTeV0+AGm8aLH5XBJmtr/AAgAAGGgCAAcxlgIAAE1QAgAACw4CAAnpWAA==
Date: Mon, 2 Sep 2013 08:30:36 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A095311@008-AM1MPN1-041.mgdnok.nokia.com>
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>
In-Reply-To: <52222B4B.7000900@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IgC3RfpT360Wbh6Q8tif6x4XQRPwZRviPCUbwaw11cFKjbsScP07csiUIg9YWTUGorTrZaXDcR82/ckJ5rb+gt5KN9lpBV6pcDddCrfH8vucFLFBIJnhkWFrLXKKGAKakNRTDj7fp/mIdB8APRupHn+bMrFWHhyRKzr7qfMMbpA4sDhQPLbGqEGDe6zmGRE47HmA0bDQYJvKCD82mbvZXVlH9BTnoi1cc5TetWLF4AsJ
x-originating-ip: [10.236.10.122]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
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 08:35:25 -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