Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

Simon Perreault <simon.perreault@viagenie.ca> Mon, 10 February 2014 14:16 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 25C581A084A for <tram@ietfa.amsl.com>; Mon, 10 Feb 2014 06:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 HVLXIMSAXyWc for <tram@ietfa.amsl.com>; Mon, 10 Feb 2014 06:16:02 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DFC721A0889 for <tram@ietf.org>; Mon, 10 Feb 2014 06:16:01 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8859040213; Mon, 10 Feb 2014 09:16:01 -0500 (EST)
Message-ID: <52F8DF21.2080303@viagenie.ca>
Date: Mon, 10 Feb 2014 09:16:01 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Karl Stahl <karl.stahl@intertex.se>, tram@ietf.org, tireddy@icisco.com
References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se>
In-Reply-To: <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
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, 10 Feb 2014 14:16:05 -0000

Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a écrit :
> - Note that to achieve some of the above points, TURN must be favored
> over STUN to enforce that the TURN-path actually is used. (The Anycast
> method suggested below, “automatically” does this.)

I understand the STUN vs TURN priority issue. But I don't see how
anycast affects it in any way. Can you please explain?

> - 3^rd The Anycast method below – I see no problem
> 
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access
> router itself, with a second interface to a public IP address on the WAN
> side. (Current volume deployed, low cost NSP triple play modems usually
> have a quality assured level 2 or level 3 WAN pipe for just voice (and
> another for IPTV) – The anycast discovered TURN-server can be the access
> gateway to such quality pipe for WebRTC media, in a single NSP provided
> CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would
this not be subject to the same service quality issues that plagued
6to4? That is, anyone could set up a badly-maintained, under-provisioned
TURN server and announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can
we prevent triangle routing? There is nothing guaranteeing that the
anycast server you see is being provided to you by your ISP, rather than
a server sitting on the other side of the planet.

Thanks,
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