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

[Justin Uberti <[e-mail]>]

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