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

["Karl Stahl" <[e-mail]>]

Karl from Ingate and Intertex just added himself to this list for exactly the purpose of the subject of Milestone 3 above 

 

I welcome this initiative that I saw yesterday after being reminded by China Mobile Research Institute who had seen the previous October discussion on the WebRTC-list, parts of which are inserted below. Large carriers have also expressed the importance of this milestone.

--------------------

We are working on this draft, will publish it next week.

-Tiru.

 

Great, please consider the input and suggestions below:

 

> -----Original Message-----

> From: tram [ <mailto:tram-bounces> mailto:tram-bounces at ietf.org] On Behalf Of Simon Perreault

> Sent: Friday, February 07, 2014 7:58 PM

> To: tram at ietf.org

> Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for

> enterprise and ISPs

> 

…

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

--- There are more reasons heard for auto-discovery of a network provided TURN server:

 

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

- 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

 

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

 

-- In my view, a TURN server is the network providers’ responsibility to provide (just like the IP address, the default gateway, the DNS etc.) – rather than the application provider’s. Our current Internet accesses may not cope with or be optimized for WebRTC usage – The NSP (or Enterprise LAN administrator) should then be able to fix the access (here by offering a TURN server). 

 

> IMHO this is also a top-priority milestone. We need to quickly have a

> mechanism that people can implement in WebRTC browsers now, while

> there is still frenetic development happening. 

--- Agree

I don't foresee actual server-

> side deployment happening quickly though. But as soon as clients are ready,

> any ISP or enterprise can deploy and immediately benefit.

- There is a definitive interest among forward SPs already, especially carriers owning the network.

(They have learned that their networks (especially mobile) seem to become data crowded no matter how much bandwidth they invest in.)

 

> I imagine that the solution will be fairly simple, spec- and implementation-

> wise. 

--- Agree that such solution should and could be found, but it is not obvious. Below you find 3 proposals (initiated by me or colleagues, where I see flaws in the two first and now only suggest the third (the Anycast mechanism). From below:

 

- 1st: … withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that you then also have to do something similar for: RA - Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and something for the mobile OTT channel – wherever DHCP is NOT the method to give you an IP address. (There were also concerns whether OSs actually supports forwards such extended DHCP information for the browser to use.)

 

- 2nd Reverse DNS-Based Service Discovery method:

Justin Uberti pointed out:  How does this get bootstrapped? That is, how is the STUN server found?

[Karl] Oops, that got lost when leaving the DHCP track, and is a problem when using DNS discovery.

(There were also hesitations of having to provision this special reverse DNS for every access.)

 

- 3rd 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.)

 

So I think we can finish this very quickly once we have a candidate

> draft. We just need authors. So I would target not long after Toronto.

> 

> Simon

 

WEB BROWSER BEHAVIOUR:

 

Network provided TURN servers will not appear over night, applications may for long provide a TURN server address, and there are exceptions where the TURN server address is preferred to be “manually” configured. It is previously suggested, and to some extent discussed, that the WebRTC browser should select the TURN server to use in the following priority order, where ICE would assure that you get some connectivity if several candidates are found and needs to be tested:

 

1) TURN server address configured in the browser by the user (special cases, normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an “admin policy template” or a WPAD method as mentioned below

3) TURN server address auto-discovered by the mechanism discussed here

4) TURN server address being supplied by the web application

 

With a good step 3), step 2) becomes obsolete since the network administrator e.g. simply can set a route in the enterprise firewall to use the Anycast mechanism instead. 

 

Even if the need for auto-discovery of the TURN server comes from WebRTC usage, a general mechanism that also can be used by SIP clients (and other protocols using TURN via ICE) is preferable. The anycast method has no application dependence, but e.g. WPAD has (a SIP Client typically does not have the luxury of a JS engine…)

 

/Karl

 

 

Från: Karl Stahl [ <mailto:[e-mail]> mailto:[e-mail]] 
Skickat: den 22 oktober 2013 16:37
Till: 'Justin Uberti'; 'Cullen Jennings (fluffy)'
Kopia: 'Bernard Aboba'; 'Harald Alvestrand'; '[e-mail]'; '[e-mail]'
Ämne: [rtcweb] [mmusic] Anycast discovery, Was TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

See my comments below. The problem of having to know a first STUN server in order to use DNS discovery, makes the suggestions below less good.

 

Another idea came up; to use anycast to allow a WebRTC browser to find a network provided TURN server (both local on a LAN or provided by a carrier). (There are some discussion around using anycast in the STUN and TURN RFCs.) This anycast-way should work both for a TURN server on a LAN and a TURN server outside the NAT/Firewall (any router in the chain can take care of an anycast address) and by the simple method below, return the available TURN server closest to the client. Finding a TURN server close to the client (the WebRTC browser) will also minimize “the turn” the real-time traffic has to take.  

 

The suggestion is to define an anycast IP address for STUN servers and:

- The network provider, offering a TURN server on his access, adds a route in his access router (or NAT/Firewall) so that the anycast address routes to his TURN/STUN server (a TURN server is an extension of STUN server, thus included in the same box).

- The TURN/STUN server is configured to respond to a binding request with a “300 Try alternate server”, that points out the same TURN/STUN server (by its real IP address, not the anycast address).

 

The WebRTC browser client would then:

- Issue a STUN binding request to the anycast address

- Issue another STUN binding request to the ALTERNATE SERVER IP address in the “300 Try alternate” response (as any client should do). 

- Interpret the received “300 Try alternate” response now having the same ALTERNATE SERVER IP address as the source IP address of that response, as an indication to use its TURN server (not the STUN server) at that address. 

 

That is the TURN server to use!

 

The only addition to existing standards is the interpretation above of the “300 Try alternate” response in the STUN RCF 5766 having the same ALTERNATE SERVER IP address as the source IP address of the response. It means: Use the TURN server at the specified address. That should be easy to clarify.

(The STUN server at the anycast address, may or may not be the same TURN/STUN server used in second binding request.) 

 

Authentication could simply be that the TURN/STUN server only is reachable from the IP addresses that the network provider want to support with the TURN server (easy for the network provider, since he is handing out those IP addresses).

 

This should be easy to provision for a carrier or a LAN administrator and trivial to try for the WebRTC browser.

 

An advantage is that the two STUN binding requests directly returns the TURN server address, whereby the following ICE process should be quick and easy. This could also be done only once when the browser is started or get a new IP address and cashed for later calls.

 

/Karl

 

PS If you wonder why not define an anycast address for a TURN server instead, read this thread from 2008:   <http://www.ietf.org/mail-archive/web/behave/current/msg03582.html> http://www.ietf.org/mail-archive/web/behave/current/msg03582.html. There, the use of anycast to a TURN server is discussed, but found not to work. (Here anycast is only used for the first request to the STUN server, where after the real address to the TURN/STUN server is used.)

 

 

 

Från: Justin Uberti [ <mailto:[e-mail]> mailto:[e-mail]] 
Skickat: den 8 oktober 2013 08:17
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy);  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]> [e-mail]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

 

On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl < <mailto:[e-mail]> [e-mail]> wrote:

So the WPAD-way of getting a network provider’s TURN server address for the real (white, global) IP address he has handed out to a user, the browser would:

- Use STUN to find the global IP address (done anyway in ICE)

 

How does this get bootstrapped? That is, how is the STUN server found?

[Karl] Oops, that got lost when leaving the DHCP track, and is a problem when using DNS discovery.

 

- Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that is not yet deployed)

- Make a URL based on the hostname from the reverse DNS lookup, e.g. from 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com

 

I was hoping we could do something simpler, such as using the ISP's configured domain search list, to determine the domain.

 [Karl] But carriers don’t push out such things, do they? And if they could do it via DHCP we are back with those problems again.

- And there find a list (in JS) of TURN server addresses for the network provider’s IP addresses

 Or would an alternative be to add your own IP address to the URL and get only your specific TURN server address?

 

Doing it at this Web level, I think we also should consider clients using ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP client be able to parse a “JS table” to find his TURN server address easily? Also, are there long time-outs to be considered when there is no h ttp://turned.myvzw.com to be found?

 

This method may be easier for a network provider to deploy (I don’t know, but for local use on a LAN I guess it is). On the other hand, the DNS-Based Service Discovery method is quick and easy for a WebRTC browser, so that may be tried as well.

 

Independent of how we find the network provided TURN server, one advantage with it is the authentication: The network provider simply sets up the TURN for usage from the IP addresses he has handed out.

 

/Karl

 

Från: Justin Uberti [mailto: <mailto:[e-mail]> [e-mail]] 
Skickat: den 3 oktober 2013 20:59
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy);  <mailto:[e-mail]> [e-mail];  <mailto:[e-mail]> [e-mail]
Ämne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

WPAD already supports DNS-based discovery (in addition to DHCP). If you have  <http://host-95-199-196-65.mobileonline.telia.com/> host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it will try to get a PAC file from  <http://wpad.mobileonline.telia.com> wpad.mobileonline.telia.com.

 

Since for all practical purposes, TURN is a "UDP proxy", I think it should be handled similar to other proxy autoconfig mechanisms.

 

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl < <mailto:[e-mail]> [e-mail]> wrote:

I happily withdraw my suggestion to use DHCP to find a network provider offered TURN server in favor of the DNS-Based Service Discovery method (inserted last below). The major problem with the DHCP usage was that you then also have to do something similar for: RA - Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and something for the mobile OTT channel – wherever DHCP is NOT the method to give you an IP address.

 

Further:

> On Thu, Sep 27, 2013 Justin Uberti wrote:

> Agree. I still think that extending PAC files to include TURN information is the right way to go.

> PAC files can already be discovered via DHCP or DNS, there is no need to reinvent this wheel.

 

>>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < <mailto:[e-mail]> [e-mail]> wrote:

>>I think we need to give some advise to the browsers vendors on what they should implement to find turn servers

 

I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file can be picked up through a URL based on the device name. Similar could work for finding a TURN server on a LAN, but what about the case with a network provider offered TURN server? The network provider hands out an IP address and wants to announce a related TURN server address: – Is there a “PAC-way” to announce it to a device on a LAN (behind a NAT/firewall)? The device must find such configuration file based on its public IP address (that he can find using STUN as in the suggestion below).

 

But generally, finding a TURN-server is a network-thing, ICE (or even TURN not using ICE), not a Web-thing, so for that reason the DNS-Based Service Discovery method is at a better level. Such method could also be used by SIP clients (even a Skype client could implement it to benefit from a real-time path with better quality, if the network provider offers such path through his TURN server).

 

The DNS-Based Service Discovery method should be easy to implement in a WebRTC browser (doing complex ICE things anyway). The question is rather how easy it is for the network provider to provision. Do they all do reverse DNS like with found with mobile operators TeliaSonera and Tele2 in Sweden? Then it should not be too difficult.

 

Or is there yet another better method to announce a TURN server address with the IP address offered?

 

/Karl

 

 

Från: [e-mail] [mailto:[e-mail]] För Bernard Aboba
Skickat: den 29 september 2013 02:41
Till: Harald Alvestrand
Kopia: [e-mail]


Ämne: Re: [rtcweb] TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

On Sep 26, 2013 8:46 PM, "Harald Alvestrand" < <mailto:[e-mail]> [e-mail]> wrote:


"So far, neither the POSIX standard nor any OS vendor has offered a generic facility to access information made available in DHCP packets."

 

[BA] The Windows DHCP client API does provide this: 

 <http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx> http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).aspx

 

In particular, the SendParams argument to the DhcpRequestParams function can be used to request a particular parameter (e.g. TURN server address), which will then be returned in the RecdParams variable.  

 

Nevertheless, I still think that using DHCP to configure the TURN server address in a browser isn't a good idea.  For one thing, since DHCP is effectively unsecured, this mechanism could be used by a rogue DHCP server to force traffic to a rogue turnserver.   Great for surveillance!

 

 

On Sep 27, 2013 1:27 AM, "Karl Stahl" < <mailto:[e-mail]> [e-mail]> wrote:

Here comes the suggestion I got from my developer that would allow a network
provider to offer his TURN server for the WebRTC browser to use. This would
require NO new DHCP-options or similar, and NO OS changes (I do realize
those should be avoided if possible...).

The idea is still, that whoever is responsible for giving a device an IP
address (the network provider or a LAN administrator) can also announce a
TURN server for the WebRTC browser to use.

The suggestion is to use RFC6763 (DNS-Based Service Discovery, see chapter
11) where the network provider (the owner of the IP address) has set up a
DNS PTR record for the TURN server in the in-addr.arpa domain.

If the device got IP 173.164.252.149, then make a query for the PTR record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the SRV record would return the actual address to the TURN server (and
you may find several for load balancing and failover I guess)

If the device is on a LAN, the IP 173.164.252.149 to query would be the WAN
IP you get via STUN in the ICE process. But if the LAN administrator
provides a local TURN server, then he also should have blocked STUN in the
firewall, and the browser should query the device's local host address (as
in the ICE procedure) and the local LAN DNS server should answer the query
to give the local TURN server address on the LAN.

Shouldn't this work to allow network provider to offer his TURN server
"automatically and generally"?

And wouldn't this work nicely for mobile devices, whenever the device is on
a "WebRTC-ready access" (actually good for everything using ICE), whether
fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network
provider hopefully offers a prioritized pipe there as one usage of this
mechanism).

Not to slow down every call setup by doing this in the ICE process, I guess
this could be done when starting the browser and when the device gets a new
IP address, to have the TURN server address ready for later use.

/Karl