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

[Justin Uberti <[e-mail]>]

On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl <[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?


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


> ****
>
> - 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 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) <
> [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" <[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****
>
> ** **
>