Re: [pntaw] TURN over websockets

Melinda Shore <melinda.shore@gmail.com> Sat, 31 August 2013 17:43 UTC

Return-Path: <melinda.shore@gmail.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 C094821F8C0C for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 10:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.441
X-Spam-Level:
X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599]
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 4kMCfjFBBTW0 for <pntaw@ietfa.amsl.com>; Sat, 31 Aug 2013 10:43:43 -0700 (PDT)
Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0CC21F8B35 for <pntaw@ietf.org>; Sat, 31 Aug 2013 10:43:43 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id ro12so3102901pbb.41 for <pntaw@ietf.org>; Sat, 31 Aug 2013 10:43:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jlGSlVgJbUokupjSe8wTH/jk5fRrNAK8OIF57QPdSG8=; b=mI5aievQjy+AsrKHfPZhcgjZ/G89te3zKHrAVJNynxAqiOmG9MOYgiRqA8/CRUhvq8 H+au3xvjqP5T29X8NWTAgvPCuuolle3q/MCV5e5OmFsCZjAyw2X0iAGG9qJ+3C5JjYLd uq9TGcrRUrL3sRau6qzNH6Y+HIx0L7rRD9Fg8YG4GNIy/UYueD8TkXCCOEQl4q9uY1fL 4c+eUDArcjZBD6Mom0eoYnl9CtigTu3bpo/ai18lPW9I429IdxvV/AA/zjEmGmteGquQ l0cVy/NDeh2UbyqRVxp6ztdiV/PLo5pg7V7Uy3ZKgbDpyNxXYgr55YsAUiGSUSJgjuKf 7DNQ==
X-Received: by 10.66.241.34 with SMTP id wf2mr16954800pac.111.1377971023100; Sat, 31 Aug 2013 10:43:43 -0700 (PDT)
Received: from spandex.local (209-193-56-207-rb1.fai.dsl.dynamic.acsalaska.net. [209.193.56.207]) by mx.google.com with ESMTPSA id fl3sm5837875pad.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 Aug 2013 10:43:42 -0700 (PDT)
Message-ID: <52222B4B.7000900@gmail.com>
Date: Sat, 31 Aug 2013 09:43:39 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
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>
In-Reply-To: <CABkgnnVt-VscwN4r_FovqCYqARxz2YmnBihwvzf6FXPcKcTz1Q@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Sat, 31 Aug 2013 17:43:43 -0000

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.
However, it requires a forklift upgrade to pretty much everything
and is extremely difficult to deploy for that reason.  This
is the primary (but not the only) reason that midcom flopped, so
I was surprised to see pcp chartered since it's got the same
barriers to deployment.  But that is a different discussion.

Melinda