Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
Justin Uberti <juberti@google.com> Tue, 11 February 2014 01:30 UTC
Return-Path: <juberti@google.com>
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 ABF201A0647 for <tram@ietfa.amsl.com>; Mon, 10 Feb 2014 17:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level:
X-Spam-Status: No, score=-1.926 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, 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 EbWcsYRCzcDZ for <tram@ietfa.amsl.com>; Mon, 10 Feb 2014 17:30:52 -0800 (PST)
Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 39A111A0635 for <tram@ietf.org>; Mon, 10 Feb 2014 17:30:52 -0800 (PST)
Received: by mail-vb0-f51.google.com with SMTP id 11so5295415vbe.24 for <tram@ietf.org>; Mon, 10 Feb 2014 17:30:51 -0800 (PST)
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=mArA3p5GoKYALUPpNTevQmAgdNkE48A1yTT2UuWfxp8=; b=bZY2xBsqd0D3r0iHUDaOf/EDzwY4G3nUTBwICxSyvrs3jbQW8MM8dbmHBwY2VSdjrx svfHagx+s7sPZr+PojOBV3YWiKJNNLrEFC+w59E0zBM8GWTb1u1Cx5/Ko0vG+KSz4I7L LpdMCMEKbyikrNLldxoDWB1Xo+hJy/M3FZBz98ofGK9j2qZAHE3y9q1o6xzCk2Y3I9/+ 1bZHHA2ajCeHEIY9Tq5G9d667sSeIru8ULADbZEGZQOdRK7oVxwH5oUbB2Zhw89VxGpc 6YBBah3exbv5CE8SUf5TjeJGxRFJxH92PDJmLrIuu8pfq/xoxNQSl7dca7xTQMUV2RkF zR2g==
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=mArA3p5GoKYALUPpNTevQmAgdNkE48A1yTT2UuWfxp8=; b=L/5Xpl8iJDUrZoYva38kTTS5dqde913VYPqBQodr3CTOs6L5P+yqSFmxmNxG5WL0yg f4TFUFQ2A5vLcDTpqsa4sASerT4tiUM1VfVXi9oyRNDJBWMj/vfckDsSKpdPVryBsCbE ovcyghLvGCPo7FiSbVl2vBKdWUAImjkacKowYWKcgByjhxFaS81Xn7u4YP0NUZoEzsgx DWhGhfMOWzKaxRKvbQA1hzBTq+AavV4lSvKlAUA3ahCkgFCUu48u3iy+k10wiHBBQNR7 FWTUPEO/tJEXBHcx//eJt7A8ghjWwJKN8LrWyLoanMUCobypp0Eha2yrdEUEIr0oIfLa ATkQ==
X-Gm-Message-State: ALoCoQnXdTsxX1yjy1wJn2jud4oi8NrDBxuMDH+jhDvAYDOokJf+DDX+htNJcj6YQRq1o5w9Dse9uUlD1QkttuZbMgt11cV6n9/129hXvisum7KjfhXUVP791KcvVClXt1eLZ+OXdoHmJ3+EGCwWR4RYKnL/XDs6eRyb8AOruIhfS1q+sJ1QbDJXZ34EdsJr2D9VL10LyBLL
X-Received: by 10.52.121.113 with SMTP id lj17mr22304233vdb.21.1392082251512; Mon, 10 Feb 2014 17:30:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.89.170 with HTTP; Mon, 10 Feb 2014 17:30:31 -0800 (PST)
In-Reply-To: <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com>
References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com>
From: Justin Uberti <juberti@google.com>
Date: Mon, 10 Feb 2014 17:30:31 -0800
Message-ID: <CAOJ7v-27jSO3j4v5H3Dz6+pL=TxNaT8y2Gc9Q2iTPmqwpabUsA@mail.gmail.com>
To: Karl Stahl <karl.stahl@intertex.se>
Content-Type: multipart/alternative; boundary="089e0122f1ca1992d704f21768e1"
Cc: tireddy@icisco.com, Simon Perreault <simon.perreault@viagenie.ca>, "tram@ietf.org" <tram@ietf.org>
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: Tue, 11 Feb 2014 01:30:55 -0000
Good to see there is a lot of interest for this milestone. But based on the description here, it seems like we want to use TURN primarily to identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem. On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote: > Simon, > > Good questions - see inline below --> . > Some more thought is required! > > /Karl > > -----Ursprungligt meddelande----- > Från: tram [mailto:tram-bounces@ietf.org] För Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > Ämne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs > > 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? > > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server is > provided and discovered, CURRENT usage of ICE may suggest a candidate from > the remote party that will make a connection without the need/usage of the > TURN server (that we wanted to be used for the good purposes listed). > > The only way we found around this, was to stop STUN through the IP default > gateway (like a restrictive Enterprise firewall does inhibiting ICE > connectivity, which others are concerned about...). Since the provisioning > of auto-discovery using the anycast mechanism, would be adding a route in a > default gateway, adding a firewall rule to eat STUN packets would assure > that the provisioned TURN server actually becomes used (and not bypassed > "by accident"). (That was the thought behind the “automatically” within > quotes.) > > BUT, since you brought up the question, assuming that we have the power to > enforce WebRTC usage of ICE, I believe a MUST requirement to use an > auto-discovered TURN server instead of STUN, would solve the same problem. > However, thinking further (in relation to your next question - "anyone > could set up a badly-maintained" - enforcing such ICE usage may not be > good.) > > > > - 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. > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > An auto-discovered TURN server must be trusted (whatever method it is > discovered by). We are trusting the one providing us with an IP address and > default gateway anyway. It would be easy if we could reuse that trust, > instead of another mechanisms. > > Is there a good way for the browser to check that the anycast address is > not handled beyond the network service provider's default gateway? Ideas? > > > > 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 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >
- [tram] Milestone 3: TURN server auto-discovery me… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- [tram] Milestone 3: TURN server auto-discovery me… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Dan Wing
- Re: [tram] Milestone 3: TURN server auto-discover… Marc Blanchet
- Re: [tram] Milestone 3: TURN server auto-discover… Dan Wing
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Oleg Moskalenko
- Re: [tram] Milestone 3: TURN server auto-discover… Pal Martinsen (palmarti)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Muthu Arul Mozhi Perumal (mperumal)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- [tram] IMPORTANT CLARIFICATIONS: Milestone 3: TUR… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- Re: [tram] Milestone 3: TURN server auto-discover… Simon Perreault
- Re: [tram] Milestone 3: TURN server auto-discover… Pal Martinsen (palmarti)
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] IMPORTANT CLARIFICATIONS: Milestone 3:… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Justin Uberti
- Re: [tram] Milestone 3: TURN server auto-discover… Hutton, Andrew
- Re: [tram] Milestone 3: TURN server auto-discover… Tirumaleswar Reddy (tireddy)
- Re: [tram] Milestone 3: TURN server auto-discover… Karl Stahl
- [tram] QoS for RTC over the Internet, DISCUSS: Mi… Karl Stahl
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Simon Perreault
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Pal Martinsen (palmarti)
- Re: [tram] QoS for RTC over the Internet, DISCUSS… Karl Stahl