IETF Logo Mail Archive

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

Justin Uberti <juberti@google.com> Fri, 07 August 2015 00:46 UTC

Return-Path: <juberti@google.com>
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 D34411ACDC7 for <rtcweb@ietfa.amsl.com>; Thu, 6 Aug 2015 17:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 KRFF5yDJsgp6 for <rtcweb@ietfa.amsl.com>; Thu, 6 Aug 2015 17:46:28 -0700 (PDT)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 552FE1ACDB9 for <rtcweb@ietf.org>; Thu, 6 Aug 2015 17:46:28 -0700 (PDT)
Received: by vkci6 with SMTP id i6so33734704vkc.3 for <rtcweb@ietf.org>; Thu, 06 Aug 2015 17:46:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SuIeVYvp28UUfKlQhc9k3RUSCYOQW2f6eFVKgdTRSs8=; b=nylZ7C2/lCD1DGh4b5rCaOVQoL6J4Zs2XNxYDlUGVP59e/YihsYX+gFTxTEZjKol82 zW/FINu7oTpJZ7Pq94YlPSfCC8JyEdaVYocqsJhUKhNK+U5S0IwEUfNuUvd5fqNOX0ab G1fHYbhwy2Zm/p7N7L4B2H22/6wnYyWfYQGe2Kwqq5SPbD8ypRyXZ8eY+BTGO3/GcYuM XZbS+gMo05vDnOiPJJcBaAMee9+vCNn0uCM6Gq0yq6T4BfoxOelDd60NWkSRt6iRIRFA Cwdp6s2k6sCUo7ll53JpHMBPqaa+cD5n6WlrvbZuVY8awKrQUfVUI78gcDLs8YS9+cQx 7jDQ==
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; bh=SuIeVYvp28UUfKlQhc9k3RUSCYOQW2f6eFVKgdTRSs8=; b=OrAp6GZNWRyHnRBG67Vz41g1Etw/6qPF+6XynL9prkvlrc6epMxgF0fX08ajoX0Gps gfE6u4gB93MfM9AWL9nTs47yOASt68GszCbihz/I6kfoTMvzn51gRpj7VVxth/AJ1v8a tE7DsFncS2GzvBRxhPSG6tEdol80esMVY6xPRgVR5dFAX3jsev+Une4gAlPpQAlw4auj mk6DrMdR3Znpz6NPuOZlxdGXGwdw0Fqu961Gjuri100RNf2hvtnQ61HlzgU8h3Ed4BZB lJbpLkxsWJDYgprKgjggI05PwE+ZS9Zx0kwZ8J1F7Swzx0n0lvwApmxe9fXqbEq/6M2s EqbA==
X-Gm-Message-State: ALoCoQmh4YUeYaBKumcMp9no0iSvJC0Xf6j+A4REQCgCbXHavSkQMrafUz3EW4BXZAsGuZgvEWrm
X-Received: by 10.52.186.72 with SMTP id fi8mr5393953vdc.19.1438908387526; Thu, 06 Aug 2015 17:46:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.191.87 with HTTP; Thu, 6 Aug 2015 17:46:08 -0700 (PDT)
In-Reply-To: <CAPvvaaK9xxxfmVOjE_UtX_Z6RzLe3RjR-Q=55F_Mp-9X1Li0Sg@mail.gmail.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>
From: Justin Uberti <juberti@google.com>
Date: Thu, 06 Aug 2015 17:46:08 -0700
Message-ID: <CAOJ7v-02F-4bM18p8JKap5PzjrsQROiXPd4xxXkCUJq9WQzW4w@mail.gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: multipart/alternative; boundary="bcaec548a8214dbe34051cadf779"
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/YiGMP4ONuRCXActMpfVoILroHcs>
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic <mmusic@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "rtcweb@ietf.org" <rtcweb@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: Fri, 07 Aug 2015 00:46:30 -0000

On Thu, Aug 6, 2015 at 5:11 PM, 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?


That is one potential solution, which would solve #1/#4/#5.

v2.23.0 | Report a Bug | By Email