IETF Logo Mail Archive

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

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Fri, 07 August 2015 07:47 UTC

Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A41B381E; Fri, 7 Aug 2015 00:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 PDPXeSSC28CL; Fri, 7 Aug 2015 00:47:36 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510961B3817; Fri, 7 Aug 2015 00:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24592; q=dns/txt; s=iport; t=1438933656; x=1440143256; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9N81s85Sn+NI7nU9oy8haMMLbh6itUeUvZTrZIxUceg=; b=c9pQG4SbdyfrCeGJKkk5eR+1hRwItCkVOj7fvEbkp8nND8VgOEvkXU0N gyZzYSuvyY4BdSmX0oKNMkD20u3w+tzkuLU2OTyvybvFtYcCwarFSGddD QvofPUn+S0gd3JLy3HVxX54RG+7ukR1oau7BGF+ajvKZDQGCZqu9N48cc o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A8BQAZYcRV/4QNJK1bgk5NVGkGgx26AYF6AQmFL0oCHIEkOhIBAQEBAQEBgQqEJAEBBAEBASBJAggDEAIBCA4qBwMCAgIfBgsUEQIEDgWIGQMSDbcqkHANhSwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItPgk+Bb0cEB4JpL4EUBZUHAYR+hW+Ba4FHkHyDTYNkJoN9b4FIgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,628,1432598400"; d="scan'208,217";a="176330403"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP; 07 Aug 2015 07:47:35 +0000
Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t777lZXI029690 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Aug 2015 07:47:35 GMT
Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 7 Aug 2015 02:47:34 -0500
Received: from xhc-aln-x06.cisco.com (173.36.12.80) by xch-rcd-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Fri, 7 Aug 2015 02:47:34 -0500
Received: from xmb-rcd-x06.cisco.com ([169.254.6.133]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0248.002; Fri, 7 Aug 2015 02:47:34 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [rtcweb] [tram] TURN permissions for private ips
Thread-Index: AQHQ0KQ4GdSUE5mBkES+Q0lZrOYQnJ3//dsAgAB/T4A=
Date: Fri, 07 Aug 2015 07:47:33 +0000
Message-ID: <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>
In-Reply-To: <CAPvvaaK9xxxfmVOjE_UtX_Z6RzLe3RjR-Q=55F_Mp-9X1Li0Sg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.23]
Content-Type: multipart/alternative; boundary="_000_3F10035A70A446AEAB444499541AC7C6ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/mWb9shDEeC7k_x8QbjdWKgYY2vw>
Cc: Jonathan Lennox <jonathan@vidyo.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "tram@ietf.org" <tram@ietf.org>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] [tram] TURN permissions for private ips
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2015 07:47:38 -0000

On 07 Aug 2015, at 02:11, Emil Ivov <emcho@jitsi.org<mailto:emcho@jitsi.org>> wrote:

On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:


On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
wrote:

On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com<mailto: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?

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?

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<https://jitsi.org/>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email