Re: [tram] TURN server discovery (please discuss!)

"Karl Stahl" <karl.stahl@intertex.se> Mon, 31 March 2014 06:50 UTC

Return-Path: <karl.stahl@intertex.se>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4A51A081D for <tram@ietfa.amsl.com>; Sun, 30 Mar 2014 23:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.8
X-Spam-Level: *
X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MSGID_MULTIPLE_AT=1] 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 1dP2La8PKQjU for <tram@ietfa.amsl.com>; Sun, 30 Mar 2014 23:50:02 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.163]) by ietfa.amsl.com (Postfix) with ESMTP id 288511A081E for <tram@ietf.org>; Sun, 30 Mar 2014 23:50:00 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201403310849558412; Mon, 31 Mar 2014 08:49:55 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Simon Perreault' <simon.perreault@viagenie.ca>, 'Martin Thomson' <martin.thomson@gmail.com>
References: <532AF25B.4020301@viagenie.ca> <CABkgnnUQ9dWmmiG1BOGBFJFzCMtcmCMu6qTaNonZ2eHN_twAgw@mail.gmail.com> <53306635.40103@viagenie.ca>
In-Reply-To: <53306635.40103@viagenie.ca>
Date: Mon, 31 Mar 2014 08:49:51 +0200
Message-ID: <04fe01cf4cad$6a98dd90$3fca98b0$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac9Hg34pfK1NJ24QSVGkhRtBbTwMZwE/LkoA
Content-Language: sv
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Sir56Hxkns3tTc5yhnyeCJ9Xur0
Cc: tram@ietf.org
Subject: Re: [tram] TURN server discovery (please discuss!)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 06:50:06 -0000

Two comments inline below /Karl

-----Ursprungligt meddelande-----
Från: tram [mailto:tram-bounces@ietf.org] För Simon Perreault
Skickat: den 24 mars 2014 18:07
Till: Martin Thomson
Kopia: tram@ietf.org
Ämne: Re: [tram] TURN server discovery (please discuss!)

Le 2014-03-24 12:58, Martin Thomson a écrit :
> Re: WPAD:  This is causing HTTPBIS considerable pain.  If you feel 
> particularly masochistic, or desperate, then perhaps it can be 
> remembered, but any attempt to use WPAD will be sorely regretted.

Duly noted.

[Karl] And an ISP can hardly provision WPAD, can he?

> On 20 March 2014 06:51, Simon Perreault <simon.perreault@viagenie.ca> wrote:
>> Martin Stiemerling proposed that we look at draft-kist-alto-3pdisc 
>> for inspiration. As I understand it, that solution relies on the 
>> client's IP address "owner" (e.g. the ISP or enterprise) to populate 
>> the DNS reverse zone (i.e., in-addr.arpa or ip6.arpa) with 
>> appropriate NAPTR records pointing to the network-provided TURN 
>> server. Can this work? This is a new idea for which I have not seen any discussion yet.

[Karl] Doesn't all reverse DNS lookup methods require that the browser finds its global ip address to begin with - for which you need a stun server? That is the bootstrap problem (how do you find a stun server to find the turn server) where the October discussion on the rtcweb terminated such track.

> 
> ALTO have been covering a lot of the same ground as GEOPRIV.
> draft-ietf-geopriv-res-gw-lis-discovery sits in the RFC editor's 
> queue.  It's the same mechanism.

Thanks for the pointer!

> That said, this is only useful to the extent that the owner of the 
> network you are using is also the one providing the TURN service.

Couldn't the NAPTR record point to a third-party TURN server?

> Is this the operating assumption here?  Or are there other avenues 
> that need to be explored?

Maybe, but I can't think of any.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram