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

[Justin Uberti <[e-mail]>]

Agreed, but enterprises are already doing this with HTTP proxies, so the
precedent (and mechanisms that can be used) are much clearer.


On Wed, Feb 12, 2014 at 11:30 AM, Hutton, Andrew <[e-mail]>wrote:

>  The case where the TURN server is the only option may become common
> within enterprise networks and that might be deliberate enterprise policy
> because it provides the better path (UDP through the F/W) and protects the
> users and the network.
>
>
>
> Andy
>
>
>
>
>
> *From:* tram [mailto:[e-mail]] *On Behalf Of *Justin Uberti
> *Sent:* 12 February 2014 17:46
>
> *To:* Muthu Arul Mozhi Perumal (mperumal)
> *Cc:* [e-mail]; Simon Perreault; Oleg Moskalenko; [e-mail];
> Marc Blanchet; Dan Wing (dwing); Karl Stahl
>
> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
> for enterprise and ISPs
>
>
>
> Agree. If TURN is indeed being provided for the user's benefit, the
> client's ICE logic (based on RTT or similar) should result in it preferring
> the TURN path.
>
>
>
> On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <
> [e-mail]> wrote:
>
> Yes, I believe the second case is rare, but would be better than a rat
> race b/w administrators trying to block p2p traffic and force it through a
> TURN server and apps/endpoints finding smarter ways to bypass them.
>
>
>
> Muthu
>
>
>
> *From:* Oleg Moskalenko [mailto:[e-mail]]
> *Sent:* Wednesday, February 12, 2014 1:07 PM
> *To:* Muthu Arul Mozhi Perumal (mperumal)
> *Cc:* Justin Uberti; Karl Stahl; [e-mail]; Marc Blanchet;
> [e-mail]; Dan Wing (dwing); Simon Perreault
>
>
> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
> for enterprise and ISPs
>
>
>
> The TURN server has to be used when it is either the only option, or if it
> provides a better path (I guess the second case is rather rare).
>
>
>
> On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) <
> [e-mail]> wrote:
>
> +1
>
>
>
> Forcing all traffic through a TURN server and expecting it would provide
> the best user experience doesn't look the right approach. Instead, if a
> path through a TURN server exists and does provide lower RTT, jitter etc,
> being able to detect and use (or switch to) that path might be desirable..
>
>
>
> Muthu
>
>
>
> *From:* tram [mailto:[e-mail]] *On Behalf Of *Justin Uberti
> *Sent:* Wednesday, February 12, 2014 11:43 AM
> *To:* Karl Stahl
> *Cc:* [e-mail]; Marc Blanchet; [e-mail]; Dan Wing (dwing);
> Simon Perreault
> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism
> for enterprise and ISPs
>
>
>
> Inline.
>
>
>
> On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <[e-mail]>
> wrote:
>
> Listening to this thread, I am afraid we are missing the very point and
> necessity for this milestone!
>
> - There are severe NAT traversal and quality issues that should and can be
> dealt with by a good auto-discovery mechanism and the right usage by the
> turn client (the WebRTC browser)
>
>
>
> There are ways, not only: Enterprises or ISPs wishing to provide their
> own TURN server, in an attempt to reduce so-called "triangle routing",need
> a new auto-discovery mechanism
>
> But also: - NSPs (Network Service Providers) want to provide a path where
> the bandwidth of WebRTC is better coped with.
>
> - NSPs or Enterprises want to offer an Internet access quality pipe for
> prioritized RTC (Real Time Communication) traffic.
>
> - Enterprises having restrictive firewalls, want to provide a UDP-path for
> WebRTC and possibly also for better quality where RTC do not compete with
> data traffic.
>
> Also considering
>
> - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G
> OTT channels, all should be able to automatically offer their own optimal
> TURN server
>
>
>
> This leads us into  “TURN…to identify WebRTC flows” etc! It is not a
> mistake, but the very need for this milestone!
>
>
>
> Again, it has not been demonstrated why TURN is the right technology here,
> compared to a more transparent flow identification tool like MALICE. We
> don't force all HTTP requests to locate a HTTP proxy via anycast, I don't
> see why we need to do the same for WebRTC.
>
>
>
> What are the hesitations raised here?
>
> > 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
>
> It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall
> traversal problem associated with real-time communication (SIP at that
> time). However, its largest flaw/problem is that quality things were not
> (could not be?) considered. The method’s very idea (like all similar
> methods for getting RTC through ordinary NAT/Firewalls) is to fool the
> media through a NAT/Firewall that is unaware of what is happening. Thus,
> this is root of quality issues (and bandwidth allocation optimization) that
> needs to be dealt with: Real-time traffic fighting with a data traffic
> crowded congestion point.
>
>
>
> I think that "fooling" is an incorrect description. The NAT is supposed to
> be transparent to the client.
>
>
>
> But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate
> request for a suitable pipe for quality demanding real time traffic. J
>
> ICE is a pre-protocol you use because you want a path for real-time media
> between parties. Here: The browser says knock knock, I want to get media
> through (and of course with as good quality as required and possible).
>
>
>
> If the NAT/Firewall owner and network owner are allowed to see these
> requests, they can help/assist in achieving the good media path. If they
> are not aware, they cannot help!
>
>
>
> Hope this made it understandable on an overview level how this can become“TURN…to identify WebRTC flows”
>
> It is also the ONLY way I can see to achieve what we want to achieve and
> should be the aim and requirement of this milestone.
>
>
>
> I am talking about general usage of WebRTC over Internet/mobile OTT (not
> feeding WebRTC into application specific networks like IMS where other
> methods may exist).
>
>
>
> This is good, not evil!
>
>
>
> If the hesitations are raised because of a belief/hope/wish that there are
> no or will not be severe quality issues “because it is all about
> bandwidth”, “it will resolve itself with time” etc., I strongly object!
> That is wrong and will be very detrimental for WebRTC usage. We already see
> it and I can give numerous examples of how much less quality demanding VoIP
> is/is not handled quality wise and that it matters. And, what would be bad
> considering quality issues and allowing/encouraging methods to deal with
> them?
>
>
>
> If the hesitations are raised, because of suspicion that the methods we
> may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to
> protect income from carrier telephony traffic), I could understand and
> would fight the same battle. But hopefully, those days are (soon) over – At
> least forward thinking carrier’s realize that already. Web RTC will happen.
> Which customers want to pay for an access with blocked WebRTC? The
> carrier’s offering/assuring good WebRTC will rather get the customers and
> income J. (Maybe the Web browser can detect and encourage this…)
>
>
>
> If there are technical concerns of bad result, or better methods allowing
> network providers and LAN managers to offer and inform the browser that
> there are good media paths to be used, and that the web browser
> automatically can chose those, then let us all understand those, so we can
> achieve what should be achieved by this milestone.
>
>
>
> Skype, Hangouts, Facetime are doing billions of minutes per week and the
> Internet has not melted yet. If we need to do flow identification to allow
> traffic to be prioritized, fine (see above regarding my preferred
> approach), but forcing all WebRTC traffic through a MITM (TURN server) is a
> much bigger jump that I don't yet see the justification for.
>
>
>
> In short: TURN is a technology that is supposed to fade away with the move
> to IPv6. I don't think we want to make it a critical element of WebRTC.
>
>
>
> /Karl
>
>
>
>
>
> *Från:* Dan Wing [mailto:[e-mail]]
> *Skickat:* den 11 februari 2014 18:25
> *Till:* Marc Blanchet
> *Kopia:* Justin Uberti; [e-mail]; Karl Stahl; [e-mail];
> Simon Perreault
>
>
> *Ämne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism for
> enterprise and ISPs
>
>
>
>
>
> On Feb 11, 2014, at 9:08 AM, Marc Blanchet <[e-mail]>
> wrote:
>
>
>
> Le 2014-02-11 à 00:39, Dan Wing <[e-mail]> a écrit :
>
>
>
>
> On Feb 10, 2014, at 5:30 PM, Justin Uberti <[e-mail]> wrote:
>
>
>
> 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.
>
>
>
> +1.
>
>
>
> I would prefer allowing flows to establish themselves using their 'best'
> path, and the best path is seldom through a TURN server.  When we imagine
> IPv6 in our future, we don't want to force an application-level proxy
> (TURN) server on the path solely for traversing an IPv6 firewall.
>
>
>
>
>
> It seems this thread is conflating all the possible reasons /
> justifications for TURN:
>
>   * mobility
>
>   * NAT traversal (both endpoints are behind endpoint-dependent mapping
> NATs)
>
>   * firewall traversal (firewall blocks UDP)
>
>   * enhancing privacy
>
>
>
> Unfortunately the TURN server nor the endpoint really know which of those
> use-cases is desired (by the user or by the IT network administrator) or
> necessary (for the call to work at all).
>
>
>
> Dan, while I agree in principle, I doubt that a user could ever say "I
> want mobility or I want NAT traversal". I think the user only want the call
> to succeed, whatever the properties of its network point of attachment are.
>
>
>
> So what can we do?  Should the TURN server provide any and all services
> the TURN client might possibly want, as that is what a robust TURN server
> will do, and the endpoint should prefer TURN candidates over all others
> because there might be some functionality / usefulness of TURN that the
> user might gain through TURN (e.g., enhanced privacy)?
>
>
>
> -d
>
>
>
>
>
>
>
>  This seems problematic.  Perhaps we need a way to signal the desired
> use-case ("trait"), or as Justin suggests, using a different technology for
> some of these use-cases.
>
>
>
> -d
>
>
>
>
>
>
>
>
>
> On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <[e-mail]
> > wrote:
>
> Simon,
>
> Good questions - see inline below --> .
> Some more thought is required!
>
> /Karl
>
> -----Ursprungligt meddelande-----
> Från: tram [mailto:[e-mail]] För Simon Perreault
> Skickat: den 10 februari 2014 15:16
> Till: Karl Stahl; [e-mail]; [e-mail]
> Ä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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
>
>
>
>
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
>
>