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.  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