Subject: [tram] Server discovery comments

From: Adam Roach <[email-masked]>
Date: Fri, 13 Feb 2015 17:57:17 -0600

In Hawaii, I volunteered to give feedback on the TURN server discovery 
draft (draft-ietf-tram-turn-server-discovery-01.txt). I apologize for 
the delay in getting around to this.

After some pretty deep consideration, I'm very apprehensive about the 
mechanism proposed in section 4, which is the bulk of the text in this 
document. A lot of my worries are informed by the difficulties that web 
browsers would have in using this for WebRTC, but I think the issues do 
generalize to many other uses of TURN.

The real showstopper is that the techniques for retrieving a domain name 
listed in section 4.1 provide no way for applications running on general 
purpose machines to acquire a domain name. In order:

4.1.1 DHCP: While this works for embedded devices (e.g., SIP hard 
phones), it's not something that a softphone or web browser will be able 
to access. In theory, the operating system could save this value and 
make it available to applications in general; however, this is unlikely 
to happen in the foreseeable future. It also precludes using the 
technique on any deployed operating systems, requiring us to wait for 
everyone to upgrade to newer OSes before they can use the feature.

4.1.2 IP Address: The overwhelming majority of clients who need to use 
TURN will be in private address spaces. I mean, if we didn't have NATs, 
then the need for TURN would be almost completely obviated. The approach 
of saying "use RFC7216 techniques to find your address" reduces this to 
the problem of STUN server discovery, which remains approximately as 
solved as TURN server discovery. (This approach also fails under the 
wide variety of circumstances that the PTR records cannot be delgated to 
the domain owner due to policy or technical reasons, but the other 
reasons that this won't work are so profound that this doesn't really 
matter).

4.1.3 From own identity: While this might work for SIP, if you're 
willing to make certain assumptions that aren't necessarily correct 
(namely that the organization hosting your registrar is the correct 
entity to provide your TURN server), it falls completely flat for 
WebRTC: we have no such identifier to fall back on. Maybe we could use 
the domain of the website serving up the script, but this really ties 
things together in a way that doesn't universally make sense. In the 
cases that we *do* use an identity (WebRTC has an optional identity 
service), it's very unlikely that the domain vouching for your identity 
would be willing to run your TURN traffic -- this would be akin to 
assuming that Verisign wants to run your website just because they 
issued you a cert.

And that leaves us with... nothing. There's no feasible way for a WebRTC 
browser to make use of any of these three techniques. All of which is to 
say that I don't think a service-resolution discovery technique is 
likely to be successful here, and would propose removing it from the 
document.

I do really like the anycast approach for its simplicity, and think we 
should keep it.

At the same time, I'm concerned that the proposed approaches don't allow 
for discovery of resources on the local network that can act as TURN 
relays, or of network-level administrative provisioning of TURN server 
addresses. Interestingly, both of these can be addressed by adding a 
DNS-SD mechanism (cf. RFC 6763): if a local resource (say, one 
straddling the NAT and/or firewall) can provide TURN services, it can 
advertise these directly. And, if a network administrator wishes to 
point its users at a server outside the firewall, it can advertise a 
DNS-SD record pointing at the relevant IP address. If there's enough 
interest in this approach, I'd be happy to propose text for inclusion in 
a draft.

/a

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 18 Feb 2015 22:40:06 +0000

Hi Adam,
Thanks for the review.

On 2/13/15, 3:57 PM, "Adam Roach" <[email-masked]> wrote:

>make it available to applications in general;

Windows, I believe, provides DHCP client APIs. See
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=vs.85).a
spx

> however, this is unlikely

Sure.

>likely to be successful here, and would propose removing it from the

Given that this is also meant to be a generic TURN server discovery draft
(potentially used by applications other than browsers), we wanted to
provide more than one mechanism to maximize opportunity for discovery.
Also, RFC 5928 already defines TURN resolution mechanism - nothing new
needs to be standardized for this discovery mechanism.

>I do really like the anycast approach for its simplicity, and think we

Yes. It seems like the most acceptable choice for discovery.

>addresses. 

Using anycast in the local network should work.

>Interestingly, both of these can be addressed by adding a

Sure, if there¹s interest in this approach, we can certainly include it.
Of course, we don¹t want too many discovery mechanisms :-)

-Prashanth

>
>/a
>
>_______________________________________________
>tram mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tram

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Feb 2015 17:16:16 -0600

> provide more than one mechanism to maximize opportunity for discovery.

Sure, that's great. I'm not asking that they all be applicable. I'm just 
pointing out that, right now, *none* of them are, and that's not really 
okay.

The other point that I was trying to make -- that 4.1.1 is only narrowly 
applicable, that 4.1.2 reduces an unsolved discovery problem to the 
*same* unsolved discovery problem, and that 4.1.3 will frequently have 
the wrong properties -- is probably the more important one.

Basically, I'm pretty sure that all of 4.1 is fatally flawed in a wide 
variety of ways.

If you can clarify how 4.1.1 is generally applicable or how 4.1.2 can 
bootstrap itself when the client is in an RFC 1918 address space (i.e., 
virtually always) or how 4.1.3 can deal with topologies where the SIP 
service provider is topologically in the wrong place to proxy media 
(i.e., often), then maybe there's some path forward.

Otherwise, it's not obvious that there's any way to salvage any of 
section 4.1.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2015 07:59:22 +0800

> On Feb 14, 2015, at 7:57 AM, Adam Roach <[email-masked]> wrote:
> 
> The approach of saying "use RFC7216 techniques to find your address" reduces this to the problem of STUN server discovery, which remains approximately as solved as TURN server discovery.

in fairness - STUN servers are cheap enough to run and without the latency issues, someone might just hardcode in a single stun server that used as part of the process to discover a TURN server - but that level of completing is not making me feel good

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Feb 2015 07:59:26 +0800

> And that leaves us with... nothing.

Seems about right.... one other things I wonder is given you do fine the address for a TURN server, how do you know what credentials to use ?

> There's no feasible way for a WebRTC browser to make use of any of these three techniques. All of which is to say that I don't think a service-resolution discovery technique is likely to be successful here, and would propose removing it from the document.
> 
> I do really like the anycast approach for its simplicity, and think we should keep it.
> 
> At the same time, I'm concerned that the proposed approaches don't allow for discovery of resources on the local network that can act as TURN relays, or of network-level administrative provisioning of TURN server addresses. Interestingly, both of these can be addressed by adding a DNS-SD mechanism (cf. RFC 6763): if a local resource (say, one straddling the NAT and/or firewall) can provide TURN services, it can advertise these directly. And, if a network administrator wishes to point its users at a server outside the firewall, it can advertise a DNS-SD record pointing at the relevant IP address. If there's enough interest in this approach, I'd be happy to propose text for inclusion in a draft.

I think using a well known existing mechanisms like DNS-SD is likely to work out better than many roll your own. I'd certainly be interested in seeing a DNS-SD based approach.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 19 Feb 2015 00:13:29 +0000

Hi Adam,

On 2/18/15, 3:16 PM, "Adam Roach" <[email-masked]> wrote:

>If you can clarify how 4.1.1 is generally applicable

It is not. It is best effort.

> or how 4.1.2 can 
>virtually always) 

It can¹t. As you point out, 4.1.2 does rely on techniques defined in
RFC7216, which is not quite ideal.

It¹s simpler with IPv6. TURN is required even with IPv6 for Enterprise
firewall traversal use cases discussed in
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14#
section-3.3.5 

>or how 4.1.3 can deal with topologies where the SIP
>(i.e., often),

That would be a matter of server selection, really. If the only server
that the client discovered was via this mechanism, there isn¹t much you
could do - it¹s better to have discovered something than not having
discovered anything at all. But if an application were to discover
multiple TURN servers, the application needs to choose the one that suits
best. One of the options suggested (which we¹re attempting to tackle in
the server selection draft) is to rely on ICE to help pick one with the
best dynamic properties (RTT).

If an application had the Œdomain¹ configured (or learned it using by some
other means), then it could do 4.2 straightaway.

The idea was to be able to use 4.2 (which is readily available via
RFC5928).

We could simplify all of this by suggesting that an application use 4.2 if
a domain is known/available somehow.

-Prashanth

> then maybe there's some path forward.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 20 Feb 2015 16:03:59 +1300

> Seems about right.... one other things I wonder is given you do fine the address for a TURN server, how do you know what credentials to use ?

I think that this is an important point to consider.

If we consider that there is *some* preconfiguration involved, much of
the framework might be unnecessary.

For instance, if this were reduced to finding an instance of a TURN
server, so that an enterprise user could find the server that covers
the office that they are currently in, that produces a very different
outcome.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 20 Feb 2015 08:59:34 -0500

On Thu, Feb 19, 2015 at 10:03 PM, Martin Thomson <[email-masked]>
wrote:

> > Seems about right.... one other things I wonder is given you do fine the
> address for a TURN server, how do you know what credentials to use ?
>
>

Well, the purpose of discovery is finding a "network-provided" server. It's
not just any server in the cloud. It's not unrealistic to consider that
access to a network-provided server could be "network-restricted", as in
"if you can talk to it then you're implicitly authenticated". I know that
doesn't equate authentication at all, but it would be good enough for the
use cases I can think of.

In any case, I agree that discovery must depend on no preconfiguration.

Simon

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Feb 2015 15:41:43 -0600

On 2/20/15 07:59, Simon Perreault wrote:
>
> On Thu, Feb 19, 2015 at 10:03 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 19 February 2015 at 12:59, Cullen Jennings <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Seems about right.... one other things I wonder is given you do
>     fine the address for a TURN server, how do you know what
>     credentials to use ?
>
>
> Well, the purpose of discovery is finding a "network-provided" server. 
> It's not just any server in the cloud. It's not unrealistic to 
> consider that access to a network-provided server could be 
> "network-restricted", as in "if you can talk to it then you're 
> implicitly authenticated". I know that doesn't equate authentication 
> at all, but it would be good enough for the use cases I can think of.

Thanks; I was going to make this point. Much of the rationale for 
authenticating to TURN servers is because providing TURN service can 
cost non-trivial amounts of money due to the bandwidth involved. In some 
cases, there's a secondary rationale of being able to track users to 
prevent abusive traffic proxying.

For the circumstances where auto discovery makes sense, these aren't 
really considerations.

Considering the bandwidth involved: the autodiscovery cases I'm familiar 
with here are those where the TURN server is either on customers' 
premises (i.e., "on the edge" of the network), or where it's provided by 
the same entity responsible a customer's default route. For both of 
those cases, the bandwidth involved is effectively "free" -- or, at the 
very least, no more costly than an IP router.

Similarly, the arguments for tracking traffic back to a user in these 
cases is approximately the same problem as tracking traffic back to a 
user through a NAT.

All of which is to say: in the case of autodiscovery, I don't think 
delivering credentials is really a requirement.

/a