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

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Wed, 12 February 2014 07:01 UTC

Return-Path: <tireddy@cisco.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 61EF91A0849 for <tram@ietfa.amsl.com>; Tue, 11 Feb 2014 23:01:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level:
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, 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 ZBcNSbJe0fw7 for <tram@ietfa.amsl.com>; Tue, 11 Feb 2014 23:01:21 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id CD6EE1A0830 for <tram@ietf.org>; Tue, 11 Feb 2014 23:01:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12456; q=dns/txt; s=iport; t=1392188480; x=1393398080; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yx0B2BQ54yCqnKMzkGdk4Ag4Z0nAZjnw/BmuIkia9RA=; b=G0fcagUtKy/DM/gTdFhOlE2IAkFecM9oaxStf7YnHp7dyJtMoSqAoMvr wOrDREfWqY7iWqAuIT6SdePMpLGt4p6aejv6dHey3ccbuUt/sr1M/Xgx7 S8SBNENnWe7L8KcPm/XEG4sFAYIkkZqGtjSmp+X8qufVBKcfmyeWu0O4e 0=;
X-IronPort-AV: E=Sophos;i="4.95,831,1384300800"; d="scan'208";a="19782252"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 12 Feb 2014 07:01:20 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1C71JKD017525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 07:01:19 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 01:01:19 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: Karl Stahl <karl.stahl@intertex.se>, 'Simon Perreault' <simon.perreault@viagenie.ca>, "tram@ietf.org" <tram@ietf.org>, "tireddy@icisco.com" <tireddy@icisco.com>
Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
Thread-Index: AQHPJrZnSgUY4V56JE+wy6rTjZeHIZqvVbIwgAEJXKCAANCLcA==
Date: Wed, 12 Feb 2014 07:01:18 +0000
Message-ID: <913383AAA69FF945B8F946018B75898A242AC8C2@xmb-rcd-x10.cisco.com>
References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> <52F8DF21.2080303@viagenie.ca> <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242ABA2D@xmb-rcd-x10.cisco.com> <058f01cf275d$da1dc6a0$8e5953e0$@stahl@intertex.se>
In-Reply-To: <058f01cf275d$da1dc6a0$8e5953e0$@stahl@intertex.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.39.65.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 12 Feb 2014 07:01:24 -0000

Hi Karl,

Yes, there is a problem but P2P WebRTC streams (both media and data channels) can be identified and QoS can be provided by the access network without forcing TURN to be used. You may want to look into PCP FLOWDATA (http://tools.ietf.org/html/draft-wing-pcp-flowdata-00), MALICE (http://tools.ietf.org/html/draft-martinsen-mmusic-malice-00). 

-Tiru.

> -----Original Message-----
> From: Karl Stahl [mailto:karl.stahl@intertex.se]
> Sent: Wednesday, February 12, 2014 12:47 AM
> To: Tirumaleswar Reddy (tireddy); 'Simon Perreault'; tram@ietf.org;
> tireddy@icisco.com
> Subject: SV: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
> 
> Tireddy wrote below > There are various ways to prioritize WebRTC media
> streams and I don't see a need to block P2P connectivity.
> 
> --- We need not only to think about prioritizing WebRTC, it is about "traffic
> shaping also".
> - If we consider the case of WebRTC traffic over Internet/mobile OTT (not
> talking about feeding WebRTC into some application specific network like
> IMS where they may be other quality measures), we get lost quality wise
> already when (if) we allow prioritized WebRTC traffic to go into a congestion
> point (like a NAT/firewall or default gateway, where there may be heavy data
> traffic already filling the pipe.
> - Quality loss here (lost WebRTC media packets) cannot be recovered later
> - That is the "need to block P2P connectivity" (which may sound ugly but is
> really about assuring that we CAN get P2P connectivity with best quality, with
> help of service providers and LAN administrators that want WebRTC traffic to
> be good and accessible...)
> 
> --- Or do see another/better way around this that I cannot see?
> 
> -----Ursprungligt meddelande-----
> Från: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
> Skickat: den 11 februari 2014 03:40
> Till: Karl Stahl; 'Simon Perreault'; tram@ietf.org; tireddy@icisco.com
> Ämne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
> 
> > 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.)
> 
> There are various ways to prioritize WebRTC media streams and I don't see a
> need to block P2P connectivity.
> --- We need not only to think about prioritizing WebRTC, it is about "traffic
> shaping also".
> - If we consider the case of WebRTC traffic over Internet/mobile OTT (not
> talking about feeding WebRTC into some application specific network like
> IMS where they may be other quality measures), we get lost quality wise
> already when (if) we allow prioritized WebRTC traffic to go into a congestion
> point (like a NAT/firewall or default gateway, where there may be heavy data
> traffic already filling the pipe.
> - Quality loss here (lost WebRTC media packets) cannot be recovered later
> - That is the "need to block P2P connectivity" (which may sound ugly but is
> really about assuring that we CAN get P2P connectivity with best quality, with
> help of service providers and LAN administrators that want WebRTC traffic to
> be good and accessible...)
> 
> --- Or do see another/better way around this that I cannot see?
> 
>  Using TURN server itself endpoint can learn server-reflexive candidates. If
> there is a restrictive firewall that blocks P2P connectivity then relayed
> candidate would eventually be nominated because ICE connectivity check
> fails with other candidate types.
> 
> I don't see any need to advertise only relayed candidates in the offer/answer
> other than for privacy reasons.
> 
> -Tiru.
> 
> > -----Original Message-----
> > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl
> > Sent: Tuesday, February 11, 2014 4:48 AM
> > To: 'Simon Perreault'; tram@ietf.org; tireddy@icisco.com
> > Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism
> > for enterprise and ISPs
> >
> > 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