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

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

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)

- 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

- 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:[e-mail]] 
Skickat: den 3 oktober 2013 20:59
Till: Karl Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); [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 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 <[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" <[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

 

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