Subject: [rtcweb] rtcweb-transports reference to TRAM discovery

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 15 Dec 2014 14:42:27 +0000

I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4 should include a requirement that a WebRTC Browser MUST support the TURN server discovery as described in https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00.

Andy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 15 Dec 2014 07:44:53 -0800

I do not believe that this is an appropriate requirement

-Ekr

On Mon, Dec 15, 2014 at 6:42 AM, Hutton, Andrew <[email-masked]>
wrote:
>
>  I am thinking that
> *https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4*
> <https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4>
> should include a requirement that a WebRTC Browser MUST support the TURN
> server discovery as described in
> *https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00*
> <https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00>.
>
>
> Andy
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 15 Dec 2014 10:49:19 -0500

> I do not believe that this is an appropriate requirement

Care to say why?

Thanks,
Simon

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 15 Dec 2014 15:56:26 +0000

+1 Also wondering why it is not appropriate?

F20 in the requirements draft states:

F20     The browser must support the use of STUN and TURN
           servers that are supplied by entities other than
           the web application (i.e. the network provider).

So I was thinking the need for specifying the discovery method would not be controversial.

Andy

From: Simon Perreault [mailto:[email-masked]]
Sent: 15 December 2014 15:49
To: Eric Rescorla
Cc: Hutton, Andrew; [email-masked]
Subject: Re: [rtcweb] rtcweb-transports reference to TRAM discovery

On Mon, Dec 15, 2014 at 10:44 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
I do not believe that this is an appropriate requirement

Care to say why?

Thanks,
Simon

---

From: Justin Uberti <[email-masked]>
Date: Mon, 15 Dec 2014 14:43:32 -0800

I think making it a requirement is probably premature until we have a WG
document that explains what should happen when you discover one of these
network-provided TURN servers. Once
https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is accepted as
a WG doc, we can add a requirement for support for RETURN and server
discovery.

Unclear whether it needs to be MUST-strength until we get some
implementation feedback though.

On Mon, Dec 15, 2014 at 7:56 AM, Hutton, Andrew <[email-masked]>
wrote:
> *From:* Simon Perreault [mailto:[email-masked]]
> *Sent:* 15 December 2014 15:49
> *To:* Eric Rescorla
> *Cc:* Hutton, Andrew; [email-masked]
> *Subject:* Re: [rtcweb] rtcweb-transports reference to TRAM discovery
>
>
>
>
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 15 Dec 2014 17:23:43 -0800

> So I was thinking the need for specifying the discovery method would not be controversial.

Note that draft-ietf-tram-turn-server-discovery only discovers TURN servers.  If we need to discover STUN servers, too -- and I think we do -- we need that document to expand its scope or a second document.

I recently attended a talk where Matt Peterson presented Burning Man's network.  That network assigns RFC6598 addresses to each Burning Man "camp", and their ISP provides CGN'd addresses to Burning Man.  Each camp operates its own WiFi network, and we can all reasonably assume they are using typical consumer or SMB NAPT devices for those networks (e.g., D-Link, Linksys, Ubiquity, etc.).  To avoid tromboning camp-to-camp WebRTC traffic to their ISP's CGN, they would benefit from a STUN and a TURN server within the Burning Man network.  His presentation can be found at https://www.nanog.org/meetings/nanog62/agenda (PDF and video).

-d

---

From: Justin Uberti <[email-masked]>
Date: Tue, 16 Dec 2014 09:40:18 -0800

Given that TURN servers can be used for STUN, is there a need to
autodiscover STUN-only servers?

On Mon, Dec 15, 2014 at 5:23 PM, 🔓Dan Wing <[email-masked]> wrote:
> Note that draft-ietf-tram-turn-server-discovery only discovers TURN
> servers.  If we need to discover STUN servers, too -- and I think we do --
> we need that document to expand its scope or a second document.
>
> I recently attended a talk where Matt Peterson presented Burning Man's
> network.  That network assigns RFC6598 addresses to each Burning Man
> "camp", and their ISP provides CGN'd addresses to Burning Man.  Each camp
> operates its own WiFi network, and we can all reasonably assume they are
> using typical consumer or SMB NAPT devices for those networks (e.g.,
> D-Link, Linksys, Ubiquity, etc.).  To avoid tromboning camp-to-camp WebRTC
> traffic to their ISP's CGN, they would benefit from a STUN and a TURN
> server within the Burning Man network.  His presentation can be found at
> https://www.nanog.org/meetings/nanog62/agenda (PDF and video).
>
> -d
>
>
>
> Andy
>
>
> *From:* Simon Perreault [mailto:[email-masked] <[email-masked]>]
>

---

From: 🔓Dan Wing <[email-masked]>
Date: Tue, 16 Dec 2014 11:16:55 -0800

On Dec 16, 2014, at 9:40 AM, Justin Uberti <[email-masked]> wrote:

> Given that TURN servers can be used for STUN, is there a need to autodiscover STUN-only servers?

I am not aware of spec encouraging such implementations, and I don't know if everyone implementing WebRTC clients is going to be aware that TURN servers can provide useful information about the mapped IP address.  Perhaps it just needs a few sentences in an appropriate spec?

-d

---

From: Justin Uberti <[email-masked]>
Date: Tue, 16 Dec 2014 16:56:13 -0800

Seems like something that should go into -transports (i.e. that WebRTC
clients SHOULD obtain a srflx address from the TURN server, in addition to
any provided STUN servers).

On Tue, Dec 16, 2014 at 11:16 AM, 🔓Dan Wing <[email-masked]> wrote:
> I am not aware of spec encouraging such implementations, and I don't know
> if everyone implementing WebRTC clients is going to be aware that TURN
> servers can provide useful information about the mapped IP address.
> Perhaps it just needs a few sentences in an appropriate spec?
>
> -d
>
>
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 17 Dec 2014 11:37:23 +0000

> On 16 Dec 2014, at 20:16, Dan Wing (dwing) <[email-masked]> wrote:
> 
> 
The information is buried deep down in the TURN RFC 5766 Section 6.2. It states that the allocation success response contains a XOR-MAPPED-ADDRESS attribute. (No use of SHOULD or MUST).

It also have a nice note:
"NOTE: The XOR-MAPPED-ADDRESS attribute is included in the response
 as a convenience to the client.  TURN itself does not make use of
 this value, but clients running ICE can often need this value and
 can thus avoid having to do an extra Binding transaction with some
 STUN server to learn it.”

Stating the above in some overview document will help people deploying WebRTC understand the requirements. The text in the TUNR RFC will probably only be read by TURN developers.

More importantly what is missing is text stating that deployed WebRTC turn servers should also send appropriate responses to Binding Requests; in other words act as a STUN server. Not sure about the appropriate spec, but it can go into TURNbis or some WebRTC overview document. 

.-.
Pål-Erik

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 17 Dec 2014 16:11:31 +0000

On: 17 December 2014 11:37 Pal Martinsen Wrote:
> 
> More importantly what is missing is text stating that deployed WebRTC
> turn servers should also send appropriate responses to Binding
> Requests; in other words act as a STUN server. Not sure about the
> appropriate spec, but it can go into TURNbis or some WebRTC overview
> document.
> 
> .-.

We could say in https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4 that WebRTC endpoints SHOULD make use of the address returned from a TURN server rather than doing a separate STUN binding.

Andy

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 17 Dec 2014 16:19:45 +0000

OP: 15 December 2014 22:44 Justin Uberti Wrote:
> 
> I think making it a requirement is probably premature until we have a
> WG document that explains what should happen when you discover one of
> these network-provided TURN servers.
> Once https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04 is
> accepted as a WG doc, we can add a requirement for support for RETURN
> and server discovery.
> 

-transports already states " WebRTC browsers MUST support configuration of STUN and TURN servers, both from browser configuration and from an application".

So it looks like we already have a requirement but no explanation of what should happen when both are available.

Looks like we need to adopt draft-schwartz-rtcweb-return and explain this stuff. I would certainly support that and put some effort into getting this done.

Andy

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 17 Dec 2014 18:06:57 +0100

> So it looks like we already have a requirement but no explanation of what should happen when both are available.

The last times we've talked about this, people have imagined configuring 
this via the same mechanism as configuring HTTP proxies (nonstandard 
script at a nonstandard URL).

Autodiscovery may be preferable, but it's not clear that it removes the 
need for the script-like things.

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 17 Dec 2014 13:58:58 -0800

On Dec 17, 2014, at 9:06 AM, Harald Alvestrand <[email-masked]> wrote:

> The last times we've talked about this, people have imagined configuring this via the same mechanism as configuring HTTP proxies (nonstandard script at a nonstandard URL).
> 
> Autodiscovery may be preferable, but it's not clear that it removes the need for the script-like things.

If there is, gathering that requirement seems important.  Mark Nottingham was beginning an effort around WPAD standardization (or something that resembled it).  CC'ing him in case there is useful status on that front.

-d

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 18 Dec 2014 17:23:37 +0000

It seems that in the mobile case and many residential cases, doing that draft would allow a service provider to force all the traffic through a TURN server of the service providers choosing. Am I reading this correctly because I am pretty sure I would not be in favor of that.

> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew <[email-masked]> wrote:
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 18 Dec 2014 18:39:18 +0000

https://tools.ietf.org/id/draft-ietf-tram-turn-server-discovery-00.txt makes the claim that it is needed for "WebRTC usage" and in fact claims that it is needed by WebRTC "immediately".

I was just pointing out that if this is the case then it should be referenced from a RTCWEB draft.

If you think the discovery mechanism is not suitable for WebRTC usage then please make that comment to the TRAM WG list.

Andy

> -----Original Message-----
> From: Cullen Jennings (fluffy) [mailto:[email-masked]]
> Sent: 18 December 2014 17:24
> To: Hutton, Andrew
> Cc: [email-masked]
> It seems that in the mobile case and many residential cases, doing that
> draft would allow a service provider to force all the traffic through a
> TURN server of the service providers choosing. Am I reading this
> correctly because I am pretty sure I would not be in favor of that.
> 
> 
> > I am thinking that https://tools.ietf.org/html/draft-ietf-rtcweb-
> transports-07#section-3.4 should include a requirement that a WebRTC
> Browser MUST support the TURN server discovery as described in
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00.
> >
> >
> > Andy
> >

---

From: Adam Roach <[email-masked]>
Date: Thu, 18 Dec 2014 14:40:03 -0600

So, I think it's important that we have some way to encourage deployment 
of TURN servers both in the ISPs, and as part of firewalls (both 
residential and enterprise). By putting TURN in paths that are already 
going to bear the traffic in question, the overall cost associated with 
calls goes down, and call quality (latency, loss) improves.

I'm sympathetic to the position that we don't want to give these 
entities specific hooks to force specific servers to be inserted into 
the flow. We need to find a balance here: something that allows the 
relevant entities to deploy and advertise such servers; something that 
allows WebRTC applications to discover and use them; and something that 
puts the ultimate decision in the hands of the users. Off the top of my 
head, adding a browser API that allows applications to  to retrieve 
these servers and elect to use them if it wants to would serve part of 
the purpose; giving users a means by which they can instruct the browser 
not to return such a list would serve the remainder.

But that's all kind of orthogonal to the IETF issues: if we're going to 
do *anything* in this space, we need the discovery mechanisms.

/a

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 18 Dec 2014 21:19:37 +0000

The priority order that makes most sense to me is:

1. user override
2. app override
3. auto discovery
4. app fallback
5. user fallback

If any override is configured by the user or app, do not perform auto
discovery, stop here.

If auto discovery fails, use a fallback configured by the app or user.

There is a big difference between an override and a fallback, so both seem
necessary.

Obviously, we need some mechanism for 3 as Adam said, in case it needs to
be invoked.

Mo

On 12/18/14, 3:40 PM, Adam Roach <[email-masked]> wrote:

/a

On 12/18/14 11:23, Cullen Jennings (fluffy) wrote:
>>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.4

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 19 Dec 2014 01:20:16 +0000

> From: rtcweb [mailto:[email-masked]] On Behalf Of Mo Zanaty
> (mzanaty)
> Sent: Friday, December 19, 2014 2:50 AM
> To: Adam Roach; Cullen Jennings (fluffy); Hutton, Andrew
> Cc: [email-masked]

TURN server selection is discussed in https://tools.ietf.org/html/draft-patil-tram-turn-serv-selection-00

-Tiru

> So, I think it's important that we have some way to encourage deployment of
> TURN servers both in the ISPs, and as part of firewalls (both residential and
> enterprise). By putting TURN in paths that are already going to bear the
> traffic in question, the overall cost associated with calls goes down, and call
> quality (latency, loss) improves.
> 
> I'm sympathetic to the position that we don't want to give these entities
> specific hooks to force specific servers to be inserted into the flow. We need
> to find a balance here: something that allows the relevant entities to deploy
> and advertise such servers; something that allows WebRTC applications to
> discover and use them; and something that puts the ultimate decision in the
> hands of the users. Off the top of my head, adding a browser API that allows
> applications to  to retrieve these servers and elect to use them if it wants to
> would serve part of the purpose; giving users a means by which they can
> instruct the browser not to return such a list would serve the remainder.
> 
> But that's all kind of orthogonal to the IETF issues: if we're going to do
> *anything* in this space, we need the discovery mechanisms.
> 
> /a
> 
> > It seems that in the mobile case and many residential cases, doing
> >that draft would allow a service provider to force all the traffic
> >through a TURN server of the service providers choosing. Am I reading
> >this correctly because I am pretty sure I would not be in favor of that.
> >
> >
> >> On Dec 15, 2014, at 7:42 AM, Hutton, Andrew
> <[email-masked]>
> >>wrote:
> >>
> >> I am thinking that
> >>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07#section-3.
> >>4 should include a requirement that a WebRTC Browser MUST support the
> >>TURN server discovery as described in

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Dec 2014 10:15:09 +0000

+1 to Adam and Mo's comments which make a lot of sense to me.

I agree we need to enable the use of TURN servers which provide the best user experience so enabling the use of TURN servers close to the clients makes sense.  At the same time there are some security considerations which we can provide some guidance on so would it make sense to do the following?

1. Add a reference to draft-ietf-tram-turn-server-discovery in -transports- and make it a SHOULD/MAY/MUST implement (I prefer MUST but I know others probably don't). 

2. Add some text either inline or in the security considerations about the concerns and the need for user/app override. 

By the way I am not sure we need the app override if we consider draft-schwartz-rtcweb-return part of the solution.

Andy

> From: Mo Zanaty (mzanaty) [mailto:[email-masked]]
> Sent: 18 December 2014 21:20
> that

---

From: Benjamin Schwartz <[email-masked]>
Date: Fri, 19 Dec 2014 10:25:33 -0500

To reiterate, the TRAM draft doesn't specify what WebRTC should actually do
with the discovered TURN server(s).  RETURN (
https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) attempts to
fill in the details, and also resolve questions about priority of different
settings, etc.

Comments on the RETURN draft are appreciated, of couse.

On Fri, Dec 19, 2014 at 5:15 AM, Hutton, Andrew <[email-masked]>
wrote:

> I agree we need to enable the use of TURN servers which provide the best
> user experience so enabling the use of TURN servers close to the clients
> makes sense.  At the same time there are some security considerations which
> we can provide some guidance on so would it make sense to do the following?
>
> 1. Add a reference to draft-ietf-tram-turn-server-discovery in
> -transports- and make it a SHOULD/MAY/MUST implement (I prefer MUST but I
> know others probably don't).
>
> 2. Add some text either inline or in the security considerations about the
> concerns and the need for user/app override.
>
> By the way I am not sure we need the app override if we consider
> draft-schwartz-rtcweb-return part of the solution.
>
> Andy
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 19 Dec 2014 22:28:19 +0530

Few cents ..

I tend to agree with Cullen's sentiment since as a end user I don't want to
end up with service provider lock-in when using a TURN server.

Such lock-ins might not be a bad option but It need not be enforced by
design.

OTOH  I am not sure how effective will be a typical not-so-technical
end-user's decision making in choosing one turn server over the other.

But having flexibility is not a bad idea , thus i feel the spec needs to
just say the plausible options but mandating with MUST might not be what we
need here.

Cheers
Suhas

On Fri, Dec 19, 2014 at 8:55 PM, Benjamin Schwartz <[email-masked]>
wrote:

> To reiterate, the TRAM draft doesn't specify what WebRTC should actually
> do with the discovered TURN server(s).  RETURN (
> https://datatracker.ietf.org/doc/draft-schwartz-rtcweb-return/) attempts
> to fill in the details, and also resolve questions about priority of
> different settings, etc.
>
>> 2. Add some text either inline or in the security considerations about
>> the concerns and the need for user/app override.
>>

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Dec 2014 11:06:11 -0600

On 12/19/14 10:58, Suhas Nandakumar wrote:
> But having flexibility is not a bad idea , thus i feel the spec needs 
> to just say the plausible options but mandating with MUST might not be 
> what we need here.

I think you're falling into the trap of not distinguishing between "MUST 
implement" and "MUST use".

I'm not necessarily arguing that this is a "MUST implement" requirement 
on browsers[1], but if we're going to figure out what makes sense, we 
need to think about this properly.

/a

____
[1] I'd love to see this kind of discovery deployed universally, since I 
believe it contributes to the long-term success of WebRTC, but I'd like 
to hear other people's arguments for/against doing so before taking a 
concrete position.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 19 Dec 2014 20:28:41 +0000

Adam, I think you are I are mostly saying the same thing. Things like there need to be incentives to deploy, the browser should tell the applications about available servers, and so on ...

There are probably a bunch of ways to do this - for example all the arguments being made about TURN server same equally true of HTTP socks servers yet my SP can't force all my traffic via a HTTP proxy of it's choosing. So I don't think claiming the privacy problems  is orthogonal to the the IETF issues is really OK. The privacy issues are pretty important. As you suggest, I'm OK with browser tells applications about servers that are available but I would not be keen on browser automatically choosing to use those. That creates the type of incentives that it's fine for the SP to block traffic that does not go through the approved (and inherently quality reducing) TURN server. 

It's also important to have solutions that makes business sense. Running TURN server is often sort of expensive from the bandwidth point of view so typically the TURN servers have a relation with the actual application to enable them - it's not just that someone is going to provide TURN servers for  for all webrtc applications in all networks. It's going to be a bit more complicated than that and that in helps drive some of the requirements for this. A way where applications can discover TURN servers that they are authorized to use if far more appealing to me. 

The privacy implications and bandwidth usage implications are very different for STUN and TURN and thus I think the appropriate discovery mechanics for them are likely different. At least the requirements for the mechanisms are different even if there is one mechanism that meets all the requirements. 

As tempting as is sounds to leave the selection up to the user, I don't think that will work. I think it needs to be up to the application running on the browser with perhaps the possibility to be overridden by user. 

There is a lot of ways to do discovery  and some of them are already supported so I think we should figure out what we want then work on which of various discovery approaches help with that. 

> On Dec 18, 2014, at 1:40 PM, Adam Roach <[email-masked]> wrote:
> 
> So, I think it's important that we have some way to encourage deployment of TURN servers both in the ISPs, and as part of firewalls (both residential and enterprise). By putting TURN in paths that are already going to bear the traffic in question, the overall cost associated with calls goes down, and call quality (latency, loss) improves.
> 
> I'm sympathetic to the position that we don't want to give these entities specific hooks to force specific servers to be inserted into the flow. We need to find a balance here: something that allows the relevant entities to deploy and advertise such servers; something that allows WebRTC applications to discover and use them; and something that puts the ultimate decision in the hands of the users. Off the top of my head, adding a browser API that allows applications to  to retrieve these servers and elect to use them if it wants to would serve part of the purpose; giving users a means by which they can instruct the browser not to return such a list would serve the remainder.
> 
> But that's all kind of orthogonal to the IETF issues: if we're going to do *anything* in this space, we need the discovery mechanisms.
> 
> /a
>