[rtcweb] [mmusic] Anycast discovery, Was TURN server address via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

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

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