Re: [rtcweb] [tram] TURN permissions for private ips

Emil Ivov <emcho@jitsi.org> Tue, 11 August 2015 13:32 UTC

Return-Path: <emcho@sip-communicator.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479BA1A8A93 for <rtcweb@ietfa.amsl.com>; Tue, 11 Aug 2015 06:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level:
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJzF1oXyqTCW for <rtcweb@ietfa.amsl.com>; Tue, 11 Aug 2015 06:32:34 -0700 (PDT)
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5FF1A8A87 for <rtcweb@ietf.org>; Tue, 11 Aug 2015 06:32:32 -0700 (PDT)
Received: by oiev193 with SMTP id v193so74301691oie.3 for <rtcweb@ietf.org>; Tue, 11 Aug 2015 06:32:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=oBog2TBuvP1PhJ8odLGCSgBFb7+sT5hGtDUVYq1FoOU=; b=hwIUorG0pYCV5yMtaqL8LOcHtG91Sxruu79ASvQlSDkqJBnbHN7PEoVYq+levJfVN2 HIW750ZxtsH2ZDlWV7UvvTyBc7eQ5dv1yeFz+9AY+w6M6+hr2nRp3+kvrzWvKaq2tnlE OvqvUkOnTgA/u0UkP+1wsWutz3vjS+TKwvamreQzBhq/cSx4wodFqeCCklICoEWRLQwO qQV11Rpp995SqjyLxKMTbFLzAIhw1dR/cZFzhsmAnSHie0zIiLxGV17wk+JS1USasN0S vzTYcTGop4vaTdUtmzrpqfuTxY0Www7ItqD1sVUxB9g4lf0+Zymvc4TKCMJV0ze7OSZW jwPA==
X-Gm-Message-State: ALoCoQlBy6TbwGxxtc+y6SehKVfwXpZto5KLkuzRPhHxOkfutUOggDTXWs8K3XumZm9Y1CELlYgL
X-Received: by 10.202.55.7 with SMTP id e7mr23362295oia.56.1439299951951; Tue, 11 Aug 2015 06:32:31 -0700 (PDT)
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com. [209.85.214.178]) by smtp.gmail.com with ESMTPSA id ix8sm1644057obc.7.2015.08.11.06.32.30 for <rtcweb@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 06:32:31 -0700 (PDT)
Received: by obbhe7 with SMTP id he7so51857756obb.0 for <rtcweb@ietf.org>; Tue, 11 Aug 2015 06:32:30 -0700 (PDT)
X-Received: by 10.182.215.226 with SMTP id ol2mr24296811obc.56.1439299950383; Tue, 11 Aug 2015 06:32:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.76.83.167 with HTTP; Tue, 11 Aug 2015 06:32:10 -0700 (PDT)
In-Reply-To: <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com>
References: <20150805130607.20844.70680.idtracker@ietfa.amsl.com> <CABcZeBMWVU9a1_e_47qddA04WhXG55QYzFA=dTrYgi+DuLQhKA@mail.gmail.com> <55C24293.5000603@cs.tcd.ie> <55C24C09.8020404@goodadvice.pages.de> <55C256C8.80606@jive.com> <CAOJ7v-3hyFhHiFq4eujLznXtehkUSxZati8YZ23o-RPLH=J5zg@mail.gmail.com> <F144FF61-AAC6-4E0A-B08E-0E3F9B487F1B@vidyo.com> <CAOJ7v-0Z4fmWjVaeiAJh=rpYPjUsk_k8_=g8CrecAZQWtRG1AQ@mail.gmail.com> <CABkgnnXubczrXpR+YHeF1+zNrNoPNMH_XdB1+pCAGZ9LQn0UXw@mail.gmail.com> <CAOJ7v-2PaLr8XLdVxfPY=YYzeQuoj49qypUTUr=wdbmSiMZO7A@mail.gmail.com> <CAPvvaaK9xxxfmVOjE_UtX_Z6RzLe3RjR-Q=55F_Mp-9X1Li0Sg@mail.gmail.com> <3F10035A-70A4-46AE-AB44-4499541AC7C6@cisco.com>
From: Emil Ivov <emcho@jitsi.org>
Date: Tue, 11 Aug 2015 08:32:10 -0500
Message-ID: <CAPvvaaJYGQKzH+93wAUzsuSwCgNx5i5FwRKUU2aOStSd47eTiA@mail.gmail.com>
To: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/eksFIXIqh5xnTwUycsoj-A5MLU0>
Cc: Jonathan Lennox <jonathan@vidyo.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "tram@ietf.org" <tram@ietf.org>, mmusic <mmusic@ietf.org>
Subject: Re: [rtcweb] [tram] TURN permissions for private ips
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 11 Aug 2015 13:32:36 -0000

Hey Pal,

On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti)
<palmarti@cisco.com> wrote:
>
> On 07 Aug 2015, at 02:11, Emil Ivov <emcho@jitsi.org> wrote:
>
> On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti <juberti@google.com> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>
> On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> wrote:
>
> I think that we should be able to avoid pairing candidates obtained from
> application TURN servers with RFC 1918 addresses. The app/browser
> clearly
> knows which is which.
>
>
> I'm concerned here that if we let the application choose, we lose the
> defence we were looking to gain.  I think that perhaps 1918 pairing
> could be restricted to TURN servers that are configured/discovered,
> "proxy"-style.
>
>
>
> Sorry, that is what I was trying to say. The browser knows which turn
> servers are "proxies" vs app servers, and can apply the 1918 filtering on
> the pairings from the candidates from the app TURN server.
>
>
> I don't think Jonathan's concerns only apply to proxies though. You
> can just as well have apps developed for specific networks and there
> is no reason to prevent those from working.
>
> Agree with your enumeration of concerns as well. Also #5, they consume
> bandwidth (at least from client to TURN server), which affects maximum check
> rate in some cases.
>
>
> Why can't we address this by TURN servers simply refusing to create
> permissions for candidates they know they won't be able to reach?
>
> How do you reliably and simply do that without a connectivity check?

There are a few ways a TURN server could be smart about this (e.g.
checking the routing table for local interfaces for example, or
looking into ARP tables) but ultimately they should allow for this to
be configured.

> If the main concern is information leakage, isn’t that up to the client to
> decide what it want to reveal to the TURN server and the remote client?

I don't know that the main concern is leakage (see my previous mail).
I don't see how an application can be worried that the TURN server it
chose is going to find out that there's one of three NATed ranged
behind a certain IP. The TURN server had a 1 in 4 chance of guessing
that even without the app.

That said, I am not opposed to giving JavaScript apps a way to
explicitly signal the stack not to pair certain addresses with TURN.

I just don't want the stack to assume this.

Emil

> Guess what I am saying is that I think it is a good thing to have a “thick”
> client and relatively simple network components.
>
> .-.
> Pål-Erik
>
>
> Emil
>
> --
> https://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>



-- 
https://jitsi.org